On 12/7/06, Eric Brower <ebrower at gmail.com> wrote: > On 12/7/06, Louis Croisez <louis.croisez at 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. On further thought, you might be able to look at destination MACs rather than IPs; for the ff:ff:ff:ff:ff:ff destination MAC on broadcast packets, or multicast destination MACs. In any case, using the kernel to lookup IP addresses just isn't going to do it without a routing table. HTH, E > > 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 > -- E
