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. DHCPv6 server not sending REPLY to Macs (Croce, Lucas)
2. Re: Esoteric question (Gregory Sloop)
3. if statements not working? (David F.)
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 Sep 2019 14:45:07 +0000
From: "Croce, Lucas" <lcr...@bju.edu>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: DHCPv6 server not sending REPLY to Macs
Message-ID:
<bn7pr07mb513834a31dab264f718f456fc9...@bn7pr07mb5138.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
I've been troubleshooting an issue where Macs have not been working on IPv6
enabled networks because they are asking to use the same IPv6 address they had
previously which is not allowed either because it's from a different VLAN or
it's been assigned out to another client already. Apple support claims that
the DHCP server is not following RFC 8415 Section 18.2.3, which states "If the
client receives no responses before the message transmission process
terminates, as described in Section 15, the client SHOULD continue to use any
leases, using the last known lifetimes for those leases, and SHOULD continue to
use any other previously obtained configuration parameters."
My understanding is that the authoritative flag in the dhcpd6.conf is what
should do what is described but I can clearly see in a packet capture taken off
the client that the DHCP server is sending a REPLY to the CONFIRM message from
the Mac. Any ideas on what I'm missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190920/6aa97d20/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 20 Sep 2019 09:45:17 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID: <494882410.20190920094...@sloop.net>
Content-Type: text/plain; charset="us-ascii"
So, the provider came in and replaced the cable-modem and that made the problem
vanish.
I'm going to see if I can get ahold of the problem modem, and *if* I get some
time, I'll see if I can tease out what might have been the root cause.
I wouldn't be holding my breath waiting for it, but we'll see.
It certainly was a *very* odd situation - and I'd love to know the cause.
-Greg
Not to "diss" any of the prior suggestions - but THIS, well this is something I
can get behind!
It *might* not be correct, and it's a bust of an idea - but it, IMNSHO, ties
all the pieces together in a really elegant way.
It's just a concept that makes so much sense and makes all the weird symptoms
all seem so much more plausible.
Wow. Really, massive thanks Simon.
I'll try to update the list when/if I figure out what's wrong. [Unless I've
done something so incredibly stupid I'm too embarrassed to post about it... :( ]
The modem did get replaced today, so it's possible the symptoms simply vanish
because of some change in the modem config, etc. But we'll see.
Thanks so much all!
-Greg
SH> Gregory Sloop <gr...@sloop.net> wrote:
>>Packet caps from the new router show that the router/DHCP server IS
>>seeing all the DHCP protocol handshake. [When it's having the
>>"problem."]
>>The client does a DISCOVER
>>Server responds with OFFER
>>The client responds with REQUEST
>>Then there's a LONG pause. [like 90s+ worth.]
>>The Server responds with ACK. [It actually appears to send several
>>ACKS.
SH> Ah, about 90s you say ?
SH> Have a look on the external interface and/or in the logs and see
SH> if it's trying to do any DNS lookups or updates. Over the years
SH> I've seen lots of threads related to 90s delays - a common one
SH> being SSH logins - which have come down to the device attempting a
SH> DNS lookup and waiting for it to time out.
SH> Anyway, what I theorise could be happening is :
SH> With WAN connected, "something" (dhcpd) is trying to do
SH> "something" with an outside service and timing out.
SH> When the WAN is link-up but not connected to the modem, such
SH> attempts fail very quickly as the device has no ARP entry for it's
SH> default route and so the network stack quickly reports "no route to host".
SH> BTW, when I first read your post I was thinking WTF ! It was only
SH> after reading the other replies that this idea came to mind.
SH> Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190920/b73b1ee2/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 20 Sep 2019 10:24:36 -0700
From: "David F." <df7...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: if statements not working?
Message-ID:
<CAGRSmLvycWF1iyqd2sDNQFR+MtH5_TjQ+gGnrszuKC=rxa9...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hello,
I have the following class section. PXE boot from an dell xps400
(BIOS mode), and it tries to load junk.efi. I looked in syslog and
my debug output is "0". So it seems like the if statement should have
caught it but it didn't. Is there something wrong with the code
below? This is on Ubuntu 9.04 using ISC DHCP Server 3.1.1.
option architecture-type code 93 = unsigned integer 16;
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
log(debug, "debug info here");
log(debug, binary-to-ascii(10,16, ".", option architecture-type));
if option architecture-type = 0 {
filename "/tftpboot/pxelinux.0";
} elsif option architecture-type = 9 {
filename "/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 7 {
filename "/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 6 {
filename "/tftpboot/efi32/syslinux.efi";
} else {
filename "/tftpboot/junk.efi";
}
}
TIA!!
------------------------------
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 131, Issue 16
*******************************************
