Sorry for the deep in-lining but....
Guy Harris wrote:
Scott
Lowrey wrote:
This has something to do with the
kernel/driver configuration on the local system. Although I don't have
enough info to update the page on the wiki,
You don't have to have complete info, you just have to have more info
than is there now. That's the nice thing about the Wiki - others can
update it later if they have more information.
OK, I'll try to write something up.
Capturing packets locally with Ethereal on a
VLAN interface -- eth2.120, for example -- will not reveal any VLAN
tags. This is expected behavior because the tag was stripped as the
frame was passed up thru the kernel/driver (?).
I *suspect* it's done either by
1) the firmware on the adapter - I think some network adapters do
the VLAN processing themselves, and can be give a VLAN tag, so that
they'll pass up to the host only VLAN frames with that tag, with the
VLAN header stripped off
or
2) a VLAN module in the kernel, doing the same filtering and tag
stripping, through which the packets are passed
although I suppose there could be drivers duplicating the filtering and
tag stripping (or perhaps there isn't a VLAN module in the Linux
kernel, so the drivers *have* to do it themselves).
Closer examination of both the driver code (in this case, the e1000
driver for the Intel PRO/1000 NIC) and the Linux VLAN kernel module
reveals that there is support in firmware for handling tags at a low
level - possibly before they get to the pcap library. We're thinking
that when a newly-created VLAN device is created in the kernel (by the
ifconfig or ip commands), that device registers with the underlying
driver and then the driver tweaks the EEPROM parameters in the NIC to
strip tags, knowing that some logical frame-to-device connection will
have already been made.
If this is correct, then it may be possible to reconfigure the driver
(or the 8021q module) to say, "Give me the tags anyway."
Capturing packets *locally* on a physical
interface -- eth2, for example -- where VLAN interfaces coexist will
probably *not* reveal any VLAN tags. The kernel/driver is stripping
them (?) but you *will* see all traffic for that interface including
the VLAN traffic -- you just won't see the tags.
That sucks. If the adapter's doing the VLAN processing, it might do
that even with the physical interface, but I'd expect it to do the
filtering, too. If it's code in the kernel (driver or a VLAN module),
it might be, as per my mail, another case of the skbuff for the packet
being manipulated in place without any copy-on-write.
Has anybody had any success capturing on the physical interface on a
Linux system attached to a VLAN, where "success" is defined as "seeing
packets with the VLAN tags attached and, at least if the capture is
being done in promiscuous mode and you're not attached to a switch
that's getting in the way, seeing packets for other VLANs or with no
VLAN tag"? If so, they might want to mention *that* on the Wiki page.
I think my answer would be "yes". I've seen the tags for several VLANs
on a single interface but not when sniffing on the device where those
VLANs are actually configured. I suspect that the "act of creating a
VLAN device" on Linux may actually reconfigure the NIC, which scuttles
further attempts at actually *seeing* the tags. This is only a hunch,
though, and it would require some experimentation to confirm.
It's very confusing until you capture packets
on an independent system running Ethereal using a mirrored port on the
switch. Bring up an anonymous interface on a laptop running SuSE 9.1,
connect it to the mirror port where VLAN "trunk" traffic is known to
exist, and capture. Ethereal will correctly display the VLAN tags
for each frame.
I.e., the anonymous interface *isn't* configured for a VLAN, so the
adapter and kernel code wouldn't be doing VLAN filtering and thus
probably wouldn't be doing VLAN tag stripping?
Right!
|