On Tue, 2011-07-26 at 00:00 +0100, Ed W wrote: > I haven't debugged this enough to understand what is happening, but I > observe the following: > > someipset = bitmap:ip,mac > > 1) br0:+someipset > 2) br0:+someipset[2] > > The first 1) doesn't match anything in rules or tcrules, the second 2) > matches fine. (Also using +someipset[1] doesn't match anything)
That is because it is equivalent to 1). > > Is it possible/sensible/feasible to have shorewall figure out the 'arity > of the ipset? With ipsets still under such rapid development, I'm reluctant to add any code that attempts to understand set types. > Is it an artifact of the ipset type used here? Yes. > > Not tested this yet, but is it a more descriptive setup to do something > like defining someipset:loc in zones and "somealias br0:+someipset[2]" > in hosts? That way I *think* I can use "somealias" everywhere and avoid > needing to remember the "arity" in various rules? I don't believe that a bitmap:ip,mac ipset works in the hosts file. Such an ipset can only be used to match the SOURCE address while an ipset listed in the hosts file must be able to match both SOURCE and DEST 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 \________________________________________________
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
