I am the author of the WRR (http://wipl-wrr.dkik.dk/wrr) qdisc, an extension to the 2.2 kernels which is supposed to run on a router/bridge/firewall and do Weighted Round Robin scheduling with a class for each local machine.
Now, I want to port this scheduler to 2.4. One of the problems is that sometimes I have an outgoing (to the world) packet which has been masqgraded. I want to account this packet to the local machine which has originally generated it. On 2.2. I used the following code to get the IP address of the local machine:
#ifdef CONFIG_IP_MASQUERADE
// iph: // The ip header from the sk_buff
// dport: // Destination port of packet
// sport: // Source port of packet
// ipaddr: // We update this with the IP address of the local machine
{
struct ip_masq* src;
// HACK!:
// ip_masq_in_get must be called for packets comming from the outside
// to the firewall. We have a a packet which is comming from the firewall
// to the outside - so we switch the parameters:
if(src=ip_masq_in_get(
iph->protocol,
iph->daddr,dport,
iph->saddr,sport))) {
// Use masqgraded address:
ipaddr=src->saddr;
// It seems like we must put it back:
ip_masq_put(src);
}
}
#endif
What should I use on 2.4?
And a second question:
When used on a bridge I also want to get the MAC source and destionation address of packets to be able to classify local machines based on these addresses (I suppose this cannot be combinated with masqgrading or routing for to-the-world packets). The ipt_mac.c file seems to do the same thing in the following code:
/* Is mac pointer valid? */
return (skb->mac.raw >= skb->head
&& skb->mac.raw < skb->head + skb->len - ETH_HLEN
/* If so, compare... */
&& ((memcmp(skb->mac.ethernet->h_source, info->srcaddr, ETH_ALEN)
== 0) ^ info->invert));
Now, as far as I can see it would be more correct to use skb->data instead of skb->head? Isn't data where the data starts and head where the sk_buff is actually allocated? I might very well have missunderstood something, but I have not succeeded in finding any usefull documenation on the sk_buff structure. And another thing - will the above check ensure that what we read is actually valid or will it just ensure that we do not read from a place in memory that would generate an exception? And if it doesn't ensure it is valid, is there any way to ensure that it is? In 2.2 I used the pkt_isbridged flag of the sk_buff which seems to have disappeared.
Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/