[SOLVED] How to solve repeated DHCPDISCOVER requests?
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Message sets like this are appearing in the dhcpd log every 10 seconds:
Code:
May 17 14:52:46 LS1 dhcpd: Adap-lease: Total: 20, Free: 8, Ends: 110, Adaptive: 600, Fill: 25, Threshold: 75
May 17 14:52:46 LS1 dhcpd: DHCPDISCOVER from 00:1b:11:1f:98:d6 (PS-1F98D6) via eth0
May 17 14:52:46 LS1 dhcpd: DHCPOFFER on 192.168.3.31 to 00:1b:11:1f:98:d6 (PS-1F98D6) via eth0
AFAIK that shows the device with MAC address 00:1b:11:1f:98:d6 is repeatedly requesting and IP address and being offered one but does not accept it. It does not show in arp -a output.
The network support person is unable to help. Is there any way to identify the device?
Look at the mac address tables on your switches. They map MAC addresses to port numbers. Once you know which port that PC is plugged in, you should be able to locate it.
Well as much as that client is obviously not getting an IP, you could drop these requests. This will save you the logs. If you feel adventurous and/or your environment allows it, you can drop more aggressively (is that machine out of date, or compromised?) and wait for someone to come with a support request to you for it
If you feel adventurous and/or your environment allows it, you can drop more aggressively (is that machine out of date, or compromised?) and wait for someone to come with a support request to you for it
That suggestion, which will almost inevitably be seen as unhelpful by someone irrespective of whether the PC was currently able to work, was on my list, too.
One thing that may be possible, depending on the total number of ports that you would have to scan, would be to have a look at the 'blinkenlights'. Anything that has a particularly regular pattern, say a flash or a double flash every ten seconds is automatically suspect. Particularly, out of normal hours.
Quote:
Anticipating no fast response from him...
...that seems like a reasonable presupposition, then if you are wrong it is a pleasant surprise...
Remember, it isn't necessarily a particularly complex fault - it could be something as moronic as one of the wire pairs in the ethernet being bad, so the data can only go in one direction, or something.
Thanks nikmit and salasi -- for the advice and the humour
I will give the network support person a while to identify the device and, if nothing comes of that, have a look for flashing NIC LEDs out of hours. If that doesn't identify the device, I will configure it out of the DHCP config.
I don't understand the details but after speaking with the network support person ...
The rogue device is a printer server.
The network uses D-link switches.
The network is configured with VLANs.
The rogue device is attempting to do a "MAC rendezvous". I have found references to this term online but no explanation; the overwhelming majority of netsearch hits are about Apple computers and a software that used to be called Rendezvous. A more targeted netsearch did not find an explanation either.
The "MAC rendezvous" broadcasts are incorrectly being passed by the switches to the VLAN with our Debian DHCP server and incorrectly being interpreted as DHCPDISCOVER requests.
Because of the VLAN configuration the DHCPOFFER packets are not reaching the printer server (which would presumably ignore them anyway because it never sent a DHCPDISCOVER ... ?).
There is some hope of a resolution by upgrading the firmware in the D-link switches (and maybe the printer server).
Meanwhile a workaround is to configure our Debian server's NICs for VLAN 30.
Sounds messy. I will try the suggested workaround.
Last edited by catkin; 05-21-2012 at 05:10 AM.
Reason: typodynamics
It really seems like this should be 'somebody else's problem...', but
Quote:
Originally Posted by catkin
The rogue device is attempting to do a "MAC rendezvous". I have found references to this term online but no explanation; the overwhelming majority of netsearch hits are about Apple computers and a software that used to be called Rendezvous. A more targeted netsearch did not find an explanation either.
The "MAC rendezvous" broadcasts are incorrectly being passed by the switches to the VLAN with our Debian DHCP server and incorrectly being interpreted as DHCPDISCOVER requests.
Rendezvous/Avahi/mDNS (etc) are broadly similar protocols; I think that the list of capabilities may be slightly different between the different versions and different vintages, but they all work along similar lines. This is all quite similar to DHCPDISCOVER (in intent), so I guess a level of confusion may be understandable.
I have to ask, failing some one responsible for network support taking an interest (which is what ought to happen), to what extent is it a real problem, and to what extent is it just an irritating little thing that you could ignore (while still pointing out that it somebody else's problem)?
I have to ask, failing some one responsible for network support taking an interest (which is what ought to happen), to what extent is it a real problem, and to what extent is it just an irritating little thing that you could ignore (while still pointing out that it somebody else's problem)?
Thanks salasi
The only real problem is filling the dhcpd log, obscuring perhaps relevant messages. AFAIK from nikmit's advice earlier in this thread, that problem could be solved by configuring dhcpd to drop requests from the problem device's MAC address.
Against that solution is a general desire to keep things simple, to keep configurations clean and minimal with "no surprises" for ease of future maintenance.
In the light of those considerations and being pragmatic, solution by dhcpd configuration is more attractive than configuring a VLAN on the server's NIC ...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.