Bugzilla – Bug 161
point-to-point netdevice pcap traces aren't libpcap-compatible
Last modified: 2008-07-01 13:32:26 EDT
You need to log in before you can comment on or make changes to this bug.
The output traces generated by: PointToPointHelper::EnablePcap ("tcp-large-transfer") all really appear to be screwed up. The packets are all malformed and tcpdump and wireshark don't correctly show any TCP traffic.
I have not been able to confirm this-- I just ran: tcpdump -nn -tt -r tcp-large-transfer-0-1.pcap -vv reading from file tcp-large-transfer-0-1.pcap, link-type RAW (Raw IP) 0.000000 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: TCP (6), length: 40, bad cksum 0 (->61cc)!) 10.1.3.1.49153 > 10.1.2.2.50000: S, cksum 0x0000 (incorrect (-> 0x138c), 0:0(0) win 65535 0.040153 IP (tos 0x0, ttl 63, id 0, offset 0, flags [none], proto: TCP (6), length: 40, bad cksum 0 (->62cc)!) 10.1.2.2.50000 > 10.1.3.1.49153: S, cksum 0x0000 (incorrect (-> 0x137b), 0:0(0) ack 1 win 65535 0.040153 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto: TCP (6), length: 40, bad cksum 0 (->61cb)!) 10.1.3.1.49153 > 10.1.2.2.50000: ., cksum 0x0000 (incorrect (-> 0x137c), 1:1(0) ack 1 win 65535
Created an attachment (id=123) [details] Test case for this bug (In reply to comment #1) > I have not been able to confirm this-- I just ran: > > tcpdump -nn -tt -r tcp-large-transfer-0-1.pcap -vv The filenames generated by PointToPointHelper::EnablePcap begin with tcp-large-transfer-0-0.pcap, not *0-1.pcap ; the *0-1.pcap file in fact doesn't exist when you run tcp-large-transfer with the patch to exercise the bug. I suspect you are using the other helper InternetStackHelper::EnablePcap.
Renamed the bug to reflect its impact. I checked out the reference traces and viewed them in wireshark. The following examples have traces which are all mangled: simple-error-model simple-global-routing simple-point-to-point-olsr And of course, my example from my patch. It appears this isn't a TCP problem at all. These examples have on commonality, and that is a point-to-point topology.
(In reply to comment #2) > Created an attachment (id=123) [edit] [details] > Test case for this bug > > (In reply to comment #1) > > I have not been able to confirm this-- I just ran: > > > > tcpdump -nn -tt -r tcp-large-transfer-0-1.pcap -vv > > The filenames generated by PointToPointHelper::EnablePcap begin with > tcp-large-transfer-0-0.pcap, not *0-1.pcap ; the *0-1.pcap file in fact doesn't > exist when you run tcp-large-transfer with the patch to exercise the bug. I > suspect you are using the other helper InternetStackHelper::EnablePcap. > You're right. I was looking at an old trace. The problem here is that point-to-point uses an LLC/Snap header which cannot be parsed properly by tcpdump since it is not prepended with the typical 802.3 header. The LLC header is being used to carry the L3 protocol information, for demuxing on the receive side. One possible solution is to implement instead a PPP header for this net device type, which tcpdump could read. PPP is probably a desirable protocol header for the future, anyway. Or maybe there is a different type code that could be used to read this header, but it wasn't apparent to me in reading this: http://anonsvn.wireshark.org/wireshark/trunk/wiretap/libpcap.c
Rename the bug once more to reflect the heart of this issue.
Removed LLC/SNAP, Added PPP encapsulation. Wireshark likes it a lot.