netdev - Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Aug 2011 09:40:50 +0200
From:	Michael Guntsche <mguntsche@...il.com>
To:	Jiri Pirko <jpirko@...hat.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)

On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@...hat.com> wrote:
> 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 :(
Sorry if my explanation was confusing but it was late night/morning
when I wrote it.

The setup is quite easy.

WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)

Client (in WLAN): 192.168.42.55
Bridge: 192.168.42.1
Server (on Wired): 192.168.42.127

With your patch the Bridge can ping the client and the server, but the
client cannot reach the server and vice-versa.

>
> 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?
The gianfar chip in this routerboard does NOT support vlan accel it is
a TSEC model.
ethtool complains that this feature is not supported.

>
> I presume you have no vlans involved in your setup, right?
No, there are no vlans in my setup.


>>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?
Yes I can access the server from the bridge so the network is working.
For me it looks like that the packets are just dropped when they
should go through the bridge.

Kind regards,
Michael
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html