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
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 \________________________________________________ ------------------------------------------------------------------------------ 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
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 ------------------------------------------------------------------------------ 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