Linux Ethernet Bridging - Apr 2007 - [Bridge] Help needed about IP class finding in a bridge netfilter module

Hi,
i am currently trying to code a little netfilter plugin, to be placed
into the bridge forwarding path.
In such plugin, i would like to test if a packet is:
- unicast
- multicast
- broadcast

The starting condition is that the bridge has no knowledge of the IP
configuration of the sending and receiving stations. It does not know
about their netmask e.g.

I have tried the following function (from 2.6 kernel):
inet_addr_type(u32 addr), but it always return RTN_UNICAST, and never
RTN_MULTICAST, RTN_BROADCAST.
 For example, for this address: 10.255.255.255 it returns RTN_UNICAST.

How could the bridge decide in which class is the destination IP of a
skb, and what is my error?

Thx in advance.
LOUIS

On 12/7/06, Louis Croisez <louis.croisez@gmail.com>
wrote:
> Hi,
> i am currently trying to code a little netfilter plugin, to be placed
> into the bridge forwarding path.
> In such plugin, i would like to test if a packet is:
> - unicast
> - multicast
> - broadcast
>
> The starting condition is that the bridge has no knowledge of the IP
> configuration of the sending and receiving stations. It does not know
> about their netmask e.g.
>
> I have tried the following function (from 2.6 kernel):
> inet_addr_type(u32 addr), but it always return RTN_UNICAST, and never
> RTN_MULTICAST, RTN_BROADCAST.
>  For example, for this address: 10.255.255.255 it returns RTN_UNICAST.
>
> How could the bridge decide in which class is the destination IP of a
> skb, and what is my error?
The bridge can't discriminate between broadcast and unicast because
you have no routing table entries (netmasks) to associate with the
destination address.  You could hack-in a class A/B/C match yourself,
but with CIDR (RFC 1519) the world does not work that way any longer.

Based on the code I would suggest multicast addresses would be matched
(have you tried to ping 224.0.0.1 [all hosts mcast] to see if it is
properly classified?).  For the locally-destined packets you could
maintain static routing table entries on your system, if that is
tenable in your environment.

You might be able to obtain this information via RMON from your
routers, if this is not a science project.

-- 
E