Bugzilla – Bug 2283
MAC corruption
Last modified: 2009-02-20 01:18:31 UTC
I have two SB2s on a WPK wireless LAN. They both died and refused to contact the LAN, let alone the Slimserver. This was all previously working fine. I knew the LAN was fine because I had a laptop on it. Here's what happened: I installed this (and let the SB2s upgrade to firmware 24): SlimServer Version: 6.2b1 - 4587 - Windows XP - EN - cp1252 They have both been functioning fine for a couple of days. This morning, after doing a little IR-Blaster testing I synchronised them. They played one track fine then I noticed silence. I was sat at my PC and hit another track in the playlist, still silence so went to look at one of them. They were both sat there looking brand new. You know, with the message about hit right to setup. I did so and noticed all the network settings had been lost. Re-entered that and tried to connect the the LAN but with no joy. This was the same for them both. Tried again, no luck. Tested the LAN, rebooted the access point. No joy. Then, purely by chance I was looking though the 'current settings' and noticed this: MAC Address: ff ff 56 00 00 00 Huh? This wasn't right, and it was like this on them both. I re-entered the correct addresses from the bottom of the units and hey-presto, all was fixed. Lucky, I looked in those settings, but what a bug!
Robin: What firmware version was on your players before the update?
Sorry, I don't recall the exact firmware upgrade path. The players were shipped 2-Oct-05, so whatever that makes it. I had Slimserver 6.1 on my PC when I received them and they upgraded to what that came with immediately. I have squeezebox2_11.bin & squeezebox2_15.bin sat in the backup of that directory so those are probably the versions. Then the upgrade to firmware 24 with 6.2b.
Robin, one more question: did you unplug the players around the time you updated them and/or was the power plug loose? (The original firmware corruption bug was triggered by intermittent power to the device.)
There were no power problems. No loose plugs, and even if one of them was loose, the chance of them both being this way is very remote. They were playing and not being touched at the time. The firmware was upgraded a couple days before the problem happened so don't think it's anything to do with that process.
any use of bridging as in bug 2221?
No, not using bridging. It could not even connect to the WLAN with the corrupted MAC. There's no MAC filtering on the access point so that doesn't look to be the problem.
Robin: can you update to the latest build (6.2b2) and let us know if the mac address gets corrupted again? I can't reproduce this issue here.
Marking fixed unless we can get another case to reproduce with the latest firmware.
I'm using firmware V48 on SB2 and since switching autoupdate on I have had a instances of corrupt MAC addresses on two players when changing the firmware version.
Thanks, Keith. Chris: can you reproduce this?
Not easily. So autoupdate is on; what do you do right before the autoupdate begins? Is the sb2 turned off? Is it connected to squeezenetwork? Do you remember? Thanks for any info!
*** Bug 2816 has been marked as a duplicate of this bug. ***
This clearly isn't going to get fixed for 6.3.
Most of the reports on this bug seem to have something to do with power failures or brownouts, so I plan to try to reproduce this by adjusting the power to an SB3. Clearly we can't fix the end user's power, and it's also difficult to fix a bug that seems to happen due to the CPU behaving unpredictably, but if I can reproduce it reliably, at least we can try some things to see if they help.
I possible fix for this bug is included in Squeezebox2/v3 firmware 64 following a code review. We need to check a month after that firmware is released to see if support have had any new reports.
It seems this bug was fixed, but come back again in a firmware rev ~70 See this thread http://forums.slimdevices.com/showthread.php?t=31754&page=5
Note it can be very difficult to determine without a controlled experiment whether the corruption happened in an earlier firmware version and was just became apparent at a later firmware revision versus actually occurring on the stated firmware.
That said, we would very much like to continue hearing from users who see this problem, so we can try to determine how serious it still is.
Dan how many instances of this issue reported post fw 64?
I can't be certain, but I think the answer is ZERO. (there've been a few false alarms, but we have no concrete example of this post-fw64.)
Dan please re-open if you see fit.
(In reply to comment #20) > I can't be certain, but I think the answer is ZERO. (there've been a few false > alarms, but we have no concrete example of this post-fw64.) Hi, Still researching around this but I have just seen this issue happen with 7.5.3 on OS X. Looks as though it was triggered by a faulty power supply. One of my squeeze boxes basically inherited all the settings from the other. Including name, MAC address etc. Easy to fix once you change the MAC address