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 \________________________________________________
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
