Saikiran Madugula wrote: > Patrick McHardy wrote: >> richardvoigt@xxxxxxxxx wrote: >>> On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi < >>> fulvio.ricciardi@xxxxxxxxxxxxx> 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 ? _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
