[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subjectbridge-netfilter patch (was: Re: [PATCH] ebtables - Ethernet bridge tables, for 2.5.34)

On Thu, Sep 12, 2002 at 11:09:16PM -0700, David S. Miller wrote:

> From: Bart De Schuymer <>
> Date: Fri, 13 Sep 2002 08:12:27 +0200
> It is not trivial however, 2 new fields to the sk_buff need to be
> added, a small change in the IP fragment code and a small change in
> ip_tables.c, a change to netfilter.h and netfilter.c.
> I've seen these changes, they are very buggy. The IPv4 copies added
> are just ugly and are buggy too, they potentially copy past the end
> of the packet buffer.

You mean this part? This is the only copy added to generic code
that I can find.

--- linux-2.4.19/net/ipv4/ip_output.c 2002-08-03 02:39:46.000000000 +0200
+++ linux-2.4.19-brnf0.0.7/net/ipv4/ip_output.c 2002-09-11 17:40:25.000000000 +0200
@@ -883,6 +885,7 @@
iph->tot_len = htons(len + hlen);

+ memcpy(skb2->data - 16, skb->data - 16, 16);

err = output(skb2);
if (err)

If this code is buggy, isn't the following bit from ip_output.c buggy
too? (around line 170)

if (hh) {
>>> memcpy(skb->data - 16, hh->hh_data, 16);
skb_push(skb, hh->hh_len);
return hh->hh_output(skb);
} else if (dst->neighbour)

> So, if you would accept br-nf, that would be great.
> You need to remove the IPv4 bits, that copy of the MAC has to happen
> at a different layer, it does not belong in IPv4. At best, everyone
> shouldn't eat that header copy.

What if I make the memcpy conditional on "if (skb->physindev != NULL)"?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.095 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site