Unnecessary DHCP Discover from Bridged Interface

I have LEDE 17.01.02 running on a Buffalo router. The Buffalo is configured exclusively as a wireless access point. I have a pfSense gateway/firewall/router box that is providing dhcp service to my entire network. The wireless AP has two VLans configured, one private and one guest.

My network configuration to the access point looks like this:

Incoming WAN ---> pfSense Gateway / Firewall / Router ---> Managed Switch (Netgear) with 3 VLANs (1=home wired vlan, 20=private wireless vlan, 30=guest wireless vlan) ---> Buffalo AP

pfSense Router = 192.168.123.2
Netgear Managed Switch = 192.168.123.4
Wired LAN = 192.168.123.xxx
Private Wlan = 192.168.124.xxx
Guest Wlan = 192.168.133.xxx
Buffalo LAN interface = bridged to Wlan
Buffalo WAN interface = 192.168.123.5 (management interface)

I am seeing in my DHCP logs a DHCP Discovery query coming from the MAC address of the Buffalo LAN interface. My DHCP server replies with a DHCP Offer, but the DHCP handshake ends there. The logs show that this sequence happens continuously every three seconds. Since the Buffalo LAN interface is bridged to the Wlan it actually does not have an IP address itself, and the DHCP exchange appears to be unnecessary. I am wondering how to stop the continuous discovery/offer exchange.

The configuration of my LAN bridged interface is listed below.

config interface 'lan'
	option type 'bridge'
	option _orig_ifname 'eth0 radio0.network1 radio1.network1'
	option _orig_bridge 'true'
	option proto 'dhcp'
	option ifname 'eth0.1'
	option hostname 'buffaloap-lan'

I see that the protocol is listed as 'dhcp', which is probably what is initiating the DHCP Discovery. I have the DHCP service disable on startup, but I do see that the odhcpd service is still enabled. The protocol options in the GUI for the bridge include 'Static', 'Dhcp-Client', and 'Unmanaged', and a list of others that don't appear to be relevant.

I don't think that I want to set the protocol to Static, since the bridge does not use an IP address directly. So that leaves me with trying to understand whether disabling the odhcpd service or changing the protocol to unmanaged is what is needed here. The documentation that I have reviewed doesn't make it clear to me whether one of these changes would solve the problem, or produce an unwanted side effect. I don't find anything describing what the unmanaged protocol does. It could also be possible that there is something else creating this problem that I haven't considered.

Thanks.

To be clear:

  • You don't want the interface to be DHCP; and
  • You don't want to statically address it

Of course it doesn't, you haven't set an address.

Perhaps you can tell us more about why you don't want to address it. Because I'd just suggest address it in another subnet.

Also, dnsmasq is likely sending those requests (if you didn't change that); but turning that off will turn off DNS (but you're getting that via DHCP).

It does nothing but enumerate the interface in OpenWrt for firewall purposes. If if you don't use command line to address it, nothing happens. Perhaps you should explain your use case better.

Thanks for reviewing this. It seems like maybe I wasn't clear enough in my description so I will try to clarify things and address your questions.

It was not initially clear to me whether this was your recommendation to me, or whether you were trying to restate what I described. I don't think it is your recommendation because your further statements below appear to contradict these. But these statements also do not accurately reflect what I stated. Regarding the first bullet, I show that the interface protocol is currently listed as DHCP, and speculate that this may be why I am seeing the continuous DHCP Discovery queries, and probably don't want that setting. This was just describing my thought process and not making a conclusion that I do, or don't, want something. Regarding the second bullet, I stated that I don't think I want to set the protocol as Static. Again, this is describing my thought process and not making a conclusion.

I don't state that I don't want to use an IP address on the bridge directly. This is just the current configuration of my setup, in that the bridge does not have an IP address. I followed guidance mostly from the LEDE and OpenWRT websites to setup the Access Point and VLANs. This configuration has been working fine for over a year now (and is still working fine right now) without an IP address on the bridge and does not appear to have any problems routing or passing traffic through the Access Point and bridge. Since my recent research on IP addresses on bridges seems to indicate that they are not necessary, and can be left off in scenarios which seem to match my network configuration. That is probably why the guidance documents I followed showed it that way. Will putting an IP address on the bridge solve the issue of continuous DHCP Discover requests, without causing unintended consequences elsewhere? And what would be the purpose / reason / benefit of using another subnet for the bridge interface?

I agree, something is initiating the sending of those requests, but I don't know what the origin of them are. I do know that the DHCP service is turned OFF by default in my configuration, but mentioned I don't know if the odhcpd service (which is turned ON) might be involved in this. All of my network DHCP and DNS is handled centrally through my pfSense gateway / firewall / router box. It even manages the VLANs on the wireless access point.

If that is about all the unmanaged protocol does, then using that protocol may not change the continuous DHCP Discover requests. My firewall is managed through my pfSense box, and the firewall on the bridged LAN of the Access Point is set to Accept on both the Input, Output, and Forward settings.

Well I am not sure what more information will explain my use case. To summarize what I said before, I have a wireless access point with two VLANs (private and guest network) bridged to my wired network and my internet gateway. Everything passes traffic just fine, everything gets the appropriate static and dynamic IP addresses they way it is configured. The only issue I am trying to understand is the source of the continuous DHCP Discover requests in my logs every three seconds, whether it is something that can be eliminated, and how to do that.

What I do know from my logs, is that the request is originating from the MAC address of the Bridged LAN interface on the wireless access point, and therefore I suspect that it has something to do with the way I have LEDE / OpenWRT configured. Below is the DHCP exchange from my log file that repeats every three seconds.

Dec 29 15:44:04 	dhcpd 		DHCPOFFER on 192.168.123.181 to 10:6f:3f:e7:f3:de (buffaloap-lan) via igb1
Dec 29 15:44:04 	dhcpd 		DHCPDISCOVER from 10:6f:3f:e7:f3:de (buffaloap-lan) via igb1 

I'm not sure if you're ignoring me or you don't want to take my advice...or missed something in my post...but if you want to stop the DHCP requests, simply turn it off (you quoted me, so you know what to turn off).

I hope everything else was explained and understood.

EDIT: I merely suggested another subnet because you seemed insistent upon not using an IP on that VLAN (and you have a management IP instead). You can simply turn off dnsmasq; or statically address the interface (I simply suggest changing it back to static, and not playing with other things). It's not too difficult of a choice.

Not ignoring you. I was also trying to consider other options that didn't add a static address to the interface through OpenWRT, when all my DHCP is managed centrally at my pfSense gateway box. Adding exceptions to a centrally managed system just makes for problems later when the exceptions are forgotten. I guess that ties into describing my use case scenario, which may not have been made explicit. I may also have mis-understood something in your posts regarding turning off DHCP, as I mentioned that it is disabled on the access point at bootup, but that the ODHCPd service is running and mentioned being curious about the effect of that running while DHCP is turned off.

So I have done some trial and error testing and seemed to have stopped the DHCP Discover requests from originating from the bridged LAN interface.

Test #1 - Disabled the ODHCPd service on the wireless AP on bootup. The DHCP service had already been disabled, so now they were both disabled. Rebooted the system to make sure that all changes were applied. The result is that DHCP Discovery queries were still being sent from the bridged LAN interface every three seconds.

Test #2 - Changed the protocol on the bridged LAN interface from DHCP-Client to Unmanaged. (For test #1 above this setting was DHCP-Client). Rebooted the system to make sure that all changes were applied. The result is that DHCP Discovery queries from the bridged LAN interface stopped.

So my conclusion is that an interface using the DHCP-Client protocol will continue to send DHCP Discovery requests even though the DHCP and ODHCPd services are disabled and off. I don't know if that is the intended design and a feature to the system, or whether it is an odd / buggy effect. It just didn't seem logical from my existing knowledge, but that could just be my lacking of specific knowledge of the specifications of how interfaces work.

Thanks for the guidance that allowed me to narrow down my options and figure out a solution that works for my case. And in the process I have added to my knowledge, which is just as import to me as finding a solution.

I'm not sure why you didn't disable dnsmasq then.

Glad you fix it, though.

:man_facepalming:

It really seems like you're ignoring me, though. Since dnsmasq does this, turning off the other services still makes no sense.

Ok, I just realized the mis-understanding / confusion between our discussion. I was stating that the DHCP service was disabled/stopped. When I should have been using the proper terminology that is listed in the OpenWRT system services list, which is dnsmasq. So if anyone else stumbles upon this post to help them with their problem, replace all references above regarding the DHCP service with dnsmasq service.

So to clarify the dnsmasq service had been disable on my system (for at least a year) and I was still getting the DHCP Discovery queries coming from the bridged LAN interface. It is only after changing the interface to unmanaged that the DHCP Discovery queries stopped.

Sorry for the confusion.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.