* Michael Stone:

> On Tue, Aug 30, 2005 at 12:17:22AM +0200, Florian Weimer wrote:
>>I think this part of the diff is pretty instructive, together with
>>upstream's explanation:
>
> Frankly, no, it's not. 
>
>>      if [ -n "$MACLIST_TTL" ]; then
>>          chain1=$(macrecent_target $interface)
>>          createchain $chain1 no
>>-         run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL 
>>--name $chain -j $chain1
>>-         run_iptables -A $chain1 -m recent --update                        
>>--name $chain -j ACCEPT
>>-         run_iptables -A $chain1 -m recent --set                           
>>--name $chain -j ACCEPT
>>+         run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL 
>>--name $chain -j RETURN
>>+         run_iptables -A $chain                                              
>>            -j $chain1
>>+         run_iptables -A $chain  -m recent --update                        
>>--name $chain -j RETURN
>>+         run_iptables -A $chain  -m recent --set                           
>>--name $chain
>>      fi
>
> I still have no idea what "chain1=$(macrecent_target $interface)" means.

It evaluates to the recent match chain for the particular interface.
There is one such chain for each interface on which this feature has
been enabled.

> I'm not sure why there's both an "update" and an "rcheck"--the man page
> says they're equivalent, except that update has an additional side
> effect. But if that's the case, why put the update in at all, since
> there's a return after the rcheck and you'll never get to the update.

The chains are different, $chain vs. $chain1.

> Presumably that has something to do with the mysterious chain1.  If we
> pull up the full source we find that macrecent_target
> is defined as 
> macrecent_target() # $1 - interface
> {
>    [ -n "$MACLIST_TTL" ] && echo $(chain_base $1)_rec || echo RETURN
> }
> and we enter a maze of twisty functions, all alike. 

It evaluates to eth0_rec in my test setup (in contrast to eth0_mac for
the chain which performs the actual MAC checks).  The relevant part of
the ACL loooks like this:

Chain eth0_in (1 references)
 pkts bytes target     prot opt in     out     source               destination 
        
   20  1734 dynamic    all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        state INVALID,NEW 
   20  1734 eth0_mac   all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        state NEW 
  985  757K net2all    all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        

Chain eth0_mac (2 references)
 pkts bytes target     prot opt in     out     source               destination 
        
    4   240 eth0_rec   all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        recent: CHECK seconds: 120 name: eth0_mac side: source 
    1    60 eth0_rec   all  --  *      *       212.9.189.171        0.0.0.0/0   
        MAC 00:0D:60:39:11:D8 
    0     0 eth0_rec   all  --  *      *       212.9.189.165        
212.9.189.175       
    0     0 eth0_rec   all  --  *      *       212.9.189.160/28     
255.255.255.255     
    0     0 eth0_rec   all  --  *      *       212.9.189.160/28     224.0.0.0/4 
        
   15  1434 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        LOG flags 0 level 6 prefix `Shorewall:eth0_mac:REJECT:' 
   15  1434 reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        

Chain eth0_rec (5 references)
 pkts bytes target     prot opt in     out     source               destination 
        
    4   240 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        recent: UPDATE name: eth0_mac side: source 
    1    60 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0   
        recent: SET name: eth0_mac side: source 


Note the ACCEPT in eth0_rec.

What further information do you need?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to