On Tue, Mar 27, 2001 at 12:05:08AM +0000, Ed Stevens wrote:
> Here is some additional descriptive information that was passed on to me:
>
> -----------------------
>
> 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
Well, for one thing, that frame doesn't look like an ARP frame; 0800
followed by 4500 looks very suspiciously like an IP frame (0800 is the
Ethernet type value for IPv4, 4 is the IP protocol version number, and 5
is the length of an option-less IP header, in 4-byte words).
For another thing, "988e" indicates that the 2-byte Ethernet type/length
value after the destination address of ff:ff:ff:ff:ff:ff ("Broadcast")
and source address of ff:ff:ff:ff:00:e0 is 988e, which I couldn't
find mentioned in my copy of IEEE Standard 802.1Q.
Tcpdump will recognize a frame as a VLAN frame only if it has an
Ethernet type of 8100, which is the type specified by 802.1Q.
> 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
This doesn't have an Ethertype of 8100, either - it has an Ethertype of
2994.
The ARP part of the packet is:
0806 - Ethernet type for ARP
0001 - ARP hardware type (Ethernet)
0800 - ARP protocol type (IPv4)
0604 - hardware and protocol address sizes (6 and 4 bytes,
respectively, which are correct for Ethernet and IPv4)
0001 - opcode (Request)
00e0 2994 a159 - source hardware address (00:e0:29:94:a1:59)
2021 2223 - sender protocol address (32.33.34.35)
0000 0000 0000 - target hardware address (00:00:00:00:00:00 -
zero, because it's unknown, and this request is asking for
it)
2021 2202 - target protocol address (32.33.34.2)
Now, it's interesting that the source hardware address has 2994 in it.
The packet began, according to "ff:ff:ff:ff:0:e0 Broadcast 2994", with:
ffff ffff ffff ffff ffff 00e0 2994 a159 0806
which is ffff ffff, followed by
ffff ffff ffff
00e0 2994 a159
0806
which is, well, an Ethernet header, with a destination address of
ff:ff:ff:ff:ff:ff (broadcast), a source address of 00:e0:29:94:a1:59
(the machine that sent the ARP request), and an Ethernet type of 0806
(ARP).
So this frame appears to, for whatever reason, consist of 4 bytes of ff,
followed by a *NON*-VLAN Ethernet header, followed by an ARP payload.
I have no idea whether this is because
1) that's really what's getting put out on the wire, in which
case there are bogus packets on your network
or
2) the Linux kernel code is somehow mangling the frame before
handing it to libpcap
but I see no sign that this is a tcpdump bug - it looks as if it's
either a Linux kernel bug or a bug in whatever device is transmitting
those packets.
(The IP packet would be
ffff ffff
ffff ffff ffff
00e0 988e df36
0800
and then the IP packet, which is the same bogus ffff ffff followed by a
broadcast destination address (ff:ff:ff:ff:ff:ff), a source address of
00:e0:98:8e:df:36, and an IP packet type.
For what it's worth, 00:e0:98 is, according to
http://standards.ieee.org/regauth/oui/oui.txt
owned by
ABOCOM SYSTEMS, INC.
12F-3, NO. 333, SEC. 1
GUAN-FU ROAD HSIN-CHU
TAIWAN, R.O.C.
and 00:e0:29 is owned by
STANDARD MICROSYSTEMS CORP.
6 HUGHES
IRVINE CA 92718
.)
-
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
