Not sure this is a SBR issue from the description.

QA could you please try to reproduce, thanks.

Ross: can you have a look at this one please

Johan, could you please try to reproduce this with WPA? If the key is entered incorrectly, you will see the symptoms you describe. In other words, DHCP failure can mean incorrect key with WEP. Please try WPA and if its an incorrect key you'll see a clear error message. 

Hi,

Well I can try with WPA, but I connect Squeezecenter through fixed Ethernet (UTP Cat 5 cable). I tested as well with Wireless (WPA and correct password) but in both cases same result (169.254...).

I'm not concerned with how the SqueezeCenter PC connects to the network, there doesn't seem to be any problem there. From the sound of it there is an issue with Duet connecting to your network. 

Please change it to WPA, factory reset both, and walk me through this. For receiver to get 169 IP this tells me you're selecting self-assign on controller, this option only presents itself either when there is no DHCP or Controller for some reason cannot reach DHCP. This is why I've speculated about WEP encryption issues, if you enter the wrong key on a WEP network you'll simply get DHCP errors because all we (Duet) knows is that we didn't get an address from DHCP. 

Walk me through this one more time when you get a chance. Enable WPA with a simple 8 digit key just as a diagnostic. Factory reset both Controller and Receiver, set them up normally (connect to wireless network, not connect using Squeezebox) and let me know at which stage you see a problem. 

Hi,

Okay, I should clarify my set-up... 

Scenario 1:
The controller is connected to a WiFi WPA 802.11g network (Linksys WRT350N). To be exact: PSK-Personal TKIP. The controller is working properly, it indicates a connected status and in the menu, when I look up the WiFi network everything is fine. The controller also appears in the router DHCP (LAN IP) table and has an IP address in the LAN IP range (192.168....). So the Controller is connected directly to the router's Wifi access point.

Scenario 2:
I tested also with an old Netgear 802.11b WEP (128bit encryption). The controller connected properly to this b-Wifi network. The controller appears in the routers table (and IP 192.168....). So also in the case the Controller is connected directly to the router's Wifi access point.

In both scenarios I've tried to connect the receiver to the router both through UTP Ethernet and wirelessly. In both scenarios I did the following. First I try to connect to (set-up receiver) 'SqueezeLiving' *). So I try to set-up SqueezeLiving both to Ethernet and Wifi, but in both cases I get an IP 169.254... Note, on some restarts (power on / off both on Controller and SB it seems to work (on the controller I don't get the menu to connect the receiver to the network as 'it' thinks it is connected (LED on receiver is BLUE!) and it tries to connect to the SqueezeCenter software running on my PC. However, it fails to connect to SC (which isn't strange when you realize that the receiver has no IP address assigned). The LED on the receiver stays blue.

*) Thus, on  the controller I cannot do anything else than 'home' 'configuration' and choose a receiver to set-up. To avoid any confusion: this behaviour happens not during intial set-up, I have already enjoyed many hours of listening to MP3 music!! (and do so now again, as the problem has dissappeared - again, but for how long?)

Now, I press and hold the button on the receiver until it flashes red. After a few seconds in the receiver list (on the controller) appear both SqueezeLiving and Squeezebox 1616E2. So this time I try to set-up SB 1616E2 both to Ethernet and Wifi, but in both cases I get an IP 169.254... 

As I already wrote, last time I was able to resolve the problem by factory reset the Controller and connect to SqueezeLiving (after the factory reset it still saw TWO receivers, connecting to Squeezebox1616E2 returned again a 169.254 address). Now it did connect SqueezeLiving to the LAN IP range and it found my PC / SqueezeCenter as well.

Hope this helps a bit. I'm willing to perform some tests. But to test connecting to WPA seems unneccessary at this point as I've already tested with both WEP and WPA (and WiFi and UTP ethernet for the receiver).

Kind regards,
Johan

It sounds like your Receiver is in some odd state. Please try factory resetting your Receiver as well as your Controller and then go through setup and let me know if you can reproduce. If you press and hold the button on receiver for 3 seconds it goes into discoverable mode, I want you to continue to hold it for 6 seconds, this is how you factory reset it. Slow blinking red indicates discoverable mode, fast blinking red indicates factory reset. 

After both units have been factory reset, then please let me know at which stage you see an issue. Please use WPA encryption for this test. 

Ross,
Another SBD user here. I can confirm this bug exists 100%. I'm using DNSMasq as my DHCP server and my receiver _does not_ keep it's assigned IP address. 

It is connected via ethernet, so I know that it's not an issue with WiFi. I know my Duet controller is working properly; I'm using WPA wireless and it always keeps it's IP address and always responds to a ping.


There is absolutely no question in my mind that there is a bug here. I'll log/debug/trace whatever you want, because I now have a $400 piece of network equipment that can't even stay connected to a network.

Nate, if you could make a capture that includes the initial acquisition and past the point of failure it would be totally helpful.  Setting a short lease time would probably speed up the process.

Created attachment 3968 [details]
DNSMasq log of receiver attemping to get IP

Chris, I have attached a log of the SB receiver's DHCP activity from DNSMasqs' perspective with log-queries and log-dns set. The SB receiver was stuck on the blue light as it so often is after a period of inactivity of about 2 hours. I unplugged the receiver and plugged it back in and let it try to re-establish itself on the network; this is what got to DNSMasq. The receiver did not use the assigned IP and has autoconfigured itself back in the 169.254.x.x block and the blue light is back on.

If your intentions were actually for a capture of the packet traffic, let me know and I'll get that as well.
-----Nate

Thank you Nate, this is indeed exactly my problem! Maybe it is also helpful to know that this problem occurs both when an address is assigned dynamically with DHCP, as well as when an IP address is reserved within the LAN IP range.

Any further updates? I'm still more than happy to provide more thorough logging and captures. 

I will say, however, that I haven't gotten a blue light in quite a few days. I'm sure it will crop back up though, especially with more regular usage.

I'm very sure it will occur again... I walked through the complete factory reset procedure (both squeezebox and controller). I ran through it without any problem. That was my expectation, as the problem doesn't occur during (initial) set-up, but during regular use. I also moved Squeezecenter from my PC to a Synology Diskstation (official package, not with SSODS), so the service isn't interrupted because I turn off my PC. However, I had a blue light, and another thing. The light on the squeezebox was white (okay and seen by the webinterface). The controller had been off. When I turned it on it couldn't discover my Squeezebox. This happens more than once. 

I really want to stress that this problem must be resolved, as the two us here are not the only one's dealing with it (see your own forum for example). Also willing to perform tests...

Richard I'm not able to reproduce this. I've tried with an Airport with DHCP lease time set to 10 minutes, still not able to reproduce. Is there anything Nate could provide that may help? I'll keep trying. 

Ross,
I may have a lead you may want to investigate, as well as a question. First and foremost I have noticed the persistent disconnect seems to occur more frequently if I have to restart the squeezecenter that the SBR is connected to. I'm not sure how the SBR hops from squeezecenter to squeezecenter, but I do know if the SBR is connected to a SC instance that was shut down, it cannot transition to another running squeezecenter on the network until the attached SC is started again or it is unplugged. That seems like curious behavior considering the SBR is still connected to the LAN after a SC shuts down (and should therefore be able to hop to a new server, in theory). I obviously don't know the implementation in firmware though, so this may be behaving as expected.

My question is more of an observation. When the SBR is not accepting DHCP addresses and autoconfigures itself it says something to the effect of "Connected to (SBR IP address) on ethernet". Basically whatever it is that it says, it seemed to me like the hostname of the squeezecenter server would have gone in place of the IP address assigned to the SBR, but I haven't paid too much attention and don't want to factory reset my box because it's on day 2 of not losing it's connection. 

I think the observation from Nate points in the right direction. I experience less problems (but I had a connection problem the other day) now that I've moved SC to the Synology DiskStation. As a matter of fact if you turn off SC (the PC it's running on) while it was playing you have most certain connection problems with SBR the next time you try to play music.

Another akward thing I remember is, whenever you try to connect SBR through Ethernet (so FIXED network) and it fails, the controller will respond that it was unable to connect SBR to the WIRELESS network... I don't no whether this is simply a GUI error (wrong text in dialogue) or in the underlying routines.

IIRC Ross mentioned to me last week that he was able to reproduce this on a very slow machine.  Please correct me if I'm wrong, Ross.

(In reply to comment #18)
> IIRC Ross mentioned to me last week that he was able to reproduce this on a
> very slow machine.  Please correct me if I'm wrong, Ross.
> 

I thought I reproduced this but actually it was something different. What happened was SqueezeCenter was running in a VM and the music source was a readyNAS, I disconnected the readyNAS from the network and Controller showed a red icon. I've since tried this again but wasn't able to reproduce. 

I'm getting some helpful feedback from my thread in the general forum. Today I'm going to try to reproduce this in bridged setup. 

I'm having this same issue with a dlink dfl-210 router.  I don't have wifi so the receiver is wired and the controller connects directly to the receiver instead through a wifi router.  If I factory reset the duet & controller it is able to obtain an address via DHCP.  However, usually within a day or so (I assume to a dhcp lease expiration or maybe a power blip) it loses it's ip and reverts to the 169.254 address.  The only way I can get it to work again is to do another factory reset of both the receiver & the controller.

I checked the logging in my router and saw this:

successful attempt to DHCP after factory reset:
2008-09-26 08:24:12 	Debug 	DHCPSERVER	900015 	lan_DHCPServer 	UDP 	lan	0.0.0.0	255.255.255.255 	68 67 	sending_offer	client_hw=00-04-20-16-09-d4 offer_ip=192.168.3.101 ipdatalen=308 udptotlen=308
2008-09-26 08:24:13 	Debug 	DHCPSERVER	900019 	lan_DHCPServer 	UDP 	lan	0.0.0.0 255.255.255.255 	68 67 	client_bound	new_lease	client_hw=00-04-20-16-09-d4 client_ip=192.168.3.101 ipdatalen=308 udptotlen=308

failed attempt to DHCP after power cycling:
2008-09-26 08:29:45 	Debug 	DHCPSERVER	900015 	lan_DHCPServer 	UDP 	lan	192.168.3.101	255.255.255.255 	68 67 	sending_offer	client_hw=00-04-20-16-09-d4 offer_ip=192.168.3.101 ipdatalen=308 udptotlen=308

The difference is that after a factory reset the source IP of the DHCP discover request was 0.0.0.0 and after power cycling it was 192.168.3.101.  The duet seems to be ignoring the DHCP offer with 192.168.3.101 in the dest ip field.

I made some MS network monitor captures and will attach in a bit.

Created attachment 4074 [details]
ms net mon capture of successful dhcp after factory reset

Created attachment 4075 [details]
failed dhcp after power cycling

(In reply to comment #23)
> Created an attachment (id=4075) [details]
> failed dhcp after power cycling

Hi David, thanks for debugging. Although not 'nice', I'm glad that more people are dealing with this issue and contribute to solve this problem. I noticed the attachments had .cap file extension. Maybe you could upload these as .jpg? I wasn't able to open them.

To the problem itself: I have less problems (mind the word LESS) with the SBR after I moved SC server from my PC (which is turned off each night) to my Synology NAS. On the other hand, when I power off the Duet Controller it most times is not able to reconnect to the SBR (which has a white light). 

So I guess if some IP address is lost after an initial correct set-up, the duet SBR / SBC have problems to reconnect / rediscover. In other words, power cycling of the router, SBR or SBC is a way that the connection is withdrawn, and the same goes for turning off the SC server... 

(In reply to comment #24)
Johan,

The .cap files are just a dump of the data I captured over my network while the duet was performing its dhcp requests so the results are similar to the ones from my router log.  It appears that either my router or the duet receiver may have some bugs in their dhcp handling.  All my other devices (including the duet controller I think - I'll need to double check) work fine with my router's dhcp server though.

In the interim I'm going to try again to setup a static ip on the duet since that should work around the problem.  I haven't had much success with getting the static ip option to show up though.  I even put it on its own network so there was no chance of it finding a dhcp server.
> 

(In reply to comment #25)
> In the interim I'm going to try again to setup a static ip on the duet since
> that should work around the problem.  I haven't had much success with getting
> the static ip option to show up though.  I even put it on its own network so
> there was no chance of it finding a dhcp server.
> > 
> 

You *should* get the static option if there is no DHCP present on the network. You're saying on a network with no DHCP you're not seeing the option? I'll try to reproduce that today. 

(In reply to comment #26)
I'll have to try it again tonight.  It was awhile back that I tried it.  I may not have done a full factory reset and there have been a few updates since then too.

(In reply to comment #27)
> I'll have to try it again tonight.  It was awhile back that I tried it.  I may
> not have done a full factory reset and there have been a few updates since then
> too.
> 

In that case I'll hold off on my testing until I hear back from you. Thank you so much David you've been tremendously helpful!

(In reply to comment #26)
> You *should* get the static option if there is no DHCP present on the network.
> You're saying on a network with no DHCP you're not seeing the option? I'll try
> to reproduce that today. 
> 
I can confirm this behavior. When my duet receiver fails to accept it's DHCP lease and autoconfigures itself in the 169 block or does not have a DHCP server present at all there is no option to enable a static IP address (if there was I would have done it a long time ago and stopped worrying so much about the DHCP problems)

(In reply to comment #29)
> I can confirm this behavior. When my duet receiver fails to accept it's DHCP
> lease and autoconfigures itself in the 169 block or does not have a DHCP server
> present at all there is no option to enable a static IP address (if there was I
> would have done it a long time ago and stopped worrying so much about the DHCP
> problems)
> 

If the Duet receiver fails to accept it's DHCP lease, then there is indeed a DHCP server, hence no static IP option. 

I just setup a network without DHCP, Duet immediately presents the static IP option which I tested and it worked for me. 

i'm probably just being thick...  BUT...

shouldn't you have a static option even if you have DHCP?  i set my SB2 to static while my SBC, SC, and other stuff is dhcp reserved by the router.

seems to me the design goal should be that regardless of whether or not your network has dhcp, you should always have access to the static IP option.

(In reply to comment #31)
> i'm probably just being thick...  

^^^ That's my job! ;-)

We don't present the static/DHCP option if Duet sees DHCP in an effort to keep the setup process as simple as possible as most consumers use DHCP. 

i totally understand the KISS idea, but the reason i set my SB2 to static was to avoid and minimize some nebulous problems it seemed to be having, and doing so seems to have helped a lot.

i have a SBR, but i haven't used it much, currently its not hooked up.  but even though i use dhcp on my router, i would want to set it up as static just like the SB2.

in my case, i set a limited range for dhcp, and each and every one is reserved.  if i need to add a device, i have to increase the range by one, and then i reserve it for that device.

i wonder what the SBR would do if it saw that i had dhcp, but that i didn't have an IP reserved (or available) for it?

regardless, one way or another, i do think the option to go static should be available just as it is for the SB2, even if dhcp is "detected."

(In reply to comment #30)
> 
> If the Duet receiver fails to accept it's DHCP lease, then there is indeed a
> DHCP server, hence no static IP option. 
> 
> I just setup a network without DHCP, Duet immediately presents the static IP
> option which I tested and it worked for me. 
> 

Perhaps this would be better explained as:
If the Duet receiver fails to accept a DHCP lease *but* the Duet controller does accept a DHCP lease then the user is not presented with the option of assigning a static IP address to the receiver. I can replicate this by hooking the duet receiver up to an empty network (IE the only device on a switch) while telling the duet controller to connect to a wireless network with a DHCP server.

Not entirely sure if this is the intended behavior or not. Perhaps it would be a good idea to program in a handshake (ping?) between the receiver and controller once they both think they're connected so that they know they're on the same network? 

(In reply to comment #26)
Where does the static option show up?  I connected the duet receiver to an empty hub and did a factory reset of the receiver and the controller.  In the setup I selected the squeezebox as my wireless network and it showed the connecting message for a bit before dumping me to the "failed to connect your squeezebox to the wireless network" screen.  I didn't see any option to enter an ip address.  One time (I tried it a few times) I went back and when I tried again it gave me the option of connecting the squeezebox via ethernet or wireless.  I chose ethernet and then after a short wait it told me it couldn't connect again.  I haven't been able to give me that option again or an option to manually enter an ip address.

Regardless of Ross's work and Nate's and David's help in figuring this out, we've now passed the critical point for getting this into the 7.2.1 bug fix release.  The 7.3 release really isn't too far off, and stable 7.3 nightlies will be available even sooner.

Nate, interesting test case. I haven't testing this scenario, I'm not sure we should. 

David, the static option only comes up in standard wireless or standard Ethernet setups, please see here:

http://wiki.slimdevices.com/index.php/SqueezeboxConnectionTypes

The setup you describe, bridged without DHCP is not supported, see here:

https://bugs-archive.lyrion.org/show_bug.cgi?id=6252

Thanks Steven. 

Felix, is there anything else that would help you to find a resolution? Do you want me to keep trying to create a reproducible case?

Ross, at least one more thing would be interesting. From all the observations it looks like in some conditions (possibly when a ip address renewal is due and obviously only with certain DHCP server implementations) an SBR can lose its regular ip address so it reverts to a self assigned one. Now it would be interesting to know if the same thing happens to an SB, TR or Boom as they share the same DHCP client code. (And we could rule out that it has anything to do with the SBC.)

And yes, a reproducible case would certainly help. Do you have any of the routers mentioned to test against?

(In reply to comment #33)
> i totally understand the KISS idea, but...

https://bugs-archive.lyrion.org/show_bug.cgi?id=7502

Ross,

so does that mean slim agrees with me?

and that bug is under controller, but is it really a SBR bug, in the guise of duet?

i'm just curious as to if slim sees it the way i do, and apparently quite a few others.

(In reply to comment #39)
> And yes, a reproducible case would certainly help. Do you have any of the
> routers mentioned to test against?

Here in QA land we don't have a Linksys WRT350N or Dlink DFL-210, I suppose I could setup a DNSMasq but I would rather use an out of the box router. I still have a few other experiments I would like to try, in an attempt to reproduce this. I will keep at it. Regarding which routers are in the QA lab, I keep this up to date as our router library grows:

http://wiki.slimdevices.com/index.php/RouterStatus

Mr Sinatra, I wish I had a better answer for you. We agree in that there is an open bug, assigned for 7.3. There are people who want to use static addressing for Duet and we want setup to be as simple and friendly as possible. 

Nate: I am playing around with DNSMasq (v2.41) and so far I was not able to reproduce what you've been seeing. A SBR (fw47), SBC (7.2r2873) and Boom (fw32) do their initial ip address request and renewal just fine (lease time is set to 2 minutes). And they always got their initial ip address again when renewing. I've tried to disturb the system by restarting DNSMasq, SC, SBR, SBC and Boom, but none of these actions broke anything.

So, I was wondering about your initial setup (i.e. before you moved SC). In comment #16 you state that you think you see the disconnects more often if you restart SC. Now my question is, did you only restart SC or the PC running SC? Also on what machine is DNSMasq running, same PC or on an other machine (i.e. is DNSMasq running all the time)? Also does your PC (running SC) use a fixed IP address or also use DHCP? Same question for the machine running DNSMasq (if different from the machine running SC)? And last question: Did you change any options for DNSMasq or just run it with default values (file dnsmasq.conf)?

Thanks
Felix

(In reply to comment #43)
> Nate: I am playing around with DNSMasq (v2.41) and so far I was not able to
> reproduce what you've been seeing. A SBR (fw47), SBC (7.2r2873) and Boom (fw32)
> do their initial ip address request and renewal just fine (lease time is set to
> 2 minutes). And they always got their initial ip address again when renewing.
> I've tried to disturb the system by restarting DNSMasq, SC, SBR, SBC and Boom,
> but none of these actions broke anything.
> 
> So, I was wondering about your initial setup (i.e. before you moved SC). In
> comment #16 you state that you think you see the disconnects more often if you
> restart SC. Now my question is, did you only restart SC or the PC running SC?
> Also on what machine is DNSMasq running, same PC or on an other machine (i.e.
> is DNSMasq running all the time)? Also does your PC (running SC) use a fixed IP
> address or also use DHCP? Same question for the machine running DNSMasq (if
> different from the machine running SC)? And last question: Did you change any
> options for DNSMasq or just run it with default values (file dnsmasq.conf)?
> 
> Thanks
> Felix
> 

Hi Felix, all very good questions. This will probably be a long comment, so my apologies in advance :P I'll try to address your questions sequentially and then comment further on what I perceive will be relevant information.

"Did you only restart SC or the PC running SC?"
Primarily I would be restarting the PC, however I was able to trigger the case where the SBR would not switch to a new SC until the disconnected SC came back online simply by executing /etc/init.d/squeezecenter stop
It is difficult to say if either method of SC being offline caused the SBR to "go blue" and lose itself in the private autoconfigured IP block though, because that behavior seems to happen with extended periods of inactivity. 

"Also on what machine is DNSMasq running, same PC or on an other machine (i.e.
is DNSMasq running all the time)?"
Again, I have tried and seen the SBR "go blue" with both cases: DNSMasq on my WRT54GS & dd-wrt firmware, as well as DNSMasq run from my Gentoo machine. Primarily the dd-wrt router runs DNSMasq as the DHCP server, but I tried running my Gentoo box as the server for about a week to see if I could curb the SBR going blue, but I was unable to despite tweaking dnsmasq.conf and extensive logging; all appeared as though it _should_ work.

"Also does your PC (running SC) use a fixed IP
address or also use DHCP?"
Interesting that you ask that. For a while my Gentoo box was a DHCP client of the router, but I forced it to 192.168.1.2 when I set it up as the DHCP server and have left it since (even though I reverted to using the dd-wrt router as the DHCP server again). I may be imagining things, but I'd venture to say that there *may* be a correlation between switching this Gentoo box to a static IP address and the SBR not going blue in a while. Then again, it's a classic case of "correlation does not imply causation" and there is no tangible basis for that observation.

"Same question for the machine running DNSMasq (if
different from the machine running SC)?"
The machine running DNSMasq is a Linksys WRT54GS router loaded with dd-wrt v23 sp2 firmware. It is of course configured with a static IP and is located at 192.168.1.1. It's been in use for a little over two years and I've never had a single hiccup from it. It regularly sees uptime of greater than 2 months.

"And last question: Did you change any options for DNSMasq or just run it with default values (file dnsmasq.conf)?"
I toyed around with telling DNSMasq to run in authoritative mode and some logging and debugging options to see if there was anything I was missing from a DHCP transaction sense, but I came up empty handed. The nature of the problem (sporadic intervals between occurrence, seeming necessity of not inconsiderable "idle" time on SBR) is of course extremely problematic because I think I'm right in saying nobody has figured out a reliable way to reproduce the bug (if I had I'd already have shipped you guys my router, SBR, and controller if packet logging was insufficient.) Without a reliable way to cause the SBR to "go blue" I have a hard time trying to keep as many variables static is possible.



I have to say I had a particularly tenacious "fit of blue" from the SBR about a week ago where I had factory reset 2-3 times and it still was jumping on the private-autoconf block despite being sent valid DHCP leases by the server, however after it came back online I think I'm right in saying it hasn't been offline since. I did spend a few days on my balcony using the SBR to stream pandora fairly regularly, but the weather has been hotting up again so I'm not using it very often and it has remained online without fault for a while (I'd say a period of 3-4 days.) With that said I'm positive I didn't change anything with any of the SCs in my network, nor did I change any DHCP options on the server so whatever happened had to happen inside the SBR. I'm going to have a go at methodically trying to get the SBR to "go blue" again since this week has been it's most reliable of my entire ownership of it.

I'm curious if, in your trials of trying to trip up the SBR, you had the controller directly connected to the wireless network, the SBR connected via ethernet, and at least a pair of squeezecenters on the network. I'd try connecting a factory reset SBR and controllers to the network, then the SBR to the first SC. Let the controller sleep, shut down the first SC, awaken the controller, attempt to switch the SBR to the second SC, and never restart the first SC. I'm going to have a go at that now and see if it turns anything up on my setup.


If there's anything I've omitted or been vague about, let me know. If I'm able to in any way, shape, or form reproduce the blues on the SBR, I'll post up immediately.
-----Nate

Fascinating; I was just able to cause some weird behavior. See if you can reproduce this... (I got a picture of the first part, for reference)

First:
SBR and Controller were happy on the network, connected to a running instance of SC on the Linux machine. I stopped SC on the linux machine, the icons on the controller and SBR both went blue (correctly). I switched the SBR to the Vista machine running SBR via the controller. It connected correctly and both lights went back to white as they should. Then I tried to reconnect to the linux machine (with the SC instance still stopped) and the controller showed a long attempt at connecting and then the failure message ("JacksonSquare could not connect to gentoo64") and went back to showing a successful connection to the Vista machine (and the light was white on the controller again). *HOWEVER* the SBR was still stuck on a blue light. (In the picture it overexposes and looks more white-ish. It isn't, it's most definitely blue.) I returned to the linux machine and restarted SC, it showed up on the controller and I reselected it and the SBR connected and the light went white again.

Second:
I did everything the same above, up until restarting the SC instance on the linux machine. Instead, after getting the blue light on the SBR from trying to connect to the SC that no longer exists (shouldn't it have disappeared from the menu, btw?) I then went back to the main menu (remember the controller says it's still connected to the Vista machine's SC) and tried to play a song. The controller said the song was playing for about 5-6 seconds despite the light on the SBR staying blue the whole time. The unexpectedly the controller dropped me out to the main menu with only two options: Settings, and Music Source. The light on the SBR remains blue, the light on the controller shows white, but it doesn't indicate what SBR it is connected to like it normally would.


I'm going to go back and play with the SBR some more, but I'm going to tentatively say that I may have just caused it to drop off the network? I'll have to see if unplugging allows me back on, but whatever is going on is somewhat curious and I need to play around with it some more.
-----Nate

Nate: Thanks for the extended feedback.

In my latest test I stopped DNSMasq for about one hour during which SBR, SBC and Boom all reverted to a self assigned ip address, but when I turned the DHCP server on again they would all come back and ask for a non self assigned ip address and connect back to SC just fine.

Another test was to add another device (iPhone) after restarting the DHCP server. The iPhone actually got the ip address Boom was using before. When Boom asked for a renewal it got a new ip address from the pool and reconnected to SC just fine.

I have not yet added a second SC to my little test setup.

However I tend to conclude that we deal with more than one scenario here (in this bug) which might (or might not) have the same root cause.

Nate's setup uses two SC's and sometimes SBC fails to switch over SBR to the other SC if the current has been stopped previously. Afterwards SBC fails to 'find' SBR which still tries to connect to the shutdown SC. I think that is more likely a SBC bug and probably should be taken out into another bug report.

Now for Johan and David's setup, I believe that either there is an issue with the particular router (i.e. some DHCP server incompatibility) and/or the DHCP ip address pool has been exhausted so that SBC gets the last available ip address and SBR fails to get one and reverts to a self assigned one.

(In reply to comment #46)
> However I tend to conclude that we deal with more than one scenario here (in
> this bug) which might (or might not) have the same root cause.
> 
> [...]
> 
> Now for Johan and David's setup, I believe that either there is an issue with
> the particular router (i.e. some DHCP server incompatibility) and/or the DHCP
> ip address pool has been exhausted so that SBC gets the last available ip
> address and SBR fails to get one and reverts to a self assigned one.
> 

I agree that there could potentially be a similar root cause to these issues. However, the issue I'm originally reporting is the very same issue that Johan and David are. Particularly, my symptoms are the exact same as those described in the original text of the bug report as well as comment 6. The other issues I'm exploring are what I believe to be precursors to the root problem of this bug report. I'm absolutely certain that the issue causing the SBR to reject/ignore valid DHCP offers is not (at least in my case) an exhausted address space. Furthermore, unless there is some fundamental flaw in DNSMasq, I doubt it's the DHCP server. Unfortunately that doesn't really help narrow anything down :(

(In reply to comment #46)
> Now for Johan and David's setup, I believe that either there is an issue with
> the particular router (i.e. some DHCP server incompatibility) and/or the DHCP
> ip address pool has been exhausted so that SBC gets the last available ip
> address and SBR fails to get one and reverts to a self assigned one.

Hi Felix,

I wish that was true, but in my case certainly not. I configured the DHCP server to use any address in the range 192.168.1.2 - 192.168.1.51, and that is more than enough (I have only about 8 devices requesting an IP address). I also configured DHCP assigning a fixed IP address (IP address reservation) to the SBR, to the controller and to both SBR and controller. In all cases I had a blue light.

An incompatibility with the router? Well, then it is at least an incompatibility with two routers as I tested with both a Netgear FM114P and a Linksys WRT350N. With both routers I got the blue light...

My observations:
- the controller never has a problem to connect to the WiFi network (to the router), but has trouble to connect / resolve the SBR after a power cycle or an extended period of inactivity. I never had problems to connect to a music source (ie. SqueezeCenter, SqueezeNetwork). 
- the SBR has problems to connect (both through WiFi or Ethernet I get these 169 addresses) and particulary when the connection with SC had been lost (simply because I turned of the PC, it was running at). Now, when SBR is streaming music and I turn of the PC/SC I'd say the chance is 90% I get a blue light. When I first stop the music the chance is 50/50.
- I moved SC to a Synology DiskStation. This device is always on, and I experience less problems. So I guess SC has a role in this akward 'blue light' behaviour.

Nate, understood. However I was not yet able to break my setup using DNSMasq. I've just tested with a 20 minute lease time, stopped DHCP server, all (SBR, SBC, Boom and iPhone) dropped to self-assigned when their lease wasn't renewed and after starting DHCP server again, all of them came back within 3 minutes.

Johan, I would like to test something on your setup if possible and if you have the time to be able to rule out some parameters.

When you have everything up and running I would like you to turn your SBC off and only control SBR via SC's webinterface. Now if you stop your SC check if SBR is dropping to a blue light (it should) and when you start SC again the light should go back to white.

Please do this a few times and possibly once over night, just let SBR sit there with a blue light and on the next day turn SC on again and hopefully the light goes back to white.

Thanks
Felix

Sorry, I didn't mean to target this to 7.2.1. 

Johan: Another question came up. When you first reported this bug about seeing two entries in the 'Choose Player' list you didn't mention what version you were using on your SBC. Could you please give us this information so we can try to reproduce that part of the bug, thanks.

David: I've just looked at the .cap file you posted with the failure and it looks like frame 2 and frame 4 (also frame 1 and frame 2) have identical time stamps. Not sure what went wrong here though.

(In reply to comment #52)
It looks like I accidentally pasted the packets in there twice while I was learning how to choose individual packets to send to the .cap file.  I'm going to try and get a capture of a regular squeezebox doing dhcp with the router today.

(In reply to comment #51)
> Johan: Another question came up. When you first reported this bug about seeing
> two entries in the 'Choose Player' list you didn't mention what version you
> were using on your SBC. Could you please give us this information so we can try
> to reproduce that part of the bug, thanks.

Some questions are easy to answer: I'm running SC 7.2 (release 28 August 2008) and SBC 7.2 r2873.

(In reply to comment #49)
> Johan, I would like to test something on your setup if possible and if you have
> the time to be able to rule out some parameters.
> When you have everything up and running I would like you to turn your SBC off
> and only control SBR via SC's webinterface. Now if you stop your SC check if
> SBR is dropping to a blue light (it should) and when you start SC again the
> light should go back to white.
> Please do this a few times and possibly once over night, just let SBR sit there
> with a blue light and on the next day turn SC on again and hopefully the light
> goes back to white.

Felix, Im running tonight the 'overnight' test, but found already some interesting test results (I can reproduce these).
- Everything is running fine. I turn off SBC. Stop SC, SBR goes blue. Start SC, SBR goes white and I can control SBR through web GUI. Repeated this few times with same (expected) result.

Regardless of the previous test (stop / start SC) I found some akward behaviour of SBC.
- When I power off SBC and after a few minutes turn it on, SBC shows 'connecting to SqueezeLiving'. After about 15 seconds it is connected.
- When I power off SBC and turn it on again, but the time interval is longer (say about 8 hours) it shows 'connecting to SqueezeLiving'. However, it fails to do so. I push the back button and now I get two menu options, Instellingen (properties) and  Muzieksysteem (music system). When I chose the latter, I get a blank screen (SBC doesn't see SBR) Now, I power off SBC and turn it on again. I select 'music system', SqueezeLiving is shown and SBC connects to it. 

Thus, after a longer (few hours) period that SBC is powered off I need to  stop/start twice.

This doen't shed anylight on the blue light, but it shows another connection problem. Maybe the two are related.

Created attachment 4098 [details]
capture of dhcp between a boom & dfl-210 router.

capture of dhcp between a boom & dfl-210 router.  I first selected ethernet & obtain ip address automatically.  This results in the first successful dhcp negotiation in the log.  Then I power cycled the boom.  It wasn't able to get an IP address (ignored dhcp offers directed at its IP instead of the broadcast address).  I went back in the interface and selected ethernet/obtain ip automatically again and it worked.

(In reply to comment #49)
> Please do this a few times and possibly once over night, just let SBR sit there
> with a blue light and on the next day turn SC on again and hopefully the light
> goes back to white.

I ran the overnight test. Stopped SC server in the evening. SBR goes blue. Started SC server the next morning, SBR goes white. Pushed the button once and it started to play its current playlist.

It might be interesting to see what happens if David and Nate run the same test (turn SBC off and stop / start SC). Can you reproduce my SBC behaviour (see comment 55)? 

Is it possible that due to the fact that SBC doesn't 'see' the SBR (or sees two SBR's, as has been the case before) drives the SBR into some modus that results in denial of DHCP service? Or in other words, that we have been focussing here on the symptoms (blue light SBR), but the cause is actually a bug in SBC? Just trying to help...

See comment 55. I've been able to reproduce the behaviour of SBC and thought I should write it down a bit more extensive.

While SC is running and SBR has white light:

- turn off SBC
- turn it on again after a few hours (we should try to specify 'a few')
- SBC shows 'connecting to SqueezeLiving'. However, it fails
to do so. 
- Push back button
- SBC shows two menu options, Instellingen (properties or configuration in English I guess)) and  Muzieksysteem (music system). 
- Select'Music system' --> SBC shows a blank screen (SBC doesn't see SBR)

- Turn off SBC
- Turn on SBC
- SBC shows Menu with two options Instellingen and Muzieksysteem
- Select 'Muziek systeem' (music system)
- SBC shows SBR by its 'nickname' (so in my case SqueezeLiving)
- Select SqueezeLiving
- SBC now shows ANOTHER 'connecting to ...' screen (the rolling one with small text)
- within 10 seconds it is ready to play.

During this process SBR light stays white (and of course SC is running as well). If bewteen first power cycle SC is stopped /started, the results as described here stay the same.

Felix notes that he is working on this now for all our IP3K products.

I've fixed DHCP code (Bug: 9415) to allow for an additional 8 seconds before giving up when trying to get a DHCP address. Now the full 30 second countdown is used and not only about 22 seconds of it.

This might help in some cases where a slow DHCP server is the issue.

It doesn't help if we aren't compatible with the DHCP server used.

The additional fix I thought might help with DHCP issues unfortunately does not work with some APs/routers I tested against. Even worse this APs/routers somehow get completely confused and stop giving out IP addresses to any device.

I think with the one change I already did regarding DHCP and all the changes on SBC I'd like to have all people affected by this bug to upgrade to 7.3 (when it is released) and to retest.

Please reopen this bug if you still see the issue with 7.3. Thanks

Okay, thank you Felix! I'll test as soon as a 7.3 package is released for Synology Diskstation.

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.