Guest network pro vlan with ethernet ports configured to anything than "All(default) - SDN Profile: default" main dhcp problem

[mistermoonlight1]

This is a general query
Is there anybody who succesfully configured a guess vlan setup where one of the ethernet port of the switch is not configured to vlan mode All(defaut). I have made tons of test on RT-AX86U Pro using a configuration like this and at some point, it will make me loose main dhcp support to connected ethx client. If the lan ports are all set to vlan mode All(defaut), multiple dhcp configuration seems not to create any problem. I have also tested to create a 7 differents vlan setup created without dhcp (by creating these vlan in the Lan vlan profile section (which is a pain as it will reboot the router each vlan that is added)). With these 7 vlans, i can set the vlan ethernet ports mode anyway i want it (trunk, access, all defaut). But as soon as i convert one of these vlan to support dhcp (through guest network menu), i will loose main ethernet lan dhcp support :-( ...

N.B. if i am configuring more than 1 dhcp server on these vlan ethernet ports (with the 7 vlans setup with ethernet port configured in different vlan modes), all the ethernet ports with dhcp configured will have dhcp working, just the main dhcp will be broken in this situation...

 

[jksmurf]

Not 100% your issue, but have a look at some observations @penguin22 and I have had in this post and see if that rings any bells?

Release - Asuswrt-Merlin 3006.102.7 is now available

Now, will Asus do the same? I already sent them the patch a few weeks ago, so expect it to be applied in a future stock release.

www.snbforums.com

 

[penguin22]

Thanks @jksmurf. I have been struggling with wireless connectivity issues on one of two Mesh nodes, where the BE82U doesn't support wired VLAN, where the BE86U does and was configured to use it for a single device. This post led me to test setting the BE86U to default without wired VLAN adjustments and I have had IoT stability for 2+ days for the first time since getting these devices. Though not ideal, it perhaps may shed some light on the seemingly intermittent impact people are experiencing.

 

[mistermoonlight1]

@jksmurf
Yes using any vlan configuration with an ethernet port configured as trunk tagged vlan or untagged vlan for a specific vlan (one of the ethernet port of the switch is not configured to vlan mode All(defaut) cause all sort of instability. I know that "All(default)" for all ethernet ports is more stable, but it is not what i want to use on my setup. This is why i initially posted this query at the top of the thread. Loosing ethernet dhcp on main ethernet network, nvram configuration parameters changes in unexpected behavior, playing with the GNP configurations repairs or corrupts things, changing behavior once reconfigured through GNP that won't persist after a reboot or a power cycle, etc.

I was able in some specific cases having a single vlan trunk on router ethernet port with dhcp ok on main wired lan, but if i add a couple of guess wifi vlan to the setup, i could loose the main dhcp function on the wired lan (but dhcp may work ok on the wifi GNP or another untagged wired ethernet port, not the main lan). In some case, i got dhcp not working on main wired lan with a single dhcp wifi GNP and playing with the GNP configuration (enable/disable) may repair things or not. Complete instability and unreliable. I also got another configuration with 1 ethernet vlan trunk port and another one configured as untagged for a specific vlan with dhcp still working on the main vlan, but adding another guess wifi may render the configuration unstable or loosing main wired lan dhcp...

see also a deeper overview:

Beta - Asuswrt-Merlin 3006.102.7 Beta is now available

Myself about what I think of mlo, I have noticed that it uses the most frequency of 2.4 and 5 ghz and almost nothing on 6 ghz, I myself have deactivated mlo because yes I think it does not work well for me anyway as I am most interested in 6ghz, so I have turned off mlo and 2.4 and 5 ghz myself...

www.snbforums.com

Beta - Asuswrt-Merlin 3006.102.7 Beta is now available

Myself about what I think of mlo, I have noticed that it uses the most frequency of 2.4 and 5 ghz and almost nothing on 6 ghz, I myself have deactivated mlo because yes I think it does not work well for me anyway as I am most interested in 6ghz, so I have turned off mlo and 2.4 and 5 ghz myself...

www.snbforums.com

Beta - Asuswrt-Merlin 3006.102.7 Beta is now available

Deeper analysis (main dhcp lan bug with guess wifi and trunk lan port)... I have also found than once i disable the guess network at the end of post #99 (which repair the main dhcp problem), then reenable it, and assigned a trunk again to the 2.5gbps lan port (same i did in post #99 the 1st...

www.snbforums.com

Beta - Asuswrt-Merlin 3006.102.7 Beta is now available

Deeper analysis (main dhcp lan bug with guess wifi and trunk lan port)... I have also found than once i disable the guess network at the end of post #99 (which repair the main dhcp problem), then reenable it, and assigned a trunk again to the 2.5gbps lan port (same i did in post #99 the 1st...

www.snbforums.com

Beta - Asuswrt-Merlin 3006.102.7 Beta is now available

Deeper analysis (main dhcp lan bug with guess wifi and trunk lan port)... I have also found than once i disable the guess network at the end of post #99 (which repair the main dhcp problem), then reenable it, and assigned a trunk again to the 2.5gbps lan port (same i did in post #99 the 1st...

www.snbforums.com

 

[jksmurf]

@mistermoonlight1

Hmm I’m really at a loss as to what to suggest as mine isn’t a DHCP issue when I have VLAN Access Mode enabled for my IoT Network, but rather devices appearing for all intents and purposes to be connected to the nodes but not being accessible via ping or the devices little WebGui.

So a bit different to your issue, the commonality being VLAN settings on nodes.

 

[penguin22]

@mistermoonlight1

Hmm I’m really at a loss as to what to suggest as mine isn’t a DHCP issue when I have VLAN Access Mode enabled for my IoT Network, but rather devices appearing for all intents and purposes to be connected to the nodes but not being accessible via ping or the devices little WebGui.

So a bit different to your issue, the commonality being VLAN settings on nodes.

While mine looks like this more than DHCP, I haven't ruled it out. Clients look connected from the router but report disconnected from the client, and that is across all IoT devices, not only one type. Since making the single change of All(Default) on the single wired VLAN port of my BE86U mesh node, I have had full stability without any clients losing connection.

 

[mistermoonlight1]

@bennor
Hi
As you followed at some point and tried to help on this issue, here are some additionnal information i discovered about the main dhcp problem and vlan configurations.

The problem is in the way windows "ipconfig /renew" deal with dhcp request. If the interface has already got a lease at some point, it already knows the gateway/dhcp server address. So when a "/renew" is issued, windows dhcp client does not release the current dhcp lease. This will cause a request like this:
DHCP Request 192.168.50.1 (router address) and normally, the main lan dhcp of the router will answer with a DHCP ACK to 192.168.50.100 (windows client address) directly, so no dhcp broadcast is used in this situation at all (direct communication between the dhcp client and dhcp server). This is working in many scenario, but at some point with different configurations of GNP VLAN, it simply does not work at all reliably anymore (and even if the dhcp server has already a leased of the window client displayed ih router "DHCP leases" tab).

But if the windows client is doing a full broadcast DHCP protocol sequence instead of direct communication with the DHCP server, using this sequence
DHCP Discover 255.255.255.255, DHCP Offer 255.255.255.255, DHCP Request 225.255.255.255, DHCP Ack 255.255.255.255, it is always working in the situation where the previous sequence above may not, even with complicated vlan configuration!
So one way with a window client to achieve the full broadcast DHCP protocol is to release the previously leased (if it already has one) with a sequence like this "ipconfig /release && ipconfig /renew".

I don't have any idea why changing GNP vlan configurations may affect this behavior and simply disabling some vlan guess config could make the simple direct dhcp communication working or not (only direct DHCP Request,Ack to the server)...