[Voyage-linux] wlan0/hostap/kernel drops packets dst for 224.0.0.2 when the src addr does not match the subnet of the listening interface?

[LEE, Yui-wah (Clement)]

Okay I found the problem.  It was caused by the
feature rp_filter (reverse path lookup filter),
which can be turned on or off by command:

# echo 1 > /proc/sys/net/ipv4/conf/wlan0/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/wlan0/rp_filter

The problem did not appear on the eth0 interface
because the interface happened to be the default
gateway interface so the reverse path lookup test
always passed.

The problem did not appear on our other redhat
machine because on that machine the
/proc/sys/net/ipv4/conf/all/rp_filter file was set
to FALSE (0).  (Both
.../conf/{all,wlan0}/rp_filter has to be TRUE to
enable the rp_filter feature.)

Thanks!

Clement

On Wed, 25 Jan 2006, LEE, Yui-wah (Clement) wrote:

> Hi,
>
> I am using voyage-linux (0.1sarge) on soekris 4521 and
> hit the following strange phenomenon.  Either I did
> something wrong, or I may have hit a strange bug
> somewhere in the kernel, the wlan0 driver, or hostap.
>
> I have a program "ma" that listens on all the packets
> destined to 224.0.0.2 (ALL-ROUTERS.MCAST.NET.) on
> wlan0, which is configured to be of address
> 10.0.0.1/24.  The program issues the usual setsockopt()
> call (SOL_IP and IP_ADD_MEMBERSHIP) to tell the
> interface to join the multicast group.  The call
> completed without any complains from the system.  After
> that, the program ma sits on a select() loop waiting
> from some packets from the socket.
>
> Then, I noticed that if the client sends a packet
> destinated to 224.0.0.2 with a source address that is
> in the subnet of 10.0.0.1/24 (e.g. 10.0.0.106), ma
> would get the packet.  If, on the other hand, the
> client sends a similar packet but with a source address
> that is OUTSIDE of the subnet (e.g. 10.0.1.106), then
> ma would NOT get the packets.
>
> I tried two different versions of kernels (2.6.8 and
> 2.4.26) and both gave the same result.
>
> I think this may be a bug somewhere in the wlan0 (or
> hostap) or the kernel, because
>
> 1. I tried the same program ma on another soekris
>    machine running a Redhat (7.0) system with kernel
>    2.4.18, and the above problem did NOT occur (i.e. ma
>    gets all packets irrespective of the source address)
>
> 2. I tried running ma on another interface ("eth0"
>    instead of "wlan0"), and the above problem did NOT
>    occur.
>
> 3. The "ma" expected behavior is required for a
>    Mobile-IP mobility agent (RFC3344, Section 2.3, 2nd
>    last paragraph of Page 23 -- in case you are
>    interested).  Also, I think the multicast join is
>    based on the *interface* but not on the *interface
>    address*, right?
>
> I also verified that when ma was run, "ip maddr show
> wlan0" showed
>
>   workit1:~# ip maddr show wlan0
>   5:      wlan0
>   	  link  01:00:5e:00:00:02
>   	  link  01:00:5e:00:00:01
>   	  inet  224.0.0.2
>   	  inet  224.0.0.1
>
> indicating that the multicast join instruction had been
> made through to the kernel.
>
> I attached my test program ma2.cc in case someone want
> to look at the code.
>
> Thanks!
>
> Clement
>
>
>
>