libnetfilter_queue conditions required to rewrite packets...

libnetfilter_queue conditions required to rewrite packets...

[Mike Auty]

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:)

Re: libnetfilter_queue conditions required to rewrite packets...

[David Vogt]

2006/4/6, Mike Auty <mike.auty@gmail.com>:
> from all the tests I've run, the original packet is continuing on, and
> the new payload seems to be ignored.
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

Re: libnetfilter_queue conditions required to rewrite packets...

[David Vogt]

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

Re: libnetfilter_queue conditions required to rewrite packets...

[Mike Auty]

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:)

Re: libnetfilter_queue conditions required to rewrite packets...

[Mike Auty]

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:)

Re: libnetfilter_queue conditions required to rewrite packets...

[David Vogt]

2006/4/11, Mike Auty <mike.auty@gmail.com>:
> 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...
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

Re: libnetfilter_queue conditions required to rewrite packets...

[David Vogt]

2006/4/11, Mike Auty <mike.auty@gmail.com>:
> 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...

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