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. Mike ------------------------------------------------------------------------------ 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
