Request ignored (not authoritative) to only one client

[Jerimiah Cole]

I've got some new gear in my test environment and the DHCP server won't give it a lease. It gives other clients in the same network leases without fail:

Jul 29 10:40:09 access00 dhcpd: DHCPDISCOVER from ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPOFFER on 10.98.100.2 to ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPREQUEST for 10.98.100.2 (192.168.39.101) from ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPACK on 10.98.100.2 to ff:ff:ff:e1:ac:06 via 10.98.0.1

But it doesn't like this new stuff:

Jul 29 10:40:27 access00 dhcpd: DHCPDISCOVER from ee:ee:ee:1e:8a:82 via 10.98.0.1
Jul 29 10:40:28 access00 dhcpd: DHCPOFFER on 10.98.193.233 to ee:ee:ee:1e:8a:82 via 10.98.0.1
Jul 29 10:40:29 access00 dhcpd: DHCPREQUEST for 10.98.193.233 (192.168.39.101) from ee:ee:ee:1e:8a:82 via 10.98.0.1: ignored (not authoritative).

The config is about as as simple as they come:

option domain-name-servers 192.168.4.13;

default-lease-time 600;
max-lease-time 600;

# local
subnet 192.168.39.0 netmask 255.255.255.0 {
}

# test
subnet 10.98.0.0 netmask 255.255.0.0 {
pool {
range 10.98.100.0 10.98.255.254;
deny dynamic bootp clients;
}
option routers 10.98.0.1;
}

I captured and compared the request packets for both the successful and failed transaction and there are no substantiative differences that I can find. Anybody else seen this or have some suggestions for further troubleshooting?

Jerimiah

[David Forrest]

Post by Jerimiah Cole
Jul 29 10:40:09 access00 dhcpd: DHCPDISCOVER from ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPOFFER on 10.98.100.2 to ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPREQUEST for 10.98.100.2 (192.168.39.101) from ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:10 access00 dhcpd: DHCPACK on 10.98.100.2 to ff:ff:ff:e1:ac:06 via 10.98.0.1
Jul 29 10:40:27 access00 dhcpd: DHCPDISCOVER from ee:ee:ee:1e:8a:82 via 10.98.0.1
Jul 29 10:40:28 access00 dhcpd: DHCPOFFER on 10.98.193.233 to ee:ee:ee:1e:8a:82 via 10.98.0.1
Jul 29 10:40:29 access00 dhcpd: DHCPREQUEST for 10.98.193.233 (192.168.39.101) from ee:ee:ee:1e:8a:82 via 10.98.0.1: ignored (not authoritative).
option domain-name-servers 192.168.4.13;
default-lease-time 600;
max-lease-time 600;
# local
subnet 192.168.39.0 netmask 255.255.255.0 {
}
# test
subnet 10.98.0.0 netmask 255.255.0.0 {
pool {
range 10.98.100.0 10.98.255.254;
deny dynamic bootp clients;
}
option routers 10.98.0.1;
}
I captured and compared the request packets for both the successful and failed transaction and there are no substantiative differences that I can find. Anybody else seen this or have some suggestions for further troubleshooting?
Jerimiah
_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users

Do you have an authoritative statement we're not seeing?

Dave

[Jerimiah Cole]

Post by David Forrest
Do you have an authoritative statement we're not seeing?

No, that's the entire config.

FWIW, if I add an authoritative statement globally or in the subnet, I
get "wrong network" instead.

Jerimiah

[David Forrest]

Post by Jerimiah Cole

Post by David Forrest
Do you have an authoritative statement we're not seeing?

No, that's the entire config.
FWIW, if I add an authoritative statement globally or in the subnet, I
get "wrong network" instead.
Jerimiah

Humph, that's expected if a client asks for the wrong network. It looks
like your new device thinks it has a valid lease somewhere. When it asks
for it answers the ping packet check from the server which should send a
DHCPNAK to get the client to abandon the wrong network it has and ask
again via a new DISCOVER request. The authoritative statement just allows
the server send the DHCPNAKs. See the dhcpd.conf man page for a more
exhaustive explanation.

Dave

[Jerimiah Cole]

Post by David Forrest

Post by Jerimiah Cole

Post by David Forrest
Do you have an authoritative statement we're not seeing?

No, that's the entire config.
FWIW, if I add an authoritative statement globally or in the subnet, I
get "wrong network" instead.
Jerimiah

Humph, that's expected if a client asks for the wrong network.

Right, but the client isn't asking for the wrong network, which is why
I'm stumped.

Jerimiah

[David Forrest]

Post by Jerimiah Cole

Post by David Forrest

Post by Jerimiah Cole

Post by David Forrest
Do you have an authoritative statement we're not seeing?

No, that's the entire config.
FWIW, if I add an authoritative statement globally or in the subnet, I
get "wrong network" instead.
Jerimiah

Humph, that's expected if a client asks for the wrong network.

Right, but the client isn't asking for the wrong network, which is why
I'm stumped.
Jerimiah

What IP is the client's DHCPDISCOVER packet asking for? (Option 50) If
the requested IP is not available on the configured subnets, then a
DHCPNAK is sent and the client should reset and request a new IP. It
could be that your client device is not set up for this procedure.
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery

It would appear from the information you have given that you are having a
client/server configuration disjuncture. If the device can be set up with
a fixed IP, you might try setting it up with an IP in your configured
subnet and then when it gets assigned that address (pick an unused IP from
your dhcpd.leases file) you can then add the reserved keyword to the
dhcpd.leases file and no other device can then get that IP. I have done
the same with some of my devices and it works quite well. I do that
because I prefer that my servers have static IPs for administration
purposes.

If your client device does not honor the DHCPNAK packet then I am finished
with my knowledge base.

Dave

[Jerimiah Cole]

Post by David Forrest
What IP is the client's DHCPDISCOVER packet asking for?

When it first boots, it does not send option 50 in the DISCOVER. After
the first OFFER packet, it sends option 50 set to the IP address that
the server offered in all subsequent DISCOVER and REQUEST packets.
That's what's so mystifying. The client is requesting the very IP
address that the server has specified in its OFFER, yet the server seems
to think the address is invalid.

I appreciate your time.

Jerimiah

[Sten Carlsen]

Post by Jerimiah Cole

Post by David Forrest
What IP is the client's DHCPDISCOVER packet asking for?

When it first boots, it does not send option 50 in the DISCOVER. After
the first OFFER packet, it sends option 50 set to the IP address that
the server offered in all subsequent DISCOVER and REQUEST packets.
That's what's so mystifying. The client is requesting the very IP
address that the server has specified in its OFFER, yet the server seems
to think the address is invalid.

Is there any other parameter in the request packet that is not valid?
Just a long shot.

If option 54 is not that server, it may think the client accepted an
offer from some other server?

Post by Jerimiah Cole
I appreciate your time.
Jerimiah
_______________________________________________
dhcp-users mailing list
https://lists.isc.org/mailman/listinfo/dhcp-users

[Jerimiah Cole]

Post by Sten Carlsen
Is there any other parameter in the request packet that is not valid?
Just a long shot.
If option 54 is not that server, it may think the client accepted an
offer from some other server?

Option 54 is included in the REQUEST with the server's IP. It also
includes options 82 and 60, but with this simple configuration they
should basically be ignored.

I compared the REQUEST packet with another one that the server ACKs and
the only differences are options 82 and 60.

Jerimiah

[Glenn Satchell]

Post by Jerimiah Cole

Post by Sten Carlsen
Is there any other parameter in the request packet that is not valid?
Just a long shot.
If option 54 is not that server, it may think the client accepted an
offer from some other server?

Option 54 is included in the REQUEST with the server's IP. It also
includes options 82 and 60, but with this simple configuration they
should basically be ignored.
I compared the REQUEST packet with another one that the server ACKs and
the only differences are options 82 and 60.
Jerimiah

Forgive me if you've already answered this, but can you tell us what
type of device the client is? Some dhcp clients require a specific
option to be set in the response, so is there anything specified in the
client documentation? Does this client also come with a server component
that can include a "special" dhcp server?

regards,
-glenn

[Allie Hopkins]

Another approach would be to turn "always broadcast" on. Your device may
not accept the unicast followup messages.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allie M Hopkins
Information Technology Services
Louisiana State University
[phone]


On Mon, Aug 1, 2011 at 9:53 AM, Glenn Satchell

Post by Jerimiah Cole

Post by Sten Carlsen
Is there any other parameter in the request packet that is not valid?
Just a long shot.
If option 54 is not that server, it may think the client accepted an
offer from some other server?

Option 54 is included in the REQUEST with the server's IP. It also
includes options 82 and 60, but with this simple configuration they
should basically be ignored.
I compared the REQUEST packet with another one that the server ACKs and
the only differences are options 82 and 60.
Jerimiah
Forgive me if you've already answered this, but can you tell us what type

of device the client is? Some dhcp clients require a specific option to be
set in the response, so is there anything specified in the client
documentation? Does this client also come with a server component that can
include a "special" dhcp server?
regards,
-glenn
______________________________**_________________
dhcp-users mailing list
https://lists.isc.org/mailman/**listinfo/dhcp-users<https://lists.isc.org/mailman/listinfo/dhcp-users>

[Allie Hopkins]

doh...wrong thread! Please disregard. Always broadcasting will likely not
solve this problem.

Post by Allie Hopkins
Another approach would be to turn "always broadcast" on. Your device may
not accept the unicast followup messages.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allie M Hopkins
Information Technology Services
Louisiana State University
[phone]

Post by Jerimiah Cole

Post by Sten Carlsen
Is there any other parameter in the request packet that is not valid?
Just a long shot.
If option 54 is not that server, it may think the client accepted an
offer from some other server?

Option 54 is included in the REQUEST with the server's IP. It also
includes options 82 and 60, but with this simple configuration they
should basically be ignored.
I compared the REQUEST packet with another one that the server ACKs and
the only differences are options 82 and 60.
Jerimiah
Forgive me if you've already answered this, but can you tell us what

type of device the client is? Some dhcp clients require a specific option to
be set in the response, so is there anything specified in the client
documentation? Does this client also come with a server component that can
include a "special" dhcp server?
regards,
-glenn
______________________________**_________________
dhcp-users mailing list
https://lists.isc.org/mailman/**listinfo/dhcp-users<https://lists.isc.org/mailman/listinfo/dhcp-users>

[Jerimiah Cole]

Post by Glenn Satchell
Forgive me if you've already answered this, but can you tell us what
type of device the client is?

It's a FTTH ONT, which is basically a VoIP IAD.

Post by Glenn Satchell
Some dhcp clients require a specific
option to be set in the response, so is there anything specified in the
client documentation? Does this client also come with a server component
that can include a "special" dhcp server?

There are some things that the client expects in option 43, but I
haven't even gotten that far. The issue here is that the server is
ignoring the client's DHCPREQUEST.

Is the server looking at the contents of option 60 in the client's
REQUEST?

Jerimiah

[Frank Bulk]

I would think that your ONT or GPON/EPON vendor would be able to help you.
Calix has a built-in DHCP serve in the C7 that we use for the SIP client in
our Calix ONTs.

Frank

-----Original Message-----
From: dhcp-users-bounces+frnkblk=***@lists.isc.org
[mailto:dhcp-users-bounces+frnkblk=***@lists.isc.org] On Behalf Of
Jerimiah Cole
Sent: Monday, August 01, 2011 10:20 AM
To: Users of ISC DHCP
Subject: Re: Request ignored (not authoritative) to only one client

Post by Glenn Satchell
Forgive me if you've already answered this, but can you tell us what
type of device the client is?

It's a FTTH ONT, which is basically a VoIP IAD.

Post by Glenn Satchell
Some dhcp clients require a specific
option to be set in the response, so is there anything specified in the
client documentation? Does this client also come with a server component
that can include a "special" dhcp server?

There are some things that the client expects in option 43, but I
haven't even gotten that far. The issue here is that the server is
ignoring the client's DHCPREQUEST.

Is the server looking at the contents of option 60 in the client's
REQUEST?

Jerimiah