[Bridge] 802.1q packets

Saikiran Madugula hummerbliss at gmail.com
Tue Mar 17 09:26:39 PDT 2009


Saikiran Madugula wrote:
> Patrick McHardy wrote:
>> richardvoigt at gmail.com wrote:
>>> On Mon, Jun 30, 2008 at 5:07 PM, Fulvio Ricciardi <
>>> fulvio.ricciardi at 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 ?


More information about the Bridge mailing list