Force dhcp isn't working, other dhcp keeps assigning an ip

Situation:
-Linksys WRT3200ACM with OpenWrt 19.07-SNAPSHOT
-Linksys Velop nodes XM5300 (3 nodes) in bridge mode.

In bridge mode the guest network still has an dhcp server up and forces an ip to guest clients.
For now it isn't possible to stop the dhcp server on the nodes for the guest network, yes even in bridge mode ;-(

(I'm in a discussion with Linksys that that is not bridge mode. But a crippled version of it...)

My guest network is on vlan id 3. This is the vlan the velop nodes are on according to Linksys.

I have the guest network on "force dhcp" so my guest clients are on 10.0.33.x and my main lan is on 10.0.1.x

The main lan is working perfectly, the guest network is fighting the other dhcp server, even on "force dhcp"

Sometimes the ip is from the router (10.0.33.x) and sometimes it's on that from the velop nodes (192.168.3.x)

As you can see, the openwrt router is realy trying to give the client a ip address, but the node wins, regardless the force option.

It is trying to give the client the ip 10.0.33.55, but it is getting the one from the node 192.168.31.131 and than it says that's a wrong server id.

BusyBox v1.30.1 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 19.07-SNAPSHOT, r11328-81266d9001
 -----------------------------------------------------
root@ROUTER_STABLE:~# logread -f | grep dhcp
Mon Mar 29 19:00:39 2021 daemon.info dnsmasq-dhcp[16677]: DHCPDISCOVER(br-guest) 3a:f5:bf:44:69:f8
Mon Mar 29 19:00:39 2021 daemon.info dnsmasq-dhcp[16677]: DHCPOFFER(br-guest) 10.0.33.55 3a:f5:bf:44:69:f8
Mon Mar 29 19:00:39 2021 daemon.info dnsmasq-dhcp[16677]: DHCPDISCOVER(br-guest) 3a:f5:bf:44:69:f8
Mon Mar 29 19:00:39 2021 daemon.info dnsmasq-dhcp[16677]: DHCPOFFER(br-guest) 10.0.33.55 3a:f5:bf:44:69:f8
Mon Mar 29 19:00:40 2021 daemon.info dnsmasq-dhcp[16677]: DHCPREQUEST(br-guest) 192.168.3.131 3a:f5:bf:44:69:f8
Mon Mar 29 19:00:40 2021 daemon.info dnsmasq-dhcp[16677]: DHCPNAK(br-guest) 192.168.3.131 3a:f5:bf:44:69:f8 wrong server-ID
^C
root@ROUTER_STABLE:~#

Is there any way, I can really force to use the dhcp from my OpenWrt router?

By the way, my guest network is working perfectly if I attach for the test an openwrt of other access point that has no dhcp up.

Before this I had apple airport extremes as access points on vlan id 1003, that worked fine. So i asssume it's really the dhcp server that's bothering me.

The Velop nodes are on ther own version of OpenWrt, I gues there is no firmware from the community. (At least I can not find them) So I can configure them completely as I wish.

Only by stopping/disabling/disconnecting the other DHCP server.
Also, there are methods to isolate client traffic from each other.

2 Likes

The problem is that it's impossible to stop/disable/disconnect the dhcp server at the node on the current linksys firmware. Even in bridge mode...

How can I isolate client traffic from each other?

1 Like

Really?

I've never seen a consumer router firmware where DHCP cannot be turned off, interesting.

(I guess that's to prevent people from buying it and using it an AP only...? :man_shrugging: )

1 Like

Really,

That wasn't something advertised in the specs of the device..

Hello Raymond,

Thanks for reaching our inbox to discuss this matter. The Velop Guest Network has its own IP pool. Its IP address is always 192.168.3.x by default since it's a separate network. Moreover, there is no option to change that because it's a reserved IP range for the guest feature. There’s no option to disable the IP service other than disabling the Guest network completely.

Hope this helps.

Regards,

Linksys Support
www.linksys.com

And m y reply..

Hello Linksys,

Thanks for your quick reply.
I understand what you are saying. My (and many many others) point is that, when you offer a “bridge mode” it should be bridge mode.

So when someone needs a guest network, they have to set this up in there router and use vlan id’s to accomplish this.

I bought this nodes for the main purpose it has a bridge mode option. It works as expected for the “ normal” wifi, so no complains there.
It’s strange that it’s not for the guest network. It’s simple made this way, so that not so technical users can have bridge mode and have a guest network without any issues.

There should be an option (hidden if needed) so a user can disable the dhcp option completely on the node)

And for as far as I can see, there’s no technical problem to do this, because the sysinfo tells me it’s running a linux version.

page generated on Sun Mar 28 08:21:38 UTC 2021

UpTime:
08:21:38 up 16:08, 0 users, load average: 2.00, 2.02, 2.00

Firmware Version: 1.1.9.200251
Firmware Builddate: 2020-03-05 04:54
Product.type: production
Linux: Linux version 4.4.60 (root@build-vm) (gcc version 5.2.0 (OpenWrt GCC 5.2.0 998fe11+r49254) ) #1 SMP Wed Mar 4 19:36:57 PST 2020
Board:

So we hope that I made my point, and Linksys will take this in recommendation in a future firmware.

Best regards,

Raymond

:confused:

Why are you using a limited guest feature on Linksys then, when you can create whatever you want on the OpenWrt?

(I'll re-read the thread...)

Because the nodes are all over the house and my OpenWrt router can't cover the whole house.
So If this (The Linksys Velops) had worked as aspected it would be ok :wink:

I have a working guest lan on my openwrt router, but the wifi cannot reach the whole house.

What you can do on OpenWrt is isolating the problematic device that you cannot disable the DHCP server role in a separate VLAN/SSID, or setting up bridge firewall, or enabling Wi-Fi client isolation.

It may not be supported or documented, but customizing the device behavior should be possible if you manage to gain admin SSH privileges with official or unofficial/hacky means.
However, that's outside the scope of this thread/forum.

Also note that each of the isolation methods has its own limitations and drawbacks.
Depending on your network topology and hardware specifics, some of the methods may suit your needs better and can be more or less effective than others.

1 Like

If I could ssh into the device (it's an openwrt version off some kind) then I would stop the dhcp service offcourse.

But I do not know how to hack into the device, any thoughts? Normal ssh port is closed.

I'm reading the other options, and going to give that a try also.. But hacking into the device has my preference offcourse.

Am I missing something, can you workaround by using the guest DHCP and disabling OpenWrt's?

:laughing:

Indeed!

The linksys nodes are in bridge mode, this means that they get an ip from my normal lan.
So if I use the guest network from the nodes, with a fixed different ip range, it still routes through my normal lan and thus can access my other clients/nas/etc on my lan.

Because the lan wifi from my openwrt router is on the nodes (that's why I have them on bridge mode) they are going through the same route.

This should work, but I do not know how to separate lan from guest clients if they are routed through the same ip adres from the node.

I'm reading in on the options that @vgaetera is giving me, "separate VLAN/SSID, or setting up bridge firewall, or enabling Wi-Fi client isolation"

Somehow I think one of this options is what I need in this case. (or get ssh access offcourse :wink: )

I think I have a thinking error.... (that is on daily basis by the way :wink: )

The lan wifi user are routed by Openwrt, they have there own ip addresses offcourse and are handled bij openwrt.

So only the guest clients are routed through the ip addresses from the nodes. So all there traffic must be visible somehow.

Or is this false too?

Just tested, I think al guest wifi traffic is going through this one ip (from the node)

So I have to isolate this ip addresses from the rest, am I right?

Any news about that? I am struggling at the same point... the problem is, that all guest clients are getting through NAT at the parent node... I just can notice the parent node IP address :confused:

thx!

so long