My bridge isnt bridging.  It was on the 94xx build I had installed, but on the latest r125xx series traffic isnt making it across the bridge from wifi to lan and vice a verse.  Its killing me, please help.

if i /etc/init.d/firewall stop bridging works as expected.  i'm digging through the iptables but i'm unsure what is causing this problem.

(Last edited by Rektide on 7 Sep 2008, 21:40)

xMff suggested setting up two separate networks and forwarding between them.  The wiki has an outline of setting up the two networks and then the uci /etc/config/firewall is pretty simple:

config 'forwarding'      
        option 'src' 'lan'
        option 'dest' 'wlan'

config 'forwarding'      
        option 'src' 'wlan'
        option 'dest' 'lan'

I would however much prefer bridging actually work and leaving my systems on the same network.

root@w67:~# brctl show br-lan
bridge name     bridge id               STP enabled     interfaces
br-lan          8000.000fb53d526c       no              ath0
                                                        eth0.0

ath0      Link encap:Ethernet  HWaddr 00:0F:B5:3D:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1551 errors:0 dropped:777 overruns:0 frame:0
          TX packets:725 errors:0 dropped:128 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:238438 (232.8 KiB)  TX bytes:62565 (61.0 KiB)

br-lan    Link encap:Ethernet  HWaddr 00:0F:B5:3D:FF:FF
          inet addr:10.7.24.67  Bcast:10.50.50.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:212509 errors:0 dropped:0 overruns:0 frame:0
          TX packets:391148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:11152664 (10.6 MiB)  TX bytes:557172231 (531.3 MiB)

eth0      Link encap:Ethernet  HWaddr 00:0F:B5:3D:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:654536 errors:0 dropped:0 overruns:0 frame:0
          TX packets:602561 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:581171461 (554.2 MiB)  TX bytes:576272037 (549.5 MiB)
          Interrupt:4

eth0.0    Link encap:Ethernet  HWaddr 00:0F:B5:3D:FF:FF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:211732 errors:0 dropped:0 overruns:0 frame:0
          TX packets:390476 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13095914 (12.4 MiB)  TX bytes:558679071 (532.7 MiB)

all as it should be

so you only stopped the firewall to make bridging work again ?

(Last edited by tuigje on 8 Sep 2008, 20:03)

"only"

I havent seen any changelogs on this; can anyone confirm whether they can bridge wifi <-> lan on recent builds?  I dont care about WGT hardware or not, but please mention whether you are atheros or not?

I have also noticed this problem on my WGT634U (I don't have any other routers running an svn kamikaze at the moment). I changed my firewall config to allow forwarding on the lan zone. Not 100% of the implications of this, but at least it helps narrow down the problem. It does seem to me that traffic within the bridge should not go into the forwarding rules.

it seems that part of the problem was that I had an old firewall configuration file in my build (did that myself).
and kmod-ipt-nat was not selected, but I'm still not completely sure if that one is necessary

I just ran into the same problem.  I believe the least-impact way to fix it is to enable LAN<->LAN forwarding in /etc/config/firewall.  Add this after the existing LAN->WAN rule:

config forwarding
        option src      lan
        option dest     lan

(Last edited by pmarks on 21 Sep 2008, 05:10)

Are you sure its not the following?

config forwarding
        option src      wan
        option dest     lan

src=wan,dest=lan would allow any hosts on the internet to connect to any machine on your local network.  Perhaps not the best for security and the "option masq 1" in your wan interface allows IP masquerading (known as network address translation) and does all the neccessary config already.

src=lan,dest=lan is the correct one as traffic on the bridge does pass through the firewall on the way through to the other side, and I assume newer versions of the kernel are trying to be flexible by allowing such traffic to also be blocked if you so choose.  The only exception to this is two wired clients where the switching is done in hardware.

The reason this is confusing is that OpenWRT's default policy is "block all", with no knowledge of such specific cases like when you are using a bridge.  IMO, they should include lan<->lan in the default configs.

what can i provide to help diagnose this problem?  this is a regression and i would really like to see it fixed.

Phorn,

Thanks for the clarification.  In my particular case I'm trying to do an Ethernet bridge between two radios (Ubiquiti Nanostation 5's -- Atheros 2312) in which case src=wan,dest=lan (along with src=lan, dest=wan) provides the desired bridging, so I really don't need a firewall nor masquerading (NAT).  I'm seeing the same problem (observed in r12928 & r13015 of the development trunk) everyone else is with regard to the 'bridge not bridging,' even when the firewall and NAT router aren't included in the build.  In order to replicate the suggested workaround, I include the firewall in the build, so that I can then configure it as suggested in this thread, and then perform an  /etc/init.d/firewall stop followed by a restart of wifi.  Then and only then do the packets begin to fly, and I'm only seeing ~7-8 Mbps throughput over a 54Mbps link (when using iperf running on the NS's).  It still seems to be seriously broken as far as I've been able to tell.

vector108