From: Bart De Schuymer <bart.de.schuymer@pandora.be>
To: "David S. Miller" <davem@redhat.com>
Cc: buytenh@math.leidenuniv.nl, linux-kernel@vger.kernel.org
Subject: Re: bridge-netfilter patch
Date: Tue, 17 Sep 2002 21:10:06 +0200 [thread overview]
Message-ID: <200209172110.06121.bart.de.schuymer@pandora.be> (raw)
In-Reply-To: <20020916.162123.116935622.davem@redhat.com>
> net/ipv4/ip_output.c:ip_fragment()
> In this function the copy of the Ethernet frame is added for each
> fragment (by the br-nf patch).
>
> 'output' callback arg to ip_fragment() must generate correct hardware
> headers when necessary. This hack usage of it via netfilter, in this
> weird bridging case, is violating this requirement.
>
> Normally ip_finish_output2() is going to make this.
>
> If it can't do the job properly, pass instead a routine that can do
> what netfilter needs.
Aha. In our case, the output function is
net/bridge/br_forward.c:__dev_queue_push_xmit(). This is because
__br_forward_finish() (same file) uses this as okfn. Remember the IP hooks
are "faked" on the bridge hooks, so functions attached to NF_IP_POST_ROUTING
are called when the IP packet/frame passes the NF_BR_POST_ROUTING hook. They
are not called earlier. All of this assuming that the destination device
according to the routing table is a (logical) bridge device. If not, the
packets go through the IP code and netfilter hooks normally.
So, what if we were to add the following code to the start of
__dev_queue_push_xmit():
if (skb->protocol == __constant_htons(ETH_P_IP)) {
struct dst_entry *dst = skb->dst;
if (hh) {
read_lock_bh(&hh->hh_lock);
memcpy(skb->data - 16, hh->hh_data, 16);
read_unlock_bh(&hh->hh_lock);
}
}
hh being NULL for an unfragmented IP packet and else non-NULL? Do realize that
I (I can't speak for Lennert ofcourse) am not very familiar to the workings
of the IP code.
Then we can remove the memcpy from ip_fragment(). Does that make sense?
--
cheers,
Bart
next prev parent reply other threads:[~2002-09-17 19:03 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 ` bridge-netfilter patch (was: Re: [PATCH] ebtables - Ethernet bridge tables, for 2.5.34) Lennert Buytenhek
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 [this message]
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=200209172110.06121.bart.de.schuymer@pandora.be \
--to=bart.de.schuymer@pandora.be \
--cc=buytenh@math.leidenuniv.nl \
--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;
as well as URLs for NNTP newsgroup(s).