Impossible to have LAN to LAN bridge using two or more AR300M

Technical Support for Routers
1

I’m having a lot of troubles for a bridged setup:
having a physical switch connected to a LAN of the main router (AR300M acting as a NAT-Gateway connected to the ISP by WAN port), and N dumb-AP connected each one by LAN (to the switch ports).
=> the scope is to have multiple Wifi AP in a common subnet/DHCP.

I had a lot of issues in the LAN to LAN connection.
For example, even having a simple setup like this, results in pings-timeouts and impossibility to reach internet.
[AR300M DUMB-AP lan]------(ethernet cable)-------[lan AR300M GW wan] — ISP

To setup the dumbap (because I want a common DHCP coming from the GW) I followed the official OpenWRT guide, and each one WORKS PERFECTLY only if I connect them (one by one or the whole switch), to an ASUS or TPLINK router.
( => with the ASUS/TPLINK as gateway, I get internet access in all the N dumb-aps connected to the switch BUT NOT if I use another AR300M as gateway).

I did’t find anything in the forum here, only a couple of related issues in the LAN to LAN connection never solved…

I tried enabling the STP, disabling the firewall, creating custom rules etc. But the connection is still scattered, and ONLY if I have more than one GLI in the same LAN (not with other brands).
To be precise, the main AR300M GW works perfectly with the other computer connected in the switch, but at the moment I connect just only a dumbap, the pings in the WHOLE subnet start going timeout.

Example, the ping trace from a device connected to the DumbAP (via wifi) is like this:
Reply from 192.168.8.1: Destination net unreachable. <<<<the .8.1 is the main AR300M GW
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=46ms TTL=111
Request timed out.
Reply from 192.168.8.1: Destination net unreachable.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=46ms TTL=111
And the same if i ping instead of google (8.8.8.8), the main ISP GW IP (192.168.10.1)

DHCP: the funny thing is that I am able to correctly have a dynamic IP assigned from the GW DHCP, but if I try to ping him, the ping trace is scattered as above (and no internet).

NOTE for @alzhao
I tried also this very simple setup:
-taking 2 AR300M routers (A / B)
-reverting to factory default in each one
-in the A, setting your switch mode as router-mode (connected it to ISP 192.168.10.1 by WAN)
-in the B, setting your switch mode as bridge-mode (connected to A 192.168.8.1 by LAN to LAN eth) ((tried also LAN A to WAN B)
=> the whole LAN (WLAN) subnet of the B doesn’t reach at all internet, and it’s even impossible to ping the A.

Tried also with a crossover cable, not working.
The LEDE version is 17.01 (and also latest gl fw).

Ideas?

2

I think there is something wrong with your bridge.

Connecting lan to lan will not make it bridge. Each router will work in router mode and have the same subnet. This is why you have a problem.

To set up bridge mode, pls turn off all dhcp server of each mini router (luci-> network → interfaces → lan) and try agin.

There is a more correct way to set up bridge. However it is not in the existing firmware. We have this in firmware 3.x and we can send a testing firmware next week.

3

I don’t think the problem is in the DumbAP.
It works perfectly (LAN to LAN) in every other subnet and with every other router as gateway (not GL).

To setup a dumbap (other than following the openwrt guide), I manually disable the DHCP, and disable the startup of dnsmasq, firewall, firewall_gl, odhcpd.
I also disable in Network > DHCP & DNS the flag ‘authoritative’ and ‘rebind protection’ (just to be sure).
I also assign him a static IP for the luci reachability (putting the gw and the dns pointing to the main gateway, as described in the openwrt dumbap tutorial).

So there’s no action made by the dumbap router. In fact it forwards perfectly the DHCP requests.

I think the problem is in the gateway.
Connecting a dumbap to the LAN, breaks the entire subnet (and thus, also the bridged wifi).

4

I see. Must test and find the problem.