Guest network wi-fi goes down

[pchadw]

I'm running Merlin on an RT-AX88U Pro using Guest Network Pro to set up 2 IoT networks and WireGuard to enable access to the IoT devices when traveling. A couple of times, the IoT wireless has gone down, and after 'service restart-wireless', the IoT devices come back on line. It is not a common occurrence as I have had things stay up for a month or more. I have now set up a cron job to ping one of the devices and restart wireless if it goes down, but any thoughts on why it goes down in the first place? I'm running 3006.102.5 and checked the 102.6 and 102.7 changelogs and didn't see anything specifically related to this.

 

[jksmurf]

A couple of us, @penguin22 and myself, but not @visortgw, have had this issue with devices attached to LAN ports of nodes, that have VLANs pushed to those specific ports, using the LAN/VLAN menu, in Access or Trunk mode.

If you have one or more of those enabled, perhaps try disabling that setting? Mine’s been incredibly solid since (sad to lose the functionality though).

Otherwise can only think the IoTs try to roam due to in-device RSSI settings if they have them or maybe that the smart connect settings or RA settings need tweaking (I have RA disabled for my IoTs on 2.4Ghz, WPA2 only).

 

[visortgw]

A couple of us, @penguin22 and myself, but not @visortgw, have had this issue with devices attached to LAN ports of nodes, that have VLANs pushed to those specific ports, using the LAN/VLAN menu, in Access or Trunk mode.

If you have one or more of those enabled, perhaps try disabling that setting? Mine’s been incredibly solid since (sad to lose the functionality though).

Otherwise can only think the IoTs try to roam due to in-device RSSI settings if they have them or maybe that the smart connect settings or RA settings need tweaking (I have RA disabled for my IoTs on 2.4Ghz, WPA2 only).

Are your nodes all 3006.102.x firmware?

 

[jksmurf]

Are your nodes all 3006.102.x firmware?

My RT-AX86U Pro are, Main GT-AX6000 is, RT-AX58U is 3004.388.11.
I did try stock at one stage but didn’t seem to help.

 

[pchadw]

@visortgw - If I correctly understood your question re firmware - I only have one node - no mesh.

@jksmurf - My IoT is 2.4 Ghz only, WPA2-Personal. I do have an Ethernet port connected to the IoT VLAN in Access Mode - but it stays up even when the wireless devices are disconnected. I do have Smart-Connect on with default settings and no load-balance, although it should only be for the main Wi-Fi network, not the IoT networks. I am using manually assigned addresses for some of the IoT devices, which is why I can ping one of them to restart wireless if the ping is unsuccessful.

 

[visortgw]

@visortgw - If I correctly understood your question re firmware - I only have one node - no mesh.

@jksmurf - My IoT is 2.4 Ghz only, WPA2-Personal. I do have an Ethernet port connected to the IoT VLAN in Access Mode - but it stays up even when the wireless devices are disconnected. I do have Smart-Connect on with default settings and no load-balance, although it should only be for the main Wi-Fi network, not the IoT networks. I am using manually assigned addresses for some of the IoT devices, which is why I can ping one of them to restart wireless if the ping is unsuccessful.

Make sure to assign static IP address(es) within Guest Network Pro or Network for any Ethernet device(s) connected to IoT VLAN in Access Mode.

 

[jksmurf]

Make sure to assign static IP address(es) within Guest Network Pro or Network for any Ethernet device(s) connected to IoT VLAN in Access Mode.

All my IoTs have static IPs in-device where possible and (belt and braces) manual assignments defined on the router (I use YazDHCP).

 

[visortgw]

All my IoTs have static IPs in-device where possible and (belt and braces) manual assignments defined on the router (I use YazDHCP).

Have you tried using the built-in feature to assign DHCP addresses for hardwired IoT VLAN devices instead of YazDHCP?

 

[jksmurf]

@visortgw - If I correctly understood your question re firmware - I only have one node - no mesh.

So the node is just Main, no second router connected either in AiMesh or AP modes, correct?

@jksmurf - My IoT is 2.4 Ghz only, WPA2-Personal.

Good.

I do have an Ethernet port connected to the IoT VLAN in Access Mode - but it stays up even when the wireless devices are disconnected.

Actually it was not about that wired device disconnecting, sorry I was not clear; it was because you have that device connected, it may (as it does for two of us, but on AiMesh nodes, not Main), that it cuases wifi devices to disconnect. No idea what the mechanism is that causes that, but after a long series of trials and testing and various settings @penguin22 made an observation which I tried and so far (touch wood) has been a rock solid solution. Best in a long time i.e. turn off that access mode (you will lose the nice SDN you got using it). @visortgw does not have this issue apparently, so it is not a uniform fix. If it fixes yours it'll be 3 vs 1 , so it will be winner winner chicken dinner...

I do have Smart-Connect on with default settings and no load-balance, although it should only be for the main Wi-Fi network, not the IoT networks. I am using manually assigned addresses for some of the IoT devices, which is why I can ping one of them to restart wireless if the ping is unsuccessful.

Maybe have a look a the long thread I linked above, which has various settings, but try disabling that access mode for a few days and see what happens first?

See also here for more on the disabling of Access mode for VLANs helping with IoT device stability.

 

[jksmurf]

Have you tried using the built-in feature to assign DHCP addresses for hardwired IoT VLAN devices instead of YazDHCP?

No, I must admit I have not and it's certainly a test I could do at some stage. I'd probably have to (9500km remotely) flash the ESP32s back to wired mode though, and enable the Access Mode again.

I'm struggling to see what the difference would be TBH, YazDHCP vs Stock DHCP; it would also mean I would have to go back and add all the MACs/IPs for my Guest and IoT SDNs back into the two dnsmasq.conf-x.add files manually, which is pretty much what YazDHCP seems to be doing (just in a different dir) under the hood? If you are using stock, that is a noteworthy point of difference though. I am not sure what @penguin22 uses for manual assignments.

[EDIT] @visortgw ... you got me thinking .... (yeah I know, headache...) ... but wondering if there is actually some tenuous relationship with DHCP; albeit that thread seems more about losing connectivity to the wired device on the ethernet port, not wireless devices.

 

[bennor]

I'm struggling to see what the difference would be TBH, YazDHCP vs Stock DHCP; it would also mean I would have to go back and add all the MACs/IPs for my Guest and IoT SDNs back into the two dnsmasq.conf-x.add files manually, which is pretty much what YazDHCP seems to be doing (just in a different dir) under the hood?

Don't forget that Guest Network Pro, at least on the RT-AX86U Pro, has a Manually assign IP around DHCP list option for clients under the Advanced Settings section. Consider trying that as a troubleshooting step if you haven't done so already.

 

[jksmurf]

Don't forget that Guest Network Pro, at least on the RT-AX86U Pro, has a Manually assign IP around DHCP list option for clients under the Advanced Settings section. Consider trying that as a troubleshooting step if you haven't done so already.

Your'e correct I could do that too, but I believe I have mentioned a number of times now, that the lists are (theoretically) limited to 32 devices and (due to memory constraints as confirmed by RMerlin) I hit a limit at 21#. So for testing it is certainly a method to use, just not for long term use for the total number of devices I have on the IoT network.

 

[bennor]

Your'e correct I could do that too, but I believe I have mentioned a number of times now, that the lists are (theoretically) limited to 32 devices and (due to memory constraints as confirmed by RMerlin) I hit a limit at 21#. So for testing it is certainly a method to use, just not for long term use for the total number of devices I have on the IoT network.

Yes there is a limit of around 20 manual IP reservations, but one can circumvent that limit by creating additional Guest Network Pro profiles, up to six at least on a RT-AX86U Pro, and assign the client to those additional profiles. But really, if one has an extremely large number of IoT devices they should consider looking into better hardware with more configurability. Or consider setting up AP units with 3006.102.x series routers with different SSID's where you might (have not tried it) be able to further add manual IP reservations for the IoT clients through the Guest Network Pro profiles.

 

[jksmurf]

Yes there is a limit of around 20 manual IP reservations, but one can circumvent that limit by creating additional Guest Network Pro profiles, up to six at least on a RT-AX86U Pro, and assign the client to those additional profiles. But really, if one has an extremely large number of IoT devices they should consider looking into better hardware with more configurability. Or consider setting up AP units with 3006.102.x series routers with different SSID's where you might (have not tried it) be able to further add manual IP reservations for the IoT clients through the Guest Network Pro profiles.

I don't see the issue in using YazDHCP to do this; the increased numbers up to 187 would be all I need.

 

[bennor]

I don't see the issue in using YazDHCP to do this;

The point was, as @visortgw suggested in post #8; to try using the built-in feature to assign DHCP addresses rather than YazDHCP. You subsequently indicated you had not tried that in post #10, so it's a basic troubleshooting next step to try.

 

[jksmurf]

The point was, as @visortgw suggested in post #8; to try using the built-in feature to assign DHCP addresses rather than YazDHCP. You subsequently indicated you had not tried that in post #10, so it's a basic troubleshooting next step to try.

I agree, that is indeed true; I will see whether I can find time to do that at some stage, but the network is 9500km away so I am a little wary of wholesale changes to the DHCP manual assignments.

Currently there seems to be only 3 or maybe 4 of us with similar VLAN / GNP capable hardware setups (VLANs propagated to Ethernet Ports on Nodes), quite a few IoTs, 2 of which 'appear' (early days) to have solved the issue as discussed above.

Before I do start troubleshooting yet again by uninstalling YazDHCP and using the stock DHCP Assignment methods, I would like to see
(a) if @penguin22 uses YazDHCP as well and
(b) hope that there will be more candidates with the hardware and setup we have in common...