about ipq_set_verdict()

about ipq_set_verdict()

[Jee J.Z.]

Hi all,

I am using the libipq library to do userspace programming on netfilter. I am
having some problems understanding the return values of the function
ipq_set_verdict():

When I set verdict (either NF_ACCEPT or NF_DROP) without modifying the
packet, the return value of ipq_set_verdict is 28 and everything works well;
however, when I set verdict trying to modify the packet, ipq_set_verdict
returns 88, and the packet seems always to be dropped even when I set
NF_ACCEPT.

Does anybody know what these return values mean? Moreover, could anybody
tell me how I can successfully modify a packet using libipq? Thank you very
much in advance!!

Regards,
Jee

Re: about ipq_set_verdict()

[Oumer Teyeb]

In the man pages it says that if you get a negative value then it is a
failure , otherwise it is a sucess.

The reason that you may get the packets dropped may be because you
modified them in such a way that they are not valid anymore (you change
thing to an invalid ip address or something like that)

On how to get the packet info

Once you get the packet = ipq_get_packet(buffer)

you can access the packet data (including header and payload) from
memory location packet +1,

for example

you can use something like

usigned char *packet_all = (unsigned char *) (packet+1);

then for example to access the ip_header length, which is located from
bits 4-7 in the ip header you can use something like

ip_header_len = (*packet_all & 0xF) * 4; // the 4 is since the header
length is specified as a multiple of 32bits,ie 4 bytes

or you can get the total length, which is the third and fourth bytes of
the header as

total_len = htons(*(unsigned short *) (packet_all + 2)))

and so on,

and based on the value of this ip header length and the data offset in
the tcp header,


(to find the data offset in the tcp header you can use something like

tcp_header_len = ((*(packet_all + ip_header_len + 12 ) & 0xF0) >> 4 )*
4; // the 12 is because we have 2 bytes for source port + 2 bytes for
destination port, 4 bytes for sequence number and 4 bytes for ack number
in the tcp header before we reach the data offset


so the data payload is from unsinged char *start = (packet_all +
ip_header_len+ tcp_header_len) till unsinged char *end = start + total_len


and I think you can just set the values of the packet, whether header or
payload, once you got a pointer to it






Jee J.Z. wrote:

>Hi all,
>
>I am using the libipq library to do userspace programming on netfilter. I am
>having some problems understanding the return values of the function
>ipq_set_verdict():
>
>When I set verdict (either NF_ACCEPT or NF_DROP) without modifying the
>packet, the return value of ipq_set_verdict is 28 and everything works well;
>however, when I set verdict trying to modify the packet, ipq_set_verdict
>returns 88, and the packet seems always to be dropped even when I set
>NF_ACCEPT.
>
>Does anybody know what these return values mean? Moreover, could anybody
>tell me how I can successfully modify a packet using libipq? Thank you very
>much in advance!!
>
>Regards,
>Jee
>
>
>

Re: about ipq_set_verdict()

[Jee J.Z.]

Hi Oumer,

Thank you for your explanations. They are quite helpful. Please see inline:


> In the man pages it says that if you get a negative value then it is a
> failure , otherwise it is a sucess.

Right. I've figured out the return value of ipq_set_verdict(), which is 28 +
data_len (one of the input parameters of ipq_st_verdict specified by users).

> The reason that you may get the packets dropped may be because you
> modified them in such a way that they are not valid anymore (you change
> thing to an invalid ip address or something like that)

Right. But I think I made some changes on the overhead of libipq itself
rather than on packets, which caused the kernel confused and couldn't figure
out what the infomation means returned by ipq_set_verdict.

> On how to get the packet info
>
> Once you get the packet = ipq_get_packet(buffer)
>
> you can access the packet data (including header and payload) from
> memory location packet +1,

As far as I can see, there are some overheads (info) used by
ip_queue/netfilter to identify the packet (such as packet_id) and to provide
some useful info (such as timestamp) to userspace. Therefore, 'packet+1'
seems not the location of putting the pure packet data (header and payload).
Instead, from the man page of ipq_get_packet (see the structure of
ipq_packet_msg), packet+1 should be packet_id. no?

> for example
>
> you can use something like
>
> usigned char *packet_all = (unsigned char *) (packet+1);
>
> then for example to access the ip_header length, which is located from
> bits 4-7 in the ip header you can use something like
>
> ip_header_len = (*packet_all & 0xF) * 4; // the 4 is since the header
> length is specified as a multiple of 32bits,ie 4 bytes
>
> or you can get the total length, which is the third and fourth bytes of
> the header as
>
> total_len = htons(*(unsigned short *) (packet_all + 2)))
>
> and so on,
>
> and based on the value of this ip header length and the data offset in
> the tcp header,
>
>
> (to find the data offset in the tcp header you can use something like
>
> tcp_header_len = ((*(packet_all + ip_header_len + 12 ) & 0xF0) >> 4 )*
> 4; // the 12 is because we have 2 bytes for source port + 2 bytes for
> destination port, 4 bytes for sequence number and 4 bytes for ack number
> in the tcp header before we reach the data offset
>
>
> so the data payload is from unsinged char *start = (packet_all +
> ip_header_len+ tcp_header_len) till unsinged char *end = start + total_len
>
>
> and I think you can just set the values of the packet, whether header or
> payload, once you got a pointer to it

Thank you very much for these excellent examples. They make sense. I am just
a bit confused whether packet+1 is the start point of a packet including its
header.

Cheers,
Jee

>
>
>
> Jee J.Z. wrote:
>
> >Hi all,
> >
> >I am using the libipq library to do userspace programming on netfilter. I
am
> >having some problems understanding the return values of the function
> >ipq_set_verdict():
> >
> >When I set verdict (either NF_ACCEPT or NF_DROP) without modifying the
> >packet, the return value of ipq_set_verdict is 28 and everything works
well;
> >however, when I set verdict trying to modify the packet, ipq_set_verdict
> >returns 88, and the packet seems always to be dropped even when I set
> >NF_ACCEPT.
> >
> >Does anybody know what these return values mean? Moreover, could anybody
> >tell me how I can successfully modify a packet using libipq? Thank you
very
> >much in advance!!
> >
> >Regards,
> >Jee
> >
> >
> >
>
>
>
>

Re: about ipq_set_verdict()

[Oumer Teyeb]

[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]

Hi Jee,

I think you have mistaken packet +1 to be the next data byte. Since
packet is a pointer to the struct ipq_packet_msg by pointer arthimetic
packet +1 will give you the pointer to the data byte after n bytes,
where n is the amount of bytes in a ipq_packet_msg struct.


so what we have is something like

packet -------points to---------> start of ipq_packet_msg

packet +1---------points to --------> data byte just after the
ipq_packet_msg struct

so if I set unsigned char * packet_all =(unsigned char*)(packet +1);
this gives me the pointer to the packet data (header + payload)

but if I say

unsigned char * packet_all =((unsigned char * )(packet)) + 1, then sure
this points to the packet id

hope this makes it clear

As to become sure, the code snippets I gave you are from actual working
code, and you can try it out.

Regards,
Oumer

Jee J.Z. wrote:

>Hi Oumer,
>
>Thank you for your explanations. They are quite helpful. Please see inline:
>
>
>>In the man pages it says that if you get a negative value then it is a
>>failure , otherwise it is a sucess.
>>
>
>Right. I've figured out the return value of ipq_set_verdict(), which is 28 +
>data_len (one of the input parameters of ipq_st_verdict specified by users).
>
>>The reason that you may get the packets dropped may be because you
>>modified them in such a way that they are not valid anymore (you change
>>thing to an invalid ip address or something like that)
>>
>
>Right. But I think I made some changes on the overhead of libipq itself
>rather than on packets, which caused the kernel confused and couldn't figure
>out what the infomation means returned by ipq_set_verdict.
>
>>On how to get the packet info
>>
>>Once you get the packet = ipq_get_packet(buffer)
>>
>>you can access the packet data (including header and payload) from
>>memory location packet +1,
>>
>
>As far as I can see, there are some overheads (info) used by
>ip_queue/netfilter to identify the packet (such as packet_id) and to provide
>some useful info (such as timestamp) to userspace. Therefore, 'packet+1'
>seems not the location of putting the pure packet data (header and payload).
>Instead, from the man page of ipq_get_packet (see the structure of
>ipq_packet_msg), packet+1 should be packet_id. no?
>
>>for example
>>
>>you can use something like
>>
>>usigned char *packet_all = (unsigned char *) (packet+1);
>>
>>then for example to access the ip_header length, which is located from
>>bits 4-7 in the ip header you can use something like
>>
>>ip_header_len = (*packet_all & 0xF) * 4; // the 4 is since the header
>>length is specified as a multiple of 32bits,ie 4 bytes
>>
>>or you can get the total length, which is the third and fourth bytes of
>>the header as
>>
>>total_len = htons(*(unsigned short *) (packet_all + 2)))
>>
>>and so on,
>>
>>and based on the value of this ip header length and the data offset in
>>the tcp header,
>>
>>
>>(to find the data offset in the tcp header you can use something like
>>
>>tcp_header_len = ((*(packet_all + ip_header_len + 12 ) & 0xF0) >> 4 )*
>>4; // the 12 is because we have 2 bytes for source port + 2 bytes for
>>destination port, 4 bytes for sequence number and 4 bytes for ack number
>>in the tcp header before we reach the data offset
>>
>>
>>so the data payload is from unsinged char *start = (packet_all +
>>ip_header_len+ tcp_header_len) till unsinged char *end = start + total_len
>>
>>
>>and I think you can just set the values of the packet, whether header or
>>payload, once you got a pointer to it
>>
>
>Thank you very much for these excellent examples. They make sense. I am just
>a bit confused whether packet+1 is the start point of a packet including its
>header.
>
>Cheers,
>Jee
>
>>
>>
>>Jee J.Z. wrote:
>>
>>>Hi all,
>>>
>>>I am using the libipq library to do userspace programming on netfilter. I
>>>
>am
>
>>>having some problems understanding the return values of the function
>>>ipq_set_verdict():
>>>
>>>When I set verdict (either NF_ACCEPT or NF_DROP) without modifying the
>>>packet, the return value of ipq_set_verdict is 28 and everything works
>>>
>well;
>
>>>however, when I set verdict trying to modify the packet, ipq_set_verdict
>>>returns 88, and the packet seems always to be dropped even when I set
>>>NF_ACCEPT.
>>>
>>>Does anybody know what these return values mean? Moreover, could anybody
>>>tell me how I can successfully modify a packet using libipq? Thank you
>>>
>very
>
>>>much in advance!!
>>>
>>>Regards,
>>>Jee
>>>
>>>
>>>
>>
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 6560 bytes --]