very long MAC addresses in DHCP logs.

Question

Level 1

25 points

very long MAC addresses in DHCP logs.

i was just trying to make a static map for a new server i bought recently. did it the same way i always do... grab the Ethernet MAC address from the machine and copy it into the DHCP static maps section on the server. then make a DNS entry.

but i noticed... for whatever reason the new machine was never getting the statically mapped address. at all.

looked in the DHCP logs for clues.

for some reason the new machine has a very long MAC address. one that is too long to ever enter in the static maps section. it is also not even remotely related to the MAC address the machine itself thinks it has.

normally a MAC address looks like :

00:1a:2b:3c:4d:5e

6 pairs.

and the DHCP logs normally look like this :

bootpd[71573]: DHCP REQUEST [en1]: 1,0:17:f2:3:4b:5c

this new machine... the requests are NOT 6 pair and thus don't work.

bootpd[71573]: DHCP REQUEST [en1]: 0,54:4d:73:65:72:76:65:7

so basically... what is up with that? and what number is that? why is it requesting it with that number? why isn't it using its normal MAC address?

and most importantly... how do i fix it?

thanks!

Posted on Jan 9, 2009 2:49 PM

Reply

Answer 1

mhanson

Level 1

0 points

Feb 16, 2009 12:32 PM in response to Bryce Polly

I am having the same problem, in addition to some other strange DHCP happenings.

We are getting many IP conflicts. Our clients come up with a message from IP Configuration which says (for example) "192.168.1.60 is in use by 43:68:61:6e:67:65 DHCP Server 192.168.1.10"

DHCP scopes have been recreated along with /etc/bootpd.plist /var/db/dhcpd_leases

Here is a snipit from a log to show you some of the strangeness. Any advice would be greatly appreciated.

Feb 16 15:19:37 RMSInfoServer bootpd[64239]: dhcpd: IP 192.168.1.46 declined by 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: service time 0.000715 seconds
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: service time 0.000167 seconds
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: service time 0.000093 seconds
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:37 RMSInfoServer bootpd[64239]: service time 0.000121 seconds
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-2>
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.47 pktsize 349
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: service time 0.001576 seconds
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-19>
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.47 pktsize 349
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: service time 0.000574 seconds
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-20>
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.47 pktsize 349
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: service time 0.000435 seconds
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-11>
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.47 pktsize 349
Feb 16 15:19:47 RMSInfoServer bootpd[64239]: service time 0.000416 seconds
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-2>
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: ACK sent <no hostname> 192.168.1.47 pktsize 349
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: service time 0.000942 seconds
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-19>
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: ACK sent RMS-Emac-Lab-19 192.168.1.47 pktsize 349
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: service time 0.000786 seconds
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-20>
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: ACK sent RMS-Emac-Lab-20 192.168.1.47 pktsize 349
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: service time 0.000608 seconds
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-11>
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: replying to 192.168.1.47
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: ACK sent RMS-Emac-Lab-11 192.168.1.47 pktsize 349
Feb 16 15:19:48 RMSInfoServer bootpd[64239]: service time 0.000727 seconds
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: dhcpd: IP 192.168.1.47 declined by 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: service time 0.000864 seconds
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: service time 0.000148 seconds
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:19:49 RMSInfoServer bootpd[64239]: service time 0.000116 seconds
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-19>
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.48 pktsize 349
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: service time 0.001540 seconds
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-20>
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.48 pktsize 349
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: service time 0.000492 seconds
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-11>
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: OFFER sent <no hostname> 192.168.1.48 pktsize 349
Feb 16 15:19:59 RMSInfoServer bootpd[64239]: service time 0.000472 seconds
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-19>
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: ACK sent <no hostname> 192.168.1.48 pktsize 349
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: service time 0.000972 seconds
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-20>
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: ACK sent RMS-Emac-Lab-20 192.168.1.48 pktsize 349
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: service time 0.000567 seconds
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: DHCP REQUEST [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-11>
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: replying to 192.168.1.48
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: ACK sent RMS-Emac-Lab-11 192.168.1.48 pktsize 349
Feb 16 15:20:00 RMSInfoServer bootpd[64239]: service time 0.000619 seconds
Feb 16 15:20:02 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:20:02 RMSInfoServer bootpd[64239]: dhcpd: IP 192.168.1.48 declined by 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:20:02 RMSInfoServer bootpd[64239]: service time 0.000737 seconds
Feb 16 15:20:02 RMSInfoServer bootpd[64239]: DHCP DECLINE [en0]: 0,43:68:61:6e:67:65:5f:4d:65
Feb 16 15:20:02 RMSInfoServer bootpd[64239]: service time 0.000123 seconds
Feb 16 15:20:12 RMSInfoServer bootpd[64239]: DHCP DISCOVER [en0]: 0,43:68:61:6e:67:65:5f:4d:65 <RMS-Emac-Lab-11>

Reply

Answer 2

Dogcow-Moof

Level 8

36,839 points

Feb 27, 2009 8:40 PM in response to mhanson

These are Mac OS X bootp client identifiers, which are in the format:

"0, ASCII bytes"

for what are DHCP clients that have supplied custom client IDs, or

"1, MAC Address"

for those that have supplied just hardware NIC addresses.

So, 0,43:68:61:6e:67:65:5f:4d:65 is the interface that supplied the DHCP Client ID Change_Me.

0,54:4d:73:65:72:76:65:7 is the is the interface that supplied the Client ID TMserve followed by a ^G (or a digit got dropped from the post.)

1,0:17:f2:3:4b:5c is the NIC with the MAC address 00:17:F2:03:4B:5C.

The DHCP client identifier, for those who are curious, is specified in RFC 2132 as option 61, and is configured on hosts in a variety of different ways, and also depends on whether the host is attempting to comply with RFC 4361 or not.

Regardless, if you have machines sending a DHCP Client ID, it may have been modified by you or a previous user and you should clear it.

To quote Princeton University:

Most Common Reasons For a Mismatched DHCP Client Identifier

The most common reasons that a DHCP client will send a DHCP Client Identifier that differs from its hardware type and client hardware address include:

* Sometimes customers mistakenly enter text into the DHCP Client Identifier field in the device's network settings. This is easy to correct; clear that field entirely; it shouldn't even contain spaces.

Here's where that setting is located for some common platforms:

o Mac OS X 10.5: System Preferences -> Network -> Select network interface on left (e.g., Ethernet or AirPort) -> Advanced (button) -> DHCP Client ID

o MS Vista: Control Panel -> Network and Sharing Center -> Manage Network Connections -> Local Area Connection (right click) -> Properties -> Configure -> Advanced -> Locally Administered Address

o iPhone/iPod Touch: Settings -> WiFi -> network name (e.g. puwireless) -> Client ID

* Some HP printers send an mismatched DHCP Client Identifier due to an issue in the printer's DHCP client software. Instead of sending the DHCP Client Identifier by concatenating the hardware type (normally '01') and the hardware address, they generate the DHCP Client Identifier by concatenating '00' and the hardware address.

If the printer's DHCP client software can be reconfigured to stop sending any DHCP Client Identifier, you may choose to do that. Otherwise, reconfigure the printer so it doesn't rely on its DHCP client software.

* Enabling Microsoft "Remote Access Server" (RAS) feature can sometimes cause it to send requests with an unusual DHCP Client Identifier, which begin with 01 52 41 53 20.

Apparently, these are attempts by RAS to obtain additional IP addresses for potential dial-in clients. In nearly all cases, RAS was enabled by mistake; disabling it will resolve the issue.

* Running a virtual machine (VM) in such a way that the VM asks for its own DHCP lease with a unique DHCP Client Identifier will cause this problem.

* Some DHCP clients send a DHCP Client Identifier which contains an Identity Association Unique Identifier (IAID) followed by a DHCP Unique Identifier (DUID). In this case, the DHCP Client Identifier may begin with FF.

The DHCP client software may use terminology such as "enabling DUID" to refer to this behavior. In that case, reconfiguring the DHCP client software to "disable DUID" may cause the DHCP client to instead send the kind of DHCP Client Identifier we expect: a hardware type followed by a hardware address.

* A Sun Advanced Lights-Out Management (ALOM) card attempting to obtain DHCP service will construct a DHCP Client Identifier which begins with 00 53 55 4E 57 2C 53 43 3D.

Reconfigure the ALOM card so it doesn't rely on DHCP to obtain its IP address. Or if you had attached the ALOM card's Ethernet interface to the campus network in error, simply disconnect the ALOM card's Ethernet interface from the campus network.

http://www.net.princeton.edu/announcements/dhcp-cliid-must-match-chaddr.html

Reply

Answer 3

Mar 4, 2009 6:19 AM in response to Bryce Polly

In all likelihood, you have very specific reasons for using DHCP to set the IP address of your server. If you do not have a specific reason to use dynamically assigned addressing for a server, you can eschew the problem by using a fixed IP address.
I've never seen an instance where anyone recommended using DHCP to give a server its IP address under normal use. I believe this would be especially problematic with an OS X server running Open Directory and Kerberos.
Either way, best of luck.
Regards,
Lyle Millander

Reply