Re: [libnetfilter_queue] extra data after payload

["U.Mutlu" <for-gmane@mutluit.com>]

U.Mutlu wrote, On 2011-09-26 20:58:
> Jeff Haran wrote, On 2011-09-26 19:45:
>>> -----Original Message-----
>>> From: netfilter-devel-owner@vger.kernel.org [mailto:netfilter-devel-
>>> owner@vger.kernel.org] On Behalf Of Jan Engelhardt
>>> Sent: Saturday, September 24, 2011 1:24 AM
>>> To: U.Mutlu
>>> Cc: netfilter-devel@vger.kernel.org
>>> Subject: Re: [libnetfilter_queue] extra data after payload
>>>
>>> On Saturday 2011-09-24 10:08, U.Mutlu wrote:
>>>>>> for example:
>>>>>> rv = recv(fd, buf, sizeof(buf), 0); // rv=84
>>>>>> ...
>>>>>> ret = nfq_get_payload(tb,&data); // ret=40 (ie. ip + tcp
>> pkt, both
>>>>>> w/o
>>>>>> options, and tcp w/o user data)
>>>>>>
>>>>>> So, here, what are the extra 44 bytes after the tcp data?
>>>>>
>>>>> I believe you will find there is a struct nlmsghdr at the
>> beginning of the
>>>>> data, before the IP header
>>>>
>>>> nlmsghdr has size 16, I've not figured out yet what comes after it
>> before
>>> the
>>>> (optional) payload starts.
>>>
>>> (It's struct nlmsghdr, struct nfgenmsg, struct nfqnl_msg_packet_hdr.)
>>>
>>> Suffice to say that, what buf actually contains is
>> implementation-defined, and
>>> "uninteresting", since you chose to use a library to deal with it for
>> you,
>>> abstracting the whole thing.
>>
>> Well, not necessarily "uninteresting". Some people like to understand
>> how something they are using works.
>>
>> Plus, if you don't know how big these headers are, you can you know how
>> big a buffer you need to read the message off of the socket into without
>> truncating the IP packet at the end?
>>
>> The sample code at
>> http://www.netfilter.org/projects/libnetfilter_queue/doxygen/group__Queu
>> e.html shows a call to recv() made into an undeclared variable named
>> "buf" with the amount of data to be read specified as "sizeof(buf)".
>>
>> I don't see anything in the API to call to tell the user this and I
>> haven't seen it in the documentation either, though perhaps I've missed
>> it.
>
> One can get the header size by subtracting the payload start from the
> buffer start.

FIX: of course the other way around... :-)

> So, the header(s) seems to have the mentioned total len
> of 44 bytes, but not sure if that's true always.
>
> BTW, since the sample above contains this func call:
> nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff)
> it then practically means that buf must be >= 64k-1+hdrsize, ie. at least 65579 bytes...