My music server is running on the firewall (shorewall, single interface, NATed) and therefore the connections are from net (local network-10.0.0.0/24) to firewall. Slimserver is running on http port 9000 where squeezebox connects.
Since i use the connection for other things including bittorrent, i had a need to shape the traffic. The problem is even when the link is idle, the shaper seems to affect my player (constant rebuffering and music connection drops). With TC disabled, the other aspects of the firewall are great and don't affect my music.The other ports don't stream music (control ports) and adding them as priority 1 on the shaper does not help either. I have provided the relevant TCclass and TCrules: eth0 1 full full 1 tcp-ack,tos-maximize-throughput,tos-minimize-delay Tcrule 1:T 0.0.0.0/0 0.0.0.0/0 tcp 9000 My default policy from $FW to NET is ACCEPT and therefore a separate rule in the opposite direction is uneccesary. Hope this helps. --- Tom Eastep <[EMAIL PROTECTED]> wrote: > Edwin Koome wrote: > > seem to have problems with my squeezebox > rebuffering & > > stuttering when playing music. I have homed the > > problem to my firewall (shorewall) especially its > > packet shaper. > > > > When the packet shaper is disabled, but the > firewall > > running everything is fine. When i enable the > internal > > packet shaper my music starts stuttering and the > > player keeps rebuffering. > > > > I have created a TC class for the player giving it > > full bandwidth and minimizing delay but it does > not > > seem to work.Let me know what i'm missing. > > > > > > Here are my relevant rules and attached a dump of > > shorewall config: > > > > #Squeezebox > > ACCEPT net:10.0.0.0/24 $FW tcp 9000 > > ACCEPT net:10.0.0.0/24 $FW tcp 3483 > > ACCEPT net:10.0.0.0/24 $FW udp 3483 > > > > I'm lost. > > 1) The rules above are for net->fw. > 2) Traffic shaping on the 'net' interface shapes > traffic from fw->net. > > So which direction is the music going? fw->net or > net->fw. > > I can't tell from your tcrules since none of them > refer to any of the > above ports except for this one: > > 6744 1333K MARK tcp -- * * > 0.0.0.0/0 > 0.0.0.0/0 multiport dports 9000 MARK set > 0x1 > > which is going in the opposite direction from the > ACCEPT rule above. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a > sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ [EMAIL PROTECTED] > PGP Public Key \ > https://lists.shorewall.net/teastep.pgp.key > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? > Stop. > Now Search log events and configuration files using > AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/> _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users > ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
