Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Hostname differences between servers (Norman Elton)
2. Migration from ISC 4.4.1 to Red Hat dhcpd (ISC 4.1.1-P1)
(Pereida, Alejandro)
3. Upgrade 4.2.4->4.3.5 (Gregory Sloop)
----------------------------------------------------------------------
Message: 1
Date: Tue, 2 Oct 2018 16:14:58 -0400
From: Norman Elton <normel...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Hostname differences between servers
Message-ID:
<CAPCnwUf7BPZmCcuiB2QL7tsUM_=qiv5uhtdsucmbz4vtcfi...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.neuf...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Wed, 3 Oct 2018 00:12:42 +0000
From: "Pereida, Alejandro" <apere...@iid.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Migration from ISC 4.4.1 to Red Hat dhcpd (ISC 4.1.1-P1)
Message-ID: <705f47f772b4459ba65de71931aa2...@iid.com>
Content-Type: text/plain; charset="us-ascii"
How can a dhcp server that has been working with ISC 4.4.1 be migrated to ISC
4.1.1-P1 (Red Hat supported version) without losing entries on the
dhcpd.leases file?
The dhcpd.conf file from the 4.4.1 version seems to run fine on 4.1.1-P1 but
the dhcpd.leases file gets trimmed, the original dhcpd.leases file under 4.4.1
has about 3400 active leases and once the 4.1.1 is started it complains about
"corrupt lease file" and trims it to a point where the dhcpd.leases file now
shows only 350 active leases (almost 10 times less), here is the error we get
once the 4.1.1-P1 server is started using a dhcpd.leases file that was produced
with 4.4.1:
First time 4.1.1-P1 is executed:
Oct 2 23:34:45 webdhcp2 dhcpd: Corrupt lease file - possible data loss!
Oct 2 23:34:45 webdhcp2 dhcpd: Corrupt lease file - possible data loss!
Oct 2 23:34:45 webdhcp2 dhcpd: Corrupt lease file - possible data loss!
Oct 2 23:34:45 webdhcp2 dhcpd: Corrupt lease file - possible data loss!
Oct 2 23:34:45 webdhcp2 dhcpd: Corrupt lease file - possible data loss!
Oct 2 23:34:45 webdhcp2 dhcpd: /var/lib/dhcpd/dhcpd.leases line 3208:
Unexpected configuration directive.
Oct 2 23:34:45 webdhcp2 dhcpd: rewind
Oct 2 23:34:45 webdhcp2 dhcpd: ^
Oct 2 23:34:45 webdhcp2 dhcpd: /var/lib/dhcpd/dhcpd.leases line 3208: possibly
corrupt lease file
Oct 2 23:34:45 webdhcp2 dhcpd: rewind binding state free;
Oct 2 23:34:45 webdhcp2 dhcpd: ^
Second time 4.1.1-P1 is executed:
Oct 2 23:35:34 webdhcp2 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Oct 2 23:35:34 webdhcp2 dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Oct 2 23:35:34 webdhcp2 dhcpd: All rights reserved.
Oct 2 23:35:34 webdhcp2 dhcpd: For info, please visit
https://www.isc.org/software/dhcp/
Oct 2 23:35:34 webdhcp2 dhcpd: WARNING: Host declarations are global. They
are not limited to the scope you declared them in.
Oct 2 23:35:34 webdhcp2 dhcpd: Not searching LDAP since ldap-server, ldap-port
and ldap-base-dn were not specified in the config file
Oct 2 23:35:34 webdhcp2 dhcpd: Wrote 0 class decls to leases file.
Oct 2 23:35:34 webdhcp2 dhcpd: Wrote 0 deleted host decls to leases file.
Oct 2 23:35:34 webdhcp2 dhcpd: Wrote 0 new dynamic host decls to leases file.
Oct 2 23:35:34 webdhcp2 dhcpd: Wrote 4634 leases to leases file.
=====================>>>>> The original file has over 7000 entries
Oct 2 23:35:34 webdhcp2 dhcpd: Listening on
LPF/eth7/fc:35:56:e0:00:8a/192.168.7.0/24
Oct 2 23:35:34 webdhcp2 dhcpd: Sending on
LPF/eth7/fc:35:56:e0:00:8a/192.168.7.0/24
Oct 2 23:35:34 webdhcp2 dhcpd: Sending on Socket/fallback/fallback-net
Thanks
Alex P
------------------------------
Message: 3
Date: Tue, 2 Oct 2018 17:20:48 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Upgrade 4.2.4->4.3.5
Message-ID: <1507140298.20181002172...@sloop.net>
Content-Type: text/plain; charset="iso-8859-15"
Re-post of my query from last week...
Any thoughts/ideas, please share!
---
So, several questions:
Moving from Ubuntu 16.04, [IIRC] and dhcpd 4.2.4 to 18.04 and version 4.3.5
[I'm completely rebuilding the pair of dns/dhcp boxes, so no in-place upgrades.]
Currently use peer/load-balancing/failover.
Will 4.2.4 communicate fine with 4.3.5? [i.e. can I convert/upgrade one of the
peers and let it sync and then do the second, at my leisure?
I don't notice any real game-changers in terms of the config files in looking
through the change-logs. Yet it's certainly possible I've missed something.
Does anyone have any warnings I ought to take to heart? :)
Any warnings outside of the peer communications and config files?
<tangent> [Is now a good time to really consider KEA, or shall I put that off
until we're closer to widespread ipv6 deployment?] </tangent>
TIA
-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20181002/517d4e47/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 120, Issue 2
******************************************
