1 Open projects for the netsniff-ng toolkit are listed here. However, those are
2 current ideas for projects that came to our mind. We are also open for blue-sky
3 proposals that are not included in this list. If you are interested in
4 participation, let us know! We are always looking forward to get help in
8 - Better protocol support for netsniff-ng's dissector: Until now, netsniff-ng
9 only supports a small subsets of protocols with rather low-level information
10 output. The aim is to improve currently supported protocols and add new
11 important protocols that should be shipped with netsniff-ng.
13 - Required skills: C, Protocols
14 - Difficulty: Easy - Medium
17 - Extensive testing (with eventual code fixing) and performance evaluation:
18 The three more complex projects of the toolkit need a throughout evaluation
19 of all their features, if they work stable under stress, if the features do
20 what they should do. In error cases, code must be fixed of course. Also,
21 the three tools should be evaluated and reviewed regarding performance (pps),
22 if optimizations can be made in the critical path. Optimizations should be
23 compared in regard to packets per second before and after the change.
24 - Tool: netsniff-ng, trafgen (both with Jumbo frames), curvetun
25 - Required skills: Testing, C
26 - Difficulty: Easy - Hard
29 - Reduce general code size, refactor, improve code (i.e. rewrite parsers):
30 Some of the toolkit's code is quite messy and some code totally unused.
31 The aim is to find such code sections and improve them in order to reduce
32 overall code size, and improve readability and software design without
33 introducing a decrease of performance.
36 - Difficulty: Easy - Hard
39 - Improve manpages, write a user's guide, maybe technical paper: Until now,
40 the focus on the toolkit was the implementation, but not that intensively
41 on the documentation. The latter is even more important for potential users.
42 Hence, manpages should be improved in depth, examples should be given and
43 a more complex documentation or technical paper should be written in LaTeX.
45 - Required skills: POD, Manpages, LaTeX
46 - Difficulty: Easy - Medium
49 - TPACKETv2 (TPACKETv3) support: Right now, the toolkit uses the TPACKETv1
50 API for the RX_RING and TX_RING of the Linux kernel. We would like to know
51 if there's a potential benefit of migrating the code to TPACKETv2 or
52 TPACKETv3 (if released). If so, then the current code should be migrated
53 to the more up-to-date TPACKET version including a review of a potential
54 performance benefit or degradation.
55 - Tool: netsniff-ng, trafgen
57 - Difficulty: Easy - Medium
60 - PCAP anonymization support: Similar to scrub-tcpdump, we would like to see
61 a possibility for packet anonymization in netsniff-ng. This means, that the
62 resulting pcap file can be used for collaboration or released without
63 corrupting anonymity of the network represented by the capture flow.
64 (http://scrub-tcpdump.sourceforge.net/index.php)
67 - Difficulty: Easy - Medium
70 - Improve ifpps with things like 'Gnuplot support', 'Power usage / temperature',
71 'Colorized output': ifpps is a useful tool to monitor the system and
72 especially the network subsystem. It could be even more useful if it has
73 features like exporting data into Gnuplot or RRD files, like adding more
74 sensor data output like power states or temperature values, and additionally
75 it could also have a colored output just like flowtop.
77 - Required skills: C, Gnuplot, Procfs
78 - Difficulty: Easy - Medium
81 - Add IPv6 support: ashunt and flowtop have been implemented in IPv4 with
82 stubs for IPv6 code. IPv6 support should be implemented and tested
83 intensively. Possibly, existing code needs to be improved and refactored
84 for IPv6 integration. IPv6 support in curvetun already exists. However,
85 it still needs throughout testing.
86 - Tool: ashunt, flowtop, curvetun (testing)
91 - Implement Packet departure timing models (i.e. exponential, uniform, cauchy,
92 normal, pareto distributed) and other packet scheduling behaviours (MB/s,
93 ...), ideally as a plugin architecture for trafgen. Until now, there are
94 only two working modes in trafgen: high-speed and a static inter-departure
95 timing gap. Hence, such features need to be added for a traffic generator.
98 - Difficulty: Medium - Hard
101 - Unit test preparation and integration for the whole toolkit: Right now, the
102 netsniff-ng toolkit does not have a suite with test cases, although
103 netsniff-ng highly needs a test suite. This project's intention is to
104 evaluate which test frameworks are appropriate for the toolkit, to integrate
105 those frameworks with an initial set of unit tests for each framework.
107 - Required skills: C, Shell, Sharness?, Coccinelle?, CMake?
108 - Difficulty: Medium - Hard
111 - Interactive txf config generator with a set of supported protocols and
112 support for packet distribution models (IMIX, Cisco, ...): We would like
113 to see an interactive txf generator, so that a set of supported protocols
114 can be used to generate full packets in byte format. For instance,
115 protocols such as VLAN, MPLS, BPDU, IGMP, DNS, ARP, ICMP, HTTP, SIP,
116 IPv4 / IPv6, UDP, TCP. The Cisco-like libcli can be used for the UI.
117 (http://code.google.com/p/libcli/)
119 - Required skills: C, Protocols
123 - PCAP-ng support: The PCAP-ng format is the next-generation of PCAP as
124 described in (http://wiki.wireshark.org/Development/PcapNg). We would like
125 to support both, the old PCAP and the new PCAP-ng format. Hence, we're
126 looking for PCAP-ng support in netsniff-ng. Design and implement it
127 appropriately, so that both formats can be used and that the source code
128 stays clear and doesn't introduce artificial software layers that can
129 cause a performance bottleneck.
135 - Take Qualcomm's uio-dma and uio-ixgbe and integrate it next to the current
136 (driver-independant) zero-copy approach into netsniff-ng and trafgen, so that
137 the user can choose which approach to use. We assume a performance gain from
138 uio-dma and uio-ixgbe since it directly maps DMA mem which is not necessarily
139 the case in RX_RING / TX_RING. Hence, it could give a good speed up for both
140 tools (under the drawback that it will be driver-dependant).
141 (https://opensource.qualcomm.com/gitphp/index.php)
142 - Tool: netsniff-ng, trafgen
143 - Required skills: C, Linux Kernel, NIC for ixgbe driver
144 - Difficulty: Hard - Very Hard
147 - Better obfuscation method of curvetun's protocol to make it hard for DPIs
148 to detect curvetun: Right now, curvetun might be quite hard to detect, but
149 with a little effort, it is still possible for DPIs. Find a way to obfuscate
150 the protocol, so that _either_ it is not distinguishable from random byte
151 garbage _or_ find possible ways to use steganography, thus the encrypted
152 payload stream is hidden in real-world traffic.
155 - Difficulty: Very Hard
158 - Perform a security review of curvetun: The implementation of curvetun is
159 a proof-of-concept and the origin for the implementation was out of interest.
160 Since this tool is useful for real-world deployment, we need security reviews
161 to make sure that the deployment would be appropriate. Hence, this project
162 concentrates on code reviews and improvement regaring security of curvetun.
164 - Required skills: C, Crypto
165 - Difficulty: Very Hard
168 - Design and implement a high-level packet filtering language that compiles
169 to bpf code: Right now, filters for netsniff-ng needs to be implemented
170 with our bpfc compiler (language: http://netsniff-ng.org/bpf.pdf), or
171 generated with ``tcpdump -dd <filter>''. We would like a higher level
172 filter description language that transforms the resulting filter into
173 the bpf language that can be translated by our bpfc compiler.
174 - Tool: either inclusion in bpfc or a new one
175 - Required skills: Haskell or C
176 - Difficulty: Very Hard
179 - Implement packet capture, replay and traffic generation for other
180 hardware types (USB, Bluetooth, GSM?, ...): netsniff-ng and trafgen
181 supports only Ethernet, but there are a lot of other interesting
182 hardware types that we could support. Very exciting would be GSM,
183 thus it could interact with Harald Welte's Open Source GSM Baseband
184 software implementation (http://bb.osmocom.org/). Other possible
185 layers are Bluetooth or USB, for instance. Extend netsniff-ng's and
186 trafgen's architecture, so that new hardware types can easily be
187 added with out a great performance loss and implement standard
188 functionality of netsniff-ng/trafgen similar to Ethernet on those
190 - Tool: netsniff-ng, trafgen (tools need to be extended)
192 - Difficulty: Very Hard
195 - Design and implement partial reconfigurable hardware for traffic
196 generation under 10 Gbps, build an interface to trafgen and offload
197 heavily used packets for packet generation (and transmission) in
198 hardware, less heavily used in software (use NetFPGA). Evaluate the
201 - Required skills: C, VHDL (plus NetFPGA board required)
202 - Difficulty: Very Hard