From: Patrick McHardy <hidden> Date: 2007-07-18 23:00:09
andrei radulescu-banu wrote:
[...]
In conclusion, here is the buglist:
1). If set promiscuous, the e1000 should disable any vlan rx filtering, so that it can receive vlan frames of other vlan id's. Other ethernet drivers probably need fixed as well.
2). The packet layer should change the rx skb device from the vlan 'fake' device (eth0.2) to the corresponding physical device (eth0), so when we run tcpdump on eth0 we see all vlan-tagged and non-vlan-tagged frames
3). The packet socket layer should insert the vlan tag header before passing frames to the upper layer, so tcpdump can display them.
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would be desirable to make use of
hardware VLAN accerlation. I was thinking about storing the
information somewhere in the packets meta-data on both RX and
TX paths, that would also allow tcpdump to properly display
packets.
I have planned to look into this when I find some time.
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From: Patrick McHardy <hidden> Date: 2007-07-18 23:42:37
Ben Greear wrote:
Patrick McHardy wrote:
quoted
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would be desirable to make use of
hardware VLAN accerlation. I was thinking about storing the
information somewhere in the packets meta-data on both RX and
TX paths, that would also allow tcpdump to properly display
packets.
MAC-VLAN could gather this information based on it's parent
device (ie, if parent-dev has VID 7, then add VID 7 to the meta
data. There would be no need for any driver changes I think.
Its actually more a problem on the RX path. VLAN acceleration
works (at least with some drivers) by enabling HW header striping
and using the VLAN ID for an immediate lookup in the VLAN devices
configured on that device. So if the VLAN is not configured on the
real device but something like macvlan, it will get the packet
without a header and without any indication that this was a VLAN
packet. This is also what causes the tcpdump problem.
On the TX path, it could simply use the CB, but this is actually
also wrong (for both macvlan and real devices) since qdiscs have
ownership of the skb in between, and at least netem *does* modify
the CB, breaking VLAN.
Other than TCP-dump, or some other raw protocol that wants to see
the VLAN header in user-space, I can't think of what use this would
be, however. And, if you just disable VLAN accel in the NIC (see below),
that would make this mac-vlan hackery not needed at all?
Optimizations for macvlan are not too important, I agree. But for
tcpdump I consider it a bug.
quoted
I have planned to look into this when I find some time.
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
I think a better method would be to allow disabling VLAN HW accel for a
NIC with
ethtool. Then, the packets will be received by the software stack with
the vlan
header intact. Something sniffing on the physical dev will
automatically get the
VLAN header.
That would also be fine. But considering that the TX path is
problematic too, a clean solution for all of this would be
to store the VLAN id in the skb. And we do have some holes
to plug currently :)
From: Ben Greear <hidden> Date: 2007-07-18 23:44:58
Patrick McHardy wrote:
andrei radulescu-banu wrote:
quoted
[...]
In conclusion, here is the buglist:
1). If set promiscuous, the e1000 should disable any vlan rx filtering, so that it can receive vlan frames of other vlan id's. Other ethernet drivers probably need fixed as well.
2). The packet layer should change the rx skb device from the vlan 'fake' device (eth0.2) to the corresponding physical device (eth0), so when we run tcpdump on eth0 we see all vlan-tagged and non-vlan-tagged frames
3). The packet socket layer should insert the vlan tag header before passing frames to the upper layer, so tcpdump can display them.
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would be desirable to make use of
hardware VLAN accerlation. I was thinking about storing the
information somewhere in the packets meta-data on both RX and
TX paths, that would also allow tcpdump to properly display
packets.
MAC-VLAN could gather this information based on it's parent
device (ie, if parent-dev has VID 7, then add VID 7 to the meta
data. There would be no need for any driver changes I think.
Other than TCP-dump, or some other raw protocol that wants to see
the VLAN header in user-space, I can't think of what use this would
be, however. And, if you just disable VLAN accel in the NIC (see below),
that would make this mac-vlan hackery not needed at all?
I have planned to look into this when I find some time.
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
I think a better method would be to allow disabling VLAN HW accel for a
NIC with
ethtool. Then, the packets will be received by the software stack with
the vlan
header intact. Something sniffing on the physical dev will
automatically get the
VLAN header.
Thanks,
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com
From: Ben Greear <hidden> Date: 2007-07-19 00:01:59
Patrick McHardy wrote:
Ben Greear wrote:
quoted
Patrick McHardy wrote:
quoted
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would be desirable to make use of
hardware VLAN accerlation. I was thinking about storing the
information somewhere in the packets meta-data on both RX and
TX paths, that would also allow tcpdump to properly display
packets.
MAC-VLAN could gather this information based on it's parent
device (ie, if parent-dev has VID 7, then add VID 7 to the meta
data. There would be no need for any driver changes I think.
Its actually more a problem on the RX path. VLAN acceleration
works (at least with some drivers) by enabling HW header striping
and using the VLAN ID for an immediate lookup in the VLAN devices
configured on that device. So if the VLAN is not configured on the
real device but something like macvlan, it will get the packet
without a header and without any indication that this was a VLAN
packet. This is also what causes the tcpdump problem.
This reminded me of something:
If we are using VLAN HW-Accel, then the skb hits the mac-vlan check with
the skb->dev == vlan-device.
So, in this case, we can put mac-vlans on top of 802.1Q VLANs.
But, if we are not using VLAN hw-accel, the skb hits the mac-vlan check
with skb->dev == ethernet-device.
In this case, we could NOT have the mac-vlan on top of the 802.1Q VLAN,
but we can have a MAC-VLAN
on the raw ethernet and we could add 802.1Q vlans on top of the
mac-vlan. This is because the
.1Q vlan will only be found once we go into the protocol handler logic,
which is necessarily after the
MAC-VLAN check logic.
Unless I am confused in my conjecture above, this is likely to confuse
others who try to mix and
match MAC-VLANs and 802.1Q VLANs.
quoted
quoted
I have planned to look into this when I find some time.
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
I think a better method would be to allow disabling VLAN HW accel for a
NIC with
ethtool. Then, the packets will be received by the software stack with
the vlan
header intact. Something sniffing on the physical dev will
automatically get the
VLAN header.
That would also be fine. But considering that the TX path is
problematic too, a clean solution for all of this would be
to store the VLAN id in the skb. And we do have some holes
to plug currently :)
With VLAN HW accel disabled, the skb will have the VLAN header in it by
the time it
hits the ethX interface, so sniffing there should still show the
header. It won't show
when sniffing the VLAN device, but I think that is OK.
Thanks,
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com
From: Patrick McHardy <hidden> Date: 2007-07-19 00:20:44
Ben Greear wrote:
Patrick McHardy wrote:
quoted
Its actually more a problem on the RX path. VLAN acceleration
works (at least with some drivers) by enabling HW header striping
and using the VLAN ID for an immediate lookup in the VLAN devices
configured on that device. So if the VLAN is not configured on the
real device but something like macvlan, it will get the packet
without a header and without any indication that this was a VLAN
packet. This is also what causes the tcpdump problem.
This reminded me of something:
If we are using VLAN HW-Accel, then the skb hits the mac-vlan check with
the skb->dev == vlan-device.
So, in this case, we can put mac-vlans on top of 802.1Q VLANs.
But, if we are not using VLAN hw-accel, the skb hits the mac-vlan check
with skb->dev == ethernet-device.
In this case, we could NOT have the mac-vlan on top of the 802.1Q VLAN,
but we can have a MAC-VLAN
on the raw ethernet and we could add 802.1Q vlans on top of the
mac-vlan. This is because the
.1Q vlan will only be found once we go into the protocol handler logic,
which is necessarily after the
MAC-VLAN check logic.
Unless I am confused in my conjecture above, this is likely to confuse
others who try to mix and
match MAC-VLANs and 802.1Q VLANs.
The current code doesn't use hardware acceleration and works fine
in all combinations where only vlan *or* macvlan devices are used
on the underlying device.
If you mix them macvlan won't get to see vlan headers anymore,
same as for tcpdump, bridge devices, or anything else that
might care. A bridge eating VLAN headers should be a clearer
indication of a bug than an inaccurate tcpdump ..
The real problem is that the device removes the header for all
vlans, not only for those that are configured on the device.
This is a result of how the hardware works. But since we don't
have the data available later, we can't even fix it up in
software.