Wireshark-bugs: [Wireshark-bugs] [Bug 8229] Need a way to treat alleged Ethernet frames as raw I
Guy Harris
changed
bug 8229
| What |
Removed |
Added |
| Summary |
"Decode as..." for entire frames required
|
Need a way to treat alleged Ethernet frames as raw IP frames to work around a WinPcap bug
|
| Severity |
Major
|
Enhancement
|
Comment # 2
on bug 8229
from Guy Harris
There are NICs (which aren't necessarily "cards" - these days, only servers and
the occasional desktop machine have network interface *cards*; most of them
just have network interface *controllers* that are on the motherboard) and
there are "network interfaces". The former are hardware devices; the latter
are software objects that show up in the network stack.
What libpcap/WinPcap handle are network interfaces, not all of which
necessarily have NICs associated with them. I don't think the tunneling
adapter (or adapters - my Windows 7 (virtual) machine reports two "Tunnel
adapter"s in "ipconfig/all") is a NIC; it's a software-defined network
interface.
This is either a problem with the software that implements the adapter or with
WinPcap - either the software is providing the wrong NdisMedium value when
WinPcap asks for it, or WinPcap is mapping that NdisMedium value to the wrong
DLT_ value.
Currently, WinPcap maps all unknown NdisMedium values to DLT_EN10MB, for
Ethernet, which is probably Not A Good Idea; it would be better for it to fail
to open the interface, and thus note that there's an NdisMedium that WinPcap
isn't handling, and it needs to be fixed to handle it.
At least this version of the list of NdisMedium values:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565910(v=vs.85).aspx
includes NdisMediumTunnel, and WinPcap has no knowledge of that (it was
introduced in Vista, with NDIS 6, but WinPcap hasn't had any changes made to it
for NDIS 6); I suspect the problem here is that WinPcap is, therefore, mapping
it to DLT_EN10MB rather than DLT_RAW (which is the correct DLT_ value for "raw
IP".
So this is a WinPcap bug.
Wireshark can only provide a workaround. There's already a preference setting
for the Ethernet dissector, to have it call the DOCSIS dissector, as a way to
work around the lack of a feature in older versions of libpcap; we could also
change the preference to support calling the IPv4 or IPv6 dissector, to work
around this WinPcap bug.
I'm classifying it as an enhancement, because the actual bug is in a separate
piece of software.
You are receiving this mail because:
- You are watching all bug changes.
