Another broken networking variant: Score - OS X and BSD: 3, SB3: 0

[bsquare]

Squeezebox User Manual, page 24:

"Squeezebox can’t connect to my computer running SlimServer"

...snip...

You will need to configure your firewall software or hardware to allow connections to ports 3483 and 9000 for both UDP and TCP connections. Refer to the documentation that came with your firewall for details.



Uh-huh.

Interestingly enough, this document is not accurate as port 9000 UDP is not used. Further, the error messages from the SB3 are less than useful for debugging.

Yes, the docs include this information.

Yes, this device should not require the docs to function properly.

If the goal of Slim Devices is to get people reading documentation, then by all means they are hitting the sweet spot. I was under the apparently mistaken impression that the point was making a simple device to play music.


bb

[snarlydwarf]

Further, the error messages from the SB3 are less than useful for debugging.

Why do I think you're flaming for the sake of flaming?

How could it be any more verbose than "Cannot connect to Slimserver"?

I guess it could add: "Perhaps your server is off, or maybe on a different network and you need to fix routing' or it could be on a different physical network, so check your cabling; or maybe it's got a firewall on... I don't really know, because I just sent a discover packet but no one is responding, you will have to figure out why nothing is responding..."

The nature of firewalls is that they don't give the client a "sorry, I'm firewalled, please check rule #16 for why you are blocked." (Some do actually send a notice that a packet is rejected due to a firewall (ICMP_PKT_FILTERED) most don't. None say why.)

Yes, this device should not require the docs to function properly.

I'd much rather not have some script messing with my firewall rules, thanks.

If the goal of Slim Devices is to get people reading documentation, then by all means they are hitting the sweet spot. I was under the apparently mistaken impression that the point was making a simple device to play music.

If you run Windows, it will (when Windows behaves, anyway...) automatically insert itself into the firewall rules. It even usually works, which is amazing on Windows. Sometimes, for reasons only Microsoft understands, it needs a reboot. Sometimes it doesn't.

None of this justifies putting them both in the same server rather than running different processes. You are describing a situation where 2 completely different things are going on, but they have been inexplicably glommed into the same, single server.

The Squeezebox does NOT use HTTP to access the server. Really. Heck, you can block it and nothing will happen except that you can't connect from your web browser or Winamp/XMMS/whatever.

The SB uses the Squeezebox API, not HTTP.

Most people like being able to use the web interface sometimes. Most people like being able to stream to clients other than a Squeezebox or Softsqueeze.

I guess, in theory, the HTTP support could be yanked from the server itself, and a CGI could use the CLI to talk to the server and it looks like that is on the road map (moving to Apache for HTTP stuff), but it's hardly critical and not even the source of your problems.

Again, it really sounds like you're just flaming to flame.

[bsquare]

How could it be any more verbose than "Cannot connect to Slimserver"?

It could, for example, say "Connection to Slimserver timed out" or "Connection to Slimserver rejected". These mean different things as I'm sure you are aware. I'm not asking for it to read my mind or debug a problem, I'm asking for it to provide the information it has.

I guess it could add: "Perhaps your server is off, or maybe on a different network and you need to fix routing' or it could be on a different physical network, so check your cabling; or maybe it's got a firewall on... I don't really know, because I just sent a discover packet but no one is responding, you will have to figure out why nothing is responding..."

Thanks for that incredibly helpful and positive contribution.

The nature of firewalls is that they don't give the client a "sorry, I'm firewalled, please check rule #16 for why you are blocked." (Some do actually send a notice that a packet is rejected due to a firewall (ICMP_PKT_FILTERED) most don't. None say why.)

Again, you are assuming all reachability problems have the same signature to the client and that they are therefore indistinguishable. This is not the case.

I'd much rather not have some script messing with my firewall rules, thanks.

Awesome! What's that got to do with wanting useful debugging information from the SB?

The Squeezebox does NOT use HTTP to access the server. Really. Heck, you can block it and nothing will happen except that you can't connect from your web browser or Winamp/XMMS/whatever.

The SB uses the Squeezebox API, not HTTP.

Most people like being able to use the web interface sometimes. Most people like being able to stream to clients other than a Squeezebox or Softsqueeze.

I guess, in theory, the HTTP support could be yanked from the server itself, and a CGI could use the CLI to talk to the server and it looks like that is on the road map (moving to Apache for HTTP stuff), but it's hardly critical and not even the source of your problems.

Please see my previous posts where I state explicitly that there are clearly 2 different protocols at play (really 2 different applications), but they have been put into a single app for no apparent reason.

The developers would seem to agree with that assessment if the direction is to split the applications. It is in fact a significant source of my problem because I expected a more rational structure for the system than it has. Software that has been developed organically, as this clearly has, often has this problem and must periodically go through a major restructuring so that it can continue to grow. Not "in theory" but in reality, and in this case.

Again, it really sounds like you're just flaming to flame.

Pot, kettle, black.


bb

[Skunk]

I've been struggling for days now to get my SB3 to work reliably.

bb

And how does it sound now that this epic struggle has come to a conclusion?

[bsquare]

And how does it sound now that this epic struggle has come to a conclusion?

Thank you, voice of reason!

I like it. I'm sure it can be improved (there's a tube DAC in its future), but what can't?


bb

[Robin Bowes]

bsquare said the following on 01/23/2006 12:12 AM:
> I've just resolved this problem:
>
> All the other clients are using HTTP on port 9000 to get their stream,

What clients are those? You mean the web interface? Or are you talking
about streaming to a client on port 9000 using stream.mp3?

> but the SB3 isn't. It is using port 3483.

SB uses port 3483 (tcp) for control and 3483 (udp) for discovery. This
is different to the dumb stream on port 9000.

> Apparently the more,
> different ports and protocols you use the better.

Not quite - two purposes, two protocols, two ports. Seems reasonable to me.

> Dumb.

No, just not what you initially understood.

R.

[Robin Bowes]

bsquare said the following on 01/23/2006 01:41 AM:
> radish Wrote:
>
>>Squeezebox User Manual, page 24:
>>
>>"Squeezebox can’t connect to my computer running SlimServer"
>>
>>...snip...
>>
>>You will need to configure your firewall software or hardware to allow
>>connections to ports 3483 and 9000 for both UDP and TCP connections.
>>Refer to the documentation that came with your firewall for details.
>>
>>
>>
>>Uh-huh.
>
>
> Interestingly enough, this document is not accurate as port 9000 UDP is
> not used. Further, the error messages from the SB3 are less than useful
> for debugging.
>
> Yes, the docs include this information.
>
> Yes, this device should not require the docs to function properly.

It's a networked audio device. Do you seriously expect the "network"
part to simply work *everywhere* it's connected without requiring any
configuration or reading of documentation?

> If the goal of Slim Devices is to get people reading documentation,
> then by all means they are hitting the sweet spot. I was under the
> apparently mistaken impression that the point was making a simple
> device to play music.

Listen, you got bitten because you have a firewall on your server. If
you'd read the docs (i.e. the user manual) it would have told you which
ports you need to open. I'm not sure what your gripe is?

R.

[Robin Bowes]

bsquare said the following on 01/23/2006 03:03 AM:
> snarlydwarf Wrote:
>
>>How could it be any more verbose than "Cannot connect to Slimserver"?
>>
>
>
> It could, for example, say "Connection to Slimserver timed out" or
> "Connection to Slimserver rejected". These mean different things as
> I'm sure you are aware. I'm not asking for it to read my mind or debug
> a problem, I'm asking for it to provide the information it has.

The SB itself is a fairly "dumb" device - most of the
processing/intelligence is done on the server. Hence the name "Slim
Devices", slimp3, etc. etc.

So, there's not a great deal of processor/ROM etc on the box itself to
fit in a load of code to perform network diagnostics for edge cases.

> snarlydwarf Wrote:
>
>>I guess it could add: "Perhaps your server is off, or maybe on a
>>different network and you need to fix routing' or it could be on a
>>different physical network, so check your cabling; or maybe it's got a
>>firewall on... I don't really know, because I just sent a discover
>>packet but no one is responding, you will have to figure out why
>>nothing is responding..."
>>
>
>
> Thanks for that incredibly helpful and positive contribution.

It made me smile - that's a positive thing.

> snarlydwarf Wrote:
>
>>The nature of firewalls is that they don't give the client a "sorry,
>>I'm firewalled, please check rule #16 for why you are blocked." (Some
>>do actually send a notice that a packet is rejected due to a firewall
>>(ICMP_PKT_FILTERED) most don't. None say why.)
>>
> Again, you are assuming all reachability problems have the same
> signature to the client and that they are therefore indistinguishable.
> This is not the case.

See above.

> snarlydwarf Wrote:
>
>>The Squeezebox does NOT use HTTP to access the server. Really. Heck,
>>you can block it and nothing will happen except that you can't connect
>>from your web browser or Winamp/XMMS/whatever.
>>
>>The SB uses the Squeezebox API, not HTTP.
>>
>>Most people like being able to use the web interface sometimes. Most
>>people like being able to stream to clients other than a Squeezebox or
>>Softsqueeze.
>>
>>I guess, in theory, the HTTP support could be yanked from the server
>>itself, and a CGI could use the CLI to talk to the server and it looks
>>like that is on the road map (moving to Apache for HTTP stuff), but
>>it's hardly critical and not even the source of your problems.
>>
>
>
> Please see my previous posts where I state explicitly that there are
> clearly 2 different protocols at play (really 2 different
> applications), but they have been put into a single app for no apparent
> reason.

Ah, I see. So a single app is not allowed to use more than one protocol?
Damn, better junk all my mail clients (they use smtp and imap, oh, and
pop3 too), web browsers (http + https), etc.

> The developers would seem to agree with that assessment if the
> direction is to split the applications.

No. The reasoning behind moving towards a modular architecture is
nothing to do with protocols.

> It is in fact a significant
> source of my problem because I expected a more rational structure for
> the system than it has.

No, the software has a perfectly rational structure. It just did not fit
into your preconception of what it might be. That does not make it wrong
or bad, just different.

The major source of your problem here was not reading the user manual.
You're obviously clued up enough to run a firewall but seem not to have
twigged that your adding a new network device and that perhaps it might
be a good idea to find out what network ports it needs/uses.

> Software that has been developed organically,
> as this clearly has, often has this problem and must periodically go
> through a major restructuring so that it can continue to grow. Not "in
> theory" but in reality, and in this case.

The core code, i.e. the command handling , streaming etc. has not
changed for a long time. There is a published CLI specification which
has not change in a long time (since the launch of the SB2? - not sure.)

Please, stop throwing brickbats; you're peeved that you had to spend
some time getting this to work because you omitted to configure the
firewall on the server running slimserver despite this being clearly
stated in the User Manual.

Put some music on and enjoy.

R.

[Skunk]

Thank you, voice of reason!

I like it. I'm sure it can be improved (there's a tube DAC in its future), but what can't?


bb

I'm actually gonna go with non-oversampling, but I have tubes in the amp. Good choice, enjoy

[bsquare]

So, there's not a great deal of processor/ROM etc on the box itself to fit in a load of code to perform network diagnostics for edge cases.

what i suggested requires no extra processor time and extremely minimal extra code. the device has the information to distinguish what problem it encountered.

received a rst? -> "connection refused"
received icmp unreachable? -> "slim server unreachable"
timed out trying to connect? -> "connection timed out"

further, the behavior of a squeezebox when it wakes from sleep and can't get a dhcp address where it previously could is another case of zero feedback. rather than indicate it can't get an address, it simply tries to connect to the slim server and fails. why not just say "unable to get an address" when it ends up with a link local IP?

again, this is not a bunch of extra code and processing.

See above.

See above.

Ah, I see. So a single app is not allowed to use more than one protocol? Damn, better junk all my mail clients (they use smtp and imap, oh, and pop3 too), web browsers (http + https), etc.

clients generally have to adapt to the proliferation of server-side protocols. this does not dictate that the server-side is a single app with all those protocol. for example, sendmail, postfix, and qmail (as with any sane MTA) don't speak pop3 and imap. to handle those protocols, there are other applications. merging all that functionality into a single, monolithic system gets you things like exchange.

you get all the checkboxes for features, along with an incredibly slow, unreliable monster.

No. The reasoning behind moving towards a modular architecture is
nothing to do with protocols.

the protocols are representative of what is going on within the application. i'd enjoy hearing the motivation for the change.

The major source of your problem here was not reading the user manual. You're obviously clued up enough to run a firewall but seem not to have twigged that your adding a new network device and that perhaps it might be a good idea to find out what network ports it needs/uses.

you can choose to see it that way or you can see that i am raising legitimate concerns and presenting ideas on how the product can be better. if you think it is best to give opaque errors, then please point me at the source code and documentation for the software running on the SB and i will make the changes myself.


bb