Message-ID: <20110810070722.GA2150@minipsycho>
Date:	Wed, 10 Aug 2011 09:07:23 +0200
From:	Jiri Pirko <jpirko@...hat.com>
To:	Michael Guntsche <mguntsche@...il.com>
Cc:	shemminger@...tta.com, sebastian.belden@...glemail.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: BUG: Bisected Gianfar in bridge not forwarding packets (was:
 3.0-rc1 Bridge not forwarding unicast packages)

Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@...il.com wrote:
>Good evening/morning,
>
>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>> testing. On a first look everything seemed to work fine, but when I
>> tried to connect via openvpn to my internal network (tap0 being bridged
>> with the internal network) I noticed that I was not able to access the
>> server on my internal network. I could access the bridge (which is
>> acting as the openvpn server as well) just fine though.
>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>> internal network. I could see the ARP requests being answered.....
><snip>
>
>After much digging and testing I found the commit that causes the
>problem for me here.
>
>87c288c6e gianfar: do vlan cleanup
>
>Before this commit my bridge works fine. I simplified the test case
>and just tried to access the server from a local wireless device with
>gets also bridged via
>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>device from the internal network afterwards it stops.
>For testing purposes I reverted this commit (plus some others to make
>the code compile) and it started working again.
>The hardware is a routerboard with three onboard nics two of em gianfar.
>The gianfar nics do not support any kind of offloading,

Thanks for testing/report. I'm not sure I understand your simplified
case :(

Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
it on/off manually by ethtool to see if it works in some setup?

I presume you have no vlans involved in your setup, right?
	
>
>Offload parameters for lan_wire:
>rx-checksumming: off
>tx-checksumming: off
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: off
>ntuple-filters: off
>receive-hashing: off
>
>The Bridge device on the other hand....
>
>Offload parameters for lan:
>rx-checksumming: on
>tx-checksumming: on
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: on
>ntuple-filters: off
>receive-hashing: off
>
>Is it possible that the new code is tripped up by the bridge offload
>parameters somehow and thinks that the gianfar nic supports it as
>well?

I don't see how now. Outside the bridge all is working correctly?

>As I wrote in my initial mail, connecting to the Bridge itself works,
>I can also see ARP requests and Broadcasts, the rest just seems to
>disappear.
>
>As for the commits I reverted:
>a4aeb2662 vlan: kill __vlan_hwaccel_rx and vlan_hwaccel_rx
>6dacaddd4 vlan: kill vlan_hwaccel_receive_skb
>7890a5b9c vlan: kill ndo_vlan_rx_register
>b852b7208 gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
>
>87c288c6e gianfar: do vlan cleanup
>
>I really think that there is only some small change in the gianfar
>code needed, but I could not figure it out myself.
>Please tell me if you need any more information.
>
>Kind regards,
>Michael Guntsche
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists