My theory is that the original MAC-address is somehow added to the SKB
before it reaches the output-part of the RAW-table (which is where I
hook in),
Routing is done before rawpost, yes, but before the (traditional) raw table.
(it's in skb->dst)
Ok, I assumed that the MAC-header was added at a lower layer, but that
was then wrong? For some reason I have always though skb->dst was the
IP-adress, I will look into that field.
skb->dst contains the pointer to the neighbor (simply put), and a
neighbor is (also simplified) what you see in `ip neigh`, i.e. MAC
I can now confirm that this works, doing another lookup and updating the
dst solved the problem and the MAC-header is now correct. I will clean
up the code and then patch it into RAWNAT or something similar tomorrow,
if it is of any interest.
However, I have noticed a similar problem when using my module on
incoming packets in PREROUTING (on the multihomed receiver), the IP
adress is changed (accoring to my dmesg-output) but then they are not
heard from again. I have not debugged this properly, but if anyone has
experienced something similar, feel free :) Can it be caused by the
wrong MAC-header (changing dst does not work on input on my machine, the
two interfaces are not aware of eachother's MAC address) being refused
by some part of the kernel? As always, it for some reasong works when
using DNAT, but I have not been able to figure out why :)
-Kristian
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
