> -----Original Message----- > From: netfilter-devel-owner@xxxxxxxxxxxxxxx [mailto:netfilter-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of U.Mutlu > Sent: Friday, September 23, 2011 9:20 AM > To: netfilter-devel@xxxxxxxxxxxxxxx > Subject: [libnetfilter_queue] extra data after payload > > Hi, > > when reading queue data via the recv() function > then one gets a return value much longer than the payload data, > so there are some extra data after the payload. > What kind of extra data is it? > > 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, followed by other netlink structures. Take a look at net/netfilter/nfnetlink_queue.c:nfqnl_build_packet_message() in your kernel source tree for the details. The messages containing packets contain a 768 in the (struct nlmsghdr *)->nlmsg_type field at the beginning of the message, which corresponds to NFNL_SUBSYS_QUEUE << 8 | NFQNL_MSG_PACKET. Note there appear to be other message types on these sockets. I've seen messages with nlmsg_type == 0 coming off these NFQUEUE sockets too, which apparently contain something other than IP packets and for which you won't get a callback when you call nfq_handle_packet(). So your code shouldn't depend on a 1 to 1 relationship between calls to nfq_handle_packet() and the callback you register via nfq_create_queue(). At least that's what I've observed after having spent the last couple of days playing with this. Jeff Haran ��.n��������+%������w��{.n����z�����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
