internet+SB = aaaargh!

[Phil Leigh]

I'd really appreciate some help with my setup.
I have a a PC running slimserver and an SB2 wired to a Linksys wag54s (UK) router/ADSL modem via a Belkin switch.
Wireless Internet access all round the house and on my wired Slimserver PC is always fine. However, I can only use the SB if I unplug the switch from the router. If I don't, the SB buffer refuses to get over 10% and I get constant dropouts (using FLAC).As soon as I unplug the PC+SB from the router, Streaming is perfect - no dropouts, 100% buffer etc. However, as I'm sure you can appreciate, I'd like to have everything running together nicely, as many of the plugins I use need Internet access...
Are there any debug traces or other stuff I could use to debug this problem? - It's driving me potty!
Many thanks in anticipation
Phil

[Phil Leigh]

rebuilt the pc with new MB (and NIC) - no change to odd behaviour when Internet is connected...
Guess it must be the router behaving badly. Any suggestions as to anything I could change on the router?

[Siduhe]

What version of the firmware are you running on the Linksys ?

This thread describes a similar problem to the one you are experiencing and the suggestions appear to be to use static IPs and upgrade the firmware (1.02.7 for UK users at time of the below posting).

http://forums.broadbandbuyer.co.uk/forum_posts.asp?TID=2362

[Phil Leigh]

Thanks - I checked out that thread...
I'm already using static IP's and my router is a newish WAG54GS not the older WAG54.
It's very annoying that I have to unplug my Internet connection (at least, disconnect the router from the hub) to use my SB.
I can't help thinking there is some basic config setting on the router that is causing a clash between my SB streams and the Internet..any help gratefully received.

[slimpy]

Have you double-checked that all of your devices use unique IPs? This sounds very much like an IP conflict. If you have more than one device with the same IP connected to the router it gets confused and can't properly forward data packets to the right physical port.
In your case it could be the SQB and the router sharing the same IP.
Also make sure that your static IPs are within one of the ranges of IPs for private use like 192.168.XXX.XXX.

-s.

[Mark Lanctot]

Check to see that DHCP is only activated in one of the devices - either the router or the switch, but not both.

Also you may want to try a static IP arrangement.

[Phil Leigh]

Thanks folks - I've checked that both my NIC and SB have static addresses (192.168.1.100 and 192.168.1.101 respectively) and DHCP is only operational (for the other wireless clients in the house) on the router, whose ip address is 192.168.1.1.

Both my NIC and the SB have 192.168.1.1 set as their DNS gateway.


(just to be clear, I only have a combo ADSL modem/router - the switch is just a 5-way ethernet hub with no "logic" in it)

[JJZolx]

Thanks folks - I've checked that both my NIC and SB have static addresses (192.168.1.100 and 192.168.1.101 respectively) and DHCP is only operational (for the other wireless clients in the house) on the router, whose ip address is 192.168.1.1.

Both my NIC and the SB have 192.168.1.1 set as their DNS gateway.

(just to be clear, I only have a combo ADSL modem/router - the switch is just a 5-way ethernet hub with no "logic" in it)
Any chance of an IP address conflict? Is the DHCP server handing out IP addresses that includes .100 and .101?

Check the router's logs. There may be some clues to what is happening.

[Phil Leigh]

The router DCHP service is set to hand out starting at 102 to avoid a conflict...I'm pretty sure (99%) it's not an ip conflict - seems more like a clash of traffic...

Network health:
Control Connection : OK
Streaming Connection : OK
Player Signal Strength : OK
Buffer Fullness : Low
Server Response Time : OK

[Phil Leigh]

This is the full health listing:

Is there anyhting else I could do to debug (debug options?)


Squeezy
Please queue up several tracks to play on this player and start them playing. Then press the Reset Counters link above to clear the statistics and update this display.

Summary
Control Connection : OK
Streaming Connection : OK
Player Signal Strength : OK
Buffer Fullness : Low
Server Response Time : OK


Warnings
The playback buffer for this player is occasionally falling lower than ideal. This is a Squeezebox2 and so the buffer fullness is expected to drop at the end of each track. You may see this warning if you are playing lots of short tracks. If you are hearing audio dropouts, please check our network signal strength.


--------------------------------------------------------------------------------

Player Performance : Squeezy
The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.

It is imporant to leave the player playing for a while and then assess the graphs.


Buffer Fullness
This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.
Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

< 10 : 2 :100% ##################################################
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 0 : 0%
< 50 : 0 : 0%
< 60 : 0 : 0%
< 70 : 0 : 0%
< 80 : 0 : 0%
< 90 : 0 : 0%
< 100 : 0 : 0%
>=100 : 0 : 0%
max : 0.089010
min : 0.000000
avg : 0.044505


--------------------------------------------------------------------------------

Server Performance
The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time
This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.
The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

< 0.002 : 42 : 95% ###############################################
< 0.005 : 1 : 2% #
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 1 : 2% #
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.016550
min : -0.008855
avg : 0.000750

Timer Accuracy
Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.
Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

< 0.002 : 3 : 75% #####################################
< 0.005 : 1 : 25% ############
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 0 : 0%
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.002330
min : 0.000882
avg : 0.001491

Timer Task Duration
This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.
< 0.002 : 4 :100% ##################################################
< 0.005 : 0 : 0%
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 0 : 0%
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.001416
min : 0.000238
avg : 0.000806

[snarlydwarf]

< 10 : 2 :100% ##################################################
< 20 : 0 : 0%
< 30 : 0 : 0%


Let it run longer: that's really not enough run time to reach any conclusion at all. (ie, "I looked twice, and it was less than 10% buffer!" It never had a chance to fill.)

[Phil Leigh]

OK - here goes...


Squeezy
Please queue up several tracks to play on this player and start them playing. Then press the Reset Counters link above to clear the statistics and update this display.

Summary
Control Connection : OK
Streaming Connection : OK
Player Signal Strength : OK
Buffer Fullness : Low
Server Response Time : OK


Warnings
The playback buffer for this player is occasionally falling lower than ideal. This is a Squeezebox2 and so the buffer fullness is expected to drop at the end of each track. You may see this warning if you are playing lots of short tracks. If you are hearing audio dropouts, please check our network signal strength.


--------------------------------------------------------------------------------

Player Performance : Squeezy
The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.

It is imporant to leave the player playing for a while and then assess the graphs.


Buffer Fullness
This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.
Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

< 10 : 783 :100% ##################################################
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 0 : 0%
< 50 : 0 : 0%
< 60 : 0 : 0%
< 70 : 0 : 0%
< 80 : 0 : 0%
< 90 : 0 : 0%
< 100 : 0 : 0%
>=100 : 0 : 0%
max : 8.554586
min : 0.000000
avg : 0.096670

Control Connection
This graph shows the number of messages queued up to send to the player over the control connection. A measurement is taken every time a new message is sent to the player. Values above 1-2 indicate potential network congestion or that the player has become disconnected.
< 1 : 14 :100% ##################################################
< 2 : 0 : 0%
< 5 : 0 : 0%
< 10 : 0 : 0%
< 20 : 0 : 0%
>=20 : 0 : 0%
max : 0.000000
min : 0.000000
avg : 0.000000


--------------------------------------------------------------------------------

Server Performance
The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time
This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.
The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

< 0.002 : 12347 : 99% #################################################
< 0.005 : 50 : 0%
< 0.01 : 7 : 0%
< 0.015 : 32 : 0%
< 0.025 : 26 : 0%
< 0.05 : 34 : 0%
< 0.1 : 1 : 0%
< 0.5 : 7 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.222441
min : -0.008578
avg : 0.000865

Timer Accuracy
Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.
Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

< 0.002 : 589 : 38% ###################
< 0.005 : 378 : 24% ############
< 0.01 : 538 : 35% #################
< 0.015 : 33 : 2% #
< 0.025 : 1 : 0%
< 0.05 : 1 : 0%
< 0.1 : 2 : 0%
< 0.5 : 4 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.138755
min : 0.000002
avg : 0.004591

Timer Task Duration
This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.
< 0.002 : 1542 :100% #################################################
< 0.005 : 3 : 0%
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 0 : 0%
< 0.05 : 1 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.026957
min : -0.008153
avg : 0.000801

[snarlydwarf]

Have you looked at your wiring?

If I read your original post right, you have:

PC --WireA -> Hub
SB --WireB -> Hub

Hub --WireC -> Router

Check WireC, since removing that fixes your packet loss.

If it's handmade and twisted wrong, you will see dropouts. (In short, ethernet needs to be 'twisted pair': each signal is carried on two wires as complements of each other, these two wires are twisted together for balance which keeps interference down. If they're not twisted together, or worse: twisted with the wrong thing, you actually get -more- interference, especially as data rates increase.)

[Phil Leigh]

Snarlydwarf - you've got my wiring exactly right. I've tried changing all the cables to no effect...
I still get teh same problem with a really simple set up (ie nothing but sb + PC + router/modem.
Are there any SS debug options that might help pinpoint the problem?

[gusi]

Originally I used
PC - router - WiFi hub -SB3
Both router and hub ran their own dhcp server and nat. I also got frequent drop outs. I then reconfigured to use a single dhcp + nat server and update the dlink firmware and it has run fine since.

If it still doesn't with the minimal fully wired setup you describe I would put a packetfilter on the NIC or better yet on the hub.

If you are handy with computers etherreal is a very powerful tool. It can check what is travelling down the wire. You should be able to see a difference between times with smooth music and hiccups.

Intermittant faults can be very hard to fix. Things to look for:

1) the rj45 flywires are very fragile. change wires make sure they are the right type. eg don't use solid core cable and bend it.

2) check for obvious electrical noise sources large magnets and motors.

3) hubs can be flaky as well check the power supply on the hub

4) try different ports on the hub

5) processes that grind the PC to the occasional standstill

6) If the router also has 4 ethernet ports try running through it instead of the hub.

I am not that familiar with the diagnostics but they all seem ok. Did you experience music drop outs while taking the diagnostics?

Gus

[Wirrunna]

Phil, Are you using a hub because all the ports on the router are taken ?
If so, as Gusi suggests, try plugging the Server(PC) and the SB direct to the router and put other devices on the hub.
If the hub is an older device, it may only be a 10Mb device and non switching, in which case all packets appear on all ports. The routers usually have 'switching' hubs built in that create virtual direct connections between two devices that prevents packets being sent to devices that haven't requested them.

[snarlydwarf]

ouch.. you see the same problem when you do:

PC->Router
SB->Router and nothing else??

You mention 'other wireless clients' in the house... so there are other machines on your network than these two?

Are you sure none of them has the 192.168.1.101 IP that your squeezebox has?

[gusi]

I just thought switching to the router as I have seen too many cheap hubs fail over the years.

If the system is swapping IP addresses you may be able to pick it up with arp -a on the command line it shows you a table of mac and ip addresses if these change you have a problem. You may also be able to turn on logging on the dhcp server to if it is switching IP addresses.

I doubt this is happening though. Dodgy hub or cables seems more likely to me. But I am not a sysadmin or network expert.

[Phil Leigh]

This is what arp says:

C:\Documents and Settings\Phil>arp -a

Interface: 192.168.1.100 --- 0x80002
Internet Address Physical Address Type
192.168.1.1 00-13-10-d6-4c-b8 dynamic
192.168.1.101 ff-ff-fc-ff-ff-ff dynamic

(my wireless clients are off at the moment)

100 is my Slimserver NIC, 1 is the router and 101 is the SB.

Would a cable problem only affect the streaming of packets to the SB?

One more thing, the problem persists if disable my internet connection on the SS PC - implying that the problem is in the router.

I'll try shutting down the router adsl link and see if that clears the problem...

Thanks for all your help so far.
Phil

[Phil Leigh]

whoa - just noticed this in the arp of the router

192.168.1.101 00:14:2A:B5:A4:0C
192.168.1.100 00:14:2A:B5:A4:0C

How come the NIC and the SB have the same mac address (which happens to be the mac address of the NIC -where's the SB mac? Could this be the problem?

[gusi]

That doesn't look right, I'd expect the mac addresses to be different. Have a look at the arp table over time. If it changes every couple of minutes there is something wrong. If it stays the same it may be ok.

From the windows box you can see your own mac address with netstat -r.

In the good old days the mac address did not change readily, it was something in the nic firmware with a device driver override. The IP address was set either from a dhcp server or traditionally configured in each box. I haven't looked too much at tcp recently perhaps another forum member is a sysadmin.

Are you using dhcp? If so where is the dhcp server? Configuring fixed IP addresses would remove one set of uncertainties. You should be able to set the dhcp server to assign from a certain range.

eg the PC, router and SB could be addresses .1 .2 and .3 Then the dhcp server could be setup to assign from .101 such that any other devices such a a laptop will slot in outside the reserved range.

I use a dhcp server in my router and it all works fine. Initially I used a dhcp server in the router and in the wifi access point and had no end of trouble.


Is the router a switch or a hub? A hub is cheaper but will send all traffic through all ports. If you use a hub, a laptop on a spare port running etherreal in promiscuous mode would tell you what is going on. Just have a look for any dhcp packets once everything is up and running.

good luck
Gus

[Phil Leigh]

Hi


To be clear, the ROUTER arp is showing the same MAC address for the SB and the NIC on the PC running SlimServer. All these connections are wired not wireless. The switch is a brand new belkin switch and is not causing the problem - I get exactly the same problem without the switch.

IS it possible for the MAC address of the SB to get overwritten inside the SB somehow?...


I am using DCHP for soem other wireless clients in the house. They are currently all off/disconnected hence not shown in my earlier posts. The DCHP server function of the router is set to start seeding IP address at 192.168.1.102, avoiding the PC that is running SlimServer and the SB itself (100 and 101 respectively).


netstat -r shows:

Route Table
================================================== =========================
Interface List
0x1 ........................... MS TCP Loopback interface
0x80002 ...00 14 2a b5 a4 0c ...... NVIDIA nForce Networking Controller
================================================== =========================
================================================== =========================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 255.255.255.255 192.168.1.1 192.168.1.100 1
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.100 20
192.168.1.100 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.1.255 255.255.255.255 192.168.1.100 192.168.1.100 20
224.0.0.0 240.0.0.0 192.168.1.100 192.168.1.100 20
255.255.255.255 255.255.255.255 192.168.1.100 192.168.1.100 1
Default Gateway: 192.168.1.1
================================================== =========================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 255.255.255.255 192.168.1.1 1

[Phil Leigh]

Guys - many thanks...after digesting your remarks the weird arp router entry suddenly leapt out at me. I changed the MAC address to the one on the SB box and all is working great. I really can't thank you enough for helping me fix this!
You rock!
Cheers
Phil