tcpdump mailing list archives
Re: RFC: DLT for "application TCP stream capture"
From: Guy Harris <guy () alum mit edu>
Date: Tue, 13 Jan 2015 19:32:46 -0800
On Jan 13, 2015, at 6:05 PM, "Paul \"LeoNerd\" Evans" <leonerd () leonerd org uk> wrote:
I want an HTTP(S) client to write a dump file of the cleartext it is sending/receiving, so I can analyse it later. I'm feeling like maybe a pcap or pcapng file is good for that, so wireshark et.al. can be applied. Ideally it would include timing information, TCP port numbers and IP addresses also. Is there a pcap(ng) DLT for application-written byte streams?
No.
Userland doesn't have access to the entire TCP stack state, so I can't just write out the actual TCP segments. It would be nice though if I could just write out chunks of bytes with timing and direction information. Failing that, I know I /could/ just emit fake IPv4 packets containing TCP segments, but that would be misleading to analysis applications, as it is fake data rather than an accurate representation of what happened. Ideally I would like to be able to emit frames that just say what the TCP stream bytes were and minimal other information that userland had to hand. Thinking more about it of course, there's no reason this has to be restricted to stream-like data - if the format could also handle one-shot datagrams such as seen on UDP or similar, that could be equally useful too.
LINKTYPE_IP_PAYLOAD, or something such as that, with a link-layer (pseudo-)header containing: 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. 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. 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? _______________________________________________ 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)