Wireshark-users: Re: [Wireshark-users] "strange" Fragmented ip packet
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 14 Apr 2008 12:48:36 -0700
Velissarios Lataris wrote:

Hi,
So presumably that device looks like an Ethernet to the operating system. 

Wireshark sees the device's interface as a PPP/SLIP interface. The
device is connected via usb2 to the system as a dial up modem. Dial up
connections are established to a umts network.
Are you capturing traffic to and from the machine on which you're running Wireshark? If so, what OS are you running on that 
machine?


I'm capturing both,  os is windows xp sp2. Hw is this connected to this
issue?
Because it means that even PPP/SLIP interfaces will look like Ethernets to WinPcap and thus to Wireshark.
Yes, that could be the problem, although I'd *expect* that if the packet weren't received correctly some checksum/CRC at the GPRS, EDGE, or UMTS layer would catch that, and the E220 wouldn't have supplied the packet to the host in the first place. 

I take it wireshark in this case is capturing what the device is sending
to the system,


Yes.


which could be different from what is actually coming
through the air interface and received from the e220.  So you are right
to assume that this packet shouldn't be displayed (should have been
rejected by the device) and thus this is an issue with the device.
True *if* the packet wasn't a valid packet; it might also have been a valid packet that wasn't an IP packet. 


It might be that the adapter or the driver is constructing a fake
Ethernet field, and is assuming that *all* traffic is IP traffic, which
might explain why the Ethernet protocol type field is valid.


I'm not exactly certain I understand what you mean here!
What I mean is that the adapter is, I think, receiving PPP packets over GPRS/EDGE/whatever UMTS calls its packet-switched service, and either supplying PPP packets to the host, which the driver (or Microsoft's NDISWAN code) is converting to Ethernet packets, or supplying Ethernet packets to the host.
If the code (on the adapter, in the driver, or in NDISWAN) is assuming that *all* packets it's supplied are IP packets, rather than looking at the PPP header to see what type of packet it's been handed, it would put hex 0800 in the type field of the fake Ethernet header it constructs, even if the packet is *not* an Ethernet packet; Wireshark will then attempt to dissect the packet as an IP packet, and find that it looks wrong. 

From what I've read from looking for

    huawei e220 linux
with Google, the E220 looks like a USB serial device, so it *probably* supplies PPP packets, not Ethernet packets, to the host. I would be surprised in NDISWAN naively converted incoming PPP packets to IP-over-Ethernet packets, so I suspect that either
1) this is a bad packet that the adapter shouldn't have supplied to the host 

or
2) Huawei didn't know about NDISWAN and wrote their own code to convert PPP packets to Ethernet packets, and it assumes all PPP packets are IP packets. Whether the packets in question are packets that are not received correctly, or are packets that *were* received correctly but just aren't IP packets, is another question; I don't know which is the case.