Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 8 of 8
  1. #1
    Christian Pernegger
    Guest

    sb2 DHCP problems

    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.

  2. #2
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    sb2 DHCP problems

    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

  3. #3
    Senior Member max.spicer's Avatar
    Join Date
    Apr 2005
    Location
    York, United Kingdom
    Posts
    1,661
    Quote Originally Posted by dean
    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?
    Some people think the title of this song is irrelevant,
    but it's not irrelevant - it's a hippopotamus.

  4. #4
    Perl Commando Dan Sully's Avatar
    Join Date
    Apr 2005
    Location
    Daly City, CA
    Posts
    2,865

    sb2 DHCP problems

    * 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.

  5. #5
    Christian Pernegger
    Guest

    sb2 DHCP problems

    > 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

  6. #6
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    sb2 DHCP problems

    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

  7. #7
    Perl Commando Dan Sully's Avatar
    Join Date
    Apr 2005
    Location
    Daly City, CA
    Posts
    2,865

    sb2 DHCP problems

    * 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.

  8. #8
    Christian Pernegger
    Guest

    sb2 DHCP problems

    > > 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •