Re: about ipq_set_verdict()

[Oumer Teyeb <oumer@kom.auc.dk>]

[-- 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 --]