ipq_set_verdict gives errors for multicast packets but works fine for unicast (kernel 2.6)

ipq_set_verdict gives errors for multicast packets but works fine for unicast (kernel 2.6)

[Maarten Wijnants]

Hello group,

I have written a libipq application that accepts QUEUEd packets from 
kernelspace, checks them, and subsequently decides what to do with them. I 
often change stuff inside a packet and then reinject it in the kernel 
through ACCEPT. More specifically, I often need to change the source IP and 
source port of UDP packets. Every time I change the content of a QUEUEd UDP 
packet, I recompute the IP checksum, and I set the UDP checksum to 0. The 
UDP checksum is optional (see RFC), so can be set to 0.

This all worked fine on kernel version 2.4. However, I have just upgraded to 
kernel 2.6.6, and all of a sudden my application doesn't work anymore. First 
I thought this was because of the UDP checksum of 0 (see my previous mail to 
the mailinglist). So I implemented an algorithm that calculates the UDP 
checksum, but the problem persists. More specifically, when I want to 
reinject an altered packet, I use the following rule of C code:

ipq_set_verdict(ipq_handle, m->packet_id, NF_ACCEPT, m->data_len, packet);

Since I didn't change the payload of the UDP packet, only some header 
information, I can use the original size of the QUEUEd packet (i.e. 
m->data_len with m being an ipq_packet_msg_t pointer). Now the strange thing 
is, if the packet is destined for a unicast destination, this line of code 
works and the packet reaches its destination. However, if this packet has a 
multicast destination, it seems to get lost. The result from ipq_set_verdict 
is positive, but the packet doesn't reach its destination. What's more, if I 
tcpdump on the host that issued the NF_ACCEPT verdict, I can't see the 
multicast packet getting sent. The above rule of code worked for both 
unicast and multicast destinations in kernel 2.4 ...

Anyone got any idea what is wrong here? Are there issues with ip_queue in 
combination with kernel 2.6? If anyone got any clues please help me, I am 
getting kind of desperate here :/

Kind regards,
Maarten

--

Maarten Wijnants
Expertisecentrum voor Digitale Media
Limburgs Universitair Centrum
Wetenschapspark 2 - 3590 Diepenbeek
Tel: +32 (0)11 268419 - Mobile: +32 (0)497 341848
E-mail: maarten.wijnants@luc.ac.be
URL: http://research.edm.luc.ac.be/~mwijnants/ 

Re: ipq_set_verdict gives errors for multicast packets but works fine for unicast (kernel 2.6)

[Pablo Neira]

Maarten Wijnants wrote:

> This all worked fine on kernel version 2.4. However, I have just 
> upgraded to kernel 2.6.6, and all of a sudden my application doesn't 
> work anymore. 


Update to lastest kernel stable 2.6. Patrick McHardy pushed forward some 
patches which fixes some problems in ip_queue some time ago.

--
Pablo

Re: ipq_set_verdict gives errors for multicast packets but works fine for unicast (kernel 2.6)

[Maarten Wijnants]

Hello Pablo (and rest of list),

Thanks for your reply,

> Maarten Wijnants wrote:
>
>> This all worked fine on kernel version 2.4. However, I have just upgraded 
>> to kernel 2.6.6, and all of a sudden my application doesn't work anymore.
>
>
> Update to lastest kernel stable 2.6. Patrick McHardy pushed forward some 
> patches which fixes some problems in ip_queue some time ago.
>

Well I tried a variety of kernels already. More specifically, I started out 
with kernel 2.4.20. Everything works fine on this kernel version. 
Afterwards, I have tried kernel 2.4.28, 2.6.6, 2.6.9 and 2.6.10. I even 
patched 2.6.10 with the latest snapshot from kernel.org. On none of these 
kernel versions the rule

ipq_set_verdict(ipq_handle, m->packet_id, NF_ACCEPT, m->data_len, packet);

works for an altered packet with a multicast destination. For unicast 
destination packets, the rule works on any kernel version. On kernel 2.4.20, 
this rule works perfectly correct in all situations (i.e. both unicast and 
multicast destinations). I have absolutely no idea what is going wrong in 
the other kernel versions. Any ideas?

Thanks in advance.

Kind regards,
Maarten 

ipq_set_verdict gives errors for multicast packets but works fine for unicast (kernel 2.6)

[Maarten Wijnants]

Hello group,

I have written a libipq application that accepts QUEUEd packets from 
kernelspace, checks them, and subsequently decides what to do with them. I 
often change stuff inside a packet and then reinject it in the kernel 
through ACCEPT. More specifically, I often need to change the source IP and 
source port of UDP packets. Every time I change the content of a QUEUEd UDP 
packet, I recompute the IP checksum, and I set the UDP checksum to 0. The
 UDP checksum is optional (see RFC), so can be set to 0.

 This all worked fine on kernel version 2.4.20. However, I have just 
upgraded to kernel 2.6.6, and all of a sudden my application doesn't work 
anymore. First I thought this was because of the UDP checksum of 0 (see my 
previous mail to the mailinglist). So I implemented an algorithm that 
calculates the UDP checksum, but the problem persists. More specifically, 
when I want to
 reinject an altered packet, I use the following rule of C code:

 ipq_set_verdict(ipq_handle, m->packet_id, NF_ACCEPT, m->data_len, packet);

 Since I didn't change the payload of the UDP packet, only some header 
information, I can use the original size of the QUEUEd packet (i.e. 
m->data_len with m being an ipq_packet_msg_t pointer). Now the strange thing 
is, if the packet is destined for a unicast destination, this line of code 
works and the packet reaches its destination. However, if this packet has a
 multicast destination, it seems to get lost. The result from 
ipq_set_verdict is positive, but the packet doesn't reach its destination. 
What's more, if I tcpdump on the host that issued the NF_ACCEPT verdict, I 
can't see the multicast packet getting sent. The above rule of code worked 
for both unicast and multicast destinations in kernel 2.4.20 ...

 Anyone got any idea what is wrong here? Are there issues with ip_queue in 
combination with kernel 2.6? If anyone got any clues please help me, I am 
getting kind of desperate here :/

 Kind regards,
Maarten

--

Maarten Wijnants
Expertisecentrum voor Digitale Media
Limburgs Universitair Centrum
Wetenschapspark 2 - 3590 Diepenbeek
Tel: +32 (0)11 268419 - Mobile: +32 (0)497 341848
E-mail: maarten.wijnants@luc.ac.be
URL: http://research.edm.luc.ac.be/~mwijnants/