PDA

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



bsquare
2006-01-22, 16:03
I've been struggling for days now to get my SB3 to work reliably. I stripped my network way down to get the SB3 working yesterday and it was able to properly connect via wireless (802.11g, Airport Express, WPA Personal) to my Powerbook G4 (also wireless).

Today I tried to return the network to its normal state and everything works except the SB3.

I can stream from the SlimServer running on OpenBSD (Ethernet connected) to my Powerbook and iMac (wireless connected via Airport Express). The SB3 connects to the network, gets an address via DHCP, and then fails to connect to the same SlimServer the other machines are using. The SB3 will, however, connect properly to SqueezeNetwork.

I can ping the SB3 from the OpenBSD system. I do not see packets from the SB3 arrive at the OpenBSD system when it claims to be trying to connect (according to tcpdump output that shows traffic from the other clients). I have reset the SB3 and re-entered all data, with identical results. The Airport Express is configured to allow both WPA and WPA2 clients (previous config only allowing WPA2 did not work correctly).

I'm used to atrocious networking from this sort of device (yes, I'm talking about you, Roku), but this is pretty ridiculous.

Does anyone have any suggestions other than ditching all embedded players and sticking with software that actually works?


bb

ceejay
2006-01-22, 16:34
Does anyone have any suggestions other than ditching all embedded players and sticking with software that actually works?


bb

Switch to Windows? (Sorry - only kidding!)

(1) Is there a firewall on the server - and if so is it possible its rejecting the IP address that the SB3 has been given, while allowing the address used by the other devices (perhaps because its only allowing a very narrow range of addresses)?

(2) I assume that since you can ping the SB3 that it has a good IP address... but, while in the mode where it can't see the slimserver, can you conenct to (and play from) SqueezeNetwork?

Ceejay

bsquare
2006-01-22, 16:42
Switch to Windows? (Sorry - only kidding!)

h0h0h0h0



(1) Is there a firewall on the server - and if so is it possible its rejecting the IP address that the SB3 has been given, while allowing the address used by the other devices (perhaps because its only allowing a very narrow range of addresses)?


The packet filter on the server permits the entire /24, that includes the range used for DHCP. The addresses in use by the DHCP clients, working or not, are sequential. Given that the packets weren't showing up in tcpdump, it seems like the SB3 wasn't even sending packets to the server when it said it was.



(2) I assume that since you can ping the SB3 that it has a good IP address... but, while in the mode where it can't see the slimserver, can you conenct to (and play from) SqueezeNetwork?


Correct. I am currently listening to the BBC World Service via SqueezeNetwork, but any attempt to connect to the same local server the Macs know and love fails.


bb

Skunk
2006-01-22, 17:01
Can you uninstall/reinstall the protocol on OpenBSD? On win 2k its pretty easy to disable TCP/IP, restart and re-enable. May recognize SS?

ceejay
2006-01-22, 17:02
Hmm, odd. I'm about to run out of ideas, but before I go, how about one thing you might try... just for fun, install another copy of slimserver on one of your other machines (it only needs to have a couple of MP3s to play with) and see if that behaves any differently?

Ceejay

bsquare
2006-01-22, 17:03
Can you uninstall/reinstall the protocol on OpenBSD? On win 2k its pretty easy to disable TCP/IP, restart and re-enable. May recognize SS?

2 other clients work fine and I don't even see traffic from the SB3 on the OpenBSD system running SlimServer. I've restarted everything involved without success in getting the SB3 working with the local server.

At this point I see no evidence of anything but the SB3 itself functioning incorrectly.


bb

bsquare
2006-01-22, 17:12
I've just resolved this problem:

All the other clients are using HTTP on port 9000 to get their stream, but the SB3 isn't. It is using port 3483. Apparently the more, different ports and protocols you use the better.

Dumb.


bb

radish
2006-01-22, 17:25
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.



Dumb.


Uh-huh.

snarlydwarf
2006-01-22, 17:38
I've just resolved this problem:

All the other clients are using HTTP on port 9000 to get their stream, but the SB3 isn't. It is using port 3483. Apparently the more, different ports and protocols you use the better.

Dumb.


Not really, the protocol is more complex than HTTP.

If it were HTTP both the server and the Squeezebox would have to have HTTP implementations since some requests are client-initiated, and some are server-initiated. (And polling every 1/2 second would... suck.)

HTTP is there for flexibility (lets you use an web browser for control or http for streaming), but the streaming sucks compared to the SB (buffering on Winamp/xmms/whatever, for example - there's no "oh, that stuff I just sent you: I changed my mind, here's new data, dump your buffer and play this... ie, "skip track with low latency")

bsquare
2006-01-22, 18:37
Not really, the protocol is more complex than HTTP.

If it were HTTP both the server and the Squeezebox would have to have HTTP implementations since some requests are client-initiated, and some are server-initiated. (And polling every 1/2 second would... suck.)

HTTP is there for flexibility (lets you use an web browser for control or http for streaming), but the streaming sucks compared to the SB (buffering on Winamp/xmms/whatever, for example - there's no "oh, that stuff I just sent you: I changed my mind, here's new data, dump your buffer and play this... ie, "skip track with low latency")

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.


bb

bsquare
2006-01-22, 18:41
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
2006-01-22, 19:29
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
2006-01-22, 20:03
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
2006-01-22, 20:54
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
2006-01-23, 00:26
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
2006-01-23, 03:51
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
2006-01-23, 03:56
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
2006-01-23, 04:11
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
2006-01-23, 06:30
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
2006-01-23, 21:16
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

snarlydwarf
2006-01-23, 22:57
the protocols are representative of what is going on within the application. i'd enjoy hearing the motivation for the change.


Performance and multithreading. (With modern processers and 'hyperthreads,' there's an advantage to multithreading even on single CPU systems, not to mention the old standby of "better interactive performance")

Apache may or may not be the method chosen (it's listed as "investigate"), but it does offer a cheap way to multithread. (Much like using MySQL for the backend may be a bit overkill for many people, but it also gives some of the same multithreaded benefits in a very well stress-tested code base.)

It fits under the generic umbrella of "Re-architect event/threading/forking model."

Of course, part of what is being investigated would have Apache handling not only HTTP but also SlimProto... so you'd be back where we started, with one program handling multiple protocols....

seanadams
2006-01-23, 23:16
bb,

Excellent points regarding the need for better feedback on DHCP failure, timeout etc.

Your sendmail analogy isn't apt though... every Squeebox must have a UI, a music library, internet radio, etc - these aren't "add-ons". The protocol that the box speakes to the server is *by design* low-level and user-feature-agnostic, which is diametrically opposite to most (all?) RFC protocols.

The single-threaded one-process-does-all architecture is sort of a legacy thing - I don't think anyone would argue that it's ideal given the software's current feature set, but it's scaled fairly well all things considered. With SlimServer 7 we'll begin breaking things out so that the UI runs separate from disk scanning, etc.

The possbility for the server architecture to change in such a fundamental way proves (IMHO) the correctness and flexilibily of the protocol design.

Robin Bowes
2006-01-24, 02:20
bsquare said the following on 01/24/2006 04:16 AM:
> Robin Bowes Wrote:
>
>>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.

svn co http://svn.slimdevices.com/repos/slim/trunk/

Patches welcome.

R.

seanadams
2006-01-24, 09:32
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.[/color]

svn co http://svn.slimdevices.com/repos/slim/trunk/

Patches welcome.



I think he was asking for the firmware source, which is not open.

bsquare
2006-01-24, 20:42
I think he was asking for the firmware source, which is not open.

you are correct.

jimbob67
2006-03-02, 08:10
I realize this thread is getting pretty long, but it's the first one I could find that addressed a firewall problem with Mac. (Thought I was a real loser, since I could "understand" a problem with Windows!)
I'm using the newest OS X, updated regularly. Just got SB3, first couldn't find the computer. I disabled my firewall, something I don't want to leave that way for long, and things seemed to work.

However, even with firewall disabled, it seems to lose the connection sporadically. Any ideas? (Set on NO WEP, dynamic address)
Also, in the very sparse instructions, I'm told "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."
Actually, the FAQ I've seen doesn't really say "both UDP and TCP" for Mac, but I presumed this is the case?
How does one do this? Separate the port numbers with a comma? Semicolon? Different?
Realize this is pretty basic but their documentation isn't real good. Appreciate any help.
Jim