Re: bridge-netfilter patch

From: Bart De Schuymer (
Date: Tue Sep 17 2002 - 14:10:06 EST

> 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

        if (skb->protocol == __constant_htons(ETH_P_IP)) {
                struct dst_entry *dst = skb->dst;
                if (hh) {
                          memcpy(skb->data - 16, hh->hh_data, 16);

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?


- 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

This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:20 EST