ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] 802.15.4 Decode

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 23 Sep 2008 18:49:28 -0700

On Sep 23, 2008, at 6:19 PM, Colin O'Flynn wrote:

Hi,

So, in that mode, can you do IP-over-802.15.4, or is that a sniff- only
mode

In that mode it's a sniffer only.

As I suspected.

If the host ever had 6lowpan

(...the Wikipedia page for which says "IPv6 is the work horse for data delivery for wired networks — the Internet." - but it wasn't the work horse that got that page to me over the Internet; that was Boring Old IPv4. :-) That's the case for *most* of the stuff I get over the Internet, both at work, where it's wired, and at home, where the first hop is wireless. But I digress....)

The device does enumerate a serial port at the same time as the network interface though, so it would be possible to do the sniffing at the same time
as the IPv6 is running possibly.


And on what OSes are you doing this? (I.e., what host OS's networking
stacks are getting these packets?)

Both Linux and Windows. The USB Network device is using the "remote NDIS" (RNDIS) protocol so that it will work on both Linux and Windows with built-in
drivers.

That would make it difficult to have it supply raw 802.15.4 packets - *maybe* the Linux networking stack could handle them (the 2.6.26.5 kernel doesn't appear to have an ARPHRD_ link-layer type for 802.15.4), but I doubt the Windows stack could.

So your options would be either

1) when in raw mode, supply the raw packets with a fake Ethernet header, as you're doing now.

or

	2) supply the raw packets via the emulated serial port.

The first of those would require Wireshark to be modified - the simplest modification would be to have the 802.15.4 dissector register itself with the "ethertype" dissector table with whatever special Ethertype value you used, either hardwired or with a preference setting.

The second of those might require driver changes (to support a device from which to get the raw packets), and would definitely require libpcap/WinPcap changes (to read from the serial port), but would require no Wireshark changes.

The second is the cleaner solution, but is probably more work.