Mike Lander wrote:
> 
> Think I found the trouble, I was wondering if tcrules could be interfering
> so I commented out my old qos as follows 
> This is out of the box sending 1c tos
> 
> #The next lines define class 1 for VOIP
> 3:11       10.19.227.18               10.192.139.240          ALL
> 2:11       $FW                        eth1                   udp      1194
> 4:11       10.19.227.18               10.194.244.240          ALL
> 2:11       $FW                        eth1                   udp      7799
> #5:11       10.19.227.18              10.143.99.241           ALL
> #2:11       $FW                       eth1                    udp     7788
> #
> The latter rules are for the tunnel I am experimenting with which are
> commented out now. See results below.
> 
> Here is show clasifiers on this box
> Note that the other end of the tunnel is sending 14 tos which to this 
> box is a download, does shorewall disreagard this because the packet
> is already accross the tunnel? Because neither box seems to match 
> the others tos after the packet is through the internet.
> 
> Device eth1:
> filter parent 2: protocol all pref 1 fw 
> filter parent 2: protocol all pref 1 fw handle 0x1 classid 2:11 
> filter parent 2: protocol all pref 1 fw handle 0x2 classid 2:12 
> filter parent 2: protocol all pref 1 fw handle 0x3 classid 2:13 
> filter parent 2: protocol all pref 1 fw handle 0x4 classid 2:14 
> filter parent 2: protocol ip pref 10 u32 
> filter parent 2: protocol ip pref 10 u32 fh 800: ht divisor 1 
> filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 
> bkt 0 flowid 2:11  (rule hit 470 success 0)
>   match 00140000/00fc0000 at 0 (success 0 ) 
> filter parent 2: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 
> bkt 0 flowid 2:11  (rule hit 470 success 42)
>   match 001c0000/00fc0000 at 0 (success 42 ) 
> filter parent 2: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 
> bkt 0 flowid 2:12  (rule hit 428 success 0)
>   match 00060000/00ff0000 at 8 (success 0 ) 
>   match 05000000/0f00ffc0 at 0 (success 0 ) 
>   match 00100000/00ff0000 at 32 (success 0 ) 
> filter parent 2: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 
> bkt 0 flowid 2:12  (rule hit 428 success 0)
>   match 00100000/00100000 at 0 (success 0 ) 
> 
> Device tun2:
> filter parent 5: protocol all pref 1 fw 
> filter parent 5: protocol all pref 1 fw handle 0x1 classid 5:11 
> filter parent 5: protocol all pref 1 fw handle 0x2 classid 5:12 
> filter parent 5: protocol all pref 1 fw handle 0x3 classid 5:13 
> filter parent 5: protocol all pref 1 fw handle 0x4 classid 5:14 
> filter parent 5: protocol ip pref 10 u32 
> filter parent 5: protocol ip pref 10 u32 fh 800: ht divisor 1 
> filter parent 5: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 
> bkt 0 flowid 5:11  (rule hit 13 success 0)
>   match 00140000/00fc0000 at 0 (success 0 ) 
> filter parent 5: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 
> bkt 0 flowid 5:11  (rule hit 13 success 13)
>   match 001c0000/00fc0000 at 0 (success 13 ) 
> filter parent 5: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 
> bkt 0 flowid 5:12  (rule hit 0 success 0)
>   match 00060000/00ff0000 at 8 (success 0 ) 
>   match 05000000/0f00ffc0 at 0 (success 0 ) 
>   match 00100000/00ff0000 at 32 (success 0 ) 
> filter parent 5: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 
> bkt 0 flowid 5:12  (rule hit 0 success 0)
>   match 00100000/00100000 at 0 (success 0 ) 
> 
> 
> Will this work to priotize these voip packets? 
> With the old way I was using the remote desktop users over these tunnels went 
> into class <device>:11 class one
> Not sure why tc rules was doing this since the tos bit was preserved all the 
> way to the lan interface.

Look at the classifiers -- the fw (mark) classifiers have priority 1
while the TOS classifiers have priority 10. That's backwards from the
way that it should ideally be.

I added a TOS column to /etc/shorewall/tcfilters so that the
classification by TOS can be moved ahead of the mark classifiers.

In the meantime, see if the attached patch corrects your problem.

  patch /usr/share/shorewall-perl/Shorewall/Tc.pm < tcpriority.diff

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________
diff --git a/4.2/Shorewall-perl/Shorewall/Tc.pm b/4.2/Shorewall-perl/Shorewall/Tc.pm
index 0814cda..230b01b 100644
--- a/4.2/Shorewall-perl/Shorewall/Tc.pm
+++ b/4.2/Shorewall-perl/Shorewall/Tc.pm
@@ -860,7 +860,7 @@ sub setup_traffic_shaping() {
 	#
 	# add filters
 	#
-	emit "run_tc filter add dev $device protocol all parent $devicenumber:0 prio 1 handle $mark fw classid $classid" unless $devref->{classify};
+	emit "run_tc filter add dev $device protocol all parent $devicenumber:0 prio 20 handle $mark fw classid $classid" unless $devref->{classify};
 	emit "run_tc filter add dev $device protocol all pref 1 parent $classnum: handle 1 flow hash keys $tcref->{flow} divisor 1024" if $tcref->{flow};
 	#
 	#options

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to