Capturing FC frames with wiresharka project by ptesarik AFAIK, wireshark is the best Linux tool for analyzing network traffic. Primarily intended for Ethernet networks, there is now also support for very different protocols (e.g. USB). Sadly, there is no support for fibre channel, most likely because there is even no infrastructure in the kernel. I doubt I could write the complete stack within just one week. The result should be a clear plan of what needs to be done on each level and a proof-of-concept implementation of at least some parts. 
|
Investigate EtherCAT fieldbusan idea by a_faerber The Infineon XMC4800 EtherCAT Relax Kit microcontroller board has two EtherCAT RJ45 connectors. I'd like to investigate using openSUSE (or SLES) as EtherCAT master. |
Analyze the security of Linux HTTPS connections and monitor the traffic of "smart" devicesan invention by thardeck I have Raspberry Pi with WLAN and an additional network module which can be run as a WIFI access point. Plan
|
layer3 cloudan idea by bmwiedemann One of the things that make deploying SUSE OpenStack Cloud hard is that it assumes that you have a layer2 network to do DHCP/PXE-boot, run your SDN on etc. We should explore how easy it is to deploy a cloud across machines that can ping each other (OSI layer 3), but are in different networks - e.g a NUE desktop machine, a prague machine and a server in the NUE cloud network. |
netlink interface for ethtoola project by mkubecek There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started. The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16). 
|
DPHAT: Data Plane Health Assessment Tool For Cloud Networking Technologya project by rtidwell A common challenge for OpenStack and K8S deployments is debugging the network when things go awry. The aim of DPHAT is to provide operators of cloud infrastructure with tooling that can analyze the environment and supply the following: - Feedback that the environment is in a healthy operational state 
|
ethtool ops for netdevsima project by mkubecek This can be seen as a subproject of ethtool netlink interface but from the technical view it's independent. Every new piece of software is going to be buggy and with frequent changes and rewrites, new regressions are introduced. Automated selftests can help a lot but as ethtool deals with hardware devices, we do not want these tests to depend on a specific hardware. The netdevsim driver was created as a virtual device which (unlike e.g. dummy) cannot be used for actual network traffic but implements various configuration interfaces so that it can be used for their (automated) testing.
|
Hammer an Envoy service mesh onto a SAP S4/HANA landscape and watch everything explode.a project by STorresi Although CNCF projects are almost exclusively related to Linux containers, some ideas, like wrapping all the services into network proxies to create a distributed data-plane and enable true observability, could perhaps be explored for some kind of backport in complex legacy distributed systems, like... say... S4/HANA?! I don't even know if this is feasible, but trying won't hurt... just stand at a safe distance from the cluster! 
|
Give avahi some lovea project by e_bischoff Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour. The project is to dig into avahi source code to modernize it if possible and fix bugs. 
|
make "predictable network interface names" more predictablean idea by mkubecek Since the so-called "predictable names" for network interfaces were introduced, the concept and mainly its implementation has been a target of a lot of critique and sometimes even hate. On the other hand, similar idea works reasonably well for block devices. In my opinion, the main reason why "predictable names" reception was not nearly as good as for block devices is the difference in how the implementation works. For block devices, the device name provided by kernel is preserved and other names based on multiple naming schemes (by path, by UUID, by various device identifiers) are created as symlinks so that all of them (including the original kernel one) can be used simultaneously. On the other hand, network interface has only one name and as it is not represented by a file, symlinks cannot be used for aliases. Therefore even if there are multiple naming schemes (e.g. based on BIOS enumeration, bus address etc.), only one of them can be used for each network device and it's rather unpredictable which one is it going to be. Moreover, some of the generated names are rather long, ugly and inconveninent and unlike with block devices, one cannot just ignore them and use a different name (e.g. one provided by kernel). |
Integrate Firecracker (microVMs) with a Cloud Foundry app runtime schedulera project by tassis DescriptionFirecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services. 
|
Sharing logic between desktop and web based applications through WASMan invention by IGonzalezSosa Project DescriptionA few months ago, the YaST team released cockpit-wicked. Compared to YaST, this module contains a pretty simple data model, but there is still some duplication with YaST logic. 
|
Get familiar with moodle.opensuse.org by creating the training "Network basics"a project by mstrigl Create a course in moodle.opensuse.orgMoodle is the world's most popular learning management system. Start creating your online learning site in minutes! 
|
Test drive some Kubernetes network pluginsan idea by doreilly Project DescriptionEvaluate some CNI plugins [1] |
multithreaded network benchmarkan invention by mkubecek Project DescriptionThere are multiple network benchmark tools already, most popular probably being netperf and iperf. Each of them has its pros and cons but the biggest drawback probably is that netperf runs only one connection (flow) and while iperf can use multiple connections, it still runs in a single thread. For benchmarking of contemporary fast networks like 40Gb/s or 100Gb/s ethernet, this can be a severe limitation as the performance is often CPU bound. Even on 10Gb/s ethernet, we are often unable to saturate the medium if tunneling or complex packet processing is involved.
|
|
mrouted: Join multicast groups via IPIP or GRE tunnelsa project by e_bischoff Goal for this Hackweekmrouted is the de facto standard for DVMRP multicast routing on Linux and other Unices.
|
|
Exploring DPDK within containersa project by paolodepa Project DescriptionContainerization is here to stay and seems to be the next big thing also in the upcoming OSes releases. 
|
grog
unbound resolvconf
