>> 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 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
