What's new

IoT network with different subnet

arsnlgunnr

New Around Here
Hi all,
I created an IoT network via GNP with the separate subnet/VLAN configuartion. When connecting devices to the separate IoT network over wifi, some devices are assigned an IP with the correct subnet and others still maintained an IP belonging to the main network subnet. Is this because I'm using an unmanaged switch?

Current AI Mesh network set up:
RT-BE88U (main)
RT-BE86U x2 (nodes)
-Ethernet backhaul
-Nodes connect to main router via un-managed switch
-firmware: merlin 3006.102.7

TIA!
 
Last edited:
Is this because I'm using an unmanaged switch?
No. It is likely that you had some of those WIFI clients connected to your main WIFI then switched them to the guest WIFI. It will take some time before the Asus Network Manager wakes up and realizes the IP's for those clients have changed. Rebooting the router may help then again it may not. The DHCP clients on the guest WIFI will get the right IP range address. Check the DHCP leases.
 
Hi all,
I created an IoT network via GNP with the separate subnet/VLAN configuartion. When connecting devices to the separate IoT network over wifi, some devices are assigned an IP with the correct subnet and others still maintained an IP belonging to the main network subnet. Is this because I'm using an unmanaged switch?

Current AI Mesh network set up:
RT-BE88U (main)
RT-BE86U x2 (nodes)
-Ethernet backhaul
-Nodes connect to main router via un-managed switch
-firmware: merlin 3006.102.7

TIA!

I would think that a simple switch does not affect DHCP IP address assignments.

Maybe the wireless clients are reflecting the DHCP of the network they are connecting to?

Does it work correctly with stock ASUSWRT firmware?

Does it work if you create your own custom IoT GNP instead of using the built-in IoT network?

OE
 
@bbunge has the most likely explanation.

If it doesn’t change after a main reboot, and allow it to settle for 10-15mins or so, could you please check your GNP, VLAN, AiMesh settings to confirm all 3 nodes are checked. Just to confirm the IoT network is set up to be propagated to all the nodes? Just curious really, I don't think it is the cause though.
 
Last edited:
I had a similar issue recently where I reserved a different IP address for a device in DHCP settings but the router didn't force it on the device. I can't remember now exactly what I did, but I spent a good bit of time trying to get the device on the new address. I think it had to do with the lease time. Maybe I temporarily set the lease to be a short time?
 
I had a similar issue recently where I reserved a different IP address for a device in DHCP settings but the router didn't force it on the device. I can't remember now exactly what I did, but I spent a good bit of time trying to get the device on the new address. I think it had to do with the lease time. Maybe I temporarily set the lease to be a short time?
Possibly :-) ... a router reboot should renew the leases so hopefully that will fix it. Easy enough to do (as long as the family are not online ... otherwise go sit in the naughty chair...)
 
@jksmurf @Justinh @OzarkEdge @bbunge

Thanks all for the replies! Based on the feedback, when connecting the devices to the IoT network and they don't get the desired IP, sounds like I just need to give it some time for the IP address to be assigned properly.

I did delete and re-create the IoT network and joined 4 devices. 3 were assigned an IP in the correct subnet right away. The remaining 1 retained it's main network IP but updated after about 5-10 min to the correct subnet IP. Will continue to monitor and make sure those 4 don't hop back and forth between subnets before adding the remaining devices to the IoT network.
 
The remaining 1 retained it's main network IP but updated after about 5-10 min to the correct subnet IP.
That’s odd behaviour but I have seen instances where the network map reports it having joined one subnet but is actually configured to only ever join another.

Just mulling it over, it’s either, as stated above:

(a) a network map anomaly in the notoriously unreliable** Asus Network Map screen, for which you really don’t need to worry or
(b) you’ve duplicated SSIDs (Main/IoT) and as such inadvertently configured the device to be able to join the main subnet OR the IoT one and it eventually migrates to the IoT one. This is highly unlikely. Or
(c) The device can save multiple SSIDs on either channel and if it can’t join one will cycle to a previously saved one. IIRC my Alexa Echo Dots have this capability and it wasn’t until I deleted an old 5Ghz profile on main did they migrate to my preferred 2.4Ghz one on the IoT network. Unlikely though as once latched on to a network they don’t tend to move.

** For (a) you may want to look at the System Log, DHCP leases menu instead, but it has a glaring drawback, it remembers the lease data for as long as the lease is set, so even if a device detaches, it shows the cached lease information which can be hours old. You could try to issue service restart_dnsmasq but I’m not sure that will force it to show the most up to date information. The RHS column does nicely list which VLAN the devices are latched on to though.

Separately, the System Log, wireless log menu is a nice tabular layout and would be ideal… if it weren’t for the fact it only lists devices connected to main.. sigh.

Another option would be be, via a Cmd Line if you’re comfortable with SSHing to your main router, is simply issue this at the prompt: ugly but ok for troubleshooting. It does depend on how often the ARP cache is flushed though, although I think this is very much more frequent than DHCP leases (60s to minutes) IIRC. You’ll probably be able to see when a device connects to what node on what VLAN sooner too. It might be that it has actually connected correctly right away, just the ASUS network map needs to scratch its head and cogitate like some contented ruminant.
Code:
arp -a

A third option, but by no means the last is RTRMON by the incomparable @Viktor Jaep. It’s an all singing all dancing script you run from amtm (as you don’t have a sig yet, and posted just 3 messages, I can’t see if you have installed any scripts before, so if your eyes glazed over right now don’t worry, you’re not the first). RTRMON has sufficient screens (see screen 7) to give the average person the mother of all headaches, but is very useful all the same. Good for troubleshooting.
 
Last edited:
The most effective in that situation (changing the network or ip addresses) is to simply cut the power to those devices, wait a little and turn them on again.
The thing is that once a device has got an ip address from DHCP it actually OWNS that ip address for the period of the lease time and it's actually not required to renew that even if it can't connect. Most devices will however forget that address when powered off and request a new one when powered up.
 
The most effective in that situation (changing the network or ip addresses) is to simply cut the power to those devices, wait a little and turn them on again.
The thing is that once a device has got an ip address from DHCP it actually OWNS that ip address for the period of the lease time and it's actually not required to renew that even if it can't connect. Most devices will however forget that address when powered off and request a new one when powered up.
Agree and I can remotely reboot most of my IoT devices for that purpose but if you don’t have that option, if you have 30 or 35 odd IoT devices, it’s a wee bit cumbersome; and is difficult to do remotely unless you put IoT devices on IoT switches … 🥱
 
Agree and I can remotely reboot most of my IoT devices for that purpose but if you don’t have that option, if you have 30 or 35 odd IoT devices, it’s a wee bit cumbersome; and is difficult to do remotely unless you put IoT devices on IoT switches … 🥱
Hehe, if you have that many devices, simply take the main power off and on, much faster ;)
I'm a big fan of the K.I.S.S. strategy (Keep It Stupidly Simple).
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top