lkml.org 
[lkml]   [2002]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: bridge-netfilter patch
Date
>    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

-
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/

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