Re: about ipq_set_verdict()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 a ck 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










[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux