Wireshark is an immensely useful tool. Although 99.999% of its users likely only use it for sniffing Ethernet IP traffic, it is a flexible framework within which one can write custom dissectors to handle just about any kind of packet traffic. For debugging some custom embedded solutions, I've found it to be very useful; it is less time-consuming than writing an analysis tool from scratch.
This presentation discusses something not dissimilar from what I've done for a few years.
Similar to the presentation, what I've been doing is to write a capture tool that writes pcap format captures to a file or FIFO. (The former is straightforward in both Windows and Linux; the latter is doable in both as well, but is less straightforward.) There are sixteen pcap link types, beginning with LINKTYPE_USER0/ DLT_USER0 that are reserved for such a purpose.
However, as a personal project, I aspired to a "driver-less" USB solution where one could just plug in a device and start capturing. However, this effort has not proven fruitful.
USB Network Adapters fall into three categories:
1) RNDIS, a Microsoft implementation supported in Windows and Linux, but not (officially) by MacOS
2) CDC ECM, a USB specification supported by Linux and MacOS, but not Windows
3) custom proprietary implementations, requiring custom drivers for each OS
#3 does not offer any benefit, as the intent of the exercise was to be "driver-less". So, I tried the RNDIS approach, as not supporting Windows was a non-starter.
What seemed very encouraging about the RNDIS approach was that the protocol enumerates what type of network connection the adapter is connected it. It does so via three quantities: OID_GEN_PHYSICAL_MEDIUM, OID_GEN_MEDIA_SUPPORTED, and OID_GEN_MEDIA_IN_USE. I was quite encouraged by this.
Alas, that enthusiasm was subsequently dashed. In my testing I found that for Linux, if the type reported by the adapter was something other than one of the Linux blessed types, it would not allow the adapter to be enumerated. Further, if one of the known types was reported, a modern Linux distribution tries to inundate the adapter with every manner of DHCP IPv4, DHCP IPv6, and network discovery method known to humankind.
Windows is even worse. For both Windows XP and 7, the driver doesn't even seem to care what the adapter reports. It just blindly assumes that it is an 802.3 adapter and tries to use it as such.
back to main page contact