Hi Eric, first, thx for your responses. I have tried to hping on destination IP 239.255.255.250 (a Multicast ip used for example in the uPnP discovery process). The inet_addr_type() function detect multicast well. For the question of the broadcast, your idea of using the mac dest address is great. I will check this and give a feedback. Cheers, LOUIS 2006/12/8, Eric Brower <ebrower at gmail.com>: > 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 >
