I am trying to reshape my traffic shaping and am getting nowhere fast! Here is what happens during shorewall compile: 1. eth0 - 1mbit classify,hfsc ifb0 - 1mbit - eth0 (the above 2 lines are from tcdevices) ifb0:21 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) ERROR: Invalid RATE (10*full/100:50ms) : /etc/shorewall/tcclasses 2. eth0 - 1mbit classify,hfsc (tcdevices) eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclases) ERROR: Duplicate interface:class number (1:1} : /etc/shorewall/tcclasses 3. 123:eth0 - 1mbit classify,hfsc (tcdevices) 123:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) ERROR: Duplicate interface:class number (291:1} : /etc/shorewall/tcclasses 4. A:eth0 - 1mbit classify,hfsc (tcdevices) A:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) ERROR: Unknown INTERFACE (A) : /etc/shorewall/tcclasses Am I missing something because I cannot find any "duplicate interface:class number" anywhere? Also, in the latest version (.19.1) with "man shorewall.conf" - USE_ACTIONS is not explained anywhere, but is referred to in various places (I presume USE_ACTIONS has been deprecated, but the documentation has not been updated). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> I am trying to reshape my traffic shaping and am getting nowhere fast! > Here is what happens during shorewall compile: > > 1. > eth0 - 1mbit classify,hfsc > ifb0 - 1mbit - eth0 (the above 2 lines are from tcdevices) > ifb0:21 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) > ERROR: Invalid RATE (10*full/100:50ms) : /etc/shorewall/tcclasses > > 2. > eth0 - 1mbit classify,hfsc (tcdevices) > eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclases) > ERROR: Duplicate interface:class number (1:1} : /etc/shorewall/tcclasses > > 3. > 123:eth0 - 1mbit classify,hfsc (tcdevices) > 123:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) > ERROR: Duplicate interface:class number (291:1} : > /etc/shorewall/tcclasses > > 4. > A:eth0 - 1mbit classify,hfsc (tcdevices) > A:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) > ERROR: Unknown INTERFACE (A) : /etc/shorewall/tcclasses > > > Am I missing something because I cannot find any "duplicate > interface:class number" anywhere? > > Also, in the latest version (.19.1) with "man shorewall.conf" - > USE_ACTIONS is not explained anywhere, but is referred to in various > places (I presume USE_ACTIONS has been deprecated, but the > documentation has not been updated).One other thing I forgot: the whole section of "man shorewall-tcrules" where it describes the use of the ":{C[F|P|T|I]} flags is part of item 1 (where the mark value help is), but it should be at the very end of that section (as item 9 perhaps) as I could have "major:minor:T" for example (which has nothing to do with the mark value as described in item 1). That is, of course, if my understanding of the syntax of that field is correct. That syntax, by the way, is also shown wrong - the "MARK/CLASSIFY" syntax should be ending with "[:{C[F|P|T|I]}]" and not, as indicated in that man page, with "[:{C|F|P|T|CF|CP|CT|I:CI}]" - just thought to mention that. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On Apr 30, 2011, at 3:44 PM, Mr Dash Four wrote:> >> I am trying to reshape my traffic shaping and am getting nowhere fast! >> Here is what happens during shorewall compile: >> >> 1. >> eth0 - 1mbit classify,hfsc >> ifb0 - 1mbit - eth0 (the above 2 lines are from tcdevices) >> ifb0:21 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >> ERROR: Invalid RATE (10*full/100:50ms) : /etc/shorewall/tcclassesYou didn''t specify hfsc on ifb0; therefore, HTB does not accept the syntax you have used for the guaranteed rate.>> >> 2. >> eth0 - 1mbit classify,hfsc (tcdevices) >> eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclases) >> ERROR: Duplicate interface:class number (1:1} : /etc/shorewall/tcclasses >> >> 3. >> 123:eth0 - 1mbit classify,hfsc (tcdevices) >> 123:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >> ERROR: Duplicate interface:class number (291:1} : >> /etc/shorewall/tcclassesI should make it more clear that ''1'' is a poor choice of class number, given that ''1'' is the class number assigned to the root class of each interface.>> >> 4. >> A:eth0 - 1mbit classify,hfsc (tcdevices)That syntax is completely wacky. What piece of the documentation led you to that one?>> A:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >> ERROR: Unknown INTERFACE (A) : /etc/shorewall/tcclasses >> >> >> Am I missing something because I cannot find any "duplicate >> interface:class number" anywhere?See above.>> >> Also, in the latest version (.19.1) with "man shorewall.conf" - >> USE_ACTIONS is not explained anywhere, but is referred to in various >> places (I presume USE_ACTIONS has been deprecated, but the >> documentation has not been updated). > One other thing I forgot: the whole section of "man shorewall-tcrules" > where it describes the use of the ":{C[F|P|T|I]} flags is part of item 1 > (where the mark value help is), but it should be at the very end of that > section (as item 9 perhaps) as I could have "major:minor:T" for example > (which has nothing to do with the mark value as described in item 1). > > That is, of course, if my understanding of the syntax of that field is > correct. That syntax, by the way, is also shown wrong - the > "MARK/CLASSIFY" syntax should be ending with "[:{C[F|P|T|I]}]" and not, > as indicated in that man page, with "[:{C|F|P|T|CF|CP|CT|I:CI}]" - just > thought to mention that. >Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> You didn''t specify hfsc on ifb0; therefore, HTB does not accept the syntax you have used for the guaranteed rate. >Yeah, I figured it out at the end, I assumed that because the ifb inherits the classify option it also inherits any other options from the redirected interface, which was wrong obviously.>>> 2. >>> eth0 - 1mbit classify,hfsc (tcdevices) >>> eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclases) >>> ERROR: Duplicate interface:class number (1:1} : /etc/shorewall/tcclasses >>> >>> 3. >>> 123:eth0 - 1mbit classify,hfsc (tcdevices) >>> 123:1 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >>> ERROR: Duplicate interface:class number (291:1} : >>> /etc/shorewall/tcclasses >>> > > I should make it more clear that ''1'' is a poor choice of class number, given that ''1'' is the class number assigned to the root class of each interface. >This actually helped me discover what I think is a bug (see below).>>> 4. >>> A:eth0 - 1mbit classify,hfsc (tcdevices) >>> > > That syntax is completely wacky. What piece of the documentation led you to that one? >"man shorewall-tcdevices" states that I could use hex numbers (A is a hex = 10 decimal, right?). So, strictly speaking, it should be able to accept that value. It gives an error instead. Anyway, it looks as though I cannot force traffic-shaping on incoming traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND use user id - it seems impossible. The documentation on tcrules is, well lets just say, there is a lot to be desired from it (where and in what circumstances am I allowed to use "I" and "CI" for example?) - I started by using classes, but gave up soon after as they work only on the postrouting chain, which is not what I am after as I don''t seem to be able to control incoming traffic at all. I then tried simple marking, but then I seem to be unable to specify the "I" flag anywhere in my tcrules to force it to shape the incoming traffic, so there... Finally there is, what I think a bug, in the latest shorewall version: eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack eth0:2 - 80*full/100 full 2 eth0:2:21 - 20*full/100 full 3 eth0:2:22 - 20*full/100 full 4 eth0:2:23 - 20*full/100 full 5 eth0:2:24 - 20*full/100 full 6 eth0:2:25 - 20*full/100 full 7 eth0:3 - 10*full/100 full 8 default shorewall compile passes, but service shorewall (re)start ultimately fails with: shorewall[1493]: RTNETLINK answers: File exists shorewall[1493]: ERROR: Command "tc class add dev eth0 parent 1:1 classid 1:1 hfsc sc umax 1500b dmax 50ms rate 10000kbit ul rate 20000kbit" Failed The culprit seems to be the use of "1" (when replaced with "12" for example all seems OK) - this should have been caught during the shorewall compilation. One other thing which I found in man shorewall-tcrules: in the classid section it states that "the major class is the device number (the first device in shorewall-tcdevices[3](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class''s MARK value in shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.)." So, following that if I have a device with major 1, then a class defined in tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as "1:121" in this case). That does not work and it gives me "Unknown Class" error. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On Apr 30, 2011, at 8:56 PM, Mr Dash Four wrote:> >>>> 4. >>>> A:eth0 - 1mbit classify,hfsc (tcdevices) >>>> >> >> That syntax is completely wacky. What piece of the documentation led you to that one? >> > "man shorewall-tcdevices" states that I could use hex numbers (A is a hex = 10 decimal, right?). So, strictly speaking, it should be able to accept that value. It gives an error instead.The error is being presented on the tcclasses record, not the tcdevices record. So it is in the processing of that record that the error is being generated. I''m still mulling over how to fix that, but I''m leaning toward requiring the hex value to be preceded by ''0x'', when the value doesn''t start with a digit.> > Anyway, it looks as though I cannot force traffic-shaping on incoming traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND use user id - it seems impossible.That''s correct. There is *no* netfilter hook between the time that a packet enters the box and when it gets redirected to an IFB. That is the entire reason that /etc/shorewall/tcfilters was originally invented. At http://www.shorewall.net/traffic_shaping.htm#IFB, it clearly states that: "Entries in /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules."> > The documentation on tcrules is, well lets just say, there is a lot to be desired from it (where and in what circumstances am I allowed to use "I" and "CI" for example?):I and :CI are included for completeness (the tcrules file is the only way to mark packets using Shorewall and packet marks are the "Swiss Army Knife" of Netfilter). Neither affect either policy routing or traffic shaping and I''ve made that clear in the online copies of the tcrules man pages.> - I started by using classes, but gave up soon after as they work only on the postrouting chain,Completely not true. But then, it you are trying to shape incoming traffic with tcrules, I can understand your confusion.> which is not what I am after as I don''t seem to be able to control incoming traffic at all. I then tried simple marking, but then I seem to be unable to specify the "I" flag anywhere in my tcrules to force it to shape the incoming traffic, so there...See above.> > Finally there is, what I think a bug, in the latest shorewall version: > > eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack > eth0:2 - 80*full/100 full 2 > eth0:2:21 - 20*full/100 full 3 > eth0:2:22 - 20*full/100 full 4 > eth0:2:23 - 20*full/100 full 5 > eth0:2:24 - 20*full/100 full 6 > eth0:2:25 - 20*full/100 full 7 > eth0:3 - 10*full/100 full 8 default > > shorewall compile passes, but service shorewall (re)start ultimately fails with: > > The culprit seems to be the use of "1" (when replaced with "12" for example all seems OK) - this should have been caught during the shorewall compilation.Yes, it is the use of ''1''; in that case, the compiler is not catching that duplication but the kernel is.> > One other thing which I found in man shorewall-tcrules: in the classid section it states that "the major class is the device number (the first device in shorewall-tcdevices[3](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class''s MARK value in shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.)." > > So, following that if I have a device with major 1, then a class defined in tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as "1:121" in this case). That does not work and it gives me "Unknown Class" error.That only applies if you let Shorewall pick the class numbers; you are specifying them explicitly in tcclasses. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 1, 2011, at 5:43 AM, Tom Eastep wrote:> > The error is being presented on the tcclasses record, not the tcdevices record. So it is in the processing of that record that the error is being generated. I''m still mulling over how to fix that, but I''m leaning toward requiring the hex value to be preceded by ''0x'', when the value doesn''t start with a digit...>> >> Finally there is, what I think a bug, in the latest shorewall version: >> >> eth0:1 - 10*full/100:50ms 20*full/100 1 tcp-ack >> eth0:2 - 80*full/100 full 2 >> eth0:2:21 - 20*full/100 full 3 >> eth0:2:22 - 20*full/100 full 4 >> eth0:2:23 - 20*full/100 full 5 >> eth0:2:24 - 20*full/100 full 6 >> eth0:2:25 - 20*full/100 full 7 >> eth0:3 - 10*full/100 full 8 default >> >> shorewall compile passes, but service shorewall (re)start ultimately fails with: >> >> The culprit seems to be the use of "1" (when replaced with "12" for example all seems OK) - this should have been caught during the shorewall compilation. > > Yes, it is the use of ''1''; in that case, the compiler is not catching that duplication but the kernel is. >The attached patch corrects both issues. As I mentioned above, a 0x prefix is required if the device number is not numeric. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> Anyway, it looks as though I cannot force traffic-shaping on incoming traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND use user id - it seems impossible. >> > > That''s correct. There is *no* netfilter hook between the time that a packet enters the box and when it gets redirected to an IFB. That is the entire reason that /etc/shorewall/tcfilters was originally invented. At http://www.shorewall.net/traffic_shaping.htm#IFB, it clearly states that: "Entries in /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules." >So, in other words there is no way on gods green Earth that I could shape incoming traffic by utilising ipsets and/or by using the tcrules file? If that is correct, then my only choice seems to be tcfilters and there I cannot use ipsets (yeah, catch22 that!).>> The documentation on tcrules is, well lets just say, there is a lot to be desired from it (where and in what circumstances am I allowed to use "I" and "CI" for example?) >> > > :I and :CI are included for completeness (the tcrules file is the only way to mark packets using Shorewall and packet marks are the "Swiss Army Knife" of Netfilter). Neither affect either policy routing or traffic shaping and I''ve made that clear in the online copies of the tcrules man pages. >OK, could you show me a simple example when I can mark traffic in the INPUT chain (presumably by using the "I" or "CI" flags) and include it in tc classes for traffic shaping? Is that possible? Say incoming traffic destined to "+web-ports" ipset (web-ports ipset containing 80, 8080-8082, 443 and 8443 as its values). i.e. traffic *->$FW:+wep-ports, and shape that traffic from 1mbit to full.>> - I started by using classes, but gave up soon after as they work only on the postrouting chain, >> > > Completely not true. But then, it you are trying to shape incoming traffic with tcrules, I can understand your confusion. >Well, that is what the man pages state (quoting the major:minor classification): "Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT chain." So, by that I can only conclude that if I wish to use classes hierarchy (major:minor etc) the only choice open for me is POSTROUTING or OUTPUT, which is more or less what I wrote above (in other words flags "P", "F" and "I" are completely useless for this classification). Following on from this, I see no sense whatsoever in applying that classification to ifb-type devices as there is NEVER going to be a match when these are included in the tcrules file as, to my understanding, ifb operates on the incoming/input chains and traffic. If that is indeed the case, why are ifb-type devices allowed to be used in the tcrules file at all - what possible purpose would that serve (genuine question as I cannot figure out what sort of match could there be if ifb devices are used in tcrules)? If that is also correct, then I also do not see much sense in using the "P", "F" and "I" flags with this kind of devices either (does shorewall gives an error if either of these are used - haven''t tested that yet?).>> One other thing which I found in man shorewall-tcrules: in the classid section it states that "the major class is the device number (the first device in shorewall-tcdevices[3](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class''s MARK value in shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.)." >> >> So, following that if I have a device with major 1, then a class defined in tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as "1:121" in this case). That does not work and it gives me "Unknown Class" error. >> > > That only applies if you let Shorewall pick the class numbers; you are specifying them explicitly in tcclasses. >Then perhaps the man page should be amended to make that clearer as this is a bit misleading. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The attached patch corrects both issues. As I mentioned above, a 0x prefix is required if the device number is not numeric. >That''s a good idea - I''ll test this later today and let you know whether it works or not. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 1, 2011, at 7:26 AM, Mr Dash Four wrote:> >>> Anyway, it looks as though I cannot force traffic-shaping on incoming traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND use user id - it seems impossible. >>> >> >> That''s correct. There is *no* netfilter hook between the time that a packet enters the box and when it gets redirected to an IFB. That is the entire reason that /etc/shorewall/tcfilters was originally invented. At http://www.shorewall.net/traffic_shaping.htm#IFB, it clearly states that: "Entries in /etc/shorewall/tcrules have no effect on shaping traffic through an IFB. To allow classification of such traffic, the /etc/shorewall/tcfilters file has been added. Entries in that file create u32 classification rules." >> > So, in other words there is no way on gods green Earth that I could shape incoming traffic by utilising ipsets and/or by using the tcrules file? If that is correct, then my only choice seems to be tcfilters and there I cannot use ipsets (yeah, catch22 that!).There is no way to shape incoming traffic using an IFB and ipsets. If this is a router, you can shape traffic exiting the router on the local interface using ipsets.> >>> The documentation on tcrules is, well lets just say, there is a lot to be desired from it (where and in what circumstances am I allowed to use "I" and "CI" for example?) >>> >> >> :I and :CI are included for completeness (the tcrules file is the only way to mark packets using Shorewall and packet marks are the "Swiss Army Knife" of Netfilter). Neither affect either policy routing or traffic shaping and I''ve made that clear in the online copies of the tcrules man pages. >> > OK, could you show me a simple example when I can mark traffic in the INPUT chain (presumably by using the "I" or "CI" flags) and include it in tc classes for traffic shaping? Is that possible? Say incoming traffic destined to "+web-ports" ipset (web-ports ipset containing 80, 8080-8082, 443 and 8443 as its values). i.e. traffic *->$FW:+wep-ports, and shape that traffic from 1mbit to full.There is no way. A Shorewall user requested the ability to mark packets in the INPUT chain (I''ve forgotten the rationale but it was legitimate) and I added it a while back.> >>> - I started by using classes, but gave up soon after as they work only on the postrouting chain, >>> >> >> Completely not true. But then, it you are trying to shape incoming traffic with tcrules, I can understand your confusion. >> > Well, that is what the man pages state (quoting the major:minor classification): "Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT chain." > > So, by that I can only conclude that if I wish to use classes hierarchy (major:minor etc) the only choice open for me is POSTROUTING or OUTPUT, which is more or less what I wrote above (in other words flags "P", "F" and "I" are completely useless for this classification).That''s correct if you use CLASSIFIERS (dev:class) in the MARK column. But if you use packet marks, you can mark in FORWARDING.> > Following on from this, I see no sense whatsoever in applying that classification to ifb-type devices as there is NEVER going to be a match when these are included in the tcrules file as, to my understanding, ifb operates on the incoming/input chains and traffic. > > If that is indeed the case, why are ifb-type devices allowed to be used in the tcrules file at all - what possible purpose would that serve (genuine question as I cannot figure out what sort of match could there be if ifb devices are used in tcrules)?I''ll be happy to add an error message if an IFB is mentioned in the tcrules file.> >>> One other thing which I found in man shorewall-tcrules: in the classid section it states that "the major class is the device number (the first device in shorewall-tcdevices[3](5) is major class 1, the second device is major class 2, and so on) and the minor class is the class''s MARK value in shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.)." >>> >>> So, following that if I have a device with major 1, then a class defined in tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as "1:121" in this case). That does not work and it gives me "Unknown Class" error. >>> >> >> That only applies if you let Shorewall pick the class numbers; you are specifying them explicitly in tcclasses. >> > Then perhaps the man page should be amended to make that clearer as this is a bit misleading.Sure. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> There is no way to shape incoming traffic using an IFB and ipsets. If this is a router, you can shape traffic exiting the router on the local interface using ipsets. >Right, that settles it then! I, however, may have another, less-glamorous (a plan B if you like) solution: the current generation of ipset (6, not sure about 5 and 4) gives me the ability to list members of a particular set in a specific format (xml, txt etc), so if I "construct" my tcfilters file at startup (via a script, which is executed in shorewall''s "init" - I take it at that point nothing has been compiled yet, right?) then I may use a template and replace the values shown there with the actual values of the ipset members. Say, I have a line in my template file like this "1:11 - - tcp - +{web-ports}", then my script could turn this into "1:11 - - tcp - 80,443,8080-8082,8443" (i.e. substitutes the members of the specified set - web-ports using my previous example - with their actual values) and then pass this resulting file to shorewall, would that work?> There is no way. A Shorewall user requested the ability to mark packets in the INPUT chain (I''ve forgotten the rationale but it was legitimate) and I added it a while back. >So, I *could* mark in the INPUT chain with tcrules, but I can''t use that for traffic shaping or use ipsets, is that right? If not, could you give me a simple example (a 1-liner perhaps) where this INPUT chain marking is used?>> Following on from this, I see no sense whatsoever in applying that classification to ifb-type devices as there is NEVER going to be a match when these are included in the tcrules file as, to my understanding, ifb operates on the incoming/input chains and traffic. >> >> If that is indeed the case, why are ifb-type devices allowed to be used in the tcrules file at all - what possible purpose would that serve (genuine question as I cannot figure out what sort of match could there be if ifb devices are used in tcrules)? >> > > I''ll be happy to add an error message if an IFB is mentioned in the tcrules file. >That makes sense as I can''t really see any case when there would possibly be a match (and I spent about 4-5 hours yesterday rimming "fantasy" scenarios in that file, using ifb-type devices and shorewall was silently swallowing it all - and laughing back in my face). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The attached patch corrects both issues. As I mentioned above, a 0x prefix is required if the device number is not numeric. >That, for me, partially works: tcdevices: 1. 0A:eth0 is silently accepted (it gives an error only when it is used) 2. 0xA:eth0 - ERROR: Invalid interface NUMBER (0xA) 3. A:eth0 is silently accepted (the only way this interface could be used is by referring to it by "eth0", otherwise it triggers an error) I was unable to test the second part of this patch fully (it works when the interface is referred to by its "native" name, i.e. "eth0:1" triggers an error as expected, but I''d like to test this with the aliases above to make sure). 4. tcdevices: A:eth0 - 100mbit classify,hfsc [...] tcclasses: eth0:11 - 10*full/100:50ms 20*full/100 1 tcp-ack [...] Passes compilation, but triggers the following error: shorewall[1566]: RTNETLINK answers: Invalid argument shorewall[1566]: We have an error talking to the kernel shorewall[1566]: ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" Failed Finally, I found what I think is ipsets syntax bug in shorewall. This is what I tested in the rules file: 1. "ACCEPT:info $FW net:!+[my-host[src]],+ssh-host[dst] tcp" produces this: Chain fw2net (1 references) pkts bytes target prot opt in out source destination 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 Chain ~excl0 (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set my-host src 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set ssh-host dst 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:fw2net:ACCEPT:'' 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 If we are to accept that the above is correct, meaning "!" has an effect on the whole line after the "!" sign I then have two more tests: 2. "ACCEPT:info $FW net:!+my-host[src],!+ssh-host[dst] tcp" produces "ERROR: Invalid DEST network list (!+my-host[src],!+ssh-host[dst])" - fair enough - it does not accept double negatives, though I think it should. 3. But then "ACCEPT:info $FW net:!10.1.0.7,10.1.0.9,+[!my-host[src]],+[!ssh-host[dst]] tcp" produces this: Chain fw2net (1 references) pkts bytes target prot opt in out source destination 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set my-host src 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set ssh-host dst Chain ~excl0 (2 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0/0 10.1.0.7 0 0 RETURN all -- * * 0.0.0.0/0 10.1.0.9 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:fw2net:ACCEPT:'' 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Which it shouldn''t if we are to assume that 1 above is right! So either 1, 2 or 3 above are wrong. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 1, 2011, at 10:47 AM, Mr Dash Four wrote:> >> There is no way to shape incoming traffic using an IFB and ipsets. If this is a router, you can shape traffic exiting the router on the local interface using ipsets. >> > Right, that settles it then! > > I, however, may have another, less-glamorous (a plan B if you like) solution: the current generation of ipset (6, not sure about 5 and 4) gives me the ability to list members of a particular set in a specific format (xml, txt etc), so if I "construct" my tcfilters file at startup (via a script, which is executed in shorewall''s "init" - I take it at that point nothing has been compiled yet, right?) then I may use a template and replace the values shown there with the actual values of the ipset members.The ''init'' script is executed by the compiled script. You want something that runs during compilation. The ''compile'' script is a good candidate for rewriting your tcfilters file the way you want it.>> > So, I *could* mark in the INPUT chain with tcrules, but I can''t use that for traffic shaping or use ipsets, is that right?That is correct.>> >> I''ll be happy to add an error message if an IFB is mentioned in the tcrules file. >> > That makes sense as I can''t really see any case when there would possibly be a match (and I spent about 4-5 hours yesterday rimming "fantasy" scenarios in that file, using ifb-type devices and shorewall was silently swallowing it all - and laughing back in my face).I will attach a patch to my response to your other post. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 1, 2011, at 4:24 PM, Mr Dash Four wrote:> >> The attached patch corrects both issues. As I mentioned above, a 0x prefix is required if the device number is not numeric. >> > That, for me, partially works: > > tcdevices: > 1. 0A:eth0 is silently accepted (it gives an error only when it is used) > 2. 0xA:eth0 - ERROR: Invalid interface NUMBER (0xA) > 3. A:eth0 is silently accepted (the only way this interface could be used is by referring to it by "eth0", otherwise it triggers an error)Given that there is no ambiguity in the tcdevices file, the last form is all that the patch supports. The patch attached to this post allows the second form. Supporting the first form requires a patch that is too extensive to include in a patch release.> > I was unable to test the second part of this patch fully (it works when the interface is referred to by its "native" name, i.e. "eth0:1" triggers an error as expected, but I''d like to test this with the aliases above to make sure). > > 4. > tcdevices: > A:eth0 - 100mbit classify,hfsc > [...] > > tcclasses: > eth0:11 - 10*full/100:50ms 20*full/100 1 tcp-ack > [...] > > Passes compilation, but triggers the following error: > > shorewall[1566]: RTNETLINK answers: Invalid argument > shorewall[1566]: We have an error talking to the kernel > shorewall[1566]: ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" FailedThe second attached patch should fix this one.> > > Finally, I found what I think is ipsets syntax bug in shorewall. This is what I tested in the rules file: > > 1. "ACCEPT:info $FW net:!+[my-host[src]],+ssh-host[dst] tcp" produces this: > > Chain fw2net (1 references) > pkts bytes target prot opt in out source destination > 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 > Chain ~excl0 (1 references) > pkts bytes target prot opt in out source destination > 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set my-host src > 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set ssh-host dst > 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:fw2net:ACCEPT:'' > 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 > If we are to accept that the above is correct, meaning "!" has an effect on the whole line after the "!" sign I then have two more tests:That is the way that Shorewall exclusion lists have always worked. So we can''t change that without breaking people''s existing configurations.> > 2. "ACCEPT:info $FW net:!+my-host[src],!+ssh-host[dst] tcp" produces > "ERROR: Invalid DEST network list (!+my-host[src],!+ssh-host[dst])" - fair enough - it does not accept double negatives, though I think it should.Again, this is the way that Shorewall exclusion lists have always worked. '',!'' is never accepted.> > 3. But then "ACCEPT:info $FW net:!10.1.0.7,10.1.0.9,+[!my-host[src]],+[!ssh-host[dst]] tcp" produces this: > > Chain fw2net (1 references) > pkts bytes target prot opt in out source destination > 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set my-host src > 0 0 ~excl0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set ssh-host dst > > Chain ~excl0 (2 references) > pkts bytes target prot opt in out source destination > 0 0 RETURN all -- * * 0.0.0.0/0 10.1.0.7 > 0 0 RETURN all -- * * 0.0.0.0/0 10.1.0.9 > 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:fw2net:ACCEPT:'' > 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 > Which it shouldn''t if we are to assume that 1 above is right! >The +[...] construct is hiding the double negative from the top-level list validator. I''ll work on a patch that rejects such a rule. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> tcdevices: >> 1. 0A:eth0 is silently accepted (it gives an error only when it is used) >> 2. 0xA:eth0 - ERROR: Invalid interface NUMBER (0xA) >> 3. A:eth0 is silently accepted (the only way this interface could be used is by referring to it by "eth0", otherwise it triggers an error) >> > > Given that there is no ambiguity in the tcdevices file, the last form is all that the patch supports. The patch attached to this post allows the second form. Supporting the first form requires a patch that is too extensive to include in a patch release. >You''ve lost me here! I have intentionally tried all 3 of the above as part of the testing I did with your previous patch - I did *not* expect all of them to be accepted, quite the contrary, I expected 1 and 3 to fail (with an appropriate error message) and 2 to be accepted, which isn''t what happened here, hence why I reported it. Again, I accept the new syntax to include "0x" if hex numbers are to be specified, which is fair enough as the same syntax is adopted by C, so I do not wish that format to be changed!> The second attached patch should fix this one. >I can only see one patch attached to your response - TC1.patch>> Finally, I found what I think is ipsets syntax bug in shorewall. This is what I tested in the rules file: >> >> 1. "ACCEPT:info $FW net:!+[my-host[src]],+ssh-host[dst] tcp" produces this: >> >> [...] >> If we are to accept that the above is correct, meaning "!" has an effect on the whole line after the "!" sign I then have two more tests: >> > > That is the way that Shorewall exclusion lists have always worked. So we can''t change that without breaking people''s existing configurations. >I have no qualms with that approach (in fact, I like it). In cases 1, 2 and 3 I stated the logic behind, what I think, the bug in case 3 is, which, in my view, should be corrected. Again, I expected 1 to be accepted (which it was), 2 to "may be" accepted (though using double-negatives aren''t everyone''s cup of tea - I get that) and I did expect 3 to fail with the appropriate error message, which wasn''t the case hence why I reported it.> The +[...] construct is hiding the double negative from the top-level list validator. I''ll work on a patch that rejects such a rule. >Yep, that was the intention of this particular syntax testing - to see whether shorewall would pick it up, which it hasn''t, hence why I raised that issue. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The ''init'' script is executed by the compiled script. You want something that runs during compilation. The ''compile'' script is a good candidate for rewriting your tcfilters file the way you want it. >Does this script currently exist (if so I wasn''t aware of that)?> I will attach a patch to my response to your other post. >I''ve got just a single patch in that response - TC1.patch ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 9:03 AM, Mr Dash Four wrote:> >> The ''init'' script is executed by the compiled script. You want something that runs during compilation. The ''compile'' script is a good candidate for rewriting your tcfilters file the way you want it. >> > Does this script currently exist (if so I wasn''t aware of that)? > >> I will attach a patch to my response to your other post. >> > I''ve got just a single patch in that response - TC1.patch >Sorry about that, -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 9:00 AM, Mr Dash Four wrote:> >>> tcdevices: >>> 1. 0A:eth0 is silently accepted (it gives an error only when it is used) >>> 2. 0xA:eth0 - ERROR: Invalid interface NUMBER (0xA) >>> 3. A:eth0 is silently accepted (the only way this interface could be used is by referring to it by "eth0", otherwise it triggers an error) >>> >> >> Given that there is no ambiguity in the tcdevices file, the last form is all that the patch supports. The patch attached to this post allows the second form. Supporting the first form requires a patch that is too extensive to include in a patch release. >> > You''ve lost me here! > > I have intentionally tried all 3 of the above as part of the testing I did with your previous patch - I did *not* expect all of them to be accepted, quite the contrary, I expected 1 and 3 to fail (with an appropriate error message) and 2 to be accepted, which isn''t what happened here, hence why I reported it. > > Again, I accept the new syntax to include "0x" if hex numbers are to be specified, which is fair enough as the same syntax is adopted by C, so I do not wish that format to be changed!But C''s default input radix is 10. In tcdevices and tcrules file, the default input radix is 16. So the ''0x'' is only required in those cases where there is an ambiguity in the syntax; e.g., when a00 can be interpreted as a hex number or as an interface name. I can''t now suddenly require all numbers in those files to be prefaced by 0x.> >> The second attached patch should fix this one. >> > I can only see one patch attached to your response - TC1.patch > >>> Finally, I found what I think is ipsets syntax bug in shorewall. This is what I tested in the rules file: >>> >>> 1. "ACCEPT:info $FW net:!+[my-host[src]],+ssh-host[dst] tcp" produces this: >>> >>> [...] >>> If we are to accept that the above is correct, meaning "!" has an effect on the whole line after the "!" sign I then have two more tests: >>> >> >> That is the way that Shorewall exclusion lists have always worked. So we can''t change that without breaking people''s existing configurations. >> > I have no qualms with that approach (in fact, I like it). In cases 1, 2 and 3 I stated the logic behind, what I think, the bug in case 3 is, which, in my view, should be corrected. > > Again, I expected 1 to be accepted (which it was), 2 to "may be" accepted (though using double-negatives aren''t everyone''s cup of tea - I get that) and I did expect 3 to fail with the appropriate error message, which wasn''t the case hence why I reported it. > >> The +[...] construct is hiding the double negative from the top-level list validator. I''ll work on a patch that rejects such a rule. >> > Yep, that was the intention of this particular syntax testing - to see whether shorewall would pick it up, which it hasn''t, hence why I raised that issue.Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 9:22 AM, Tom Eastep wrote:> > On May 2, 2011, at 9:03 AM, Mr Dash Four wrote: > >> >>> The ''init'' script is executed by the compiled script. You want something that runs during compilation. The ''compile'' script is a good candidate for rewriting your tcfilters file the way you want it. >>> >> Does this script currently exist (if so I wasn''t aware of that)? >> >>> I will attach a patch to my response to your other post. >>> >> I''ve got just a single patch in that response - TC1.patch >> > > Sorry about that, > > -Tom > > <TC2.patch>Hmmm -- that patch has a problem. It should say ''in_hexp'' rather than ''in_hex''. -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 \________________________________________________ > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersTom 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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> But C''s default input radix is 10. In tcdevices and tcrules file, the default input radix is 16. So the ''0x'' is only required in those cases where there is an ambiguity in the syntax; e.g., when a00 can be interpreted as a hex number or as an interface name.Not if it is followed by a colon (:) it isn''t. Anyway, whatever you decide what the final format should be, it needs to be the same regardless of which file it appears in. In other words, is it "A", "0A" (00000A too?) or "0xA" (or any of these?)? I need clarity.> I can''t now suddenly require all numbers in those files to be prefaced by 0x. >It was your idea to put the "0x" in front of these numbers, not mine, so, stop complaining! Whatever you decide the format should be let me know so that I could test it. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Hmmm -- that patch has a problem. It should say ''in_hexp'' rather than ''in_hex''. >I''ve corrected it. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>>> 1. >>> eth0 - 1mbit classify,hfsc >>> ifb0 - 1mbit - eth0 (the above 2 lines are from tcdevices) >>> ifb0:21 - 10*full/100:50ms 20*full/100 1 tcp-ack (tcclasses) >>> ERROR: Invalid RATE (10*full/100:50ms) : /etc/shorewall/tcclasses >>> > > You didn''t specify hfsc on ifb0; therefore, HTB does not accept the syntax you have used for the guaranteed rate. >Adding the "hfsc" option to *any* ifbX device completely screws up the network! Even with no tcrules, tcfilters or tcclasses defined not a single packet can get out (or in). Typing "route" hangs (trying to do dns resolution, unsuccessfully, obviously) and only "route -n" shows what I need to know. Something is definitely awry there! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>>> I''ll be happy to add an error message if an IFB is mentioned in the tcrules file. >>> >>> >> That makes sense as I can''t really see any case when there would possibly be a match (and I spent about 4-5 hours yesterday rimming "fantasy" scenarios in that file, using ifb-type devices and shorewall was silently swallowing it all - and laughing back in my face). >> > > I will attach a patch to my response to your other post. >I don''t see this fixed (if that was your intention with patches TC1 and TC2) - just so that you know. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> 4. >> tcdevices: >> A:eth0 - 100mbit classify,hfsc >> [...] >> >> tcclasses: >> eth0:11 - 10*full/100:50ms 20*full/100 1 tcp-ack >> [...] >> >> Passes compilation, but triggers the following error: >> >> shorewall[1566]: RTNETLINK answers: Invalid argument >> shorewall[1566]: We have an error talking to the kernel >> shorewall[1566]: ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" Failed >> > > The second attached patch should fix this one. >After applying TC1 and TC2 and having this: tcdevices 0xA:eth0 ... tcclasses 0xA:11 ... 0xA:12 ... .... compilation passes, but then I get the following error on shorewall (re)start ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" Failed ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 2:29 PM, Mr Dash Four wrote:> >>>> I''ll be happy to add an error message if an IFB is mentioned in the tcrules file. >>>> >>> That makes sense as I can''t really see any case when there would possibly be a match (and I spent about 4-5 hours yesterday rimming "fantasy" scenarios in that file, using ifb-type devices and shorewall was silently swallowing it all - and laughing back in my face). >>> >> >> I will attach a patch to my response to your other post. >> > I don''t see this fixed (if that was your intention with patches TC1 and TC2) - just so that you know. >Here''s my test case: tcdevices: 0a:eth0 - 1mbit classify,hfsc 0xb:ifb0 - 1mbit - eth0 tcclasses: 0xa:11 - 10*full/100:50ms 20*full/100 1 tcp-ack 0xb:21 - 50*full/100 full 1 tcrules: 0xa:11 10.1.10.0/24 0xb:21 - 10.1.10.0/24 Result: Checking /home/teastep/shorewall/regressionLibrary/4.4.19/ifb/tcrules... ERROR: IFB Classes may not be specified in tcrules : /home/teastep/shorewall/regressionLibrary/4.4.19/ifb/tcrules (line 2) -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 2:30 PM, Mr Dash Four wrote:> >>> 4. >>> tcdevices: >>> A:eth0 - 100mbit classify,hfsc >>> [...] >>> >>> tcclasses: >>> eth0:11 - 10*full/100:50ms 20*full/100 1 tcp-ack >>> [...] >>> >>> Passes compilation, but triggers the following error: >>> >>> shorewall[1566]: RTNETLINK answers: Invalid argument >>> shorewall[1566]: We have an error talking to the kernel >>> shorewall[1566]: ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" Failed >>> >> >> The second attached patch should fix this one. >> > After applying TC1 and TC2 and having this: > > tcdevices > 0xA:eth0 ... > > tcclasses > 0xA:11 ... > 0xA:12 ... > .... > > compilation passes, but then I get the following error on shorewall (re)start > > ERROR: Command "tc filter add dev eth0 parent 10:0 protocol ip prio 266 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid a:11" FailedI misunderstood which file entry was generating this problem. The attached patch causes the incorrect "parent 10:0" to be replaced by "parent a:0". The earlier patch did the same for entries in the tcfilters file. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 2, 2011, at 10:32 AM, Mr Dash Four wrote:> >> But C''s default input radix is 10. In tcdevices and tcrules file, the default input radix is 16. So the ''0x'' is only required in those cases where there is an ambiguity in the syntax; e.g., when a00 can be interpreted as a hex number or as an interface name. > Not if it is followed by a colon (:) it isn''t. Anyway, whatever you decide what the final format should be, it needs to be the same regardless of which file it appears in. In other words, is it "A", "0A" (00000A too?) or "0xA" (or any of these?)? I need clarity. > >> I can''t now suddenly require all numbers in those files to be prefaced by 0x. >> > It was your idea to put the "0x" in front of these numbers, not mine, so, stop complaining! Whatever you decide the format should be let me know so that I could test it.The final format is: a) The 0x prefix is neither required nor accepted when referring to devices. b) In the tcclasses file, if the token preceding the first ":" matches the name of a device defined in the tcdevices file, then it is assumed to be an interface name. Otherwise, if it is composed of valid hex digits, then it is interpreted as a device number. Otherwise, it is an error. This means that it is very unwise to have a device named "a" if it isn''t device number 10 (hex a). There is a preview of 4.4.19.2 at http://www.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.19 if you are interested in testing. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> b) In the tcclasses file, if the token preceding the first ":" matches the name of a device defined in the tcdevices file, then it is assumed to be an interface name. Otherwise, if it is composed of valid hex digits, then it is interpreted as a device number. Otherwise, it is an error. >What about tcdevices file? What is the format there? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 3, 2011, at 2:37 PM, Mr Dash Four wrote:> >> b) In the tcclasses file, if the token preceding the first ":" matches the name of a device defined in the tcdevices file, then it is assumed to be an interface name. Otherwise, if it is composed of valid hex digits, then it is interpreted as a device number. Otherwise, it is an error. >> > What about tcdevices file? What is the format there?There is no ambiguity in the first column of the tcdevices file. The syntax is [<number>:>]interface. So if there is a colon present, then whatever precedes it must be a hex number. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> There is no ambiguity in the first column of the tcdevices file. The syntax is [<number>:>]interface. So if there is a colon present, then whatever precedes it must be a hex number. >I take it you meant "[<number>:]interface"? Also, is there a limit on the number of (hex) digits I could use? In other words, is "dead:eth0" acceptable in both tcdevices and tcclasses? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 3, 2011, at 3:37 PM, Mr Dash Four wrote:> >> There is no ambiguity in the first column of the tcdevices file. The syntax is [<number>:>]interface. So if there is a colon present, then whatever precedes it must be a hex number. >> > I take it you meant "[<number>:]interface"? Also, is there a limit on the number of (hex) digits I could use? In other words, is "dead:eth0" acceptable in both tcdevices and tcclasses?They are 4 digits but iproute2 reserves the "upper half" (those values where value LAND 0X8000 is non-zero). Shorewall currently does not enforce that restriction. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> They are 4 digits but iproute2 reserves the "upper half" (those values where value LAND 0X8000 is non-zero). Shorewall currently does not enforce that restriction. >I am not sure I understand this - what range of values for the hex are accepted then? Also, I''ve asked about the event-triggers in shorewall as I intend to run a script which creates my tcfilters file to be compiled by shorewall - I intended to use "init", but you mentioned in one of your previous posts that a "compile" script/file may be what is needed. In that script I have to load all my ipsets (which is what I am currently doing in "init") and then substitute the values in my tcfilters template with the actual ipset values and then pass the resulting file to shorewall for compilation. I know this is quite ugly, but I cannot see a better solution at present. Finally, one more query before I delve into this - is it possible to enforce "traffic shaping" on a lo (loopback) device? I know it may sound/look a bit idiotic, but I am using this device to run quite a lot of "services" (mainly as a tunnel via the ssh server) and would like to prioritise these. Is there actually a limit on the lo device? If so, how much is it? The lo device is already in use by shorewall (i.e. it is defined/used in zones as well as rules and secmarks files). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 3, 2011, at 5:13 PM, Mr Dash Four wrote:> >> They are 4 digits but iproute2 reserves the "upper half" (those values where value LAND 0X8000 is non-zero). Shorewall currently does not enforce that restriction. >> > I am not sure I understand this - what range of values for the hex are accepted then?Thinking about this some more, Shorewall assumes a maximum of 255 devices with the similar assumption that device numbers will have a (decimal) value of 255 or less. So the maximum acceptable size is two hex digits. I will add enforcement of that limit before I release 4.4.19.2.> > Also, I''ve asked about the event-triggers in shorewall as I intend to run a script which creates my tcfilters file to be compiled by shorewall - I intended to use "init", but you mentioned in one of your previous posts that a "compile" script/file may be what is needed. In that script I have to load all my ipsets (which is what I am currently doing in "init") and then substitute the values in my tcfilters template with the actual ipset values and then pass the resulting file to shorewall for compilation. > > I know this is quite ugly, but I cannot see a better solution at present.Nor can I. Note that the ''compile'' script must be written in Perl since it is executed directly in the compiler.> > Finally, one more query before I delve into this - is it possible to enforce "traffic shaping" on a lo (loopback) device? I know it may sound/look a bit idiotic, but I am using this device to run quite a lot of "services" (mainly as a tunnel via the ssh server) and would like to prioritise these. Is there actually a limit on the lo device? If so, how much is it? The lo device is already in use by shorewall (i.e. it is defined/used in zones as well as rules and secmarks files).You are on your own there. I haven''t experimented with trying to shape traffic exiting on ''lo''. One thing I can tell you is that TCO and GCO are enabled on ''lo'' in recent kernels. So you need to use the "minburst" setting when specifying the OUT-BANDWIDTH. See http://www.shorewall.net/LennyToSqueeze.html#SimpleTC. Don''t be mislead by the fact that only simple TC is mentioned at that URL; the same applies to Complex TC. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> I am not sure I understand this - what range of values for the hex are accepted then? >> > > Thinking about this some more, Shorewall assumes a maximum of 255 devices with the similar assumption that device numbers will have a (decimal) value of 255 or less. So the maximum acceptable size is two hex digits. I will add enforcement of that limit before I release 4.4.19.2. >Fair enough I think. So, "0ff:eth0" should be an acceptable value then, right?>> I know this is quite ugly, but I cannot see a better solution at present. >> > > Nor can I. Note that the ''compile'' script must be written in Perl since it is executed directly in the compiler. >Ah, that''s me out of this then - I don''t know much perl, so I can''t really get this "compile" script constructed! Although perl may have better substituting capabilities than a shell (or awk even) script I am totally hopeless with it. If I include my (shell) script in init would that work?> You are on your own there.Well, no guts - no glory right?> I haven''t experimented with trying to shape traffic exiting on ''lo''. One thing I can tell you is that TCO and GCO are enabled on ''lo'' in recent kernels. So you need to use the "minburst" setting when specifying the OUT-BANDWIDTH. See http://www.shorewall.net/LennyToSqueeze.html#SimpleTC. Don''t be mislead by the fact that only simple TC is mentioned at that URL; the same applies to Complex TC. >Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 4, 2011, at 9:03 AM, Mr Dash Four wrote:> >>> I am not sure I understand this - what range of values for the hex are accepted then? >>> >> >> Thinking about this some more, Shorewall assumes a maximum of 255 devices with the similar assumption that device numbers will have a (decimal) value of 255 or less. So the maximum acceptable size is two hex digits. I will add enforcement of that limit before I release 4.4.19.2. >> > Fair enough I think. So, "0ff:eth0" should be an acceptable value then, right?Correct.> >>> I know this is quite ugly, but I cannot see a better solution at present. >>> >> >> Nor can I. Note that the ''compile'' script must be written in Perl since it is executed directly in the compiler. >> > Ah, that''s me out of this then - I don''t know much perl, so I can''t really get this "compile" script constructed! Although perl may have better substituting capabilities than a shell (or awk even) script I am totally hopeless with it. If I include my (shell) script in init would that work?No. Again, init is executed by the compiled script. What you want to do is to create your own tcfilters file from ipset contents; that must be done when the script is being compiled. But your compile script can be as simple as this: system ''/etc/shorewall/myscript''; where /etc/shorewall/myscript is your shell program that builds tcfilters.> >> You are on your own there.> Well, no guts - no glory right?Indeed.> >> I haven''t experimented with trying to shape traffic exiting on ''lo''. One thing I can tell you is that TCO and GCO are enabled on ''lo'' in recent kernels. So you need to use the "minburst" setting when specifying the OUT-BANDWIDTH. See http://www.shorewall.net/LennyToSqueeze.html#SimpleTC. Don''t be mislead by the fact that only simple TC is mentioned at that URL; the same applies to Complex TC. >> > Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)?No idea. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> system ''/etc/shorewall/myscript''; > > where /etc/shorewall/myscript is your shell program that builds tcfilters. >OK, where do I have to insert this line into then - in which file? It would be easy enough to build the (shell) script, so if I have to place a single line somewhere that would be OK. Alternatively, I could use the shorewall init.d script as this is normally executed when shorewall starts/stops/reloads etc.>> Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)? >> > > No idea. >Google says there is no limit - the only limit is how much the CPU/kernel can handle, so I might go for 0.5gbits (500mbits) and see how it goes. On another note, I think I''ve discovered another 2 bugs (1 in tcclasses and 1 in tcrules) - will post details later on. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 4, 2011, at 1:38 PM, Mr Dash Four wrote:> >> system ''/etc/shorewall/myscript''; >> >> where /etc/shorewall/myscript is your shell program that builds tcfilters. >> > OK, where do I have to insert this line into then - in which file? It would be easy enough to build the (shell) script, so if I have to place a single line somewhere that would be OK.Create the file /etc/shorewall/compile with that single line.> Alternatively, I could use the shorewall init.d script as this is normally executed when shorewall starts/stops/reloads etc.Not recommended since that file gets replaced on each upgrade.> >>> Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)? >>> >> >> No idea. >> > Google says there is no limit - the only limit is how much the CPU/kernel can handle, so I might go for 0.5gbits (500mbits) and see how it goes. On another note, I think I''ve discovered another 2 bugs (1 in tcclasses and 1 in tcrules) - will post details later on.Okay -- I''ll hold off releasing 4.4.19.2 until I hear from you. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Create the file /etc/shorewall/compile with that single line. >Yep, I could do that.>> Alternatively, I could use the shorewall init.d script as this is normally executed when shorewall starts/stops/reloads etc. >> > > Not recommended since that file gets replaced on each upgrade. >I am replacing this file anyway because the one you supply with the rpm is, quite frankly, crap! When the service runs - i.e. it is started and/or stopped - I get no indication whatsoever whether there was an error or whether the service started OK and I have to look at the syslog to see what has happened. That also means my gdm error log daemon won''t pick it up and won''t show on the status screen (of the gdm when it starts) if that service fails. I can provide you with a more "glamorous" init.d file if you like - just let me know if you need it.>>>> Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)? >>>> >>>> >>> No idea. >>> >>> >> Google says there is no limit - the only limit is how much the CPU/kernel can handle, so I might go for 0.5gbits (500mbits) and see how it goes.One question relating to that - if there is enough bandwidth available for two services with different priorities (one low, one high) do they get served at the same time or is the priority value honoured and the high-priority service gets served first regardless of the fact that there is a bandwidth available to serve both services, while the low priority one waits? If they both get served when a bandwidth *is* available then I do not see any sense in applying traffic shaping on the loopback device as its bandwidth exceeds (by a factor of 5) what my CPU/kernel can handle, compared to my real network interface.>> On another note, I think I''ve discovered another 2 bugs (1 in tcclasses and 1 in tcrules) - will post details later on. >> > > Okay -- I''ll hold off releasing 4.4.19.2 until I hear from you. >OK, here goes: 1. When tcdevices is defined, but tcrules/tcfilters and tclasses are empty shorewall compiles everything (without complaining!) and when it (re)starts the whole network grinds to a screeching halt - no packets in or out. I had a similar issue with this a while ago, which I thought, wrongly, was because of the presence of the "hfsc" option in my ifbX device. As it turned out, this all comes down to the absence of a default class - everything grinds to a halt then! So, in short, if there is *no* default classes defined in either of the interfaces listed in tcdevices shorewall *should* produce an error as no packets will be allowed over these interfaces. 2. tcdevices 0ff:ifb0 tcfilters 0ff:14 ... ... ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11) 3. Same concerns about the use of anything other than ifbX device classes in tcfilters as with the use of ifbX device classes in tcrules - should this be allowed by shorewall (and, more importantly, if it *is* allowed, is there a probability of a match at all)? 4. tcdevices 0ff:eth0 ... ifb0 .... ifb0 is allocated "100" (hex) which is against the pre-defined limits (0-ff). That, in turn, screws up the tcfilters statements completely (they are simply ignored and everything is "routed" through the default class defined for ifb0). 5. Similar to 4 above: tcdevices 0fe:eth0 ... ifb0 ... tcfilters ifb0:.... ifb0 has a major class number of "ff" defined. Whatever I put in the tcfilters is completely ignored (everything is "routed" through the "default" ifb0 class) 6. tcdevices 1:eth0 ... 2:ifb0 ... tclasses 1:11 .... (default class) 1:12 .... 2:21 .... (default class) 2:22 .... tcrules 1:11 ... 11 .... (N.B. this is simply a mark, not a class definition!) 2:22 ... So, shorewall passes all this despite the fact that the mark defined as "11" is never used - there, I think, should at least be a warning issued that this mark is never used. Same is valid for "unused" classes as well (i.e. when I define a class and do not use it anywhere). That is for now. I have tested all this with the "19.2" version specified by the link you provided me with (which was wrong, by the way) in one of your previous posts. Also, I was not able to test the range restriction (0-FF) in tcdevices as this was not yet implemented there. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 4, 2011, at 3:58 PM, Mr Dash Four wrote:> >> Create the file /etc/shorewall/compile with that single line. >> > Yep, I could do that. > >>> Alternatively, I could use the shorewall init.d script as this is normally executed when shorewall starts/stops/reloads etc. >>> >> >> Not recommended since that file gets replaced on each upgrade. >> > I am replacing this file anyway because the one you supply with the rpm is, quite frankly, crap! When the service runs - i.e. it is started and/or stopped - I get no indication whatsoever whether there was an error or whether the service started OK and I have to look at the syslog to see what has happened. That also means my gdm error log daemon won''t pick it up and won''t show on the status screen (of the gdm when it starts) if that service fails. I can provide you with a more "glamorous" init.d file if you like - just let me know if you need it.Thanks, but I think I''ll keep the current "least-common-denominator" version. I expect distributions to provide more robust versions in the RPMs that they package. I personally count on the init.d script at reboot; which I do every several months. All other times, I run /sbin/shorewall directly.> >>>>> Right! I am not sure I understand what "miniburst" is, but if I turn TSO and GCO off (via shorewall init) would that be OK? What should I specify in the bandwidth limit of lo though (I have no idea how much the loopback can handle)? >>>>> >>>> No idea. >>>> >>> Google says there is no limit - the only limit is how much the CPU/kernel can handle, so I might go for 0.5gbits (500mbits) and see how it goes. > One question relating to that - if there is enough bandwidth available for two services with different priorities (one low, one high) do they get served at the same time or is the priority value honoured and the high-priority service gets served first regardless of the fact that there is a bandwidth available to serve both services, while the low priority one waits? > > If they both get served when a bandwidth *is* available then I do not see any sense in applying traffic shaping on the loopback device as its bandwidth exceeds (by a factor of 5) what my CPU/kernel can handle, compared to my real network interface.Prioritization only occurs if there is queuing on the device. So there really isn''t much point unless you restrict the bandwidth to the point where there *is* queuing.> >>> On another note, I think I''ve discovered another 2 bugs (1 in tcclasses and 1 in tcrules) - will post details later on. >>> >> >> Okay -- I''ll hold off releasing 4.4.19.2 until I hear from you. >> > OK, here goes: > > > 1. When tcdevices is defined, but tcrules/tcfilters and tclasses are empty shorewall compiles everything (without complaining!) and when it (re)starts the whole network grinds to a screeching halt - no packets in or out. I had a similar issue with this a while ago, which I thought, wrongly, was because of the presence of the "hfsc" option in my ifbX device. As it turned out, this all comes down to the absence of a default class - everything grinds to a halt then! So, in short, if there is *no* default classes defined in either of the interfaces listed in tcdevices shorewall *should* produce an error as no packets will be allowed over these interfaces.I''ve added that test.> > 2. > tcdevices > 0ff:ifb0 > > tcfilters > 0ff:14 ... > ... > ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11)I have a fix for that one.> > 3. Same concerns about the use of anything other than ifbX device classes in tcfilters as with the use of ifbX device classes in tcrules - should this be allowed by shorewall (and, more importantly, if it *is* allowed, is there a probability of a match at all)?When I used complex TC, I used nothing but tcfilters (and I had no IFB).> > 4. > tcdevices > 0ff:eth0 ... > ifb0 .... > > ifb0 is allocated "100" (hex) which is against the pre-defined limits (0-ff). That, in turn, screws up the tcfilters statements completely (they are simply ignored and everything is "routed" through the default class defined for ifb0).I had already added a test for that case when I started enforcing the limit. Those changes aren''t in the pre-release.> > 5. Similar to 4 above: > tcdevices > 0fe:eth0 ... > ifb0 ... > > tcfilters > ifb0:.... > > ifb0 has a major class number of "ff" defined. Whatever I put in the tcfilters is completely ignored (everything is "routed" through the "default" ifb0 class)Think I''ve fixed that one too.> > 6. > tcdevices > 1:eth0 ... > 2:ifb0 ... > > tclasses > 1:11 .... (default class) > 1:12 .... > 2:21 .... (default class) > 2:22 .... > > tcrules > 1:11 ... > 11 .... (N.B. this is simply a mark, not a class definition!) > 2:22 ... > > So, shorewall passes all this despite the fact that the mark defined as "11" is never used - there, I think, should at least be a warning issued that this mark is never used.No. Once again; packet marks have *many* uses other than traffic shaping. If I could go back to day 1, I would name the file ''marks'' rather than ''tcrules'' so that people didn''t automatically connect the two.> Same is valid for "unused" classes as well (i.e. when I define a class and do not use it anywhere).I''ll put that on my ''to-do'' list.> > That is for now. I have tested all this with the "19.2" version specified by the link you provided me with (which was wrong, by the way) in one of your previous posts.Thanks.> > Also, I was not able to test the range restriction (0-FF) in tcdevices as this was not yet implemented there.Yep. I will upload a new 4.4.19.2 preview that I believe corrects these issues. Please stand by. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 4, 2011, at 5:31 PM, Tom Eastep wrote:> > I will upload a new 4.4.19.2 preview that I believe corrects these issues. Please stand by. >Okay -- it is available at http://ipv6.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.19.2/ -Tom PS -- that site also has an IPv4 address. 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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 4, 2011, at 6:57 PM, Tom Eastep wrote:> > On May 4, 2011, at 5:31 PM, Tom Eastep wrote: > >> >> I will upload a new 4.4.19.2 preview that I believe corrects these issues. Please stand by. >> > > Okay -- it is available at http://ipv6.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.19.2/ > > -Tom > > PS -- that site also has an IPv4 address.Please hold off on testing this. There seems to have been an operator during the build and, at least the tarball, doesn''t include the updated contents. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 05/05/2011 07:14 AM, Tom Eastep wrote:>> Okay -- it is available at >> http://ipv6.shorewall.net/pub/shorewall/development/4.4/shorewall-4.4.19.2/ >> >> PS -- that site also has an IPv4 address. > > Please hold off on testing this. There seems to have been an operator > error during the build and, at least the tarball, doesn''t include the > updated contents.The problem has been corrected. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The problem has been corrected. >OK, I''ll download it again then. Will test this later this evening and will let you know. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On May 5, 2011, at 8:19 AM, Mr Dash Four wrote:> >> The problem has been corrected. >> > OK, I''ll download it again then. Will test this later this evening and > will let you know.Thanks. I''m going to be out of town for several days and won''t have much time for Shorewall. So if there are issues, I may not be able to address them until Sunday or Monday. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> 1. When tcdevices is defined, but tcrules/tcfilters and tclasses are > empty shorewall compiles everything (without complaining!) and when it > (re)starts the whole network grinds to a screeching halt - no packets > in or out. I had a similar issue with this a while ago, which I > thought, wrongly, was because of the presence of the "hfsc" option in > my ifbX device. As it turned out, this all comes down to the absence > of a default class - everything grinds to a halt then! So, in short, > if there is *no* default classes defined in either of the interfaces > listed in tcdevices shorewall *should* produce an error as no packets > will be allowed over these interfaces.That''s fixed.> > 2. > tcdevices > 0ff:ifb0 > > tcfilters > 0ff:14 ... > ... > ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11)That''s fixed.> 4. > tcdevices > 0ff:eth0 ... > ifb0 .... > > ifb0 is allocated "100" (hex) which is against the pre-defined limits > (0-ff). That, in turn, screws up the tcfilters statements completely > (they are simply ignored and everything is "routed" through the > default class defined for ifb0).That combination above causes the "number" for ifb0 (as "automatically" assigned by shorewall) to be 100 (hex) and therefore triggers the following error: "ERROR: Attempting to assign a device number > 255 : /etc/shorewall/tcdevices (line 12)". Perhaps you could try and issue an unused random number from the 0-FF range instead.> > 5. Similar to 4 above: > tcdevices > 0fe:eth0 ... > ifb0 ... > > tcfilters > ifb0:.... > > ifb0 has a major class number of "ff" defined. Whatever I put in the > tcfilters is completely ignored (everything is "routed" through the > "default" ifb0 class)That''s fixed. I also noticed from the latest Changelog that you have fixed the ipset double-negative statement bug as I indicated a while ago. That particular bug is indeed cleared! However, when I have "ACCEPT:info $FW net:10.1.0.7,10.1.0.9,+[!my-host[src],!ssh-host[src]] tcp" I get "ERROR: Invalid host list (!my-host[src],!ssh-host[src]) : /etc/shorewall/rules (line 21)". This is a valid statement according to man shorewall-exclusion: "+[!set1,!set2,...!setN] produces a packet match if the packet does not match any of the sets. In other words, it is like NOT match set1 AND NOT match set2 ... AND NOT match setN.", so this statement should be allowed. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 05/05/2011 03:49 PM, Mr Dash Four wrote:>> 4. >> tcdevices >> 0ff:eth0 ... >> ifb0 .... >> >> ifb0 is allocated "100" (hex) which is against the pre-defined limits >> (0-ff). That, in turn, screws up the tcfilters statements completely >> (they are simply ignored and everything is "routed" through the >> default class defined for ifb0). > That combination above causes the "number" for ifb0 (as "automatically" > assigned by shorewall) to be 100 (hex) and therefore triggers the > following error: "ERROR: Attempting to assign a device number > 255 : > /etc/shorewall/tcdevices (line 12)". Perhaps you could try and issue an > unused random number from the 0-FF range instead.For this patch release, I think I''ll leave it as it is and possibly do as you suggest in 4.4.20.> I also noticed from the latest Changelog that you have fixed the ipset > double-negative statement bug as I indicated a while ago. That > particular bug is indeed cleared! > > However, when I have "ACCEPT:info $FW > net:10.1.0.7,10.1.0.9,+[!my-host[src],!ssh-host[src]] tcp" I get "ERROR: > Invalid host list (!my-host[src],!ssh-host[src]) : /etc/shorewall/rules > (line 21)". > > This is a valid statement according to man shorewall-exclusion: > "+[!set1,!set2,...!setN] produces a packet match if the packet does not > match any of the sets. In other words, it is like NOT match set1 AND NOT > match set2 ... AND NOT match setN.", so this statement should be allowed. >The somewhat imposing attached patch corrects this problem. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The somewhat imposing attached patch corrects this problem. >Is this patch in addition to (the just-released) 19.2 or do I just install the released version and forget about this patch? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
It is included in 4.4.19.2. Tom Sent from my iPad On May 6, 2011, at 8:53 AM, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> The somewhat imposing attached patch corrects this problem. >> > Is this patch in addition to (the just-released) 19.2 or do I just install the released version and forget about this patch? >------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Sent from my iPad >Tricky business this, eh? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Indeed Sent from my iPad On May 6, 2011, at 12:08 PM, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> >> Sent from my iPad >> > Tricky business this, eh? > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The somewhat imposing attached patch corrects this problem. >The released 19.2 version fixes this. As I have started compiling my TC policies now, I have one more query for something I haven''t thought of until now - when the host machine (on which shorewall operates) initiates a TCP connection this connection is bi-directional - information flows in both directions. So, presumably, I have to account (and define!) both parts of this connection (i.e. via tcrules as well as tcfilters for the "opposite" side), right? This becomes even trickier with UDP connections (VOIP in particular, which is what I am mostly after) - with VOIP connections, especially when there are "fascist" firewalls built by admins like myself, the VOIP client needs to punch a hole through the firewall (I define a strict range of ports, programs and conditions under which this is allowed) and connect to the server, then let the server send VOIP data to the client. In other words, the connection is established by the client, but is used by the VOIP server on the opposite side of that connection. Given that, I take it I have to account for this in tcrules, but most importantly (as data will flow mainly from the opposite direction), I have to define the proper class to fit that flow in tcfilters, right? The difficult part (well, for me anyway) is that with tcfilters I have very little to play with - the ports on both sides are (almost) random and I do not have the luxury of using ipset or any other way to ID this flow, except, may be the destination host, but that is not 100% guaranteed in my case. Any other ideas? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Another bug: tcdevices a:eth0 ... b:tun0 ... tcclasses a:11 ... b:21 ... 1. tcrules a:11 $FW 10.1.1.1 tcp 22 b:21 $FW 10.1.1.1 tcp 22 would not give me what I would like, i.e. traffic shaping through the appropriate eth0 class when the source ($FW) is eth0 and traffic shaping through the appropriate tun0 class when the source ($FW) is tun0. An attempt to do the following: 2. tcrules a:11 eth0 10.1.1.1 tcp 22 b:21 tun0 10.1.1.1 tcp 22 Gives me 2 warnings: 1) "WARNING: Using an interface as the SOURCE in a T: rule requires the interface to be up and configured when Shorewall starts/restarts" for eth0 and 2) "WARNING: default route ignored on interface eth0", plus "ERROR: Unknown Interface (tun0)" (tun0 is UP and RUNNING with a valid IP address). In addition, shorewall, for some unknown bizarre reason, uses eth0''s source address to create the CLASSIFY rule in tcpost, which is wrong (see below). "man shorewall-tcrules (SOURCE section)" says: "1. An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the :T chain qualifier." which is another non-sensical self-imposed shorewall restriction. Shorewall translates "a:11 $FW 10.1.1.1 tcp 22" to "-A tcpost -p 6 --dport 22 -s $source -d 10.1.1.1 -j CLASSIFY --set-class a:11" in the mangle table, where $source is picked up to be the source of the device in question (eth0). In order to use the second form (2. above) successfully the iptables statement needs to be replaced with the following (using eth0 as an example, but the same is valid for tun0 as well): "-A tcpost -p 6 --dport 22 -o eth0 -d 10.1.1.1 -j CLASSIFY --set-class a:11" on the same table (mangle). I have tried both statements (to replace the complete nonsense shorewall puts in the tcpost chain) successfully and it works, so I think the man page as well as the building of that construct should be amended accordingly. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/6/11 7:34 PM, Mr Dash Four wrote:> Another bug: > > tcdevices > a:eth0 ... > b:tun0 ... > > tcclasses > a:11 ... > b:21 ... > > 1. > tcrules > a:11 $FW 10.1.1.1 tcp 22 > b:21 $FW 10.1.1.1 tcp 22 > > would not give me what I would like, i.e. traffic shaping through the > appropriate eth0 class when the source ($FW) is eth0When the source is $FW, there is no source interface.> and traffic shaping > through the appropriate tun0 class when the source ($FW) is tun0. An > attempt to do the following: > > 2. > tcrules > a:11 eth0 10.1.1.1 tcp 22 > b:21 tun0 10.1.1.1 tcp 22 > > Gives me 2 warnings: 1) "WARNING: Using an interface as the SOURCE in a > T: rule requires the interface to be up and configured when Shorewall > starts/restarts" for eth0 and 2) "WARNING: default route ignored on > interface eth0", plus "ERROR: Unknown Interface (tun0)" (tun0 is UP and > RUNNING with a valid IP address). > > In addition, shorewall, for some unknown bizarre reason, uses eth0''s > source address to create the CLASSIFY rule in tcpost, which is wrong > (see below). > > "man shorewall-tcrules (SOURCE section)" says: "1. An interface name - > matches traffic entering the firewall on the specified interface. May > not be used in classify rules or in rules using the :T chain qualifier." > which is another non-sensical self-imposed shorewall restriction. > > Shorewall translates "a:11 $FW 10.1.1.1 tcp 22" to "-A tcpost -p 6 > --dport 22 -s $source -d 10.1.1.1 -j CLASSIFY --set-class a:11" in the > mangle table, where $source is picked up to be the source of the device > in question (eth0). > > In order to use the second form (2. above) successfully the iptables > statement needs to be replaced with the following (using eth0 as an > example, but the same is valid for tun0 as well): "-A tcpost -p 6 > --dport 22 -o eth0 -d 10.1.1.1 -j CLASSIFY --set-class a:11" on the same > table (mangle).The two rules you want are: a:11 $FW eth0:10.1.1.1 tcp 22 b:11 $FW tun0:10.1.1.1 tcp 22 -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> When the source is $FW, there is no source interface. >In other words, "a:11 - 10.1.1.1 tcp 22" is exactly the same as "a:11 $FW 10.1.1.1 tcp 22". Why is that? To me, when $FW is specified shorewall should then pick up the IP address of the interface to which the specified class belongs (eth0 in this case as "a:11" is defined for eth0) and when the actual device is specified, i.e. "a:11 eth0 10.1.1.1 tcp 22", then enforce the use of that interface in the iptables statement instead (it should also give an error if "a:11 tun0 10.1.1.1 tcp 22" is specified as the class "belongs" to eth0 and that statement will *never* return any matches). Of course, when "a:11 - 10.1.1.1 tcp 22" is specified then no IP address will be included in the iptables statement, but the use of eth0 should really be enforced as this class make sense (i.e. likely to return matches) only on that interface.> The two rules you want are: > > a:11 $FW eth0:10.1.1.1 tcp 22 > b:11 $FW tun0:10.1.1.1 tcp 22 >I thought I wasn''t allowed to do that. Is there any reason why shorewall moans when I specify "a:11 eth0 10.1.1.1 tcp 22" and I get the 2 warnings - that to me looks a perfectly legitimate statement (and eth0 is up and running so it has a valid IP address, not to mention that the "tun0 does not exists" message I also get is a complete and utter joke)? I also don''t see why I should prefix source interface with destination address and place all this in the destination column - it is quite confusing and has nothing to do with the destination, quite frankly! Specifying the source interface in the source column (and ask shorewall to take the name of that interface rather than its IP address) seems the more logical choice, don''t you think? Besides, not specifying any interface - like "a:11 $FW 10.1.1.1 tcp 22" for example - makes sense *only* for one interface - eth0 (for tun0 that statement will *never* return a match), so I do not know why shorewall can''t pick that "automatically" so to speak (by "looking" at the interface of the class for which this statement refers), or, even better, enforce the use of that interface (eth0 in this case) as the class defined makes sense only for that interface and no other? It is very similar scenario with ifbX devices as well - the class(es) in use will only make sense (i.e. return matches) on one interface only - that of the class'' interface. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/7/11 5:11 AM, Mr Dash Four wrote:> >> When the source is $FW, there is no source interface. >> > In other words, "a:11 - 10.1.1.1 tcp 22" is exactly the same as "a:11 > $FW 10.1.1.1 tcp 22". Why is that?Normally, $FW is used to trigger placement of the rule in the OUTPUT chain (actually, in the ''tcout'') chain. When a classifier is listed in the first column however, that is overridden and the rule is placed in the POSTROUTING (tcpost) chain. iptables/Netfilter only supports CLASSIFY rules in that chain.> > To me, when $FW is specified shorewall should then pick up the IP > address of the interface to which the specified class belongs (eth0 in > this case as "a:11" is defined for eth0) and when the actual device is > specified, i.e. "a:11 eth0 10.1.1.1 tcp 22", then enforce the use of > that interface in the iptables statement instead (it should also give an > error if "a:11 tun0 10.1.1.1 tcp 22" is specified as the class "belongs" > to eth0 and that statement will *never* return any matches).In *all* Shorewall configuration files, an interface name in the SOURCE column specifies the interface on which the traffic *enters* the firewall (-i option in iptables). So the above statement says that traffic entering the firewall on tun0 and being routed out of eth0 to 10.1.1.1 should be part of class a:11. If you want to insist that the traffic matching the rule has the primary IP address of eth0 as its source, then you would code: a:11 ð0 eth0:10.1.1.1 tcp 22 See http://www.shorewall.net/configuration_file_basics.htm#Rvariables.> > Of course, when "a:11 - 10.1.1.1 tcp 22" is specified then no IP address > will be included in the iptables statement, but the use of eth0 should > really be enforced as this class make sense (i.e. likely to return > matches) only on that interface. > >> The two rules you want are: >> >> a:11 $FW eth0:10.1.1.1 tcp 22 >> b:11 $FW tun0:10.1.1.1 tcp 22 >> > I thought I wasn''t allowed to do that. > > Is there any reason why shorewall moans when I specify "a:11 eth0 > 10.1.1.1 tcp 22" and I get the 2 warnings - that to me looks a perfectly > legitimate statement (and eth0 is up and running so it has a valid IP > address, not to mention that the "tun0 does not exists" message I also > get is a complete and utter joke)?The iptables/Netfilter restriction about -i in the output chain requires Shorewall to use the routing table to determine the source addresses of traffic that might enter through the specified interface. a) If there is a default route out of the interface, it is ignored since that would mean that traffic from *any* address would match. b) After 8-9 years of getting problem reports that say "My firewall won''t start during boot but will later", I put in a warning about it.> > I also don''t see why I should prefix source interface with destination > address and place all this in the destination column - it is quite > confusing and has nothing to do with the destinationThe traffic is going *out* of that interface.> quite frankly! > Specifying the source interface in the source column (and ask shorewall > to take the name of that interface rather than its IP address) seems the > more logical choice, don''t you think?No -- what about forwarded traffic?> > Besides, not specifying any interface - like "a:11 $FW 10.1.1.1 tcp 22" > for example - makes sense *only* for one interface - eth0 (for tun0 that > statement will *never* return a match)And maybe someday when I''m desperately bored, I''ll make such rules automatically insert the appropriate -o clause in the generated rule. , so I do not know why shorewall> can''t pick that "automatically" so to speak (by "looking" at the > interface of the class for which this statement refers), or, even > better, enforce the use of that interface (eth0 in this case) as the > class defined makes sense only for that interface and no other? > > It is very similar scenario with ifbX devices as well - the class(es) in > use will only make sense (i.e. return matches) on one interface only - > that of the class'' interface.Whatever -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> To me, when $FW is specified shorewall should then pick up the IP >> address of the interface to which the specified class belongs (eth0 in >> this case as "a:11" is defined for eth0) and when the actual device is >> specified, i.e. "a:11 eth0 10.1.1.1 tcp 22", then enforce the use of >> that interface in the iptables statement instead (it should also give an >> error if "a:11 tun0 10.1.1.1 tcp 22" is specified as the class "belongs" >> to eth0 and that statement will *never* return any matches). >> > > In *all* Shorewall configuration files, an interface name in the SOURCE > column specifies the interface on which the traffic *enters* the > firewall (-i option in iptables). >My point is that if a class is defined for a particular interface (as is "a:11" in my case for eth0) this will ever produce only one match and that is when this interface is involved, isn''t that so?> If you want to insist that the traffic matching the rule has the primary > IP address of eth0 as its source, then you would code: > > a:11 ð0 eth0:10.1.1.1 tcp 22 > > See http://www.shorewall.net/configuration_file_basics.htm#Rvariables. >Forgot about variables, but will use this in another place in my rules file.>> Specifying the source interface in the source column (and ask shorewall >> to take the name of that interface rather than its IP address) seems the >> more logical choice, don''t you think? >> > > No -- what about forwarded traffic? >Ah, right, never thought of that!>> Besides, not specifying any interface - like "a:11 $FW 10.1.1.1 tcp 22" >> for example - makes sense *only* for one interface - eth0 (for tun0 that >> statement will *never* return a match) >> > > And maybe someday when I''m desperately bored, I''ll make such rules > automatically insert the appropriate -o clause in the generated rule. >Well, even with your suggestion I can''t still make this to work unless I *manually* rearrange the insane rule shorewall places in tcpost (see my next post). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The two rules you want are: > > a:11 $FW eth0:10.1.1.1 tcp 22 > b:11 $FW tun0:10.1.1.1 tcp 22 >ERROR: Unknown interface (tun0) - I already pointed this out (the actual statement is "b:21 $FW tun0:10.1.1.1 tcp 22" as b:21 is defined for the tun0 interface)! If I *manually* insert what the rule should be I get no complaints from iptables, so I don''t know why shorewall is continuously moaning about this "unknown" or "missing" interface?! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/7/11 9:59 AM, Mr Dash Four wrote:>> In *all* Shorewall configuration files, an interface name in the SOURCE >> column specifies the interface on which the traffic *enters* the >> firewall (-i option in iptables). >> > My point is that if a class is defined for a particular interface (as is > "a:11" in my case for eth0) this will ever produce only one match and > that is when this interface is involved, isn''t that so?No -- it will match traffic going to 10.1.1.1 out of *any* inteface. It will only be useful if the traffic is going out of eth0. Attached is a patch that interprets this rule: a:11 - 10.1.1.1 tcp 22 as a:11 - eth0:10.1.1.1 tcp 22 (assuming that eth0 == device a).>> >> And maybe someday when I''m desperately bored, I''ll make such rules >> automatically insert the appropriate -o clause in the generated rule.Which is what the attached patch does.>> > Well, even with your suggestion I can''t still make this to work unless I > *manually* rearrange the insane rule shorewall places in tcpost (see my > next post).Your next post seems to whine about the Shorewall requirement that interface names mentioned in SOURCE and DEST columns must be defined in /etc/shorewall/interfaces. You can complain all you want but that isn''t going to change. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
Tom Eastep
2011-May-08 22:13 UTC
Re: traffic shaping peculiarities (please don''t apply the last patch)
On 5/8/11 2:36 PM, Tom Eastep wrote:> On 5/7/11 9:59 AM, Mr Dash Four wrote: > >>> In *all* Shorewall configuration files, an interface name in the SOURCE >>> column specifies the interface on which the traffic *enters* the >>> firewall (-i option in iptables). >>> >> My point is that if a class is defined for a particular interface (as is >> "a:11" in my case for eth0) this will ever produce only one match and >> that is when this interface is involved, isn''t that so? > > No -- it will match traffic going to 10.1.1.1 out of *any* inteface. It > will only be useful if the traffic is going out of eth0. Attached is a > patch that interprets this rule:Please do not apply this patch. I''m working on a replacement -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 3:13 PM, Tom Eastep wrote:> On 5/8/11 2:36 PM, Tom Eastep wrote: >> On 5/7/11 9:59 AM, Mr Dash Four wrote: >> >>>> In *all* Shorewall configuration files, an interface name in the SOURCE >>>> column specifies the interface on which the traffic *enters* the >>>> firewall (-i option in iptables). >>>> >>> My point is that if a class is defined for a particular interface (as is >>> "a:11" in my case for eth0) this will ever produce only one match and >>> that is when this interface is involved, isn''t that so? >> >> No -- it will match traffic going to 10.1.1.1 out of *any* inteface. It >> will only be useful if the traffic is going out of eth0. Attached is a >> patch that interprets this rule: > > Please do not apply this patch. I''m working on a replacementHere''s the correct patch. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Which is what the attached patch does. >Ignored as I''ve seen your other post.> Your next post seems to whine about the Shorewall requirement that > interface names mentioned in SOURCE and DEST columns must be defined in > /etc/shorewall/interfaces. You can complain all you want but that isn''t > going to change. >The reason it isn''t there is because it takes no part in any of my zones nor is it constraint by any of blacklists, rules etc - I will only need this interface for traffic shaping and maybe accounting at a later stage - same with "lo" really. If I "register" this interface in the interfaces file, but place a dash (-) and "ignore" in the options column would that work? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Here''s the correct patch. >OK, I assume you got sufficiently bored to devise the attached patch so that shorewall always includes the "-o" option specifying the interface to which the specified class belongs (provided it is not overwritten by "xxx:" in the destination column)? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> OK, I assume you got sufficiently bored to devise the attached patch > so that shorewall always includes the "-o" option specifying the > interface to which the specified class belongs (provided it is not > overwritten by "xxx:" in the destination column)?Yeah, the patch works! I also found out that if the interface is specified and the class included in the MARK field do not match shorewall moans, which is good! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> My point is that if a class is defined for a particular interface (as is >> "a:11" in my case for eth0) this will ever produce only one match and >> that is when this interface is involved, isn''t that so? >> > > No -- it will match traffic going to 10.1.1.1 out of *any* inteface. It > will only be useful if the traffic is going out of eth0. Attached is a > patch that interprets this rule: > > a:11 - 10.1.1.1 tcp 22 > > as > > a:11 - eth0:10.1.1.1 tcp 22 > > (assuming that eth0 == device a). >Am I likely to face similar issues with tcfilters? Same scenario: tcfilters ba:11 10.1.1.1 - tcp 22 bb:21 10.1.1.1 - tcp 22 (ba is the ifb0 device derived from eth0, bb is the ifb1 device derived from tun0). Should I assume that packets would get properly "redirected" to the interface that class belongs to? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 5:17 PM, Mr Dash Four wrote:> >> Which is what the attached patch does. >> > Ignored as I''ve seen your other post. > >> Your next post seems to whine about the Shorewall requirement that >> interface names mentioned in SOURCE and DEST columns must be defined in >> /etc/shorewall/interfaces. You can complain all you want but that isn''t >> going to change. >> > The reason it isn''t there is because it takes no part in any of my zones > nor is it constraint by any of blacklists, rules etc - I will only need > this interface for traffic shaping and maybe accounting at a later stage > - same with "lo" really.Shorewall knows about ''lo'' and sets up ACCEPT rules in and out of that interface.> > If I "register" this interface in the interfaces file, but place a dash > (-) and "ignore" in the options column would that work? >It would make your tcrules compile cleanly. But you must have extremely liberal policies if traffic in and out of such an interface is accepted by the filtering part of Netfilter. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 5:25 PM, Mr Dash Four wrote:> >> Here''s the correct patch. >> > OK, I assume you got sufficiently bored to devise the attached patch so > that shorewall always includes the "-o" option specifying the interface > to which the specified class belongs (provided it is not overwritten by > "xxx:" in the destination column)?Yes -- and if xxx: names another interface, the compiler will object also (that''s been there for some time). -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 5:54 PM, Mr Dash Four wrote:> > >>> My point is that if a class is defined for a particular interface (as is >>> "a:11" in my case for eth0) this will ever produce only one match and >>> that is when this interface is involved, isn''t that so? >>> >> >> No -- it will match traffic going to 10.1.1.1 out of *any* inteface. It >> will only be useful if the traffic is going out of eth0. Attached is a >> patch that interprets this rule: >> >> a:11 - 10.1.1.1 tcp 22 >> >> as >> >> a:11 - eth0:10.1.1.1 tcp 22 >> >> (assuming that eth0 == device a). >> > Am I likely to face similar issues with tcfilters? > > Same scenario: > > tcfilters > ba:11 10.1.1.1 - tcp 22 > bb:21 10.1.1.1 - tcp 22 > > (ba is the ifb0 device derived from eth0, bb is the ifb1 device derived > from tun0). Should I assume that packets would get properly "redirected" > to the interface that class belongs to?In tcfilters, Shorewall uses the first column (classid) to pick the interface to attach the filter to. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> If I "register" this interface in the interfaces file, but place a dash >> (-) and "ignore" in the options column would that work? >> >> > > It would make your tcrules compile cleanly.So "- tun0 ignore" it is then (btw the "ignore" option isn''t documented anywhere in shorewall-interfaces). One other issue I have been thinking lately - in some circumstances shorewall requires the interface to be "present" (or even up) - why is this and what happens if the interface suddenly "disappears" (like if I am to completely close the tun0 device)? If I want to "cheat" (as I often do!) I could artificially "open" tun0, start shorewall and then close that device. What would happen then (if anything)?> But you must have extremely > liberal policies if traffic in and out of such an interface is accepted > by the filtering part of Netfilter. >tun0 on one of my machines will only serve traffic internally coming from one of my subnets, so I am not overly worried about "intrusions". ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> In tcfilters, Shorewall uses the first column (classid) to pick the > interface to attach the filter to. >Right! Is there a place I could look at (by executing shorewall, tc or iptables) to see the restrictions/statements placed in tcfilters? Where is this information stored? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 7:08 PM, Mr Dash Four wrote:> >>> If I "register" this interface in the interfaces file, but place a dash >>> (-) and "ignore" in the options column would that work? >>> >>> >> >> It would make your tcrules compile cleanly. > So "- tun0 ignore" it is then (btw the "ignore" option isn''t documented > anywhere in shorewall-interfaces). > > One other issue I have been thinking lately - in some circumstances > shorewall requires the interface to be "present" (or even up) - why is > this and what happens if the interface suddenly "disappears" (like if I > am to completely close the tun0 device)?It depends on whether you have Shorewall-init installed. Since you aren''t beating on me about it''s shortcomings, I assume that you have not installed that package.> > If I want to "cheat" (as I often do!) I could artificially "open" tun0, > start shorewall and then close that device. What would happen then (if > anything)?Nothing, unless you are running Shorewall-init.> >> But you must have extremely >> liberal policies if traffic in and out of such an interface is accepted >> by the filtering part of Netfilter. >> > tun0 on one of my machines will only serve traffic internally coming > from one of my subnets, so I am not overly worried about "intrusions".*All* traffic passing to/from/through the Shorewall box is subject to Shorewall policies/rules. So traffic involving tun0 is subject to one of the following policies: all->fw : Traffic destined to the Shorewall box. fw->all : Traffic originating from the Shorewall box with a destination outside that box. all->all : If neither of the above policies apply. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/8/11 7:08 PM, Mr Dash Four wrote:> >> In tcfilters, Shorewall uses the first column (classid) to pick the >> interface to attach the filter to. >> > Right! > > Is there a place I could look at (by executing shorewall, tc or > iptables) to see the restrictions/statements placed in tcfilters? Where > is this information stored?shorewall show filters The Complex TC HOWTO at shorewall.net has some information about how to decipher the output. But have your favorite IP reference book handy before you try... -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> It depends on whether you have Shorewall-init installed. Since you > aren''t beating on me about it''s shortcomings, I assume that you have not > installed that package. >Hehe, I am not that bad! You are right, though, I don''t have it installed - I just use shorewall.>> If I want to "cheat" (as I often do!) I could artificially "open" tun0, >> start shorewall and then close that device. What would happen then (if >> anything)? >> > > Nothing, unless you are running Shorewall-init. >Maybe then shorewall shouldn''t place such restrictions in this case - the device traffic shaping rules are "ignored" by shorewall if the device in question is not "present" (or up) and if that doesn''t actually matter (which I presumed was the case as I was able to "bypass" shorewall completely and recreate those policies using iptables/tc without the device being "present") this restriction should be removed. To "force" shorewall to apply my traffic shaping policies for this device I currently have to run a separate program in rc.sysinit to bring the tun0 device into existence (and up), then let shorewall do its work, after which I close the device in rc.local. If there is no need for this restriction, then it should be removed. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> shorewall show filters > > The Complex TC HOWTO at shorewall.net has some information about how to > decipher the output. But have your favorite IP reference book handy > before you try... >You were right, I need a new degree! The "HFSC Scheduling with Linux//" article at the top of that page was also quite helpful! ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> But have your favorite IP reference book handy > before you try... >I''ve just made another observation: ip range (like 10.1.1.0-10.1.1.255 or even 10.1.1.1,10.1.1.2) is rejected by shorewall, but specifying 10.1.1.0/24 is, apparently, OK (I haven''t tested whether that would actually run though)? If that is the case it would complicate things significantly when I start designing my "compile" script for ipset replacement as I would have to create a separate rule (i.e. a line) for each ip address I encounter in my ipset - bl**dy hell! OK, I may get away with it if I could shove all the ip members into a cidr address, but that is one hell of a workaround! Ah, well... ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 7:01 AM, Mr Dash Four wrote:> >> But have your favorite IP reference book handy >> before you try... >> > I''ve just made another observation: ip range (like 10.1.1.0-10.1.1.255 > or even 10.1.1.1,10.1.1.2) is rejected by shorewall, but specifying > 10.1.1.0/24 is, apparently, OK (I haven''t tested whether that would > actually run though)? > > If that is the case it would complicate things significantly when I > start designing my "compile" script for ipset replacement as I would > have to create a separate rule (i.e. a line) for each ip address I > encounter in my ipset - bl**dy hell! OK, I may get away with it if I > could shove all the ip members into a cidr address, but that is one hell > of a workaround! Ah, well...u32 filters work by mask and compare on the contents of the protocol headers. Not possible to implement a range test directly using that technique. But you might look at the shorewall ''iprange'' command. It accepts a range as an argument and reduces that range to a list of CIDR addresses. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> But you might look at the shorewall ''iprange'' command. It accepts a > range as an argument and reduces that range to a list of CIDR addresses. >OK, I take it there is no error in this - I cannot use "10.1.1.0-10.1.1.255", but "10.1.1.0/24" is perfectly legitimate and will be accepted, right? I have no problems with port ranges as they seem to be accepted (either "1,2,3" or "1:3" is fine, it seems). You may be interested to know that I was "inspired" by that feature in shorewall (which was diabolical in the early versions as it was giving me *all* possible ranges instead of the "shortest" one available) to create a C program doing exactly that (much quicker and less resource-intensive). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 5:10 AM, Mr Dash Four wrote:> >> It depends on whether you have Shorewall-init installed. Since you >> aren''t beating on me about it''s shortcomings, I assume that you have not >> installed that package. >> > Hehe, I am not that bad! You are right, though, I don''t have it > installed - I just use shorewall. > >>> If I want to "cheat" (as I often do!) I could artificially "open" tun0, >>> start shorewall and then close that device. What would happen then (if >>> anything)? >>> >> >> Nothing, unless you are running Shorewall-init. >> > Maybe then shorewall shouldn''t place such restrictions in this case - > the device traffic shaping rules are "ignored" by shorewall if the > device in question is not "present" (or up) and if that doesn''t actually > matter (which I presumed was the case as I was able to "bypass" > shorewall completely and recreate those policies using iptables/tc > without the device being "present") this restriction should be removed. > > To "force" shorewall to apply my traffic shaping policies for this > device I currently have to run a separate program in rc.sysinit to bring > the tun0 device into existence (and up), then let shorewall do its work, > after which I close the device in rc.local. > > If there is no need for this restriction, then it should be removed.Let''s be clear about what Shorewall can and cannot do when a device is down (not an exhaustive list but it covers TC and policy routing). a) tcrules with the device specified in the DEST column *can* be applied. b) tcrules with the device specified in the SOURCE column *can* be applied *except* when the rule is in the POSTROUTING chain. That''s because iptables/netfilter doesn''t support -i in the POSTROUTING chain so Shorewall has to use the routing table to construct the corresponding -s list. c) tcdevices and tcclasses *cannot* be defined - tc/kernel restriction. d) Policy routing (providers file) *cannot* be defined - iproute/kernel restriction. So, contrary to your assertions, Shorewall does not impose capricious restrictions on such operations. These restrictions are, in fact, why shorewall-init was introduced. The general idea is this: a) You define these transient interfaces as ''optional'' in /etc/shorewall/interfaces. b) You install and configure shorewall-init. Shorewall-init installs ifup/ifdown scripts which are triggered each time that an interface goes up or down. When an ''optional'' interface goes up or down, a fast restart (/var/lib/shorewall/firewall restart) is done to adjust the configuration accordingly. There is also a ''required'' interface option. When a ''required'' interface comes up, an attempt is made to start the firewall (/var/lib/shorewall/firewall start). When a ''required'' interface goes down, the firewall is stopped (/var/lib/shorewall/firewall stop). /var/lib/shorewall/firewall is the script which performed the last successful start/restart operation. Running that script directly bypasses the complation phase. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> c) tcdevices and tcclasses *cannot* be defined - tc/kernel restriction. > > d) Policy routing (providers file) *cannot* be defined - iproute/kernel > restriction. >So what happens if the above is satisfied when shorewall executes and then that device disappears after shorewall does its job (i.e. I close that device as soon as shorewall completes)? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 7:39 AM, Mr Dash Four wrote:> >> c) tcdevices and tcclasses *cannot* be defined - tc/kernel restriction. >> >> d) Policy routing (providers file) *cannot* be defined - iproute/kernel >> restriction. >> > So what happens if the above is satisfied when shorewall executes and > then that device disappears after shorewall does its job (i.e. I close > that device as soon as shorewall completes)?The routes and routing rules that were added are automatically removed by the kernel. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> The routes and routing rules that were added are automatically removed > by the kernel. >But CLASSIFY and other such iptables statements defined as a result of tcclasses and tcrules stay, right? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 7:42 AM, Tom Eastep wrote:> On 5/9/11 7:39 AM, Mr Dash Four wrote: >> >>> c) tcdevices and tcclasses *cannot* be defined - tc/kernel restriction. >>> >>> d) Policy routing (providers file) *cannot* be defined - iproute/kernel >>> restriction. >>> >> So what happens if the above is satisfied when shorewall executes and >> then that device disappears after shorewall does its job (i.e. I close >> that device as soon as shorewall completes)? > > The routes and routing rules that were added are automatically removed > by the kernel. > > -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 7:56 AM, Mr Dash Four wrote:> >> But, of course, CLASSIFY and MARK rules are of no value without the >> related class. >> > I understand that - they would never produce a match unless the device > is up an running again and when that happens it is business as usual, > isn''t that so?Not unless the classes get re-added. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 8:02 AM, Mr Dash Four wrote:> >> Not unless the classes get re-added. >> > Bugger! So, I would need that device to stay open (i.e. UP) at all times > to preserve everything created by shorewall, is that it? What about if I > place it in up state, but do not give it a real IP address (yet)? >Without an IP address, there can be no routes out of the device. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> Bugger! So, I would need that device to stay open (i.e. UP) at all times >> to preserve everything created by shorewall, is that it? What about if I >> place it in up state, but do not give it a real IP address (yet)? >> >> > > Without an IP address, there can be no routes out of the device. >I am aware of that, but at least the tc classes will be preserved, right? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 8:08 AM, Mr Dash Four wrote:> >>> Bugger! So, I would need that device to stay open (i.e. UP) at all times >>> to preserve everything created by shorewall, is that it? What about if I >>> place it in up state, but do not give it a real IP address (yet)? >>> >>> >> >> Without an IP address, there can be no routes out of the device. >> > I am aware of that, but at least the tc classes will be preserved, right?Yes. TC can be defined for a device that has no IP address (think of port devices on a bridge). -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Yes. TC can be defined for a device that has no IP address (think of > port devices on a bridge). >OK, so the next time that device acquires a real IP address everything would be back to normal, I will start getting matches and the tc policy will be fully operational - I won''t have to do anything, right? ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 8:15 AM, Mr Dash Four wrote:> >> Yes. TC can be defined for a device that has no IP address (think of >> port devices on a bridge). >> > OK, so the next time that device acquires a real IP address everything > would be back to normal, I will start getting matches and the tc policy > will be fully operational - I won''t have to do anything, right? >Everything will be back to normal, unless you need policy routing out of the device (providers file). -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Everything will be back to normal, unless you need policy routing out of > the device (providers file). >I don''t use it - the tun0 device acquires its ip address upon connection (and adds 4 routing table entries which are deleted when the connection is closed). I take it then, everything I defined previously in terms of tcclasses, tcrules, tcfilters and the like will be fully operational, provided that device stayed in UP state and was open all along? The alternative, as you suggested, is to use shorewall-init, but I haven''t looked at it yet and I am not sure whether it is clever enough to reload the firewall and introduce only the policy(ies) for that particular device (rules entries, tcclasses, tcfilters, tcrules etc) and not reload the whole lot, which would be a bit of a waste really. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 8:36 AM, Mr Dash Four wrote:> >> Everything will be back to normal, unless you need policy routing out of >> the device (providers file). >> > I don''t use it - the tun0 device acquires its ip address upon connection > (and adds 4 routing table entries which are deleted when the connection > is closed). I take it then, everything I defined previously in terms of > tcclasses, tcrules, tcfilters and the like will be fully operational, > provided that device stayed in UP state and was open all along? > > The alternative, as you suggested, is to use shorewall-init, but I > haven''t looked at it yet and I am not sure whether it is clever enough > to reload the firewall and introduce only the policy(ies) for that > particular device (rules entries, tcclasses, tcfilters, tcrules etc) and > not reload the whole lot, which would be a bit of a waste really.As I have already described, shorewall-init executes this command: /var/lib/shorewall/firewall restart So it reloads "the whole lot". -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 9:20 AM, Tom Eastep wrote:> On 5/9/11 8:36 AM, Mr Dash Four wrote: >> >>> Everything will be back to normal, unless you need policy routing out of >>> the device (providers file). >>> >> I don''t use it - the tun0 device acquires its ip address upon connection >> (and adds 4 routing table entries which are deleted when the connection >> is closed). I take it then, everything I defined previously in terms of >> tcclasses, tcrules, tcfilters and the like will be fully operational, >> provided that device stayed in UP state and was open all along? >> >> The alternative, as you suggested, is to use shorewall-init, but I >> haven''t looked at it yet and I am not sure whether it is clever enough >> to reload the firewall and introduce only the policy(ies) for that >> particular device (rules entries, tcclasses, tcfilters, tcrules etc) and >> not reload the whole lot, which would be a bit of a waste really. > > As I have already described, shorewall-init executes this command: > > /var/lib/shorewall/firewall restart > > So it reloads "the whole lot".Actually, it executes /var/lib/shorewall/firewall {up|down} <interface> For optional interfaces, that is equivalent to /var/lib/shorewall/firewall restart For required interfaces, it is equivalent to /var/lib/shorewall/firewall {start|stop} -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
>> As I have already described, shorewall-init executes this command: >> >> /var/lib/shorewall/firewall restart >> >> So it reloads "the whole lot". >> > > Actually, it executes > > /var/lib/shorewall/firewall {up|down} <interface> > > For optional interfaces, that is equivalent to > > /var/lib/shorewall/firewall restart > > For required interfaces, it is equivalent to > > /var/lib/shorewall/firewall {start|stop} >I take it the bottom line is that everything is reloaded/restarted. It would have been better if it was possible to just reload the changes which truly affect the running of the firewall if that particular device goes up/down (you pointed out what these are in previous posts) and not just "reload everything". If that was possible I would have probably gone that way and use shorewall-init without bothering with rc.sysinit scripts and the like. I guess this must be complicated as there may be some interdependencies between various devices - can''t comment on that further as I am not really an expert in this and judge everything purely from a (selfish) user perspective. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 10:46 AM, Mr Dash Four wrote:> > > I take it the bottom line is that everything is reloaded/restarted.Yes.> It would have been better if it was possible to just reload the > changes which truly affect the running of the firewall if that > particular device goes up/down (you pointed out what these are in > previous posts) and not just "reload everything". If that was > possible I would have probably gone that way and use shorewall-init > without bothering with rc.sysinit scripts and the like. > > I guess this must be complicated as there may be some > interdependencies between various devices - can''t comment on that > further as I am not really an expert in this and judge everything > purely from a (selfish) user perspective.There are certainly dependencies among multiple interfaces in policy routing. And testing a ''just-enough'' implementation would be a lot of work. And given that restart (without compilation) is fast and non-disruptive, it seems like the right approach. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> And given that restart (without compilation) is fast and > non-disruptive, it seems like the right approach. >It isn''t in my case - I have init script running which loads some 30k+ subnets and addresses into ipsets (that runs on various machines ranging from lo-end ppc 604e to Core2 Duo on 3.1MHz), not to mention the various port ranges I am loading. Besides, if there is traffic currently on the other (unaffected) interfaces that would be disrupted if a restart/reload of shorewall is initiated. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 12:39 PM, Mr Dash Four wrote:> >> And given that restart (without compilation) is fast and >> non-disruptive, it seems like the right approach. >> > It isn''t in my case - I have init script running which loads some 30k+ > subnets and addresses into ipsets (that runs on various machines ranging > from lo-end ppc 604e to Core2 Duo on 3.1MHz), not to mention the various > port ranges I am loading.Aren''t you only doing that if $COMMAND = start?> Besides, if there is traffic currently on the > other (unaffected) interfaces that would be disrupted if a > restart/reload of shorewall is initiated.Shouldn''t be. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Aren''t you only doing that if $COMMAND = start? >Yeah, I have that, but it still gets executed if "reload" or "restart" is called upon as I see the loading of ipsets in the syslog (I customised that part of init to show me what''s happening).>> Besides, if there is traffic currently on the >> other (unaffected) interfaces that would be disrupted if a >> restart/reload of shorewall is initiated. >> > > Shouldn''t be. >Well, it resets all the rules, classes, counters etc, so this is bound to disrupt traffic on the unaffected interfaces. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 12:58 PM, Mr Dash Four wrote:> >> Aren''t you only doing that if $COMMAND = start? >> > Yeah, I have that, but it still gets executed if "reload" or "restart" > is called upon as I see the loading of ipsets in the syslog (I > customised that part of init to show me what''s happening).Does your customized init script execute stop/start for reload and restart? Because if you actually run /sbin/shorewall restart, $COMMAND will contain ''restart''.> >>> Besides, if there is traffic currently on the >>> other (unaffected) interfaces that would be disrupted if a >>> restart/reload of shorewall is initiated. >>> >> >> Shouldn''t be. >> > Well, it resets all the rules, classes, counters etc, so this is boundIt does not reset all rules. It uses iptables-restore which does an atomic ruleset swap of each Netfilter table. Resetting traffic shaping doesn''t disrupt the flow of traffic; it just makes it uncontrolled for a short interval. Clearing policy routing can cause traffic to be mis-routed momentarily but retries will allow sessions to recover without disconnects. And you aren''t using that feature. -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 \________________________________________________ ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
> Does your customized init script execute stop/start for reload and > restart? Because if you actually run /sbin/shorewall restart, $COMMAND > will contain ''restart''. >My bad! I have been replacing the shorewall init script since I can remember because the one supplied with shorewall is crap. As it turned out, it has "stop/start" in it instead of "restart" and that is what caused the whole thing. I will be packaging shorewall from source from now on so that I could patch the bits on the script supplied the way I want (and not just blindly copy an old script over).> It does not reset all rules. It uses iptables-restore which does an > atomic ruleset swap of each Netfilter table. Resetting traffic shaping > doesn''t disrupt the flow of traffic; it just makes it uncontrolled for a > short interval. > > Clearing policy routing can cause traffic to be mis-routed momentarily > but retries will allow sessions to recover without disconnects. And you > aren''t using that feature. >I have to investigate this a bit more carefully! Even though the restart is now much faster that is on a fast machine, on a slow one I have to see how it behaves when I try this on a low-end system - in terms of performance as well as resources it takes/uses. I also do not wish the traffic flow to be disrupted in any way (I am mostly worried about VOIP traffic, which is time-sensitive). ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
On 5/9/11 3:08 PM, Mr Dash Four wrote:> >> Does your customized init script execute stop/start for reload and >> restart? Because if you actually run /sbin/shorewall restart, $COMMAND >> will contain ''restart''. >> > My bad! I have been replacing the shorewall init script since I can > remember because the one supplied with shorewall is crap. As it turned > out, it has "stop/start" in it instead of "restart" and that is what > caused the whole thing. I will be packaging shorewall from source from > now on so that I could patch the bits on the script supplied the way I > want (and not just blindly copy an old script over).When you have it the way you want it, please send me a copy.>> > I have to investigate this a bit more carefully! Even though the restart > is now much faster that is on a fast machine, on a slow one I have to > see how it behaves when I try this on a low-end system - in terms of > performance as well as resources it takes/uses. I also do not wish the > traffic flow to be disrupted in any way (I am mostly worried about VOIP > traffic, which is time-sensitive).Yes -- that would be a valid concern. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
When I have this in my tcclasses: a:11 a:12 a:12:13 a:12:14 a:15 and then try to use class a:12 in any shape or form in tcrules, everything compiles just fine, shorewall reloads the new settings and then the entire network grinds to a screeching halt - nothing can go in or out. The same thing happens if a:12 is my default class. Using a:13, however, is fine. What could be the cause of this? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/12/2011 12:28 PM, Mr Dash Four wrote:> When I have this in my tcclasses: > > a:11 > a:12 > a:12:13 > a:12:14 > a:15 > > and then try to use class a:12 in any shape or form in tcrules, > everything compiles just fine, shorewall reloads the new settings and > then the entire network grinds to a screeching halt - nothing can go in > or out. The same thing happens if a:12 is my default class. Using a:13, > however, is fine. What could be the cause of this?I have a hunch that classifying to a parent class shouldn''t be allowed. What happens if you try to configure a tcfilter that classifies to a:12? -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> I have a hunch that classifying to a parent class shouldn''t be allowed. > What happens if you try to configure a tcfilter that classifies to a:12? >When I got this error I had a lot going on at the time, but from what I remember, after the numerous combinations I tried, was that at some stage I had a warning from shorewall (something about not using a class which is a parent or something) - that actually prompted me to re-adjust tcclasses and change tcrules to allocate that match to the first leaf child instead. I can''t be more specific though. I''ll try tcfilters with this and will let you know later on this evening. Yes, I agree, shorewall should pick this up and issue an error if this combination for some reason screws up the network completely, though I do not know why that is - the root class although can''t be involved in any matches in tcrules or tcfilters has a traffic happily passing through it. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/12/2011 02:10 PM, Mr Dash Four wrote:> >> I have a hunch that classifying to a parent class shouldn''t be allowed. >> What happens if you try to configure a tcfilter that classifies to a:12? >> > When I got this error I had a lot going on at the time, but from what I > remember, after the numerous combinations I tried, was that at some > stage I had a warning from shorewall (something about not using a class > which is a parent or something) - that actually prompted me to re-adjust > tcclasses and change tcrules to allocate that match to the first leaf > child instead. I can''t be more specific though.There is an error generated when a class with dmax and/or umax is specified and the class is used as a parent class.> > I''ll try tcfilters with this and will let you know later on this > evening. Yes, I agree, shorewall should pick this up and issue an error > if this combination for some reason screws up the network completely, > though I do not know why that is - the root class although can''t be > involved in any matches in tcrules or tcfilters has a traffic happily > passing through it.I have a two-line patch ready that rejects tcfilters and tcrules that spacify a non-leaf class. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
>> When I got this error I had a lot going on at the time, but from what I >> remember, after the numerous combinations I tried, was that at some >> stage I had a warning from shorewall (something about not using a class >> which is a parent or something) - that actually prompted me to re-adjust >> tcclasses and change tcrules to allocate that match to the first leaf >> child instead. I can''t be more specific though. >> > > There is an error generated when a class with dmax and/or umax is > specified and the class is used as a parent class. >Yeah! That was exactly it!> I have a two-line patch ready that rejects tcfilters and tcrules that > spacify a non-leaf class. >Small correction - when I have a non-leaf class (regardless of whether this is in tcrules or tcfilters) shorewall check/compile/reload/restart silently ignores this, but then there is never a match - tc as well as iptables just bypass this as if that class isn''t there. Even if I do "a:12 - - tcp" (either in tcrules or tcfilters) and use the tcp protocol, "shorewall show tc" shows me that a:12 had no matches (all counts are 0). When I select a:12 to be the default class, however, everything is again accepted by shorewall, but no network traffic is going in or out. So, yes, I think this should not be ignored by shorewall, but flagged as a warning if non-leaf class is used in either tcrules or tcfilters and issue an error if this class is specified as the default class in tcclasses. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/12/2011 03:36 PM, Mr Dash Four wrote:> >>> When I got this error I had a lot going on at the time, but from what I >>> remember, after the numerous combinations I tried, was that at some >>> stage I had a warning from shorewall (something about not using a class >>> which is a parent or something) - that actually prompted me to re-adjust >>> tcclasses and change tcrules to allocate that match to the first leaf >>> child instead. I can''t be more specific though. >>> >> >> There is an error generated when a class with dmax and/or umax is >> specified and the class is used as a parent class. >> > Yeah! That was exactly it! > >> I have a two-line patch ready that rejects tcfilters and tcrules that >> spacify a non-leaf class. >> > Small correction - when I have a non-leaf class (regardless of whether > this is in tcrules or tcfilters) shorewall check/compile/reload/restart > silently ignores this, but then there is never a match - tc as well as > iptables just bypass this as if that class isn''t there. Even if I do > "a:12 - - tcp" (either in tcrules or tcfilters) and use the tcp > protocol, "shorewall show tc" shows me that a:12 had no matches (all > counts are 0). > > When I select a:12 to be the default class, however, everything is again > accepted by shorewall, but no network traffic is going in or out. > > So, yes, I think this should not be ignored by shorewall, but flagged as > a warning if non-leaf class is used in either tcrules or tcfilters and > issue an error if this class is specified as the default class in tcclasses.Okay, thanks for testing. I''ll modify my patch as you suggest. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> Okay, thanks for testing. I''ll modify my patch as you suggest. >OK! One more query: On one of my machines I do SNAT. What source should I specify when using this in tcrules - the original IP address or the one I changed it to? In other words, what should I use: the "SOURCE" or the "ADDRESS" column (from the masq file) when creating rules in tcrules (also bearing in mind that I use classes and not marks)? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 12, 2011, at 4:23 PM, Mr Dash Four wrote:> >> Okay, thanks for testing. I''ll modify my patch as you suggest. >> > OK! One more query: On one of my machines I do SNAT. What source should > I specify when using this in tcrules - the original IP address or the > one I changed it to? In other words, what should I use: the "SOURCE" or > the "ADDRESS" column (from the masq file) when creating rules in tcrules > (also bearing in mind that I use classes and not marks)?There is no Netfilter hook called after the SOURCE address has been re-written by SNAT/MASQUERADE rules. So all netfilter rules must use the original SOURCE address. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
>> OK! One more query: On one of my machines I do SNAT. What source should >> I specify when using this in tcrules - the original IP address or the >> one I changed it to? In other words, what should I use: the "SOURCE" or >> the "ADDRESS" column (from the masq file) when creating rules in tcrules >> (also bearing in mind that I use classes and not marks)? >> > > There is no Netfilter hook called after the SOURCE address has been re-written by SNAT/MASQUERADE rules. So all netfilter rules must use the original SOURCE address. >Erm, I don''t quite understand this! The masquerading I use is to change the source address to "appear" as if it originated from another interface and then transmit packets over the wire using that interface. This has been working for years for me, though it wasn''t "traffic-shaped" properly. The problem I now have is how to classify it, because it originates on one interface and it is transmitted using another (with its source address changed). Here is an example with which I will try to illustrate this: eth0 is 10.1.1.12 and is on the 10.1.1.0/24 net eth1 is 10.1.2.7 and is on the 10.1.2.0/24 net Both interfaces are on the same machine. The stream I am interested in originates on 10.1.1.12 and is destined for the outside world, say to 212.58.254.251 port ranges from 1193 to 2193 via eth1 (10.1.2.7). So, I use the following statements in masq: "eth1::212.58.254.251 10.1.1.12 10.1.2.7 udp 1193:2193" and "eth1::212.58.254.251 10.1.1.12 10.1.2.7 tcp 1193:2193". Please note that the routing table is already altered in a way to correctly route this stream (as I pointed out - it has been working for me for years, though that traffic was not "shaped" properly). Also, the traffic is in both directions (hence the use of port ranges!), so I need to "shape" it using tcrules as well as tcfilters. Now, the problem I face is how do I classify this traffic? Should I create and use a class belonging to eth0 or eth1 given that the actual flow will *never* pass through eth0? In other words, do I use "eth0:12 - $FW 212.58.254.251 ...." or "eth1:12 - $FW 212.58.254.251 ...."? What about tcfilters - the traffic originating from 212.58.254.251 arrives at eth1:10.1.2.7, but is actually destined for 10.1.1.12 - do I use ifb0-related classes (assuming ifb0 is derived from eth0) or do I define classes using ifb1? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/13/2011 05:22 AM, Mr Dash Four wrote:> >>> OK! One more query: On one of my machines I do SNAT. What source >>> should I specify when using this in tcrules - the original IP >>> address or the one I changed it to? In other words, what should I >>> use: the "SOURCE" or the "ADDRESS" column (from the masq file) >>> when creating rules in tcrules (also bearing in mind that I use >>> classes and not marks)? >>> >> >> There is no Netfilter hook called after the SOURCE address has been >> re-written by SNAT/MASQUERADE rules. So all netfilter rules must >> use the original SOURCE address. >> > Erm, I don''t quite understand this! The masquerading I use is to > change the source address to "appear" as if it originated from > another interface and then transmit packets over the wire using that > interface. This has been working for years for me, though it wasn''t > "traffic-shaped" properly. The problem I now have is how to classify > it, because it originates on one interface and it is transmitted > using another (with its source address changed). Here is an example > with which I will try to illustrate this: > > eth0 is 10.1.1.12 and is on the 10.1.1.0/24 net eth1 is 10.1.2.7 and > is on the 10.1.2.0/24 net > > Both interfaces are on the same machine. The stream I am interested > in originates on 10.1.1.12 and is destined for the outside world, say > to 212.58.254.251 port ranges from 1193 to 2193 via eth1 (10.1.2.7).What do you mean by originates on 10.1.1.12? Do you mean that some host connected to 10.1.1.2 (say, 10.1.1.99) creates the packet? I''ll assume so.> So, I use the following statements in masq: > > "eth1::212.58.254.251 10.1.1.12 10.1.2.7 udp 1193:2193" and > "eth1::212.58.254.251 10.1.1.12 10.1.2.7 tcp 1193:2193". >Hmm -- If my assumption is correct, then you would need something like: eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 udp 1193:2193 eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 tcp 1193:2193> Please note that the routing table is already altered in a way to > correctly route this stream (as I pointed out - it has been working > for me for years, though that traffic was not "shaped" properly). > Also, the traffic is in both directions (hence the use of port > ranges!), so I need to "shape" it using tcrules as well as tcfilters. > > Now, the problem I face is how do I classify this traffic? Should I > create and use a class belonging to eth0 or eth1 given that the > actual flow will *never* pass through eth0? In other words, do I use > "eth0:12 - $FW 212.58.254.251 ...." or "eth1:12 - $FW 212.58.254.251 > ...."? > > What about tcfilters - the traffic originating from 212.58.254.251 > arrives at eth1:10.1.2.7, but is actually destined for 10.1.1.12 - do > I use ifb0-related classes (assuming ifb0 is derived from eth0) or do > I define classes using ifb1?As far as traffic shaping goes, outbound traffic will pass through ifb0 eth1 In both cases, the source IP will be 10.1.1.99 and the destination address will be 212.58.254.251. Inbound traffic will pass through ifb1 source IP will be 212.58.254.25 and dest IP will be 10.1.2.7. Destination port number may have been changed if it was a duplicate of another active proto/port pair. eth0 source IP will be 212.58.254.25 and dest IP will be 10.1.1.99 Now, if you really mean that an application on the Shorewall box binds its inet socket to 10.1.1.12 and connects/sends to 212.58.254.25, then outbound traffic will not go through ifb0 and inbound traffic will not go through eth0. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/13/2011 06:20 AM, Tom Eastep wrote:> > > What do you mean by originates on 10.1.1.12? Do you mean that some host > connected to 10.1.1.2 (say, 10.1.1.99) creates the packet? I''ll assume so.-------- s/b 10.1.1.12 -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
>> Erm, I don''t quite understand this! The masquerading I use is to >> change the source address to "appear" as if it originated from >> another interface and then transmit packets over the wire using that >> interface. This has been working for years for me, though it wasn''t >> "traffic-shaped" properly. The problem I now have is how to classify >> it, because it originates on one interface and it is transmitted >> using another (with its source address changed). Here is an example >> with which I will try to illustrate this: >> >> eth0 is 10.1.1.12 and is on the 10.1.1.0/24 net eth1 is 10.1.2.7 and >> is on the 10.1.2.0/24 net >> >> Both interfaces are on the same machine. The stream I am interested >> in originates on 10.1.1.12 and is destined for the outside world, say >> to 212.58.254.251 port ranges from 1193 to 2193 via eth1 (10.1.2.7). >> > > What do you mean by originates on 10.1.1.12? Do you mean that some host > connected to 10.1.1.2 (say, 10.1.1.99) creates the packet? I''ll assume so. >No! As I pointed above, the machine in question has two interfaces - eth0 with ip address 10.1.1.12 (which is part of the 10.1.1.0/24 internal subnet) and another interface - eth1 - with ip address 10.1.2.7 (which is part of a separate subnet - 10.1.2.0/24). The traffic originates on eth0 - it is created by a program, which listens on that address - "10.1.1.12:*" and that program hooks/uses port ranges 1193 to 2193. When it sends traffic destined to, say, 212.58.254.251 using the same destination port ranges (1193-2193) that traffic gets SNATed and routed through eth1 on 10.1.2.7. In other words after SNAT is done it "appears" as if it comes from 10.1.2.7.>> So, I use the following statements in masq: >> >> "eth1::212.58.254.251 10.1.1.12 10.1.2.7 udp 1193:2193" and >> "eth1::212.58.254.251 10.1.1.12 10.1.2.7 tcp 1193:2193". >> >> > > Hmm -- If my assumption is correct, then you would need something like: > > eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 udp 1193:2193 > eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 tcp 1193:2193 >No! I only need traffic originating on eth0 with that single ip address - 10.1.1.12 to be SNATed to 10.1.2.7. The rest of the traffic to/from 10.1.1.0/24 is left intact and is processed in the usual manner.>> Please note that the routing table is already altered in a way to >> correctly route this stream (as I pointed out - it has been working >> for me for years, though that traffic was not "shaped" properly). >> Also, the traffic is in both directions (hence the use of port >> ranges!), so I need to "shape" it using tcrules as well as tcfilters. >> >> Now, the problem I face is how do I classify this traffic? Should I >> create and use a class belonging to eth0 or eth1 given that the >> actual flow will *never* pass through eth0? In other words, do I use >> "eth0:12 - $FW 212.58.254.251 ...." or "eth1:12 - $FW 212.58.254.251 >> ...."? >> >> What about tcfilters - the traffic originating from 212.58.254.251 >> arrives at eth1:10.1.2.7, but is actually destined for 10.1.1.12 - do >> I use ifb0-related classes (assuming ifb0 is derived from eth0) or do >> I define classes using ifb1? >> > > As far as traffic shaping goes, outbound traffic will pass through > > ifb0 eth1 > > In both cases, the source IP will be 10.1.1.99 and the destination > address will be 212.58.254.251. >I don''t see where ifb0 comes from except in inbound traffic (may be) - it is never involved as I think the traffic flow goes like this: (outbound) eth0 -> SNAT -> eth1 -> 212.58.254.251 and (inbound) 212.58.254.251 -> ifb1 -> (SNAT "return "leg") -> ifb0> Inbound traffic will pass through > > ifb1 source IP will be 212.58.254.25 and dest IP will be > 10.1.2.7. Destination port number may have been changed > if it was a duplicate of another active proto/port pair. > > eth0 source IP will be 212.58.254.25 and dest IP will be > 10.1.1.99 > >Nope! I don''t use 10.1.1.99 at all.> Now, if you really mean that an application on the Shorewall box binds > its inet socket to 10.1.1.12 and connects/sends to 212.58.254.25, then > outbound traffic will not go through ifb0 and inbound traffic will not > go through eth0. >That is exactly what I have! So, do I have this then: (outbound) eth0 -> 212.58.254.251, but passing through eth1 and (inbound) 212.58.254.251 -> ifb0, but passing through ifb1? If so, which classes should I use for the purpose of defining my traffic shaping? The other "unknown" for me is, assuming I need to use eth0 class for outbound traffic, that presumably needs to be accounted for from the eth0 quota and that would be wrong, I think, as that traffic *never* actually passes through eth0 at all as it is SNATed and actually goes via eth1, isn''t it? A similar point I think is valid for inbound traffic as well - do I use ifb0 or ifb1 classes to "capture" this traffic in tcfilters? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/13/2011 07:31 AM, Mr Dash Four wrote:> That is exactly what I have! > > So, do I have this then: (outbound) eth0 -> 212.58.254.251, but passing > through eth1 and (inbound) 212.58.254.251 -> ifb0, but passing through > ifb1? If so, which classes should I use for the purpose of defining my > traffic shaping?No -- eth1 and ifb1 are the *only* interfaces involved when 10.1.1.12 communicates with 212.58.254.251. eth0 and ifb0 are *not* involved.> > The other "unknown" for me is, assuming I need to use eth0 class for > outbound traffic, that presumably needs to be accounted for from the > eth0 quota and that would be wrong, I think, as that traffic *never* > actually passes through eth0 at all as it is SNATed and actually goes > via eth1, isn''t it?In tcrules for eth0, the source IP is 10.1.1.12 and the dest IP is 212.58.254.251. For tcfilters for ifb0, the source IP is 212.58.254.251 and the dest IP is 10.1.2.7. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> No -- eth1 and ifb1 are the *only* interfaces involved when 10.1.1.12 > communicates with 212.58.254.251. eth0 and ifb0 are *not* involved. > > [...] > > In tcrules for eth0, the source IP is 10.1.1.12 and the dest IP is > 212.58.254.251. > > For tcfilters for ifb0, the source IP is 212.58.254.251 and the dest IP > is 10.1.2.7. >So, in other words, even though only eth1 and ifb1 are involved I have to use eth0 class in tcrules (out of eth0''s quota!) and ifb0 class in tcfilters (out of ifb0''s quota) to capture and "shape" traffic even though neither interfaces take part in the net flow, is that right? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/13/2011 08:13 AM, Mr Dash Four wrote:> >> No -- eth1 and ifb1 are the *only* interfaces involved when 10.1.1.12 >> communicates with 212.58.254.251. eth0 and ifb0 are *not* involved. >> >> [...] >> >> In tcrules for eth0, the source IP is 10.1.1.12 and the dest IP is >> 212.58.254.251. >> >> For tcfilters for ifb0, the source IP is 212.58.254.251 and the dest IP >> is 10.1.2.7. >> > So, in other words, even though only eth1 and ifb1 are involved I have > to use eth0 class in tcrules (out of eth0''s quota!) and ifb0 class in > tcfilters (out of ifb0''s quota) to capture and "shape" traffic even > though neither interfaces take part in the net flow, is that right?eth0 and ifb0 are not involved and you need no eth0/ifb0 tcrules/tcfilters for 10.1.1.12<->212.58.254.251 communication. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
>>> No -- eth1 and ifb1 are the *only* interfaces involved when 10.1.1.12 >>> communicates with 212.58.254.251. eth0 and ifb0 are *not* involved. >>> >>> [...] >>> >>> In tcrules for eth0, the source IP is 10.1.1.12 and the dest IP is >>> 212.58.254.251. >>> >>> For tcfilters for ifb0, the source IP is 212.58.254.251 and the dest IP >>> is 10.1.2.7. >>> >>> >> So, in other words, even though only eth1 and ifb1 are involved I have >> to use eth0 class in tcrules (out of eth0''s quota!) and ifb0 class in >> tcfilters (out of ifb0''s quota) to capture and "shape" traffic even >> though neither interfaces take part in the net flow, is that right? >> > > eth0 and ifb0 are not involved and you need no eth0/ifb0 > tcrules/tcfilters for 10.1.1.12<->212.58.254.251 communication. >Ah, OK! I am glad that has been clarified as otherwise it didn''t make sense at all! So, for outbound communication between eth0:10.1.1.12 (which is SNATed to eth1:10.1.2.7) I should use "eth1:12 ..." class in tcrules and for inbound "ifb1:12 ..." in tcfilters then, is that right? ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 13, 2011, at 8:57 AM, Mr Dash Four wrote:> >>>> No -- eth1 and ifb1 are the *only* interfaces involved when 10.1.1.12 >>>> communicates with 212.58.254.251. eth0 and ifb0 are *not* involved. >>>> >>>> [...] >>>> In tcrules for eth0, the source IP is 10.1.1.12 and the dest IP is >>>> 212.58.254.251. >>>> >>>> For tcfilters for ifb0, the source IP is 212.58.254.251 and the dest IP >>>> is 10.1.2.7. >>>> >>> So, in other words, even though only eth1 and ifb1 are involved I have to use eth0 class in tcrules (out of eth0''s quota!) and ifb0 class in tcfilters (out of ifb0''s quota) to capture and "shape" traffic even though neither interfaces take part in the net flow, is that right? >>> >> >> eth0 and ifb0 are not involved and you need no eth0/ifb0 >> tcrules/tcfilters for 10.1.1.12<->212.58.254.251 communication. >> > Ah, OK! I am glad that has been clarified as otherwise it didn''t make sense at all! > > So, for outbound communication between eth0:10.1.1.12 (which is SNATed to eth1:10.1.2.7) I should use "eth1:12 ..." class in tcrules and for inbound "ifb1:12 ..." in tcfilters then, is that right?Assumeing that class 12 is the correct one, yes. Just keep in mind that the source IP for eth1:12 will be 10.1.1.12 where as on ifb1:12, the destination IP will be 10.1.2.7 (the two are not symmetric). -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> Assumeing that class 12 is the correct one, yes. > > Just keep in mind that the source IP for eth1:12 will be 10.1.1.12 where as on ifb1:12, the destination IP will be 10.1.2.7 (the two are not symmetric). >Thanks! Good point about the asymmetric nature of the flow too - I am not using DNAT, so it makes perfect sense the destination address to be the one of the eth1 interface. I will be implementing a quick test over the weekend anyway, to verify all this, so if there is something odd/wrong/I don''t like etc. I am sure you will read it in here. I also hope the test I will be performing won''t turn the same way as it did with my network latency test though! ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/13/2011 11:13 AM, Mr Dash Four wrote:> >> Assumeing that class 12 is the correct one, yes. >> >> Just keep in mind that the source IP for eth1:12 will be 10.1.1.12 >> where as on ifb1:12, the destination IP will be 10.1.2.7 (the two are >> not symmetric). >> > Thanks! Good point about the asymmetric nature of the flow too - I am > not using DNAT, so it makes perfect sense the destination address to be > the one of the eth1 interface.tcfilters always work with packets as they appear "on the wire". So the packets seen on ifb1 would be the same with or without DNAT. tcrules always work with packets before SNAT is applied. Hence, the asymmetry. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> tcfilters always work with packets as they appear "on the wire". So the > packets seen on ifb1 would be the same with or without DNAT. tcrules > always work with packets before SNAT is applied. Hence, the asymmetry. >Well, the good news is that SNATed traffic shaping works as advertised! Another bit of good news is that as a result of my new traffic shaping polic(ies) my network is absolutely flying! Upgrading to the new iproute2 package as well as iptables (1.4.10), which I compiled all from source and optimised for my systems, had a massive effect on the speed of it all! Now, for the annoying bits: 1. tcfilters ba:25 - - all (ba is on ifb0) Passes compilation, but then I get this: RTNETLINK answers: Invalid argument We have an error talking to the kernel ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 flowid ba:25" Failed 2. tcrules bb:12 $FW +[mickey-mouse,ip-port] tcp "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of ipsets. 3. tcfilters ba:12 212.... - tcp 17001 1193:2193 The above has absolutely *no* chance on gods green Earth to produce a match - EVER! Unless the destination IP address is also specified, that is! I don''t know why that is, but if it is some sort of misconfiguration error then I should at least be given a warning. In relation to this, I have another query: I found out that this "requirement" for specifying a destination ip address is only valid when I have selected the source ip address as well. If I have a tcfilters statement which matches on just the port part (source and/or destination ports) then it all seems fine and matches are produced. I have no idea why that is! If I have to specify a destination ip address/range when I filter on the source address what would happen if I use a device which may change its ip address regularly (dhcp, tunX to name a few possibilities) - do I have to then reload/restart shorewall every time that happens? 4. dmax values When I have dmax=375ms the resulting flow (as seen with shorewall show tc ethX/ifbX) is set as 75ms. In other places where I have dmax=100ms the actual value is 0 - it looks as though the first digit of what I specified in tcclasses seems to be "eaten up" by shorewall. 5. Not a bug, just a query: When I have not specified umax shorewall/tc assumes some spectacularly wrong values - I had anything ranging from 2500b to 20000b! Why is that and how can this be corrected? Finally, I attach my "bog-standard" shorewall startup script (the one which sits in /etc/init.d) which I use on all my machines - it is much better version than the one supplied with the shorewall rpm. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 14, 2011, at 6:20 PM, Mr Dash Four wrote:> >> tcfilters always work with packets as they appear "on the wire". So the >> packets seen on ifb1 would be the same with or without DNAT. tcrules >> always work with packets before SNAT is applied. Hence, the asymmetry. >> > Well, the good news is that SNATed traffic shaping works as advertised! Another bit of good news is that as a result of my new traffic shaping polic(ies) my network is absolutely flying! Upgrading to the new iproute2 package as well as iptables (1.4.10), which I compiled all from source and optimised for my systems, had a massive effect on the speed of it all! > > Now, for the annoying bits: > > 1. > tcfilters > ba:25 - - all > (ba is on ifb0) > > Passes compilation, but then I get this: > > RTNETLINK answers: Invalid argument > We have an error talking to the kernel > ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 flowid ba:25" FailedThis is not enough information to understand the problem. Please include a tarball of /etc/shorewall (with capabilities file) so that I can reproduce the problem. Thanks.> > 2. > tcrules > bb:12 $FW +[mickey-mouse,ip-port] tcp > > "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of insets.Shorewall hasn''t, doesn''t and won''t verify the existence of ipsets. Shorewall rulesets can be compiled on one system and executed on another system running shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and load ipsets that don''t exist before the script runs. I''m sure that if the Shorewall compiler generated a compile-time error or warning message about a missing ipset, you would be on this list pointing out how stupid the product is.> > 3. > tcfilters > ba:12 212.... - tcp 17001 1193:2193 > > The above has absolutely *no* chance on gods green Earth to produce a match - EVER! Unless the destination IP address is also specified, that is! I don''t know why that is, but if it is some sort of misconfiguration error then I should at least be given a warning.Why could no packet ever match that? Is there an RFC that prohibits sending TCP packets to address 212.., port 17001 when the source port is in the range 1193:2193? If so, I am not familiar with it.> > In relation to this, I have another query: I found out that this "requirement" for specifying a destination ip address is only valid when I have selected the source ip address as well. If I have a tcfilters statement which matches on just the port part (source and/or destination ports) then it all seems fine and matches are produced. I have no idea why that is! > > If I have to specify a destination ip address/range when I filter on the source address what would happen if I use a device which may change its ip address regularly (dhcp, tunX to name a few possibilities) - do I have to then reload/restart shorewall every time that happens?I''m sorry. I have no idea what you are talking about. Are you suggesting that the generated ''tc filter add'' command is malformed? Are you getting confusing error messages? ???> > 4. dmax values > When I have dmax=375ms the resulting flow (as seen with shorewall show tc ethX/ifbX) is set as 75ms. In other places where I have dmax=100ms the actual value is 0 - it looks as though the first digit of what I specified in tcclasses seems to be "eaten up" by shorewall.Have you confirmed that Shorewall is doing the truncation? My reading of the code indicates that Shorewall doesn''t alter the user-supplied value.> > 5. Not a bug, just a query: When I have not specified umax shorewall/tc assumes some spectacularly wrong values - I had anything ranging from 2500b to 20000b! Why is that and how can this be corrected?Why do you believe that Shorewall is supplying this value? Have you generated a script that includes this ''spectacularly wrong'' value''? Possibly Shorewall should raise an error if dmax isn''t specified on a leaf HSFC class?> > Finally, I attach my "bog-standard" shorewall startup script (the one which sits in /etc/init.d) which I use on all my machines - it is much better version than the one supplied with the shorewall rpm.Thanks. My comments regarding the init script.f a) It sources /etc/rc.d/init.d/functions which is not available in all distros. b) As near as I can tell, the script''s principal functional difference involves logging. The standard init script handles logging through the STARTUP_LOG and LOG_VERBOSITY settings in /etc/shorewall/shorewall.conf. And those settings also cause logging when /sbin/shorewall is run directly. c) Contrary to your interpretation, ''restart'' is not ''stop'' followed by ''start''. It is rather a minimally-intrusive operation that conditionally compiles (based on the -f option) and reloads the configuration. It is much closer to ''start'' than it is to ''stop'' followed by ''start''. d) Your script unconditionally uses a lockfile. Not all distributions use/support them. So, while it works for you on Fedora, I''ll stick with my version. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
>> 1. >> tcfilters >> ba:25 - - all >> (ba is on ifb0) >> >> Passes compilation, but then I get this: >> >> RTNETLINK answers: Invalid argument >> We have an error talking to the kernel >> ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 flowid ba:25" Failed >> > > > This is not enough information to understand the problem. Please include a tarball of /etc/shorewall (with capabilities file) so that I can reproduce the problem. Thanks. >The class in question is created on ifbX device. The statement I included above is from tcfilters - it lists nothing specific in terms of source and destination (address or subnet) and the protocol is specified as "all". That passes check/compilation, but gives the error I indicated above when shorewall (tries to) restart/reload. If you bother to try it out my guess is that you will run into the same error.>> 2. >> tcrules >> bb:12 $FW +[mickey-mouse,ip-port] tcp >> >> "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of insets. >> > > Shorewall hasn''t, doesn''t and won''t verify the existence of ipsets. Shorewall rulesets can be compiled on one system and executed on another system running shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and load ipsets that don''t exist before the script runs. I''m sure that if the Shorewall compiler generated a compile-time error or warning message about a missing ipset, you would be on this list pointing out how stupid the product is. >And you know this how exactly? I wasn''t aware that you became Mystic bloody Meg all of a sudden!>> 3. >> tcfilters >> ba:12 212.... - tcp 17001 1193:2193 >> >> The above has absolutely *no* chance on gods green Earth to produce a match - EVER! Unless the destination IP address is also specified, that is! I don''t know why that is, but if it is some sort of misconfiguration error then I should at least be given a warning. >> > > Why could no packet ever match that? Is there an RFC that prohibits sending TCP packets to address 212.., port 17001 when the source port is in the range 1193:2193? If so, I am not familiar with it. >Try it out and see if you are ever going to get any matches! My guess is that you won''t!>> In relation to this, I have another query: I found out that this "requirement" for specifying a destination ip address is only valid when I have selected the source ip address as well. If I have a tcfilters statement which matches on just the port part (source and/or destination ports) then it all seems fine and matches are produced. I have no idea why that is! >> >> If I have to specify a destination ip address/range when I filter on the source address what would happen if I use a device which may change its ip address regularly (dhcp, tunX to name a few possibilities) - do I have to then reload/restart shorewall every time that happens? >> > > I''m sorry. I have no idea what you are talking about. Are you suggesting that the generated ''tc filter add'' command is malformed? Are you getting confusing error messages? ??? >My query was in relation to the above "requirement" (if it is indeed a requirement) for specifying a destination IP address in tcfilters (for ifbX classes) in order to get a match - if that is indeed the case this would pose difficulties with devices which change their IP address frequently (say if ethX is relying on dhcp or a tunX device is used and ifbX is derived from these devices) as in order to get a match I have to change the destination address in tcfilters and restart/reload shorewall every time that happens. Is it clearer for you now or would you like me to explain it in another - different - way for you?>> 4. dmax values >> When I have dmax=375ms the resulting flow (as seen with shorewall show tc ethX/ifbX) is set as 75ms. In other places where I have dmax=100ms the actual value is 0 - it looks as though the first digit of what I specified in tcclasses seems to be "eaten up" by shorewall. >> > > Have you confirmed that Shorewall is doing the truncation? My reading of the code indicates that Shorewall doesn''t alter the user-supplied value. >How do I confirm that? I have specified 100ms and 375ms in my tcclasses and when I run "shorewall show tc <device>" I see 0 and 75ms respectively, so I do not know what else might have truncated these values apart from shorewall? If you know, please do elaborate!>> 5. Not a bug, just a query: When I have not specified umax shorewall/tc assumes some spectacularly wrong values - I had anything ranging from 2500b to 20000b! Why is that and how can this be corrected? >> > > Why do you believe that Shorewall is supplying this value? Have you generated a script that includes this ''spectacularly wrong'' value''? Possibly Shorewall should raise an error if dmax isn''t specified on a leaf HSFC class? >I have no idea who specifies what as I am not intimately involved with the development of shorewall to know its internal routines and peculiarities. The classes in question have no specific dmax and umax values set (though the bandwidth available to them is quite a lot I have to admit) so when I look at these with "shorewall show tc <device>" I see them as they appear on my screen. As I pointed out above, they differ very wildly. Why is that? I have always assumed that if umax is not specified the default value would be taken from the MTU value of the device this class relates to, but, evidently, this is not the case here and I wonder why that is?> a) It sources /etc/rc.d/init.d/functions which is not available in all distros. >This is available in all Fedora versions, which is what I use here.> c) Contrary to your interpretation, ''restart'' is not ''stop'' followed by ''start''. It is rather a minimally-intrusive operation that conditionally compiles (based on the -f option) and reloads the configuration. It is much closer to ''start'' than it is to ''stop'' followed by ''start''. >This is what I have amended a while ago - the script I attached is a mixture of the standard script supplied by Fedora distribution of the shorewall package, the script supplied with your own rpm and I have made a few changes myself on top of everything else.> d) Your script unconditionally uses a lockfile. Not all distributions use/support them. >I am not and have never pretended that the script I attached could be used in "all distributions" - you asked a while ago to see my script and I attached it. If you still wish to distribute rpms with the most-common denominator shorewall script which has crappy functionality, but "runs on all distros" then I won''t try to stop you, I''ll just patch it up with my additions/changes (as I started doing recently) and compile the shorewall package from source disregarding the Tom Eastep-distributed rpm completely.> So, while it works for you on Fedora, I''ll stick with my version. >This is your prerogative, of course. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/15/2011 05:51 AM, Mr Dash Four wrote:> >>> 1. >>> tcfilters >>> ba:25 - - all >>> (ba is on ifb0) >>> >>> Passes compilation, but then I get this: >>> >>> RTNETLINK answers: Invalid argument >>> We have an error talking to the kernel >>> ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 flowid ba:25" Failed >>> >> >> >> This is not enough information to understand the problem. Please include a tarball of /etc/shorewall (with capabilities file) so that I can reproduce the problem. Thanks. >> > The class in question is created on ifbX device. The statement I > included above is from tcfilters - it lists nothing specific in terms of > source and destination (address or subnet) and the protocol is specified > as "all". That passes check/compilation, but gives the error I indicated > above when shorewall (tries to) restart/reload. If you bother to try it > out my guess is that you will run into the same error.It would have been helpful to simply point out that any degenerate tcfilter produces this result. I''ve reproduced the problem and the attached patch ignores such tcfulters with a warning.> > >>> 2. >>> tcrules >>> bb:12 $FW +[mickey-mouse,ip-port] tcp >>> >>> "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of insets. >>> >> >> Shorewall hasn''t, doesn''t and won''t verify the existence of ipsets. Shorewall rulesets can be compiled on one system and executed on another system running shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and load ipsets that don''t exist before the script runs. I''m sure that if the Shorewall compiler generated a compile-time error or warning message about a missing ipset, you would be on this list pointing out how stupid the product is. >> > And you know this how exactly? I wasn''t aware that you became Mystic > bloody Meg all of a sudden!Your track record speaks for itself.> > >>> 3. >>> tcfilters >>> ba:12 212.... - tcp 17001 1193:2193 >>> >>> The above has absolutely *no* chance on gods green Earth to produce a match - EVER! Unless the destination IP address is also specified, that is! I don''t know why that is, but if it is some sort of misconfiguration error then I should at least be given a warning. >>> >> >> Why could no packet ever match that? Is there an RFC that prohibits sending TCP packets to address 212.., port 17001 when the source port is in the range 1193:2193? If so, I am not familiar with it. >> > Try it out and see if you are ever going to get any matches! My guess is > that you won''t!Works fine for me: tcdevices: ba:ifb0 - 1000mbit hfsc,classify eth2 tcclasses: ba:25 - 500mbit:50ms full 1 default tcfilter: ba:25 172.20.1.146 - all I pinged this host from 172.20.1.146 and: Device ifb0: filter parent ba: protocol ip pref 10 u32 filter parent ba: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent ba: protocol ip pref 10 u32 fh 800::800 order 2048 key ht filter parent ba: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid ba:25 (rule hit 29 success 9) match ac140192/ffffffff at 12 (success 9 ) ---------->>> 4. dmax values >>> When I have dmax=375ms the resulting flow (as seen with >>> shorewallshow tc ethX/ifbX) is set as 75ms. In other places where I have dmax=100ms the actual value is 0 - it looks as though the first digit of what I specified in tcclasses seems to be "eaten up" by shorewall.>>> >> >> Have you confirmed that Shorewall is doing the truncation? My >> reading of the code indicates that Shorewall doesn''t alter the user-supplied value. >> > How do I confirm that? I have specified 100ms and 375ms in my tcclasses > and when I run "shorewall show tc <device>" I see 0 and 75ms > respectively, so I do not know what else might have truncated these > values apart from shorewall? If you know, please do elaborate!I changed the tcclasses entry to this: tcclasses: ba:25 - 500mbit:350ms full 1 default And the compiler emits this command (which you can find by looking at the /var/lib/shorewall/firewall file after a successful start/restart or compile command). tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax ${ifb0_mtu}b dmax 350ms rate 500000kbit ul rate 1000000kbit ----------> >>> 5. Not a bug, just a query: When I have not specified umaxshorewall/tc assumes some spectacularly wrong values - I had anything ranging from 2500b to 20000b! Why is that and how can this be corrected?>> >> Why do you believe that Shorewall is supplying this value? Have >> you generated a script that includes this ''spectacularly wrong'' value''? >> > I have no idea who specifies what as I am not intimately involved with > the development of shorewall to know its internal routines and > peculiarities. The classes in question have no specific dmax and umax > values set (though the bandwidth available to them is quite a lot I have > to admit) so when I look at these with "shorewall show tc <device>" I > see them as they appear on my screen. As I pointed out above, they > differ very wildly. Why is that? I have always assumed that if umax is > not specified the default value would be taken from the MTU value of the > device this class relates to, but, evidently, this is not the case here > and I wonder why that is?I had originally mis-read your post and thought that it was dmax that was not supplied. Shorewall does supply the mtu as umax if it is omitted. From the above tcclass, the actual command executed is: tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax 1500b dmax ---------- 350ms rate 500000kbit ul rate 1000000kbit You can see what ''tc class add'' commands Shorewall is executing by: /var/lib/shorewall/firewall trace restart 2> trace fgrep ''class add'' trace -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 14, 2011, at 9:14 PM, Tom Eastep wrote:>> >> 2. >> tcrules >> bb:12 $FW +[mickey-mouse,ip-port] tcp >> >> "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of insets. > > Shorewall hasn''t, doesn''t and won''t verify the existence of ipsets. Shorewall rulesets can be compiled on one system and executed on another system running shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and load ipsets that don''t exist before the script runs. I''m sure that if the Shorewall compiler generated a compile-time error or warning message about a missing ipset, you would be on this list pointing out how stupid the product is.After thinking about this some more, it seems reasonable to issue a WARNING if: a) The compiler is being run by root (The ''inset'' program requires that). b) The compilation is not generating a script to be run on a remote system. c) A named ipset does not exist on the local system. Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 15, 2011, at 11:59 AM, Tom Eastep wrote:> > On May 14, 2011, at 9:14 PM, Tom Eastep wrote: >>> >>> 2. >>> tcrules >>> bb:12 $FW +[mickey-mouse,ip-port] tcp >>> >>> "shorewall check/compile" passes, but it fails when shorewall reload/restart is executed with "...Set mickey-mouse doesn''t exist.". In other words, shorewall don''t capture this error. I am not sure whether shorewall used to capture this before - i.e. the (non)existence of insets. >> >> Shorewall hasn''t, doesn''t and won''t verify the existence of ipsets. Shorewall rulesets can be compiled on one system and executed on another system running shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and load ipsets that don''t exist before the script runs. I''m sure that if the Shorewall compiler generated a compile-time error or warning message about a missing ipset, you would be on this list pointing out how stupid the product is. > > After thinking about this some more, it seems reasonable to issue a WARNING if: > > a) The compiler is being run by root (The ''inset'' program requires that)....''ipset''. Seems like I always want to type ''inset''. -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 \________________________________________________ ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
> It would have been helpful to simply point out that any degenerate > tcfilter produces this result. I''ve reproduced the problem and the > attached patch ignores such tcfulters with a warning. >I had no idea that would be the case. Anyway, the attached patch works.> I had originally mis-read your post and thought that it was dmax that > was not supplied. Shorewall does supply the mtu as umax if it is > omitted. From the above tcclass, the actual command executed is: > > tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax 1500b dmax > ---------- > 350ms rate 500000kbit ul rate 1000000kbit > > You can see what ''tc class add'' commands Shorewall is executing by: > > /var/lib/shorewall/firewall trace restart 2> trace > fgrep ''class add'' trace >OK, I used the (grand-calculation) example I started in the hfsc thread. To recap, this is what I had, according to my calculations: a:11 - 10*full/100 20*full/100 1 tcp-ack a:18 - 80*full/100 full 9 default a:13 - 320kbit 320kbit 2 a:13:14 - 120kbit:60ms:1500b full 2 a:13:15 - 80kbit:100ms:1500b full 3 a:13:16 - 80kbit:224ms:1500b full 4 a:13:17 - 40kbit:374ms:1500b full 5 "a" is eth0, the speed of which is capped at 100mbit in tcdevices (it can go up to 1gbit, but I am placing the cap intentionally here). So, this is the output from shorewall show tc eth0: Shorewall 4.4.19.3 Traffic Control at test1.my.net - Tue May 17 23:32:56 BST 2011 Device eth0: qdisc hfsc a: root refcnt 2 default 18 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq ff: parent a:11 limit 127p quantum 2500b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq 100: parent a:14 limit 127p quantum 1500b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq 101: parent a:15 limit 127p quantum 1500b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq 102: parent a:16 limit 127p quantum 1500b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq 103: parent a:17 limit 127p quantum 1500b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc sfq 104: parent a:18 limit 127p quantum 20000b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc ingress ffff: parent ffff:fff1 ---------------- Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 class hfsc a:11 parent a:1 leaf ff: sc m1 0bit d 0us m2 10000Kbit ul m1 0bit d 0us m2 20000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 class hfsc a: root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 3 class hfsc a:1 parent a: sc m1 0bit d 0us m2 100000Kbit ul m1 0bit d 0us m2 100000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 2 class hfsc a:13 parent a:1 sc m1 0bit d 0us m2 320000bit ul m1 0bit d 0us m2 320000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 1 class hfsc a:15 parent a:13 leaf 101: sc m1 120000bit d 100.0ms m2 80000bit ul m1 0bit d 0us m2 320000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 class hfsc a:14 parent a:13 leaf 100: sc m1 200000bit d 60.0ms m2 120000bit ul m1 0bit d 0us m2 320000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 class hfsc a:17 parent a:13 leaf 103: sc m1 0bit d 74.0ms m2 40000bit ul m1 0bit d 0us m2 320000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 class hfsc a:16 parent a:13 leaf 102: sc m1 0bit d 74.0ms m2 80000bit ul m1 0bit d 0us m2 320000bit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 class hfsc a:18 parent a:1 leaf 104: sc m1 0bit d 0us m2 80000Kbit ul m1 0bit d 0us m2 100000Kbit Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 period 0 level 0 So, for the parts I haven''t got a clue as to why they are set as they are: qdisc sfq ff: parent a:11 limit 127p quantum 2500b flows 127/1024 perturb 10sec <---- Why 2500b? Where does that come from? qdisc sfq 104: parent a:18 limit 127p quantum 20000b flows 127/1024 perturb 10sec <-- Same as above... class hfsc a:17 parent a:13 leaf 103: sc m1 0bit d 74.0ms m2 40000bit ul m1 0bit d 0us m2 320000bit <-- Why 74ms when I specified 375ms? Where does that come from (see my calculations on the hfsc thread for details)? class hfsc a:16 parent a:13 leaf 102: sc m1 0bit d 74.0ms m2 80000bit ul m1 0bit d 0us m2 320000bit <-- Same as above... Another query: On one of my machines I get a large number of "overlimits" count - this is on the main (root) class, not a leaf. What does that mean? I do not have "overlimits" anywhere else though. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> After thinking about this some more, it seems reasonable to issue a WARNING if: > > a) The compiler is being run by root (The ''inset'' program requires that). > b) The compilation is not generating a script to be run on a remote system. > c) A named ipset does not exist on the local system. > > Patch attached. >Yeah, that works too. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 17, 2011, at 4:00 PM, Mr Dash Four wrote:> >> It would have been helpful to simply point out that any degenerate >> tcfilter produces this result. I''ve reproduced the problem and the >> attached patch ignores such tcfulters with a warning. >> > I had no idea that would be the case. Anyway, the attached patch works. > >> I had originally mis-read your post and thought that it was dmax that >> was not supplied. Shorewall does supply the mtu as umax if it is >> omitted. From the above tcclass, the actual command executed is: >> >> tc class add dev ifb0 parent ba:1 classid ba:25 hfsc sc umax 1500b dmax >> ---------- >> 350ms rate 500000kbit ul rate 1000000kbit >> >> You can see what ''tc class add'' commands Shorewall is executing by: >> >> /var/lib/shorewall/firewall trace restart 2> trace >> fgrep ''class add'' trace >> > OK, I used the (grand-calculation) example I started in the hfsc thread. > To recap, this is what I had, according to my calculations: > > a:11 - 10*full/100 20*full/100 1 tcp-ack > a:18 - 80*full/100 full 9 default > a:13 - 320kbit 320kbit 2 > a:13:14 - 120kbit:60ms:1500b full 2 > a:13:15 - 80kbit:100ms:1500b full 3 > a:13:16 - 80kbit:224ms:1500b full 4 > a:13:17 - 40kbit:374ms:1500b full 5 > > "a" is eth0, the speed of which is capped at 100mbit in tcdevices (it > can go up to 1gbit, but I am placing the cap intentionally here). So, > this is the output from shorewall show tc eth0: > > Shorewall 4.4.19.3 Traffic Control at test1.my.net - Tue May 17 23:32:56 > BST 2011 >...> > So, for the parts I haven''t got a clue as to why they are set as they are: > > qdisc sfq ff: parent a:11 limit 127p quantum 2500b flows 127/1024 > perturb 10sec <---- Why 2500b? Where does that come from?Notice that you are looking at the embedded SFQ qdisc subordinate to a:11. The ''HTB'' qdisc requires that the ''quantum'' be adjusted above the MTU on fast lines, and the compiler is using the quantum from the HTB calculation for SFQ (yes, I know - you aren''t using HTB but the compiler unconditionally calculates the HTB quantum. And it applies it to the SFQ qdisc so that the quanta for HTB and SFQ are the same). The attached patch omits the ''quantum'' specification when adding an SFQ qdisc subordinate to an HFSC class.> class hfsc a:17 parent a:13 leaf 103: sc m1 0bit d 74.0ms m2 40000bit ul > m1 0bit d 0us m2 320000bit <-- Why 74ms when I specified 375ms? Where > does that come from (see my calculations on the hfsc thread for details)?In my post that you are responding to, I showed you how to look at the generated script to see the ''tc add class'' commands that Shorewall is generating. If that command shows ''74ms'' then I will try to understand why that is happening. But I suspect that it shows 375, which means that you will need to ask the HFSC developers.> > Another query: On one of my machines I get a large number of > "overlimits" count - this is on the main (root) class, not a leaf. What > does that mean? I do not have "overlimits" anywhere else though.Don''t know. I used HFSC long enough to convince myself that the Shorewall HFSC support was working. I personally use nothing but the simple TC. -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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> The attached patch omits the ''quantum'' specification when adding an SFQ qdisc subordinate to an HFSC class. >Before I delve in and apply this patch I wanted to know whether increasing the umax value (deliberately or not) is a good thing or a bad thing with the configuration I have as it was my understanding that umax is (usually) set to the MTU value on the device to which this flow relates, which, evidently, isn''t the case with what I have seen so far, so there must be a reason as to why that is.>> class hfsc a:17 parent a:13 leaf 103: sc m1 0bit d 74.0ms m2 40000bit ul >> m1 0bit d 0us m2 320000bit <-- Why 74ms when I specified 375ms? Where >> does that come from (see my calculations on the hfsc thread for details)? >> > > In my post that you are responding to, I showed you how to look at the generated script to see the ''tc add class'' commands that Shorewall is generating. If that command shows ''74ms'' then I will try to understand why that is happening. But I suspect that it shows 375, which means that you will need to ask the HFSC developers. >I''ll check that later this evening and will query the dev list if it turns out that tc is setting these on its own account ignoring what I have specified via shorewall.> Don''t know. I used HFSC long enough to convince myself that the Shorewall HFSC support was working. I personally use nothing but the simple TC. >It looks as though there is another reason to contact the dev list then! ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/18/2011 06:32 AM, Mr Dash Four wrote:> >> The attached patch omits the ''quantum'' specification when adding an SFQ qdisc subordinate to an HFSC class. >> > Before I delve in and apply this patch I wanted to know whether > increasing the umax value (deliberately or not) is a good thing or a bad > thing with the configuration I have as it was my understanding that umax > is (usually) set to the MTU value on the device to which this flow > relates, which, evidently, isn''t the case with what I have seen so far, > so there must be a reason as to why that is.The quantum on the subordinate SFQ qdisc has nothing to do with umax. So altering umax won''t change that quantum, with or without the patch. -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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> The quantum on the subordinate SFQ qdisc has nothing to do with umax. So > altering umax won''t change that quantum, with or without the patch. >Oh, right, I was assuming that this is the umax value I was seeing, seeing as all others were set to the (umax) value I specified in my tcclasses file. Where can I check this value then (apart from .start)? ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/18/2011 07:31 AM, Mr Dash Four wrote:> >> The quantum on the subordinate SFQ qdisc has nothing to do with umax. So >> altering umax won''t change that quantum, with or without the patch. >> > Oh, right, I was assuming that this is the umax value I was seeing, > seeing as all others were set to the (umax) value I specified in my > tcclasses file. Where can I check this value then (apart from .start)?I don''t know -- I haven''t been able to find it either. -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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> I don''t know -- I haven''t been able to find it either. >Right, the tc dev forum it is then. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
>> Oh, right, I was assuming that this is the umax value I was seeing, >> seeing as all others were set to the (umax) value I specified in my >> tcclasses file. Where can I check this value then (apart from .start)? >> > > I don''t know -- I haven''t been able to find it either. >I''ll register on the tc dev forum in the coming days to see if someone could shed a light on these issues. Your patch does the job, though I see the value of 1514b shown (my MTU is 1500b) - is this intentional? ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On 05/18/2011 02:56 PM, Mr Dash Four wrote:> > >>> Oh, right, I was assuming that this is the umax value I was seeing, >>> seeing as all others were set to the (umax) value I specified in my >>> tcclasses file. Where can I check this value then (apart from .start)? >>> >> >> I don''t know -- I haven''t been able to find it either. >> > I''ll register on the tc dev forum in the coming days to see if someone > could shed a light on these issues. Your patch does the job, though I > see the value of 1514b shown (my MTU is 1500b) - is this intentional?When no quantum is included in a ''tc qdisc add ...sfq'' command , SFQ uses MTU + 14 (length of an ethernet header). -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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay