Feature #3243
open
ndndump: follow TCP stream
0%
Description
Currently, ndndump is able to recognize NDN packets on IPv4/IPv6 TCP tunnels only if an NDN packet is aligned to the front of a TCP segment.
If a TCP segment contains more than one NDN packets, all but the first NDN packet would be discarded.
If a NDN packet spans multiple TCP segments, it would be discarded, and "TLV length exceeds buffer length" error may appear.
ndndump should follow the TCP stream in the general case, and parse NDN packets in order.
In case of packet loss or reordering, a fallback heuristic of "looking for NDN packet aligned to the front of a TCP segment" can be used.
Files
Updated by Junxiao Shi over 8 years ago
- File 20151007120415.pcap 20151007120415.pcap added
- File 20151007120415.tlv 20151007120415.tlv added
Under low traffic, NDN packets between NFDs typically align to the front of TCP segments.
However, this is not the case under high traffic, such as high definition video.
Attached is part of a tcpdump capture that shows this phenomenon, and the extracted payload that can be successfully parsed by ndn-dissect.
Updated by Alex Afanasyev over 8 years ago
I'm kind of inclined towards rejecting this issue. We may want to print out partial packet information, but following actual TCP stream requires a non-trivial implementation of tcp stream reassembly.
Moreover, a similar functionality is already available in wireshark (and its command-line version tshark) with LUA NDN filter.
Updated by Junxiao Shi over 8 years ago
Is there any harm in doing TCP reassembly?
Following TCP stream isn't so hard: a hashtable keyed by <next-tcp-sequence, src-endpoint, dst-endpoint>.
I did TCP reassembly for RPC messages in 180 lines of C code: nfsdump:commit:677b7e1f5b4cef742f046fb8c98765841f885364.
Updated by Davide Pesavento over 5 years ago
- Subject changed from dump: follow TCP stream to ndndump: follow TCP stream