Bugzilla – Bug 17462
Ethernet-cabled Receiver doesn't acquire DHCP IP address after reboot - requires factory reset
Last modified: 2013-02-28 20:26:33 UTC
When upgrading from 7.5.4 to 7.5.5 and from 7.5.5 to 7.6.0 I experienced the same problem with all three of my Receivers (all ethernet connected). The new firmware applied and then after reboot they all stayed at the blue LED state. A factory reset of all of them and reconfiguration using one of my Controllers got them talking to SBS again and working perfectly. I had to power cycle one of them yesterday to reorganise some cabling and after power-up it remained at the blue LED state again. A factory reset got it working again. I then tested a different Receiver, starting a continuous ping test to its (reserved) IP address. After pulling and restoring the power it DHCP-ed (green LED) and then stuck at the blue LED state again, but it wasn't responding to ping on its IP address. I initiated a factory reset and began configuring it from the Controller. After choosing a wired connection it acquired an IP address of something like 169.254.* which is nothing to do with my IP address ranges, failed to connect to the music library and stuck at the blue LED state again. A second, full factory reset got it working again properly. Clearly this presents a major headache every time the Receivers are rebooted for whatever reason and I've already heard of one other user who appears to have experienced the same issue in the thread: http://forums.slimdevices.com/showthread.php?t=89657
*** This bug has been confirmed by popular vote. ***
Voted, I dont have this, but there have been a lot of new routers developed since 2008 maybe it's time to yet again investigate the dhcp and router compatability for the squeezeboxes. it is not that common, but there have always been a trickle of reports in the forum that a squeezebox is somewhat lees likely to pick up dhcp than other networked product people have.
I've also experienced the same problem since upgrading to 7.6.x and have to do a factory reset to correct the problem. I've also noticed other problems such as drop-outs and the constant rescanning of my music library. I have over 15,000 songs on a ReadyNAS Duo so this is VERY annoying.
Felix going to look into this issue? or...? doesn't seems to have any respond from logitech...
Guys, come on. Two months you've had this logged and confirmed and all we're seeing is updates for the benefit of the Logitech Revue, which isn't even part of the Squeezebox family. How about supporting some of your paying customers and getting this really problematic bug fixed.
Okay guys, here's the three-month wake-up call for someone to please take a look at this. It still happens every time a Receiver is rebooted under 7.7.0.
Please see this thread: http://forums.slimdevices.com/showthread.php?t=91796 Another two users have noted that having a gateway of 192.168.1.2 caused the same problem whereas 192.168.1.1 worked fine. I'm using a class B private range rather than class C. It looks like there's something flaky in the DHCP code.
FW vesrions: http://update.slimdevices.com/update/firmware/ receiver_67.bin 10-Jan-2011 7.5.3 receiver_68.bin 14-Apr-2011 7.5.4 receiver_69.bin 28-Jul-2011 7.5.5 receiver_77.bin 25-Jul-2011 7.6 -7.7 latest Trying to locate the change logs , they rarely update the network capabilities at all. But a recent update to the SB3 to accommodate some new DRM scheme to one of the services rendered the SB3 without bridging mode . Receiver officially never had it, but it could be made to work with some fiddling with net::udap So this point to some common code and bridging is a network function !! It is plausible that this change had some unintended effect. Have anyone tried running older receiver fw with current LMS (not a recomended practice I know ) I think you can by locating the firmware folder in LMS replacing the current fw with older fw and edit the receiver.version file and restart the server . Backup the newer version and fw file first No guarantee I have not tried in while myself and my own reciever is in storage. My network would not exhibit the problem either gateway is 192.168.0.1 and class C subnet 255.255.255.0 as standard as it gets I speculate that my vanilla network wont expose the bug. The idea is to try to find out which fw file that broke it.
I am having a simular problem. But not only when restaring the unit itself, but when I restart the Squeezebox server on my Synology NAS. When I then power cycle the unit, everything is fine. As a workaround, I have changed the setup of the receiver to use a static IP and now it is working fine after restarting the Squeezebox server. My gateway address is 192.168.10.1. I really hope this will be resolved in the near future.
Okay, so we're at the 6 month anniversary and no-one from Logitech has yet even commented yet. Can you please assign this to somebody who is actually around to take a look at it.
6 months is a blink of an eye in logitech bug time. if you want them to see this, post a link to it in the beta forum and add their emails to the cc above. i'm not sure if Felix is still with them either, but he might be. seems like its just michael, andy, and maybe alan and felix.
Not much action here lately ? I know this is a catch , you don't do ip3k work anymore . But what little you did last year actually broke parts of the dhcp function in the receiver . I would not expect any new stuff in a receiver ,but if a developer breaks existing functionality it would seem proper to fix that ? Would it not ?