[Guy Harris <guy@xxxxxxxxxxxx>]

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.