> This is what a VLAN packet from tcpdump should look like...
>
> 19:27:35.522141 ff:ff:ff:ff:0:e0 Broadcast 988e 346:
> df36 0800 4500 0148 c503 0000 8011 74a2
> 0000 0000 ffff ffff 0044 0043 0134 3cfc
> 0101 0600 555d e627 d04f 0000 0000 0000
> 0000 0000 0000
I don't know what happened to the mail I'd sent out about this from home
last night, but it didn't show up here at work, or in the tcpdump.org
archive, so I'll reconstruct the important part.
The "988e" in the first line indicates that the Ethernet-frame dissector
saw an Ethernet type field of hex 988e in the frame header, meaning the
frame had:
6 bytes that the dissector interpreted as the destination
address;
6 bytes that the dissector interpreted as the source address
2 bytes with 988e in them.
988e is *NOT* a valid Ethernet type value for a VLAN frame (the right
value is hex 8100), so, not surprisingly, tcpdump doesn't dissect it as
a VLAN frame.
The destination address is "Broadcast", which means ff:ff:ff:ff:ff:ff;
the source address is claimed to be ff:ff:ff:ff:00:e0, which looks a bit
bogus.
So the frame, as captured by tcpdump, was:
ffff ffff ffff ffff ffff 00e0 988e df36
0800 4500 0148 c503 0000 8011 74a2 0000
0000 ffff ffff 0044 0043 0134 3cfc 0101
0600 555d e627 d04f 0000 0000 0000 0000
0000 0000
> This is what an "arp for gateway" VLAN packet looks like from
> tcpdump:
>
> 19:18:14.382141 ff:ff:ff:ff:0:e0 Broadcast 2994 64:
> a159 0806 0001 0800 0604 0001 00e0 2994
> a159 2021 2223 0000 0000 0000 2021 2202
> 0000 2910 0001 0000 0000 0001 2046 4446
> 0000
Same here; hex 2994 isn't a valid Ethernet type for a VLAN frame,
either, so tcpdump, quite correctly, doesn't dissect that frame as a
VLAN frame.
The frame was:
ffff ffff ffff ffff ffff 00e0 2994 a159
0806 0001 0800 0604 0001 00e0 2994 a159
2021 2223 0000 0000 0000 2021 2202 0000
2910 0001 0000 0000 0001 2046 4446 0000
If you remove the ffff ffff from the beginnings of those frames, you get
ffff ffff ffff 00e0 988e df36 0800 4500
0148 c503 0000 8011 74a2 0000 0000 ffff
ffff 0044 0043 0134 3cfc 0101 0600 555d
e627 d04f 0000 0000 0000 0000 0000 0000
and
ffff ffff ffff 00e0 2994 a159 0806 0001
0800 0604 0001 00e0 2994 a159 2021 2223
0000 0000 0000 2021 2202 0000 2910 0001
0000 0000 0001 2046 4446 0000
The first of those frames looks like an IP packet, sent from
00:e0:98:8e:df:36 to ff:ff:ff:ff:ff:ff (i.e., a broadcast frame); the
frame type is 0800, meaning it's an IPv4 frame, and the next byte is
45, which is "IP version 4, frame length 5 4-byte words", in an IP
header - i.e., an IP header with no options.
There appears to be "ffff ffff" in that packet; I'll bet that's the
destination IP address of that frame (i.e., an IP broadcast).
The second of those frames looks like an ARP packet, sent from
00:e0:29:94:a1:59 to ff:ff:ff:ff:ff:ff (i.e., a broadcast ARP packet);
if you parse the ARP packet, you find that the frame is an ARP request,
with the hardware addresses being Ethernet addresses and the protocol
addresses being IP addresses, with the source Ethernet address being
00:e0:29:94:a1:59, and the target Ethernet address being
00:00:00:00:00:00 (because it's unknown - that's what the request is
trying to find).
So it appears that the real problem is either that
1) some device is putting bogus frames onto the Ethernet, with
an extra "ffff ffff" stuck at the front
or
2) the Linux networking code is somehow mangling those frames,
perhaps doing so while handling VLAN stuff.
I didn't see any obvious place in the 2.4.2 kernel where there's an
802.1Q implementation (which I find a bit surprising), so, for now, I
suspect 1) might be the case.
I'd suggest putting some other network analyzer - whether it's a PC
running some OS other than Linux plus some network analyzer program (a
BSD PC running a libpcap-based program such as tcpdump or Ethereal or
Ksnuffle, or a Solaris PC running any of the preceding programs or
running snoop, or a Windows PC running WinDump or Analyzer or Ethereal
or any of the zillions of commercial analyzer programs), or a
specialized device (which, admittedly, are often just PC's running DOS
or Windows plus some network analyzer software).
If that analyzer has the same problem, something probably really is
putting bogus frames on the wire.
If that analyzer *doesn't* have the same problem, then Linux's
networking code is probably mangling the frame somewhere after
receiving it.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
