[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  Monowall User List <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] WAN download <> LAN upload
 Date:  Sun, 27 Jan 2008 19:22:35 -0800 (PST)
On Mon, 21 Jan 2008, Michel Servaes wrote:

> Jan 21 22:34:34 gw1 ipmon[112]: 22:34:34.329898 rl0 @0:18 b 10.132.80.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:34:34 gw1 ipmon[112]: 22:34:34.330874 rl0 @0:18 b 10.173.192.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:34:34 gw1 ipmon[112]: 22:34:34.331830 rl0 @0:20 b 172.22.16.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:34:34 gw1 ipmon[112]: 22:34:34.332313 rl0 @0:18 b 10.50.0.1 -> 
> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> ...
> Jan 21 22:49:09 gw1 ipmon[112]: 22:49:08.577563 rl0 @0:20 b 172.22.16.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:49:09 gw1 ipmon[112]: 22:49:08.578537 rl0 @0:18 b 10.173.192.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:49:09 gw1 ipmon[112]: 22:49:08.579510 rl0 @0:18 b 10.132.80.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> ...
> Jan 21 22:53:05 gw1 ipmon[112]: 22:53:05.006321 2x re0 @0:3 b 
> 172.16.0.254 -> 224.0.0.1 PR igmp len 24 (36) IN low-ttl multicast  **** ???
> Jan 21 22:53:18 gw1 ipmon[112]: 22:53:18.643674 rl0 @0:18 b 10.50.0.1 -> 
> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:53:18 gw1 ipmon[112]: 22:53:18.644158 rl0 @0:20 b 172.22.16.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:53:18 gw1 ipmon[112]: 22:53:18.645129 rl0 @0:18 b 10.173.192.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast
> Jan 21 22:53:18 gw1 ipmon[112]: 22:53:18.646103 rl0 @0:18 b 10.132.80.1 
> -> 224.0.0.1 PR igmp len 20 (28) IN low-ttl multicast

Based on the lengths, I'm pretty sure most of these don't have any IP
options.  The minimum IGMP payload is 8 octets, so there's no room for
options in 28.  That says those are is probably IGMPv1, since v2 and v3
require the RA option.  But the one from 172.16.0.254 looks like it has a
4-octet option (and a 12-byte payload), which is consistent with its being
dropped by rule 0:3.  *That* one is probably v2 or v3, with the RA option.

The expressions like "@0:18" indicate which rule is responsible for
dropping the packet, as group number and rule number.  If you list the
actual filter rules with "ipfstat -hnio" (in exec.php), you can see which
rules these are.

You seem to have multiple neighboring routers using private network
addresses.  Have you unchecked "block private networks"?

> What is the "2x re0" ???

I think that means it saw two of the same thing in a row.

					Fred Wright