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.
