Posted: Thu May 23, 2019 1:41 Post subject: Routing (?) problem with client bridge
I'm trying to use a DLink DIR-615 E3 as a repeater bridge that will create a wireless network that is connected wirelessly to my main network. It works sometimes, but mostly my packets do not get out onto the Internet. I suspect the problem is to do with routing. Here are are the details.
I have Comcast Business Internet with a DPC3941 box. This box manages a wireless network "Neptune". Its address is 10.0.0.1. I have a DIR-615 E3 on which I'm running DD-WRT v3.0-r39654. I followed the instructions under Qualcomm Atheros in https://wiki.dd-wrt.com/wiki/index.php/Repeater_Bridge . I set the IP address of the DIR-615 to 10.0.0.13 and reserved this address with the Comcast box. I set the physical interface mode to "Client Bridge (Routed)" and created a virtual interface with mode: AP and SSID Nereid.
I saved and applied settings and rebooted the DIR-615. I connected my tablet to the Nereid wireless network, and everything worked! But only for about 30 seconds. After that, my packets would not go to the Internet. The situation is reproducible. If I disconnect the tablet from the network, connect it again, and ping a machine on the Internet, it will work for about 30 seconds and then give either "Request timed out" or "Reply from 10.0.0.13: Destination net unreachable." Occasionally it works after that, but usually not. Sometimes the first error is followed a few successful pings, but then only errors.
On the other hand, I can always ping the comcast box at 10.0.0.1. I can also ping my server, which has a static IP and wired ethernet to the comcast box. Only machines that are actually out on the Internet give the problem. Since the error comes from the DIR-615, which has no way to know the difference between my static IP and any other Internet IP, I'm guessing that the comcast box must be sending some routing information that is confusing DD-WRT into thinking the net is unreachable, but I don't really know.
Wireless bridging in dd-wrt (like most other third-party firmware) is a hack. It's not a real bridge in the same sense as WDS. And as such, it doesn't always work. And to be honest, I don't know why it works in some cases and not others. There's just something about certain switches that don't handle this hack properly.
Over the years, at least in my own experience, the DIR-615 line of routers have been notorious for this problem. If you search the forums for by name and DIR-615, you'll find plenty of examples, dating way back to probably 2014 or even earlier.
In most cases, switching to a routed configuration solves the problem. And it's probably because the underlying problem is related to ARP. And when in a routed configuration, you don't have the issue of ARP crossing the boundary from the clients of that router over to the primary router. All ARP traffic for those clients remains confined to behind the WAN (or virtual WAN in the case of client mode) of that router.
If you want to use any form of wireless bridge, you may have to rely on static IP configuration on the devices behind that router rather than the DHCP server of the primary router. I know in that at least some cases this solves the problem, although it's obviously a bit of a hassle.
I gave up and bought a TP-Link RE305 range extender, which worked fine right out of the box. It came with a GPL brochure saying how to get the source code. I wonder if it is DD-WRT inside.
So I accomplished what I needed to, but it's too bad that DD-WRT didn't allow me to use my existing hardware. I suspect there must be some specific issue that was causing the problem, but not knowing where to start I felt it would take too long to try to debug it.
Most likely an ARP problem. I worked w/ a dd-wrt user a few years ago who came to discover that he had two routers on the same network w/ the same MAC address! Evidently some router manufacturers are trying to save on MAC address allocations by reusing them, I assume on the belief that users would never have more than one of their routers on the same ethernet network. That might be true for the typical user, but third-party firmware users are not typical.
Recently discovered in my own case that an old motherboard I was using to build a cheap PC is using a Ralink NIC w/ the same MAC address as a recent Ralink NIC I purchased from Frys!
Now granted, I don't have a large sample size here, but you'd think if manufacturers were truly handing out unique MAC addresses, or at least distributing them randomly, the chances of any one individual of getting duplicate MAC addresses would be like hitting the lottery.