How to solve repeated DHCPDISCOVER requests?
 

Message sets like this are appearing in the dhcpd log every 10 seconds:
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.

Thanks nikmit :)

Unfortunately I don't have access to the switches but I will suggest it to the network support person.

Anticipating no fast response from him, is anything else possible?

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 :)

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.

...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 ...

1. The rogue device is a printer server.
2. The network uses D-link switches.
3. The network is configured with VLANs.
4. 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.
5. 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.
6. 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 ... ?).
7. There is some hope of a resolution by upgrading the firmware in the D-link switches (and maybe the printer server).
8. Meanwhile a workaround is to configure our Debian server's NICs for VLAN 30.

Sounds messy. I will try the suggested workaround.

It really seems like this should be 'somebody else's problem...', but

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)?

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 ...

The problem "went away" several days ago and the network support person has not responded to my "did you change anything" mail.

Marking this thread SOLVED.