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/