Bugzilla – Bug 8397
SqueezeCenter cannot cope with a SlimProto read finising within the first 8 bytes of a frame
Last modified: 2011-03-16 04:35:05 UTC
Created attachment 3424 [details] Patch to deal with SlimProto reads ending within the first 8 bytes of a frame Recently I've started noticing random disconnects of my SSH tunneled softsqueeze, with the server logging: 'Client sent bad data' This was tracked down to the fact that the server assumes that a read from a client will never finish within the first 8 bytes of a frame, i.e. that it has successfully read OP and LEN. Over LANs, this is very unlikely to happen, every packet sent by the client will almost certainly correspond to a single chunk of data read by the server. However, as TCP is stream based, there's no guarantee of this, especially with SSH tunneled connections. The attached patch should fix this, at a very slight cost in processing overhead for partial reads. However, as I'm only seeing partial reads every 2 mins or so, this overhead should be utterly negligible. It's had a cursory test and probably needs rather more rigorous analysis.
Created attachment 3437 [details] Updated patch to deal with SlimProto reads ending within the first 8 bytes of a frame Updated patch so that debug info makes more sense.
Thanks, patch applied as 7.1 change 20842.
Christopher: please retest with SqueezeCenter 7.1-21796. if you still see the error, then reopen the bug with added comments.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com 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.
Reduce number of active targets for SC