<div dir="ltr"><div dir="ltr"><div>Hi John</div><div><br></div><div>Frame 45 is a Nack packet. The dissector from git master branch can decode it correctly. You probably have an older version. Even if you have installed the latest version, your Wireshark could be loading an older version elsewhere in the filesystem. It's also possible that your Wireshark version is too old or too new for the dissector. I'm using Wireshark v2.6.3.</div><div><div><img src="cid:ii_jrgn4xkh2" alt="Capture.PNG" style="margin-right: 0px;" width="562" height="228"><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wireshark is capable of reconstructing split packets of TCP streams (regardless the actual packet order) and our dissector simply works on top of that... I did basic tests in the past, but not too extensive ones.<br></blockquote><div><br></div><div>It seems that ndn.lua does not use Wireshark's TCP reconstruction functionality. It tries to interpret each TCP segment individually. Any NDN packet crossing TCP segment boundary cannot be decoded correctly. In a subsequent TCP segment, ndn.lua can find where the packet starts by trying different offsets in <a href="https://github.com/named-data/ndn-tools/blob/7664b12f2ae20fbfbffdb763a2de3ead6cea8631/tools/dissect-wireshark/ndn.lua#L370-L381">findNdnPacket function</a>.</div><div><br></div><div>Frame 1267 has two Data packets, and four leftover bytes 06fd03c0 at the end. These four bytes indicates that the next 960 bytes should be a Data packet.<br></div><div>Frame 1268 TCP payload starts with 075e080577. ndn.lua discards 07e508, and interprets 0577 as the start of an Interest. Since this isn't actually an Interest, the dissector fails to decode the sub elements such as Name, so it displays as just "Interest".</div><div><br></div></div><div>Following TCP stream is a useful feature. It's now tracked as <a href="https://redmine.named-data.net/issues/4820">https://redmine.named-data.net/issues/4820</a></div><div><br></div><div>Yours, Junxiao</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 28, 2019 at 11:59 AM Dehart, John <<a href="mailto:jdd@wustl.edu">jdd@wustl.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="overflow-wrap: break-word;">
<div>Here is a link to a snippet from the pcap file that is giving me problems.</div>
<div><br>
</div>
<div><a href="https://www.arl.wustl.edu/~jdd/tcpdump.2000.pkts.pcap" target="_blank">https://www.arl.wustl.edu/~jdd/tcpdump.2000.pkts.pcap</a>
<div><br>
</div>
</div>
<div>If I run this through wireshark with the ndn-dissector from ndn-tools </div>
<div>version  0.6.2-ppa1~xenial (version on the NDN Testbed),</div>
<div>I get Lua Errors for several packets, for example Frame # 45.</div>
<div><img id="gmail-m_505327681908546524348F3A1D5-B362-40B9-9F47-76D1041E2EE6" src="cid:168959e6a9d5b2e86771"></div>
<div><br>
</div>
<div>Also, I thought wireshark used to display the NDN names in the Info field, but it is not doing this now.</div>
<div><br>
</div>
<div>Full discolosure: This pcap file was generated on ONL where we are still running NFD 0.6.1.</div>
<div>And for various reasons we have to continue running that version for a while longer.</div>
<div>I have tried processing it with wireshark there as well and have different problems.</div>
<div>For example, frames 1268, 1270 and 1271 are not processed properly. </div>
<div><img id="gmail-m_5053276819085465243A91A739E-94EA-4909-9C02-00ABB48A1893" src="cid:168959e6a9d5b206ef62"></div>
<div>Any help is appreciated.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>John</div>
<div><br></div>
</div>

</blockquote></div></div></div>