[Bug 567] ulogd writes invalid len field in per-packet headers

bugzilla-daemon at bugzilla.netfilter.org bugzilla-daemon at bugzilla.netfilter.org
Tue May 15 18:14:24 CEST 2007


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





------- Additional Comments From jaap.keuter at 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.



More information about the netfilter-buglog mailing list