[Bridge] 802.1q packets

[Bridge] 802.1q packets

[Fulvio Ricciardi]

Hi,

I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
tagged packets larger than 1470 bytes are not forwarded at
all by a bridge.
I think there is a bad interaction between bridge and
netfilter codes. Any chance to a have a patch to solve this
problem that limit the possibility to use the Linux bridges
in a environment with VLANs?

Best Regards
Fulvio Ricciardi

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> Hi,
> 
> I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> tagged packets larger than 1470 bytes are not forwarded at
> all by a bridge.
> I think there is a bad interaction between bridge and
> netfilter codes. Any chance to a have a patch to solve
> this problem that limit the possibility to use the Linux
> bridges in a environment with VLANs?

With the following command it works:

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

but this disable the iptables support that it's important
for obtaining complex bridge-firewall scenarios.

Regards
Fulvio Ricciardi

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[Stephen Hemminger]

On Sat, 28 Jun 2008 14:07:33 +0200
"Fulvio Ricciardi" <fulvio.ricciardi@zeroshell.net> wrote:

> 
> > Hi,
> > 
> > I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> > tagged packets larger than 1470 bytes are not forwarded at
> > all by a bridge.
> > I think there is a bad interaction between bridge and
> > netfilter codes. Any chance to a have a patch to solve
> > this problem that limit the possibility to use the Linux
> > bridges in a environment with VLANs?
> 
> With the following command it works:
> 
> echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
> 
> but this disable the iptables support that it's important
> for obtaining complex bridge-firewall scenarios.
> 
> Regards
> Fulvio Ricciardi

Your iptables need to know about VLAN's as well.
I bet your default action is to DROP.

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> > > Hi,
> > > 
> > > I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> > > tagged packets larger than 1470 bytes are not
> > > forwarded at all by a bridge.
> > > I think there is a bad interaction between bridge and
> > > netfilter codes. Any chance to a have a patch to solve
> > > this problem that limit the possibility to use the
> > > Linux bridges in a environment with VLANs?
> > 
> > With the following command it works:
> > 
> > echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
> > 
> > but this disable the iptables support that it's
> > important for obtaining complex bridge-firewall
> > scenarios. 
> > Regards
> > Fulvio Ricciardi
> 
> Your iptables need to know about VLAN's as well.
> I bet your default action is to DROP.
> 
No, the default policy is ACCEPT for the FORWARD chain. In
any case the problem takes place only with large packets.
For example if I try

ping -s 1472 192.168.99.74

it works, but

ping -s 1473 192.168.99.74

it does not.
I am sure that the network cards are VLAN 802.1q aware
because only the forwarding process is broken. If instead I
just ping the IP of the bridge interface it works fine.

Regards
Fulvio

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Sat, Jun 28, 2008 at 2:50 PM, Fulvio Ricciardi <
fulvio.ricciardi@zeroshell.net> wrote:

>
> > > > Hi,
> > > >
> > > > I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> > > > tagged packets larger than 1470 bytes are not
> > > > forwarded at all by a bridge.
> > > > I think there is a bad interaction between bridge and
> > > > netfilter codes. Any chance to a have a patch to solve
> > > > this problem that limit the possibility to use the
> > > > Linux bridges in a environment with VLANs?
> > >
> > > With the following command it works:
> > >
> > > echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
> > >
> > > but this disable the iptables support that it's
> > > important for obtaining complex bridge-firewall
> > > scenarios.
> > > Regards
> > > Fulvio Ricciardi
> >
> > Your iptables need to know about VLAN's as well.
> > I bet your default action is to DROP.
> >
> No, the default policy is ACCEPT for the FORWARD chain. In
> any case the problem takes place only with large packets.
> For example if I try
>
> ping -s 1472 192.168.99.74
>
> it works, but
>
> ping -s 1473 192.168.99.74
>
> it does not.
> I am sure that the network cards are VLAN 802.1q aware
> because only the forwarding process is broken. If instead I
> just ping the IP of the bridge interface it works fine.


Are the other nodes directly connected to the netfilter bridge, or are there
ethernet switches involved?   Are these switches managed, smart, or dumb?
Are jumbo frames enabled on all devices in the path?


>
>
> Regards
> Fulvio
>
> --------------------------------------------------------------------
> Fulvio Ricciardi
> web: http://www.zeroshell.net/eng/
> skype: zeroshellnet
> Phone: +3908321835630
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

[-- Attachment #2: Type: text/html, Size: 3060 bytes --]

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> > > > > Hi,
> > > > >
> > > > > I notice that with the Kernel 2.6.25.9 the 802.1q
> > > > > VLAN tagged packets larger than 1470 bytes are not
> > > > > forwarded at all by a bridge.
> > > > > I think there is a bad interaction between bridge
> > > > > and netfilter codes. Any chance to a have a patch
> > > > > to solve this problem that limit the possibility
> > > > > to use the Linux bridges in a environment with
> > > VLANs? >
> > > > With the following command it works:
> > > >
> > > > echo 0 >
> > > /proc/sys/net/bridge/bridge-nf-call-iptables >
> > > > but this disable the iptables support that it's
> > > > important for obtaining complex bridge-firewall
> > > > scenarios.
> > > > Regards
> > > > Fulvio Ricciardi
> > >
> > > Your iptables need to know about VLAN's as well.
> > > I bet your default action is to DROP.
> > >
> > No, the default policy is ACCEPT for the FORWARD chain.
> > In any case the problem takes place only with large
> > packets. For example if I try
> >
> > ping -s 1472 192.168.99.74
> >
> > it works, but
> >
> > ping -s 1473 192.168.99.74
> >
> > it does not.
> > I am sure that the network cards are VLAN 802.1q aware
> > because only the forwarding process is broken. If
> > instead I just ping the IP of the bridge interface it
> works fine.
> 
> 
> Are the other nodes directly connected to the netfilter
> bridge, or are there ethernet switches involved?   Are
> these switches managed, smart, or dumb? Are jumbo frames
> enabled on all devices in the path?
> 


One host is directly connected with a cross cable to the
bridge and the other one with an unmanaged switch that works
fine because if I issue the command

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

to disable the Netfilter action for the bridge there is no
problem for the large packets on VLAN.



--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

On Sat, Jun 28, 2008 at 4:17 PM, Fulvio Ricciardi <
fulvio.ricciardi@zeroshell.net> wrote:

>
> > > > > > Hi,
> > > > > >
> > > > > > I notice that with the Kernel 2.6.25.9 the 802.1q
> > > > > > VLAN tagged packets larger than 1470 bytes are not
> > > > > > forwarded at all by a bridge.
> > > > > > I think there is a bad interaction between bridge
> > > > > > and netfilter codes. Any chance to a have a patch
> > > > > > to solve this problem that limit the possibility
> > > > > > to use the Linux bridges in a environment with
> > > > VLANs? >
> > > > > With the following command it works:
> > > > >
> > > > > echo 0 >
> > > > /proc/sys/net/bridge/bridge-nf-call-iptables >
> > > > > but this disable the iptables support that it's
> > > > > important for obtaining complex bridge-firewall
> > > > > scenarios.
> > > > > Regards
> > > > > Fulvio Ricciardi
> > > >
> > > > Your iptables need to know about VLAN's as well.
> > > > I bet your default action is to DROP.
> > > >
> > > No, the default policy is ACCEPT for the FORWARD chain.
> > > In any case the problem takes place only with large
> > > packets. For example if I try
> > >
> > > ping -s 1472 192.168.99.74
> > >
> > > it works, but
> > >
> > > ping -s 1473 192.168.99.74
> > >
> > > it does not.
> > > I am sure that the network cards are VLAN 802.1q aware
> > > because only the forwarding process is broken. If
> > > instead I just ping the IP of the bridge interface it
> > works fine.
> >
> >
> > Are the other nodes directly connected to the netfilter
> > bridge, or are there ethernet switches involved?   Are
> > these switches managed, smart, or dumb? Are jumbo frames
> > enabled on all devices in the path?
> >
>
>
> One host is directly connected with a cross cable to the
> bridge and the other one with an unmanaged switch that works
> fine because if I issue the command
>
> echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
>
> to disable the Netfilter action for the bridge there is no
> problem for the large packets on VLAN.


That mostly rules out other devices in the path as the cause of the
problem.  There's just one chance of a netfilter interaction that I can
think of: netfilter may cause fragments to be recombined, without netfilter
the fragments could be bridged.  Are you running the ping command from the
bridge itself, or across the bridge? (I presume across the bridge because
you are discussing the FORWARD chain only)

Do the large ping requests show up in the iptables counters?

What happens if you set no fragmentation when you run ping?


>
>
>
> --------------------------------------------------------------------
> Fulvio Ricciardi
> web: http://www.zeroshell.net/eng/
> skype: zeroshellnet
> Phone: +3908321835630
>

[-- Attachment #2: Type: text/html, Size: 4056 bytes --]

Re: [Bridge] 802.1q packets

[Leigh Sharpe]

I had a similar problem not long ago. Make sure that ip_conntrack is not
loaded. In my case, it was re-assembling all fragmented packets passing
through the bridge, and not fragmenting them again. The resulting large
packet was too big for the interface, and it got dropped. 

Regards,
             Leigh
 
Leigh Sharpe
Network Systems Engineer
Pacific Wireless
Ph +61 3 9584 8966
Mob 0408 009 502
Helpdesk 1300 300 616
email lsharpe@pacificwireless.com.au
web www.pacificwireless.com.au
 

-----Original Message-----
From: bridge-bounces@lists.linux-foundation.org
[mailto:bridge-bounces@lists.linux-foundation.org] On Behalf Of Fulvio
Ricciardi
Sent: Saturday, 28 June 2008 2:56 PM
To: bridge@osdl.org
Subject: [Bridge] 802.1q packets

Hi,

I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
tagged packets larger than 1470 bytes are not forwarded at
all by a bridge.
I think there is a bad interaction between bridge and
netfilter codes. Any chance to a have a patch to solve this
problem that limit the possibility to use the Linux bridges
in a environment with VLANs?

Best Regards
Fulvio Ricciardi

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> I had a similar problem not long ago. Make sure that
> ip_conntrack is not loaded. In my case, it was
> re-assembling all fragmented packets passing through the
> bridge, and not fragmenting them again. The resulting
> large packet was too big for the interface, and it got
> dropped. 
> 

I use the modules nf_conntrack_ipv4 and nf_conntrack. I
can't remove them. Does exist a workaround if this is the
problem?

Thanks
Fulvio 

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> 
> That mostly rules out other devices in the path as the
> cause of the problem.  There's just one chance of a
> netfilter interaction that I can think of: netfilter may
> cause fragments to be recombined, without netfilter the
> fragments could be bridged.  Are you running the ping
> command from the bridge itself, or across the bridge? (I
> presume across the bridge because you are discussing the
> FORWARD chain only)

I ping across the bridge. If instead a ping from the bridge
itself, all works right.

> 
> Do the large ping requests show up in the iptables
> counters?

Yes, in any case (either ping -s 1472 and ping -s 1473) the
packets are counted in the FORWARD chain.

> 
> What happens if you set no fragmentation when you run
> ping?

it's the same

Thanks
Fulvio

--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi <
fulvio.ricciardi@zeroshell.net> wrote:

>
> >
> > That mostly rules out other devices in the path as the
> > cause of the problem.  There's just one chance of a
> > netfilter interaction that I can think of: netfilter may
> > cause fragments to be recombined, without netfilter the
> > fragments could be bridged.  Are you running the ping
> > command from the bridge itself, or across the bridge? (I
> > presume across the bridge because you are discussing the
> > FORWARD chain only)
>
> I ping across the bridge. If instead a ping from the bridge
> itself, all works right.
>
> >
> > Do the large ping requests show up in the iptables
> > counters?
>
> Yes, in any case (either ping -s 1472 and ping -s 1473) the
> packets are counted in the FORWARD chain.
>
> >
> > What happens if you set no fragmentation when you run
> > ping?
>
> it's the same


Just to verify, you mean that with no fragmentation, large pings go through
if and only if bridge-nf-call-iptables is disabled?

I would expect large pings to be dropped irregardless of the
bridge-nf-call-iptables option when the no fragmentation bit is set, based
on your scenario.


>
>
> Thanks
> Fulvio
>
> --------------------------------------------------------------------
> Fulvio Ricciardi
> web: http://www.zeroshell.net/eng/
> skype: zeroshellnet
> Phone: +3908321835630
>

[-- Attachment #2: Type: text/html, Size: 2128 bytes --]

Re: [Bridge] 802.1q packets

[Patrick McHardy]

richardvoigt@gmail.com wrote:
> On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi <
> fulvio.ricciardi@zeroshell.net> wrote:
> 
>>> That mostly rules out other devices in the path as the
>>> cause of the problem.  There's just one chance of a
>>> netfilter interaction that I can think of: netfilter may
>>> cause fragments to be recombined, without netfilter the
>>> fragments could be bridged.  Are you running the ping
>>> command from the bridge itself, or across the bridge? (I
>>> presume across the bridge because you are discussing the
>>> FORWARD chain only)
>> I ping across the bridge. If instead a ping from the bridge
>> itself, all works right.
>>
>>> Do the large ping requests show up in the iptables
>>> counters?
>> Yes, in any case (either ping -s 1472 and ping -s 1473) the
>> packets are counted in the FORWARD chain.
>>
>>> What happens if you set no fragmentation when you run
>>> ping?
>> it's the same
> 
> 
> Just to verify, you mean that with no fragmentation, large pings go through
> if and only if bridge-nf-call-iptables is disabled?


Just FYI for all affected, I'm looking into this. One
problem is that only packets with skb->protocol == ETH_P_IP
are refragmented, but not ETH_P_8021Q. That change alone
doesn't fix it though, still trying to track it down.

Re: [Bridge] 802.1q packets

[Adam Osuchowski]

Fulvio Ricciardi wrote:
> I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> tagged packets larger than 1470 bytes are not forwarded at
> all by a bridge.
> I think there is a bad interaction between bridge and
> netfilter codes. Any chance to a have a patch to solve this
> problem that limit the possibility to use the Linux bridges
> in a environment with VLANs?

Is it maybe problem described here?

  https://lists.linux-foundation.org/pipermail/bridge/2007-May/005436.html

If so, it was reported more than one year ago and still none of developers
care about it.

-- 
##  Adam Osuchowski                            Adam.Osuchowski@polsl.pl
##  Silesian University of Technology, Computer Centre, Gliwice, Poland

Re: [Bridge] 802.1q packets

[Fulvio Ricciardi]

> Fulvio Ricciardi wrote:
> > I notice that with the Kernel 2.6.25.9 the 802.1q VLAN
> > tagged packets larger than 1470 bytes are not forwarded
> > at all by a bridge.
> > I think there is a bad interaction between bridge and
> > netfilter codes. Any chance to a have a patch to solve
> > this problem that limit the possibility to use the Linux
> > bridges in a environment with VLANs?
> 
> Is it maybe problem described here?
> 
>  
>
https://lists.linux-foundation.org/pipermail/bridge/2007-May/005436.html
> 
> If so, it was reported more than one year ago and still
> none of developers care about it.
> 

Yes, it is exactly the same problem. Thanks for the patch
that I hope developers will include it in the vanilla Kernel
as soon as possible.

Regards 
Fulvio Ricciardi


--------------------------------------------------------------------
Fulvio Ricciardi
web: http://www.zeroshell.net/eng/
skype: zeroshellnet
Phone: +3908321835630

Re: [Bridge] 802.1q packets

[Adam Osuchowski]

Fulvio Ricciardi wrote:
> Thanks for the patch

This patch has one shortcoming. Better version (with PPPoE support as well)
is here:

https://lists.linux-foundation.org/pipermail/bridge/2007-May/005447.html

> that I hope developers will include it in the vanilla Kernel
> as soon as possible.

Don't be under the illusion that it will be done quickly (if at all).
I have been waiting for that since I reported bug.

-- 
##  Adam Osuchowski                            Adam.Osuchowski@polsl.pl
##  Silesian University of Technology, Computer Centre, Gliwice, Poland

Re: [Bridge] 802.1q packets

[Stephen Hemminger]

On Tue, 22 Jul 2008 21:35:46 +0200
Adam Osuchowski <Adam.Osuchowski@polsl.pl> wrote:

> Fulvio Ricciardi wrote:
> > Thanks for the patch
> 
> This patch has one shortcoming. Better version (with PPPoE support as well)
> is here:
> 
> https://lists.linux-foundation.org/pipermail/bridge/2007-May/005447.html
> 
> > that I hope developers will include it in the vanilla Kernel
> > as soon as possible.
> 
> Don't be under the illusion that it will be done quickly (if at all).
> I have been waiting for that since I reported bug.
> 

Problem has been fixed since 2.6.17 (over 2 yrs ago).
Look before you whine.
------------------------------------------------------

commit 85ca719e5756d79ea0f10c469e3762462ac45e22
Author: Stephen Hemminger <shemminger@osdl.org>
Date:   Wed Apr 26 02:39:19 2006 -0700

    [BRIDGE]: allow full size vlan packets
    
    Need to allow for VLAN header when bridging.
    
    Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 2d24fb4..56f3aa4 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
 #include <linux/skbuff.h>
+#include <linux/if_vlan.h>
 #include <linux/netfilter_bridge.h>
 #include "br_private.h"
 
@@ -29,10 +30,15 @@ static inline int should_deliver(const struct net_bridge_port *p,
 	return 1;
 }
 
+static inline unsigned packet_length(const struct sk_buff *skb)
+{
+	return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
+}
+
 int br_dev_queue_push_xmit(struct sk_buff *skb)
 {
 	/* drop mtu oversized packets except tso */
-	if (skb->len > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
+	if (packet_length(skb) > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
 		kfree_skb(skb);
 	else {
 #ifdef CONFIG_BRIDGE_NETFILTER

Re: [Bridge] 802.1q packets

[richardvoigt]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

On Tue, Jul 22, 2008 at 9:59 PM, Stephen Hemminger <shemminger@vyatta.com>
wrote:

> On Tue, 22 Jul 2008 21:35:46 +0200
> Adam Osuchowski <Adam.Osuchowski@polsl.pl> wrote:
>
> > Fulvio Ricciardi wrote:
> > > Thanks for the patch
> >
> > This patch has one shortcoming. Better version (with PPPoE support as
> well)
> > is here:
> >
> > https://lists.linux-foundation.org/pipermail/bridge/2007-May/005447.html
> >
> > > that I hope developers will include it in the vanilla Kernel
> > > as soon as possible.
> >
> > Don't be under the illusion that it will be done quickly (if at all).
> > I have been waiting for that since I reported bug.
> >
>
> Problem has been fixed since 2.6.17 (over 2 yrs ago).
> Look before you whine.


If I'm reading that thread correctly, it is a patch against 2.6.21 for a
problem encountered in 2.6.17 and later.


>
> ------------------------------------------------------
>
> commit 85ca719e5756d79ea0f10c469e3762462ac45e22
> Author: Stephen Hemminger <shemminger@osdl.org>
> Date:   Wed Apr 26 02:39:19 2006 -0700
>
>    [BRIDGE]: allow full size vlan packets
>
>    Need to allow for VLAN header when bridging.
>
>    Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> index 2d24fb4..56f3aa4 100644
> --- a/net/bridge/br_forward.c
> +++ b/net/bridge/br_forward.c
> @@ -16,6 +16,7 @@
>  #include <linux/kernel.h>
>  #include <linux/netdevice.h>
>  #include <linux/skbuff.h>
> +#include <linux/if_vlan.h>
>  #include <linux/netfilter_bridge.h>
>  #include "br_private.h"
>
> @@ -29,10 +30,15 @@ static inline int should_deliver(const struct
> net_bridge_port *p,
>        return 1;
>  }
>
> +static inline unsigned packet_length(const struct sk_buff *skb)
> +{
> +       return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN
> : 0);
> +}
> +
>  int br_dev_queue_push_xmit(struct sk_buff *skb)
>  {
>        /* drop mtu oversized packets except tso */
> -       if (skb->len > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
> +       if (packet_length(skb) > skb->dev->mtu &&
> !skb_shinfo(skb)->tso_size)
>                kfree_skb(skb);
>        else {
>  #ifdef CONFIG_BRIDGE_NETFILTER
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>

[-- Attachment #2: Type: text/html, Size: 3848 bytes --]

Re: [Bridge] 802.1q packets

[Adam Osuchowski]

Stephen Hemminger wrote:
> Problem has been fixed since 2.6.17 (over 2 yrs ago).
> Look before you whine.

No, it is not this problem. That one which I'm talking about was observed
by me in kernel 2.6.21 first time and still exists in recent version
(2.6.26.5). Check it once again, please.

Re: [Bridge] 802.1q packets

[Saikiran Madugula]

Patrick McHardy wrote:
> richardvoigt@gmail.com wrote:
>> On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi <
>> fulvio.ricciardi@zeroshell.net> wrote:
>>
>>>> That mostly rules out other devices in the path as the
>>>> cause of the problem.  There's just one chance of a
>>>> netfilter interaction that I can think of: netfilter may
>>>> cause fragments to be recombined, without netfilter the
>>>> fragments could be bridged.  Are you running the ping
>>>> command from the bridge itself, or across the bridge? (I
>>>> presume across the bridge because you are discussing the
>>>> FORWARD chain only)
>>> I ping across the bridge. If instead a ping from the bridge
>>> itself, all works right.
>>>
>>>> Do the large ping requests show up in the iptables
>>>> counters?
>>> Yes, in any case (either ping -s 1472 and ping -s 1473) the
>>> packets are counted in the FORWARD chain.
>>>
>>>> What happens if you set no fragmentation when you run
>>>> ping?
>>> it's the same
>>
>> Just to verify, you mean that with no fragmentation, large pings go through
>> if and only if bridge-nf-call-iptables is disabled?
> 
> 
> Just FYI for all affected, I'm looking into this. One
> problem is that only packets with skb->protocol == ETH_P_IP
> are refragmented, but not ETH_P_8021Q. That change alone
> doesn't fix it though, still trying to track it down.
> 

Is this problem fixed ? I am unable to find if this problem is fixed in later 
commits in the tree.

Thanks,
Saikiran.

Re: [Bridge] 802.1q packets

[Saikiran Madugula]

Saikiran Madugula wrote:
> Patrick McHardy wrote:
>> richardvoigt@gmail.com wrote:
>>> On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi <
>>> fulvio.ricciardi@zeroshell.net> wrote:
>>>
>>>>> That mostly rules out other devices in the path as the
>>>>> cause of the problem.  There's just one chance of a
>>>>> netfilter interaction that I can think of: netfilter may
>>>>> cause fragments to be recombined, without netfilter the
>>>>> fragments could be bridged.  Are you running the ping
>>>>> command from the bridge itself, or across the bridge? (I
>>>>> presume across the bridge because you are discussing the
>>>>> FORWARD chain only)
>>>> I ping across the bridge. If instead a ping from the bridge
>>>> itself, all works right.
>>>>
>>>>> Do the large ping requests show up in the iptables
>>>>> counters?
>>>> Yes, in any case (either ping -s 1472 and ping -s 1473) the
>>>> packets are counted in the FORWARD chain.
>>>>
>>>>> What happens if you set no fragmentation when you run
>>>>> ping?
>>>> it's the same
>>>
>>> Just to verify, you mean that with no fragmentation, large pings go 
>>> through
>>> if and only if bridge-nf-call-iptables is disabled?
>>
>>
>> Just FYI for all affected, I'm looking into this. One
>> problem is that only packets with skb->protocol == ETH_P_IP
>> are refragmented, but not ETH_P_8021Q. That change alone
>> doesn't fix it though, still trying to track it down.
>>
> 
> Is this problem fixed ? I am unable to find if this problem is fixed in 
> later commits in the tree.
> 

I realized that commit (fbd8104c2eb2f00a031a3e472a0fc08e40d04c0b) disables 
bridge netfilter code on PPOE and VLAN tagged frames entirely. Is it because the 
problem mentioned in the above thread still there ?