Hostname differences between servers

Norman Elton normelton at gmail.com
Tue Oct 2 20:14:58 UTC 2018


Keith gets a gold star for explaining it more clearly. My head is
hurting from staring at log files all day! Rather than interpret the
log files, perhaps it's easiest just to share the relevant snippets:

## ANDROID DEVICE COMING ONLINE
Sep 30 13:53:46 landlord01: DHCPDISCOVER from c0174ddd00a4
(android-9375f90cad51e32f) via 10.45.13.2
Sep 30 13:53:46 landlord02: DHCPDISCOVER from c0174ddd00a4 via 10.45.13.2
Sep 30 13:53:46 landlord01: DHCPOFFER on 10.45.13.73 to c0174ddd00a4
(android-9375f90cad51e32f) via 10.45.13.2
Sep 30 13:53:46 landlord02: uid lease 10.45.13.196 for client
c0174ddd00a4 is duplicate on INIT-MONROE
Sep 30 13:53:46 landlord02: DHCPOFFER on 10.45.13.196 to c0174ddd00a4
(android-9375f90cad51e32f) via 10.45.13.2
Sep 30 13:53:46 landlord02: DHCPREQUEST for 10.45.13.73
(128.239.10.121) from c0174ddd00a4 via 10.45.13.2: lease owned by peer
Sep 30 13:53:46 landlord01: DHCPREQUEST for 10.45.13.73
(128.239.10.121) from c0174ddd00a4 (android-9375f90cad51e32f) via
10.45.13.2
Sep 30 13:53:46 landlord01: DHCPACK on 10.45.13.73 to c0174ddd00a4
(android-9375f90cad51e32f) via 10.45.13.2

## IPHONE COMING ONLINE
Oct  1 01:03:46 landlord01: DHCPDISCOVER from e8802ea2eb7f via 10.45.13.2
Oct  1 01:03:46 landlord02: DHCPDISCOVER from e8802ea2eb7f via
10.45.13.2: load balance to peer wm-dhcp-01-02
Oct  1 01:03:46 landlord01: DHCPOFFER on 10.45.13.196 to e8802ea2eb7f
(Michaels-iPhone) via 10.45.13.2
Oct  1 01:03:48 landlord02: DHCPREQUEST for 10.45.13.196
(128.239.10.121) from e8802ea2eb7f (android-9375f90cad51e32f) via
10.45.13.2: lease owned by peer
Oct  1 01:03:48 landlord01: DHCPREQUEST for 10.45.13.196
(128.239.10.121) from e8802ea2eb7f (Michaels-iPhone) via 10.45.13.2
Oct  1 01:03:48 landlord01: DHCPACK on 10.45.13.196 to e8802ea2eb7f
(Michaels-iPhone) via 10.45.13.2

Landlord02 offers 10.45.13.196 to the Android on September 30th, then
regurgitates that hostname on October 1st when the iPhone is
connecting.

Question is ... why does dhcpd log the hostname from its lease file
when that lease is irrelevant to the client in question?

Norman

On Tue, Oct 2, 2018 at 3:50 PM Neufeld, Keith <Keith.Neufeld at wichita.edu> wrote:
>
> In the previous example, e8802ea2eb7f (an Apple device) is requesting
> 10.45.13.196. One server, landlord02, is erroneously stating that the
> client hostname is android-9375f90cad51e32f. It turns out that, a few
> days ago, landlord02 offered this IP address to an Android device with
> the hostname of android-9375f90cad51e32f. Looking at the source code,
> it appears that dhcpd is not reporting the hostname found in the
> packet, but rather, the information collected from its lease file.
>
>
> Norman, since we see the REQUEST relayed by your router, it’s a broadcast REQUEST.  I’m assuming this is part of the initial broadcast DISCOVER - OFFER - REQUEST - ACK sequence, and not a later REQUEST being broadcast?  (That can happen but only under special circumstances.)
>
> I speculate that this happened:
>
> 1.  The client did a broadcast DISCOVER that was relayed to both servers.  Possibly both of them logged the correct client-hostname in their DISCOVER messages.
> 2.  Both servers sent OFFERs back toward the client via the relay.  landlord01’s OFFER was for 10.45.13.196 ; landlord02’s OFFER was for some other IP.
> 3.  The client decided to accept landlord01’s offer and broadcast a REQUEST for that offer.
> 4.  landlord01 received the REQUEST and logged it correctly.
> 5.  landlord02 received the REQUEST and, recognizing that it was in response to an OFFER made by its peer, logged it without inspecting the packet for current supplemental data, leaving in place the cached client-hostname from the last client to hold this lease (IP) when offered by landlord02.
>
> That is to say, client-hostname tends to stay cached a long time, misleadingly, in the lease database of the peer of the server that’s handling the client currently holding that lease / IP.
>
> That’s … more difficult to phrase than I expected it to be.  Perhaps there’s an easier way to describe it.
>
> --
> Keith Neufeld
> Director of Networking, Telecommunications, and IT Security
> Wichita State University
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


More information about the dhcp-users mailing list