mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lennert Buytenhek <buytenh@math.leidenuniv.nl>
To: "David S. Miller" <davem@redhat.com>
Cc: bart.de.schuymer@pandora.be, linux-kernel@vger.kernel.org
Subject: bridge-netfilter patch (was: Re: [PATCH] ebtables - Ethernet bridge tables, for 2.5.34)
Date: Fri, 13 Sep 2002 14:45:18 +0200	[thread overview]
Message-ID: <20020913144518.A31318@math.leidenuniv.nl> (raw)
In-Reply-To: <20020912.230916.96754743.davem@redhat.com>; from davem@redhat.com on Thu, Sep 12, 2002 at 11:09:16PM -0700


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

>    From: Bart De Schuymer <bart.de.schuymer@pandora.be>
>    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);

                ip_send_check(iph);
+               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) {
                read_lock_bh(&hh->hh_lock);
>>>             memcpy(skb->data - 16, hh->hh_data, 16);
                read_unlock_bh(&hh->hh_lock);
                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)"?


cheers,
Lennert

  reply	other threads:[~2002-09-13 12:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-11 22:32 802.1q + device removal causing hang Simon Kirby
2002-09-11 22:31 ` David S. Miller
2002-09-12  6:36   ` [PATCH] ebtables - Ethernet bridge tables, for 2.5.34 Bart De Schuymer
2002-09-12 23:04     ` David S. Miller
2002-09-13  3:20       ` Bart De Schuymer
2002-09-13  4:29         ` David S. Miller
2002-09-13  6:12           ` Bart De Schuymer
2002-09-13  6:09             ` David S. Miller
2002-09-13 12:45               ` Lennert Buytenhek [this message]
2002-09-13 18:22                 ` bridge-netfilter patch David S. Miller
2002-09-14  7:05                   ` Bart De Schuymer
2002-09-16  3:35                     ` David S. Miller
2002-09-16 21:41                       ` Bart De Schuymer
2002-09-16 23:21                         ` David S. Miller
2002-09-17 19:10                           ` Bart De Schuymer
2002-09-17 19:35                             ` David S. Miller
2002-09-15 21:27                   ` Lennert Buytenhek
2002-09-16  6:50               ` [PATCH] ebtables - Ethernet bridge tables, for 2.5.35 Bart De Schuymer
2002-09-16 23:01                 ` David S. Miller
2002-10-14 18:05     ` [RFC] bridge-nf -- map IPv4 hooks onto bridge hooks, vs 2.5.42 Bart De Schuymer
2002-10-14 18:01       ` David S. Miller
2002-10-14 18:32         ` bert hubert
2002-10-14 18:58         ` Bart De Schuymer
2002-10-14 19:02           ` David S. Miller
2002-10-14 19:29             ` Bart De Schuymer
2002-10-14 19:26               ` David S. Miller
2002-10-20 22:20       ` [RFC] bridge-nf -- map IPv4 hooks onto bridge hooks, vs 2.5.44 Bart De Schuymer
2002-10-20 22:19         ` David S. Miller
2002-10-22 23:40         ` Bart De Schuymer
2002-10-25  6:01           ` [PATCH][RFC] bridge-nf -- map IPv4 hooks onto bridge hooks - try 3, " Bart De Schuymer
2002-10-25  6:22             ` [netfilter-core] " Harald Welte
2002-10-28 13:02             ` David S. Miller
     [not found]     ` <200210141953.38933.bart.de.schuymer@pandora.be>
2002-10-14 19:59       ` [RFC] place to put bridge-netfilter specific data in the skbuff Bart De Schuymer
2002-10-24  8:16         ` [netfilter-core] " Harald Welte
2002-10-24  8:15           ` David S. Miller
2002-10-24 12:22             ` Harald Welte
2002-09-12 23:49   ` 802.1q + device removal causing hang Simon Kirby
2002-09-12 23:53     ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020913144518.A31318@math.leidenuniv.nl \
    --to=buytenh@math.leidenuniv.nl \
    --cc=bart.de.schuymer@pandora.be \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®