netfilter buglog - May 2007 - [Bug 567] ulogd writes invalid len field in per-packet headers

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=567





------- Additional Comments From kaber@trash.net  2007-05-14 14:28 MET -------
There are two len fields, caplen and len. Which one is wrong?

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=567





------- Additional Comments From kaber@trash.net  2007-05-14 14:28 MET -------
There are two len fields, caplen and len. Which one is wrong?

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=567





------- Additional Comments From jaap.keuter@xs4all.nl  2007-05-14 15:10 MET
-------
The Wireshark bugreport quotes the error produced by this line:
  *err_info = g_strdup_printf("pcap: File has %u-byte packet, bigger than
maximum of %u", hdr->hdr.orig_len, WTAP_MAX_PACKET_SIZE);
Where hdr.orig_len comes from this structure:
struct pcaprec_hdr {
	guint32	ts_sec;		/* timestamp seconds */
	guint32	ts_usec;	/* timestamp microseconds (nsecs for PCAP_NSEC_MAGIC) */
	guint32	incl_len;	/* number of octets of packet saved in file */
	guint32	orig_len;	/* actual length of packet */
};

The sample capture shows for the first packet incl_len "00 00 00 30"
(matching
the contents of the captured packet), while orig_len shows "00 30 00
00".


-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=567





------- Additional Comments From jaap.keuter@xs4all.nl  2007-05-15 18:14 MET
-------
>From ulogd_PCAP.c
------8<-------
#define INTR_IDS 	5
static struct intr_id intr_ids[INTR_IDS] = {
	{ "raw.pkt", 0 },
	{ "raw.pktlen", 0 },
	{ "ip.totlen", 0 },
	{ "oob.time.sec", 0 },
	{ "oob.time.usec", 0 },
};

#define GET_VALUE(x)
ulogd_keyh[intr_ids[x].id].interp->result[ulogd_keyh[intr_ids[x].id].offset].value
#define GET_FLAGS(x)
ulogd_keyh[intr_ids[x].id].interp->result[ulogd_keyh[intr_ids[x].id].offset].flags

static int pcap_output(ulog_iret_t *res)
{
	struct pcap_pkthdr pchdr;

	pchdr.caplen = GET_VALUE(1).ui32;
	pchdr.len = GET_VALUE(2).ui32;
------8<-------
It seems that the IP packet total length is placed in the packet header. This is
possibly wrong in two ways. 
1. ip.totlen is a 16bit value in the IP header, so the method should probably be
ui16.  It makes sense looking at the sample capture file.
2. pchdr.len is meant as the reported size of that PDU, which can be a fragment
of the original IP SDU. I don't know how ip.totlen is set, but that might be
the
unfragmented size?.

Looking at the term 'packet' it is easy to make this mistake. What is
meant by
the field 'len' though is the size of the SDU on the wire, that is eg.
an
Ethernet frame. That is the reason the Wireshark designation for the lowest
level SDU has changed from 'packet' to 'frame'. 

In this case (RAW_IP) the IP SDU is the lowest level SDU, so these lengths are
the same. This simple patch should do the trick:
------8<-------

	pchdr.caplen = GET_VALUE(1).ui32;
-	pchdr.len = GET_VALUE(2).ui32;
+	pchdr.len = GET_VALUE(1).ui32;

------8<-------

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.