PDA

View Full Version : sb2 DHCP problems



Christian Pernegger
2005-05-12, 05:16
It seems to me that the sb2 does not honor the lease-time of a DHCP
lease, i. e. when a lease has run out it won't rerequest a lease or
stop using the address. Rather, it will continue using the IP it got
during network setup indefinitely. IIRC I've reported the problem some
time ago. In the meantime I've changed the lease to never run out :)

But today I had to restart the sb2 because of an access point update.
It took quite some time for the DHCP request (normally it's instant)
and then "obtained" the IP 169.254.188.141.

It's just that this address is in a reserved address space that I'm
_not using_ and my own DHCP server did not log a request for an
address. So either:

1) I have a rogue DHCP server on my network - worrisome
2) The sb2 gave up on the DHCP and fell back to a default address
- please don't. If this is really useful to anyone, please change the
message in that case from "obtained from DHCP" to "fell back to
default IP"

In any case, my sb2 shows this behaviour every second reset.

C.

dean
2005-05-12, 08:11
On May 12, 2005, at 5:16 AM, Christian Pernegger wrote:
> It seems to me that the sb2 does not honor the lease-time of a DHCP
> lease, i. e. when a lease has run out it won't rerequest a lease or
> stop using the address. Rather, it will continue using the IP it got
> during network setup indefinitely. IIRC I've reported the problem some
> time ago. In the meantime I've changed the lease to never run out :)
>
> But today I had to restart the sb2 because of an access point update.
> It took quite some time for the DHCP request (normally it's instant)
> and then "obtained" the IP 169.254.188.141.
That's a link-local address. If the DHCP request times out, it will
use a 169.254.x.x address until DHCP succeeds, at which point it will
switch to the new address.

Some questions for you:
1. What DHCP server are you using? (Built into a router or running
on a server somewhere? Version number?)
2. Do you have the ability to capture a packet trace of the DHCP
request/response?

> 2) The sb2 gave up on the DHCP and fell back to a default address
> - please don't. If this is really useful to anyone, please change the
> message in that case from "obtained from DHCP" to "fell back to
> default IP"
This is a good suggestion, there should be some visible feedback when
this happens.

-dean

max.spicer
2005-05-12, 09:25
That's a link-local address. If the DHCP request times out, it will
use a 169.254.x.x address until DHCP succeeds, at which point it will
switch to the new address.

What is a link-local address? Windows boxes fall back to 169.254 when they can't get an address and I've always assumed this was just Microsoft being random. How does it help to pick a seemingly invalid address that almost certainly won't work in any situation?

Dan Sully
2005-05-12, 09:31
* max.spicer shaped the electrons to say...

>> That's a link-local address. If the DHCP request times out, it will
>> use a 169.254.x.x address until DHCP succeeds, at which point it will
>>
>> switch to the new address.
>
>What is a link-local address? Windows boxes fall back to 169.254 when
>they can't get an address and I've always assumed this was just
>Microsoft being random. How does it help to pick a seemingly invalid
>address that almost certainly won't work in any situation?

If there are multiple machines on the same network with no DHCP server, it
will allow them to communicate:

http://www.faqs.org/rfcs/rfc3330.html

In combination with something like Zeroconf (Rendezvous/Bonjour), naming is also solved.

-D
--
You know, for kids.

Christian Pernegger
2005-05-12, 11:24
> 1. What DHCP server are you using?

dnsmasq 2.22-1 (Debian testing)

> 2. Do you have the ability to capture a packet trace of the DHCP request/response?

Is there a suitable sniffer for this in Debian testing / could you
give me an appropriate command line for the info you need?

Thanks

C

dean
2005-05-12, 11:40
On May 12, 2005, at 11:24 AM, Christian Pernegger wrote:
>> 1. What DHCP server are you using?
>>
>
> dnsmasq 2.22-1 (Debian testing)
>
>
>> 2. Do you have the ability to capture a packet trace of the DHCP
>> request/response?
>>
>
> Is there a suitable sniffer for this in Debian testing / could you
> give me an appropriate command line for the info you need?
Sure:

sudo tcpdump -w dhcplog.pcap

Will dump all the TCP traffic to the file dhcplog.pcap

If you can capture the DHCP failure there, we can look at that file
and see what's going on.

-dean

Dan Sully
2005-05-12, 11:53
* dean blackketter shaped the electrons to say...

>>Is there a suitable sniffer for this in Debian testing / could you
>>give me an appropriate command line for the info you need?
>Sure:
>
>sudo tcpdump -w dhcplog.pcap
>
>Will dump all the TCP traffic to the file dhcplog.pcap
>
>If you can capture the DHCP failure there, we can look at that file
>and see what's going on.

You should also check /var/log/dhcp

-D
--
On second thought, let's not go to Camelot. It is a silly place.

Christian Pernegger
2005-05-12, 13:56
> > Is there a suitable sniffer for this in Debian testing / could you
> > give me an appropriate command line for the info you need?
> Sure:
>
> sudo tcpdump -w dhcplog.pcap
>
> Will dump all the TCP traffic to the file dhcplog.pcap
>
> If you can capture the DHCP failure there, we can look at that file
> and see what's going on.

It refuses to misbehave in front of the camera :( I have a nice
capture of the "worked flawlessly" case now, though, including a
syslog fragment. Will keep trying.

C.