Re: bridge-netfilter patch

Bart De Schuymer (bart.de.schuymer@pandora.be)
Tue, 17 Sep 2002 21:10:06 +0200


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