libnetfilter_queue conditions required to rewrite packets...

Hi,
I appologize if this is a bit of a daft question, but looking
through all the documentation I've managed to locate it's never made explicit, and the list archives are rather difficult to use when looking for specific information.
I'm trying to make use of the libnetfilter_queue module to
intelligently mangle certain packets on their way through certain points in iptables. I think I've got all the code working correctly, and I believe I'm modifying the packet and using a pointer to the modified packet in the nfq_set_verdict call with the new packet length, however from all the tests I've run, the original packet is continuing on, and the new payload seems to be ignored. Are there special conditions under which packet modification will work, or should it work under all circumstances?
I've read several things which might help narrow the problem. In
one example (for libipq as it turns out), they have a test so that rewriting only happens if the packet's come in from hook 0 (which is PREROUTING). Does this mean that packet modification can only be done in certain chains (for example, PREROUTING and OUTPUT only)? Must the NFQUEUE target be in the mangle table rather than the filter table to perform payload rewriting? I've tried both and I still seem not to be sending out the modified data. I'd also read somewhere that the kernel might silently ignore packets if their checksums had not been calculated correctly. Does this mean invalid packets can't be sent using this method? Would nfq_set_verdict fail if that were the case? Finally if the packet contents can be modified no matter where the hook is, does anyone have any ideas how I could further debug the problem? Last thing I know is I'm passing the right data to the nfq_set_verdict call and I'm getting back a positive response, but the data received always appears to be the original data sent. Is there someway to track what's going on further inside the netlink?
Any light anyone can shed on this would be greatly appreciated.
Thanks very much...

    Mike  5:)

2006/4/6, Mike Auty <[email protected]>:

Same here, just ported an libipq application (which was working fine) to libnetfilter_queue and encountered the same problem. I will post to the list, once I found out anything. Any advice would be highly appreciated.

David

For testing purposes I simply rewrote the nfq_test.c application in libnetfilter_queue/utils, such that the reinjected packet should have the ttl field modified.
1) receive original payload and length with nfq_get_payload
2) modify payload
3) call nfq_set_verdict(qh, id, NF_ACCEPT, len, modified_payload)

I tried to find a place where things go wrong, but as far as I can see, everything looks fine all the way down to the actual sendmsg call on the netlink socket (i.e. nfnl_sendiov() in libnfnetlink.c). On the "receiver" side I checked nfqnl_recv_verdict(), which is part of nfnetlink_queue module (linux-2.6.16/net/netfilter/nfnetlink_queue.c). The check if (nfqa[NFQA_PAYLOAD-1]) {
// call nfqnl_mangle
}
fails. However, a raw dump of the skb that nfqnl_recv_verdict() operates, reveals that the payload IS there, WITH the modifications that have been applied.

I haven't gain enought insight into the *nfqa[] stuff, yet, so any help would be appreciated. Maybe I'm looking for a solution in all the wrong places. What do I do wrong?

David

Looks as though,
The code in the subversion repository's quite different, so I've
checked out a copy of that and I'm gonna give it a test when I next get a chance. It requires >=libnfnetlink-0.0.16, so that's also gonna have to be built from subversion.
The changes include incrementing the size of the structure to include
the size of the payload, and also the structure holding the payload is defined outside the conditional statement. These I think, should mean the packet's better formed and hopefully will do the actual mangling...
I'm not sure how far away those packages are from becoming releases,
but it seems they have some definite enhancements in them...

	Mike  5:)

Ok,
So yesterday I needed to use a small program to rewrite packets flowing
through my transparent bridge. I started using the an ipq implementation and after a bit of jiggery pokery fixing up all the checksums, it seemed to be working a treat. I then knocked up an nfqueue implementation using the code I'd been writing that did exactly the same job, and using the the subversion copies of libnetfilter_queue (0.0.12) and libnfnetlink (0.0.16), I did manage to mangle the packets successfully...
I still don't seem to be able to send out packets with a broken
checksum, but I haven't yet verified whether that's the target end dropping them or the linux kernel killing them before they get on the wire. I hope this helps...

	Mike  5:)

2006/4/11, Mike Auty <[email protected]>:

That's good news. I took a holiday this week, so I haven't been working on this issue anymore, but will try to check if the subversion copies solve my problems as well.
Thank you very much!

David

2006/4/11, Mike Auty <[email protected]>:

For the sake of completeness. After Amin Azez helped me (thanks again) to compile the current library version from the svn trunk and installing them, I gave it a quick shot and my application seems to work fine as well. Thank you as well, Mike.

David