> Thats the thing - there were not any protocols on top of LLC (for
> incomming) that i could see in the capture (using the ethereal default
> length) - thats why I thought it was odd. And for the outgoing packets the
> capture does not show an LLC layer under the TCP etc...
>
> here is an example outgoing capture
>
> source dest
> 168.192.1.100 213.189.207.68
> Frame 10
> Ethernet II
> IP
> TCP
>
> and an example incomming cature
>
> source dest
> 00:04:5a:ce:3a:99 00:02:2d:2c:f7:24
> Frame 11
> IEEE 802.3 Ethernet
> Logical-Link Control
> Data
(I assume by "outgoing capture" and "incoming capture" you mean
"outgoing packet" and "incoming packet" - a packet capture isn't
inherently "incoming" or "outgoing".)
802.3 Ethernet?
Your driver has decided to supply confused data to WinPcap via NDIS, I
suspect.
802.11 drivers on various OSes appear to pretend to be Ethernet drivers,
perhaps in order to fit better into existing networking stacks; 802.11,
however, is *not* "wireless Ethernet" - 802.11 packets don't have
Ethernet headers, they have 802.11 headers, which don't have an
Ethernet-style packet type field, so you need 802.2 LLC for that, and
often need SNAP as well (to put the Ethernet-style packet type field
in).
The incoming packet has an 802.3 header rather than an Ethernet header;
both 802.3 and Ethernet headers have a 6-byte destination address
followed by a 6-byte source address, the difference is that the 2 bytes
after the source address in an 802.3 header are a packet length field,
with a value <= 1500, whereas the 2 bytes after the source address in an
Ethernet header are a packet type field, with a value > 1500 (Ethernet
type field values are all > 1500, so that you *can* distinguish between
802.3 and Ethernet frames).
For some reason, the driver is supplying an 802.3 header for the
incoming frames, and an Ethernet header for the outgoing frames - and
the 802.3 header is probably bogus, as Ethereal isn't recognizing the
destination Service Access Point or source Service Access Point values.
Over the air, *all* the non-management packets have 802.11 and (802.2)
Logical-Link Control headers; *none* of them have Ethernet II headers,
even the ones that are claimed to have them. However, the driver is
translating the 802.11, 802.2, and, if present, SNAP headers to an
Ethernet II header for outgoing packets - and somehow mangling them into
an 802.3 header for incoming packets (I wouldn't be surprised to see
that the LLC header on those packets is junk). The code path, in most
packet capture mechanisms in the OS kernel, is different for outgoing
packets and incoming packets, so there may be a bug in the path for
incoming packets.
What values do the fields within the 802.3 and Logical-Link Control
header have?