tcpdump mailing list archives
Re: RFC: DLT for "application TCP stream capture"
From: "Paul \"LeoNerd\" Evans" <leonerd () leonerd org uk>
Date: Wed, 14 Jan 2015 15:28:19 +0000
On Tue, 13 Jan 2015 19:32:46 -0800 Guy Harris <guy () alum mit edu> wrote:
LINKTYPE_IP_PAYLOAD, or something such as that, with a link-layer (pseudo-)header containing:
I'm happy with that as a name.
an indication of whether the network-layer addresses are IPv4 or IPv6; source address; destination address; IP protocol number (6 for TCP, 17 for UDP, etc.); source port number; destination port number.
I'd prefer to also have a flag to say if this segment was received or transmitted - I've never liked inferring that information from the identity of the source/dest. addresses. It then makes it impossible to sensibly analyse the file if you don't know the underlying networking configuration, as may well be the case for .pcap(ng) files copied from one machine to another.
The description would explicitly note that, at least for TCP, there is *NO* guarantee that packets correspond to actual TCP segments; for UDP, packet boundaries *are* exposed to the application, so maybe we make that TCP-only.
That seems reasonable; that's the only guarantee we can really give. Also, for "transmitted" data, we don't even give the guarantee that this data ever reached the network. All the userland knows is it told that data to the kernel. It could still be sitting in a buffer. Also, how to signify the eventual termination of a TCP stream? Does a zero-byte segment seem sensible? Or should perhaps there be an explicit "end" flag?
Do you need to provide the timing information in a form other than the time stamp in a pcap record or a pcap-ng packet block?
I don't think any other timestamping is needed (or in fact accessible to userland most of the time anyway). I'm sure the pcap(ng) timestamps alone will be sufficient. I think then, the header fields need to be: 1 byte | IP version: 4, 6 1 byte | IP protocol number: 6=TCP, 17=UDP 1 byte | Flags: 0x01 = write/!read 2 bytes | Source port 2 bytes | Destination port 2 bytes | Body length - 0=EOF, up to 65535 bytes {addr} bytes | Source address \ + IP version determines the length {addr} bytes | Destination address / {len} bytes | Segment payload I wonder though, whether the flags could be combined with the IP version field, given as the version in the underlying (real) IP packet anyway is only a 4-bit field. 1 byte | Flags and IP version: bit7 [ VVVV...W ] bit0 VVVV = IP version W = write/!read Does it seem sensible to merge those to save a byte of output? (and also ensure nice alignment of the header to 32bit boundaries). It does momentarily seem wasteful to repeat the source/destination information in every single packet (especially in the case of IPv6 with its 256bits of addressing information). Though I don't know if that outweighs the statefulness and added complexity of representing "flow setup" operations and "more bytes of data sent/received on this flow" as extra frame types. -- Paul "LeoNerd" Evans leonerd () leonerd org uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 13)
- Re: RFC: DLT for "application TCP stream capture" Guy Harris (Jan 13)
- Re: RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Michael Richardson (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Denis Ovsienko (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Michael Tuexen (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Guy Harris (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 15)
- Re: RFC: DLT for "application TCP stream capture" Paul "LeoNerd" Evans (Jan 14)
- Re: RFC: DLT for "application TCP stream capture" David Laight (Jan 15)
- Re: RFC: DLT for "application TCP stream capture" Guy Harris (Jan 13)
- Re: RFC: DLT for "application TCP stream capture" David Laight (Jan 15)