Gargoyle Forum

Beware of typos! (Router IP 192.163.0.3?).

As @Lantis says, there's really nothing to spoil if you plug it in correctly and select the correct IP address.

Go through it again with a clean configuration and it must work. In rare cases, the WAN port may not work, so always start with a LAN port.

Can people please stop connecting to the WAN port in this configuration, and test if it is still "not working".
Because if that's all that is wrong, that's easier to investigate.

This is the most likely thing to have changed in these versions, so please test LAN to LAN only and report back.

RomanHK wrote:Do not forget about DHCP:

Router1 - DHCP Server ON
Router2 - DHCP Server OFF

Check the settings after the routers have restarted - sometimes, if you change the settings, the DHCP server will turn on again.

The NAS must have the same subnet (in your case 192.168.0.0/24) as the LAN on the routers and the IP must not be the same as Router1 and 2.

Set the NAS to IP 192.168.0.3 (Mask: 255.255.255.0, Gateway: 192.168.0.1, DNS: 192.168.0.1) or from DHCP. For now, do not connect NAS to WAN, leave LAN (2,3,4).

I remember about dhcp: it is enabled only on Router1. All my devices are in 192.168.0.X mask 255.255.255.0 gateway 192.168.0.1 dns 192.168.0.1. The NAS has a static address 192.168.0.3 and connected to LAN port 2 of Router2.
After restarting both routers, wireless clients connected to Router2 saw local resources (NAS). At the same time, wireless and wired clients connected to Router1 do not see the NAS.
However, I see the unstable operation of Router2. After about 10 minutes, wireless clients connected to the Router2 lost access to local network resources (NAS). After another 10-15 minutes, local resources (NAS) became available again wireless clients connected to the Router2. Access disappears and appears not only to local resources, but also to the Router2.

Thanks to both of you for your responses. I'm not sure what is meant by a "clean start", but the typo was in my post, not in the configuration. As far as "plugging everything in correctly" is concerned, nothing in the cable connections was changed from the working configuration with Gargoyle 1.8.1. until I tried using a LAN port instead of the WAN port, which did not make a difference. The Gargoyle router is a TL-WDR4300v1. No clients (cabled or wireless) receive DHCP through the upgraded Gargoyle router. The only way I can access the Gargoyle router is through a cable-connected client with a manually assigned IP address. Please let me know if there is any diagnostic info which I should consult or post here.

rsbrux wrote:I'm not sure what is meant by a "clean start"

Reset to default. Many people use the original saved configuration (backup) and this creates additional problems.

rsbrux wrote:Please let me know if there is any diagnostic info which I should consult or post here.

Make sure the DHCP server is running over ssh: The must be running in router1 and must not be running in router2.

Some useful tips:

- Both routers must be in "Gateway (default)" mode.
- Router1 DHCP ON, Router2 DHCP OFF.
- Connect routers only with Ethernet cable LAN1 to LAN1.
- Do not connect the WAN port on router2.
- Both routers must only have WiFi in AP mode (AP+WDS).
- If you have the same WiFi SSID, make sure you have the same passwords on both router1 and router2!
- Beware of loops try to avoid them!: https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

If you follow this procedure, it should work for you.

Thanks for all of the suggestions. As it turns out, none are relevant. In v1.12.0, the setting "Wireless Client Isolation" for the primary (not guest) network under "Connection - Basic" prevents clients both cabled and wireless) from receiving IP addresses via DHCP from a gateway router when "Enabled". As long as it is "Disabled", everything else (including the WAN to LAN bridge) works as it did in v1.8.1.
Thanks for your help.

Ok great, that's a good outcome!
That gives me something to look at and see if we can improve, otherwise there is some kind of caveat or warning that we need to provide.

Thanks for posting your solution.