Tom Eastep wrote: > 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 >
Also in 4.4, the priority of the fw and the option-generated classifiers are adjusted in a way that is similar to the simple patch I posted. -Tom -- Tom Eastep \ The ultimate result of shielding men from the effects of Shoreline, \ folly is to fill the world with fools. Washington, USA \ -- Herbert Spencer ------------------------------------------------------------------------ http://www.shorewall.net
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
