Ben Greear <[EMAIL PROTECTED]> writes:
>> IOW: I think all Ethernet interfaces should always be VLAN-aware,
>> stripping the tag (only one) early on RX and adding it late on TX.
>> That means tcpdump would see packets with exactly one tag removed
>> (unless there was no tag), in both RX and TX.
Krzysztof Halasa wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
There is already a flag you can set on vlan devices (reorder-header)
that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can you have the
Ben Greear <[EMAIL PROTECTED]> writes:
> There is already a flag you can set on vlan devices (reorder-header)
> that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can you have the tag stripped from frames captured
Ben Greear [EMAIL PROTECTED] writes:
There is already a flag you can set on vlan devices (reorder-header)
that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can you have the tag stripped from frames captured on
Krzysztof Halasa wrote:
Ben Greear [EMAIL PROTECTED] writes:
There is already a flag you can set on vlan devices (reorder-header)
that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can you have the tag
Ben Greear [EMAIL PROTECTED] writes:
IOW: I think all Ethernet interfaces should always be VLAN-aware,
stripping the tag (only one) early on RX and adding it late on TX.
That means tcpdump would see packets with exactly one tag removed
(unless there was no tag), in both RX and TX.
Tcpdump
Krzysztof Halasa wrote:
Another idea - perhaps we could make the software VLANs behave
the same as hw ones? I.e., stripping the tag on RX while setting
some magic skb field?
The packets could go via main interface first (normal path, with
eth_type_trans stripping the tag and setting protocol =
Ben Greear <[EMAIL PROTECTED]> writes:
>> The net result is that dev_queue_xmit_nit() is called twice, once
>> for dev=eth0.2 then for dev=eth0.
>
> Maybe binding to all isn't such a good idea then.
Anyway I would expect the frame on eth0.2 and then on eth0 as well.
Anything different is crazy.
Another idea - perhaps we could make the software VLANs behave
the same as hw ones? I.e., stripping the tag on RX while setting
some magic skb field?
The packets could go via main interface first (normal path, with
eth_type_trans stripping the tag and setting protocol = some 802.1Q),
netif_rx |
On Wed, Jul 18, 2007 at 12:34:33PM -0700, andrei radulescu-banu wrote:
>
> Dear kernel networking gurus,
>
> I am trying to understand why tcpdump does not work properly for vlan packets
> on linux. Here is the existing behavior, observed with:
> - kernel 2.6.16,
> - e1000 driver
> -
On Wed, Jul 18, 2007 at 12:34:33PM -0700, andrei radulescu-banu wrote:
Dear kernel networking gurus,
I am trying to understand why tcpdump does not work properly for vlan packets
on linux. Here is the existing behavior, observed with:
- kernel 2.6.16,
- e1000 driver
- libpcap
Another idea - perhaps we could make the software VLANs behave
the same as hw ones? I.e., stripping the tag on RX while setting
some magic skb field?
The packets could go via main interface first (normal path, with
eth_type_trans stripping the tag and setting protocol = some 802.1Q),
netif_rx |
Ben Greear [EMAIL PROTECTED] writes:
The net result is that dev_queue_xmit_nit() is called twice, once
for dev=eth0.2 then for dev=eth0.
Maybe binding to all isn't such a good idea then.
Anyway I would expect the frame on eth0.2 and then on eth0 as well.
Anything different is crazy.
--
Krzysztof Halasa wrote:
Another idea - perhaps we could make the software VLANs behave
the same as hw ones? I.e., stripping the tag on RX while setting
some magic skb field?
The packets could go via main interface first (normal path, with
eth_type_trans stripping the tag and setting protocol =
andrei radulescu-banu wrote:
During debugging, I noticed that dev_queue_xmit() is called twice for tx vlan
frames. This results in a frame being passed twice to a packet socket bound to
'any' interface. If the packet socket is bound to a specific interface, though,
it will get only one copy
During debugging, I noticed that dev_queue_xmit() is called twice for tx vlan
frames. This results in a frame being passed twice to a packet socket bound to
'any' interface. If the packet socket is bound to a specific interface, though,
it will get only one copy of the tx frame, which is good.
On Thu, 19 Jul 2007 11:20:43 -0700 (PDT)
andrei radulescu-banu <[EMAIL PROTECTED]> wrote:
> > [Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can
> explicitly do so by some API. That is better than overloading
> the promisc flag in my opinion.
>
> I guess I could be
> [Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion.
I guess I could be persuaded in the end. But let me still play devil advocate.
The semantics of 'promiscuous', in my
>> [Andrei] VLAN_TX_SKB_CB() is perfect for that.
> [Patrick, Stephen] No its not. Its only legal to use while something has
> ownership
of the skb. Between VLAN devices and real devices qdiscs are
free to use it.
All right, using VLAN_TX_SKB_CB() is a bad idea. In that case, we need to amend
andrei radulescu-banu wrote:
[Ben] I think a better method would be to allow disabling VLAN HW accel for a
NIC with ethtool.
This requires changes to ethtool and e1000 driver, +other drivers. It is a
handy thing to have. I don't view it as a solution to tcpdump - or to the vlan
andrei radulescu-banu wrote:
> The consensus seems to be that skb's need to carry vlan accelerated tags in
> their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices
On Thu, 19 Jul 2007 08:47:01 -0700 (PDT)
andrei radulescu-banu <[EMAIL PROTECTED]> wrote:
> The consensus seems to be that skb's need to carry vlan accelerated tags in
> their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
>
> > [Patrick] On the TX path, it could simply use
One additional thought: with the proposed changes in my prev message, the
driver can be set to hw vlan accelerated mode, even if no vlan interfaces are
configured. We would not have to switch hw vlan accelerated mode anymore, when
vlan interfaces are created or destroyed.
The consensus seems to be that skb's need to carry vlan accelerated tags in
their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
> [Patrick] 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
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> Not at runtime, acceleration is always on if you compile kernel with vlan
> support. That is a design mistake as far as I can tell.
I think so.
>> However seeing unknown tags on master device (with tcpdump etc)
>> would certainly be useful.
>
>
On Thu, 19 Jul 2007 16:23:48 +0200
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> > 1) non-accelerated device
> > * all frames show in promiscious mode
> > * tag is part of the frame that shows up
> >in tcpdump, and then gets
On Thu, 19 Jul 2007 16:23:48 +0200
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> > 1) non-accelerated device
> > * all frames show in promiscious mode
> > * tag is part of the frame that shows up
> >in tcpdump, and then gets
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> 1) non-accelerated device
> * all frames show in promiscious mode
> * tag is part of the frame that shows up
>in tcpdump, and then gets stripped by the 8021q module.
Sure. It's IMHO good and working, modulo the tag being removed
on
Stephen Hemminger wrote:
> On Thu, 19 Jul 2007 15:28:46 +0200
> Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
>
>>>Your suggestion of disabling VLAN acceleration in promiscous
>>>mode sounds like a reasonable solution until then ..
>>
>>From a user perspective:
>>
>>I'm not sure promiscous mode is
On Thu, 19 Jul 2007 15:28:46 +0200
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
> > Your suggestion of disabling VLAN acceleration in promiscous
> > mode sounds like a reasonable solution until then ..
>
> From a user perspective:
>
> I'm not sure
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Your suggestion of disabling VLAN acceleration in promiscous
> mode sounds like a reasonable solution until then ..
>From a user perspective:
I'm not sure promiscous mode is related to the problem.
Tcpdump without promiscous mode makes perfect
Patrick McHardy [EMAIL PROTECTED] writes:
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From a user perspective:
I'm not sure promiscous mode is related to the problem.
Tcpdump without promiscous mode makes perfect sense.
I
On Thu, 19 Jul 2007 15:28:46 +0200
Krzysztof Halasa [EMAIL PROTECTED] wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From a user perspective:
I'm not sure promiscous
Stephen Hemminger wrote:
On Thu, 19 Jul 2007 15:28:46 +0200
Krzysztof Halasa [EMAIL PROTECTED] wrote:
Your suggestion of disabling VLAN acceleration in promiscous
mode sounds like a reasonable solution until then ..
From a user perspective:
I'm not sure promiscous mode is related to the
Stephen Hemminger [EMAIL PROTECTED] writes:
1) non-accelerated device
* all frames show in promiscious mode
* tag is part of the frame that shows up
in tcpdump, and then gets stripped by the 8021q module.
Sure. It's IMHO good and working, modulo the tag being removed
on the
On Thu, 19 Jul 2007 16:23:48 +0200
Krzysztof Halasa [EMAIL PROTECTED] wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
1) non-accelerated device
* all frames show in promiscious mode
* tag is part of the frame that shows up
in tcpdump, and then gets stripped by the
On Thu, 19 Jul 2007 16:23:48 +0200
Krzysztof Halasa [EMAIL PROTECTED] wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
1) non-accelerated device
* all frames show in promiscious mode
* tag is part of the frame that shows up
in tcpdump, and then gets stripped by the
Stephen Hemminger [EMAIL PROTECTED] writes:
Not at runtime, acceleration is always on if you compile kernel with vlan
support. That is a design mistake as far as I can tell.
I think so.
However seeing unknown tags on master device (with tcpdump etc)
would certainly be useful.
Only in
The consensus seems to be that skb's need to carry vlan accelerated tags in
their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
[Patrick] 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
One additional thought: with the proposed changes in my prev message, the
driver can be set to hw vlan accelerated mode, even if no vlan interfaces are
configured. We would not have to switch hw vlan accelerated mode anymore, when
vlan interfaces are created or destroyed.
On Thu, 19 Jul 2007 08:47:01 -0700 (PDT)
andrei radulescu-banu [EMAIL PROTECTED] wrote:
The consensus seems to be that skb's need to carry vlan accelerated tags in
their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
[Patrick] On the TX path, it could simply use the CB,
andrei radulescu-banu wrote:
The consensus seems to be that skb's need to carry vlan accelerated tags in
their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices
andrei radulescu-banu wrote:
[Ben] I think a better method would be to allow disabling VLAN HW accel for a
NIC with ethtool.
This requires changes to ethtool and e1000 driver, +other drivers. It is a
handy thing to have. I don't view it as a solution to tcpdump - or to the vlan
[Andrei] VLAN_TX_SKB_CB() is perfect for that.
[Patrick, Stephen] No its not. Its only legal to use while something has
ownership
of the skb. Between VLAN devices and real devices qdiscs are
free to use it.
All right, using VLAN_TX_SKB_CB() is a bad idea. In that case, we need to amend
the
[Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion.
I guess I could be persuaded in the end. But let me still play devil advocate.
The semantics of 'promiscuous', in my
On Thu, 19 Jul 2007 11:20:43 -0700 (PDT)
andrei radulescu-banu [EMAIL PROTECTED] wrote:
[Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion.
I guess I could be persuaded
During debugging, I noticed that dev_queue_xmit() is called twice for tx vlan
frames. This results in a frame being passed twice to a packet socket bound to
'any' interface. If the packet socket is bound to a specific interface, though,
it will get only one copy of the tx frame, which is good.
andrei radulescu-banu wrote:
During debugging, I noticed that dev_queue_xmit() is called twice for tx vlan
frames. This results in a frame being passed twice to a packet socket bound to
'any' interface. If the packet socket is bound to a specific interface, though,
it will get only one copy
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> 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
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
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
Patrick McHardy wrote:
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
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> 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
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
Dear kernel networking gurus,
I am trying to understand why tcpdump does not work properly for vlan packets
on linux. Here is the existing behavior, observed with:
- kernel 2.6.16,
- e1000 driver
- libpcap 0.9.6
- tcpdump 3.9.6
The e1000 driver has two modes when handling vlan
Dear kernel networking gurus,
I am trying to understand why tcpdump does not work properly for vlan packets
on linux. Here is the existing behavior, observed with:
- kernel 2.6.16,
- e1000 driver
- libpcap 0.9.6
- tcpdump 3.9.6
The e1000 driver has two modes when handling vlan
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
Ben Greear wrote:
Patrick McHardy wrote:
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
Patrick McHardy wrote:
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
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
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
Ben Greear wrote:
Patrick McHardy wrote:
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
60 matches
Mail list logo
