1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tomato's Wireless Ethernet Bridge not working for LAN ports

Discussion in 'Tomato Firmware' started by ChuckHL, Mar 20, 2013.

  1. ChuckHL

    ChuckHL Serious Server Member

    I have been fighting with this issue this week and have been unable to fix it or find a solution online.

    The scenario:
    I have 3 Linksys routers (E1500, E2500, and E1200v2) all running Shibby's latest version 108EN based on Tomatos V1.28. My E1500 router is my main router. Its configured to run with IP and DHCP leases range from to 150. On this router I enabled static IPs for certain computers. I also have OpenVPN configured in this router. All connections to this router work fine (both wireless and wired). The wireless service on the main router is configured to run Wireless N only with WPA2 + AES security.

    The other two routers (E2500 and E1200v2) connect to this router using Wireless Ethernet Bridge. Both were configure to use a different ip ( and Both routers have DHPC disabled, and have the DNS and gateway set to Both routers have been switched to operate on Router Mode rather than Gateway Mode.

    The problem: All devices connected to this additional routers through the LAN ports cannot connect to the internet for some strage reason. For example, if I hook my pc by wire to these additional routers, the PC says there is no internet connection and I cannot reach the internet. Additionally if i try to reach the main router at I cannot reach it (it can be reached if I connect wireless or through the LAN ports on the main router though). The funny thing here is that I can reach all other devices connected to the network.

    To clarify with an example:
    Let say Router A is the main router. And Router B and C are the additional routers connected to A by Wireless Ethernet Bridge.
    Let say Computer LA1 is hooked to router A, computer LB1 to router B and computer LC1 to router C all by cable to the LAN ports.
    Let say Computers WA1 is hooked to router A by wireless Connection.

    When using computer LB1 I cannot reach router A at nor the internet but I can reach routers B and C at their respective IPs. Additionally I can reach the other computers LA1, LC1, and WA1.

    The devices I connect to the LAN ports in the additional routers get assigned a valid IP within the DHCP range set in the Main router. Additionally, if I set an static IP on the main router for a computer and connect that computer on the additional router's lan port, it knows what IP it should assign.

    My windows computer reports to have the IP (Set by static IP on the main router) and it reports that the gateway is With this in mind, I know there is some connectivity between the main router and the computer. I just dont know why I cannot reach the main router nor the internet from the additional routers when connected by LAN.

    My guess: Its a firewall related issue of some sort.

    Another interesting fact (and the reason I started with all of this) is that I can enabled virtual SSIDs on this additional routers to extend my internet and if I connect to the additional routers through the VSSID I can connect to the internet and the local devices fine. If I connect to the main router SSID or to the additional routers VSSID, I can connect locally or to the internet just fine without any issues.

    Hope anyone can shine some light on this puzzle

  2. ChuckHL

    ChuckHL Serious Server Member

    My apologies but I have a correction to mention. This error of no internet only applies to computers connected to the additional routers and with an Static IP assigned through the main router under Basic->Static DHCP/ARP/IPT.
  3. ChuckHL

    ChuckHL Serious Server Member

    Solved. I just had to move the static DHCP/ARP to the right routers.
  4. nmalinoski

    nmalinoski Serious Server Member

    I ran into this issue earlier and was completely unaware that I had to reconfigure the Static DHCP/ARP on the additional routers. Seems silly.

    Edit: So part of the issue is that when a device connects to your host router through the bridge, the host router identifies that device with the MAC address of the bridge router, making the static lease entry on the host router useless.
    Last edited: Dec 31, 2014
  5. eibgrad

    eibgrad Addicted to LI Member

    I know this is an old thread, but this doesn’t make sense. A client (or repeater) bridge shouldn't require static IP/DHCP/ARP entries on the WAP. The whole point of being bridged is that the bridge itself is transparent. The only purpose of binding a static IP in DHCP is to make sure the client gets the same IP each time the DHCP server responds. And if you use the Bound To option, it creates a permanent entry in the router’s ARP table, which is only useful for WOL (wake on LAN).

    The only reason I’m pursuing this is that over the past several years, I’ve heard of client/repeater bridges sometimes not working much like the OP described. And it’s driven me crazy trying to understand why this happens only some of the time, to some ppl. I’ve never had this problem personally w/ any of my routers when configured as WAPs. FWIW, 98% of the time I use Broadcom.

    But one thing I do know; the client/repeater bridge used in dd-wrt and tomato is a hack. And it’s based to some degree on masking the MAC addresses of the clients behind the bridge over the bridge’s MAC address (think of it as NAT for MAC). But for some reason in certain chipsets/firmware this just doesn’t work properly. Then when I saw this post where the OP decides to install a static IP/DHCP/ARP entry “on the bridge”, it got me wondering if this isn’t a clue to the problem. Because as I said, this should NOT be required. But if it fixes the problem, it suggests that somehow the ARP table is getting messed up or lost on these bridges, and using static IP/DHCP/ARP on the bridge effectively puts it back.

    I’m just very curious. At least if I don’t understand the underlying cause completely, knowing a solid and dependable workaround would be highly beneficial.

    I’m particularly interested in knowing if when you “moved” these static IP/DHCP/ARP entries to the bridge, did you enable DHCP on the bridge too? Maybe w/ forwarding? IOW, are these clients getting their configurations from the bridge, or are you merely adding this information to the bridge so ARP works properly?
  6. ghoffman

    ghoffman Addicted to LI Member

    i have wireless ethernet bridging working for anumber of connections (2 bridges, 1-3 lan connections per bridge). the dhcp function is handled by the main router (X.X.X.254). the bridges have dhcp, nat, and firewall disabled , and point to the main router as the gateway and dns server. (I also have 2 AP's throughout the house, at X.X.X.2 and X.X.X.3).

    the bridges have static IP's outside the dhcp range. you have to configure the lan address and most of the setup of each bridge manually. this requires a static IP on the computer you are using to configure the bridge. In my setup, the bridges are at X.X.X.201 and X.X.X.202.

    clients behind the bridges get IP addresses and internet routes whether or not they have static (reserved) ip addresses, inside or outside the dhcp range of the main router.

    to have the main router distinguish the bridge from the hosts behind it, I set a static IP on the main router using the lan address of the bridge (X.X.X.201), but using the MAC address of the WIRELESS interface on the bridge, since that is what is connecting to the main router or AP. with this setup, i can access the bridge router gui over the LAN, and the clients behind it are also accessible.

    this setup has been more or less stable for years. the bridges are WRT150, WRT300. The main router is an r6300v2 (all broadcom). My AP's are atheros units set to dumb APmode, and the bridges connect to these just fine)
  7. eibgrad

    eibgrad Addicted to LI Member

    I've never had to do even that. I just assign a static IP to the WAP, disable DHCP, and I'm done. Period!

    Something is definitely "funky" w/ how wireless bridging is implemented on these third party firmwares. Something is just not quite right. And I'm so frustrated (been trying to pin this down for YEARS) that I haven't been able to determine EXACTLY what the differences are that make it work in some cases, and not others. And then is seems everyone has their own unique ways of getting around it (assuming they eventually do). And I haven’t found anyone in all these years who can ever tell me why what they did, did work. It always seems to be a case of just experimenting w/ this or that fix-up until hopefully it works. Very, very frustrating when you’re trying to help someone w/ this problem and all you can do is “guess” what workaround might do the trick.

    One of these days, before I meet my maker, I’m swear I’m gonna find out the truth about what the heck is going on here!!!
  8. Grimson

    Grimson Networkin' Nut Member

    Let me try to explain this easy:
    First you have to remember that you have 2 network segments at play on the bridge, the wireless network and the wired network. Both are on different hardware devices and only bridged on the IP level.

    But as you need to remember MAC addresses only work in the same physical segment, not across those segments.
    So the main router only sees the MAC address of the wireless adapter in the bridge, and the bridge routes all the packets it receives to the devices on the wired switch, this is not a bug but how ethernet networks are designed.

    This works without a hitch unless you start messing with the ARP tables by binding them to a specific MAC, that is on a different network segment.

    If you want I can write a more extensive explanation later.
  9. eibgrad

    eibgrad Addicted to LI Member

    I understand this is a hack. And that we're giving the illusion that both ethernet segments are physically joined. That’s not the issue for me. What I don't understand is why this hack doesn't work consistently from router to router when using the same firmware. What I've been finding over the years is that most times it works, occasionally it doesn't. And I don't recall it not working because someone started messing w/ ARP. In every case I can recall (certainly recently), they were doing nothing out of the ordinary. They just configured their bridge, disabled its DHCP server, and expected it to work. I just can't understand why two seemingly identical configurations will have it work in one case and not the other. On the face of it, it would appear that none of this has any chipset dependencies. I assume it’s all just higher level coding.

    Btw, I routinely assign static IPs to MAC addresses of clients behind my bridges using my primary router’s DHCP server. And the MAC addresses of those clients do appear in the Device List of tomato (and so does the MAC of the bridge). So the primary router is aware of the MAC addresses behind the bridge. I can only assume the bridge is listening for and responding to these MAC addresses, then forwarding them to the clients (and vice versa). That makes it a little different than NAT’ing IP where the remote location only sees the masked IP address. So I get it. I just don’t get why sometimes it doesn’t work for no good reason.
  10. ghoffman

    ghoffman Addicted to LI Member

    "And the MAC addresses of those clients do appear in the Device List of tomato (and so does the MAC of the bridge)"

    have you ever seen that a client behind the bridge sometimes also is duplicated on the device list with the MAC address of the bridge itself? this is where i think the problem is. supposedly this is fixed with a WDS link but i have not had good reliability with that.

Share This Page