Messages in this thread |  | | Date | Mon, 16 Sep 2002 16:21:23 -0700 (PDT) | Subject | Re: bridge-netfilter patch | From | "David S. Miller" <> |
| |
From: Bart De Schuymer <bart.de.schuymer@pandora.be> Date: Mon, 16 Sep 2002 23:41:17 +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.
Lennert says:
So if we postpone FORWARD and POST_ROUTING until after br_dev_xmit, we effectively reverse refragmentation and neighbor resolution. But refragmentation messes up the hardware header.
The 16byte hardware header copy fixes this by copying to each fragment the hardware header that was tacked onto or was already present on the bigger packet. It's ugly, I admit. There's currently no better way though.
I don't understand why you can't add on the hardware header some other way.
If ip_finish_output doesn't put the right hardware header on there, you have to use as 'okfn' (what netfilter sends down as 'output' to ip_fragment) some routine which will do it correctly. - 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/
|  |