Request ignored (not authoritative) to only one client
allie at lsu.edu
Mon Aug 1 15:30:45 UTC 2011
doh...wrong thread! Please disregard. Always broadcasting will likely not
solve this problem.
On Mon, Aug 1, 2011 at 10:04 AM, Allie Hopkins <allie at lsu.edu> wrote:
> 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
> On Mon, Aug 1, 2011 at 9:53 AM, Glenn Satchell <glenn.satchell at uniq.com.au
> > wrote:
>> On 08/02/11 00:32, Jerimiah Cole wrote:
>>> On Sat, 2011-07-30 at 18:16 +0200, Sten Carlsen wrote:
>>>> 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.
>>> 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?
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users