[Ns-bugs] [Bug 161] Link layer pcap tracing is broken for many point-to-point simulations

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=161





------- Comment #4 from tomh at tomh.org  2008-04-10 08:14 -------
(In reply to comment #2)
> Created an attachment (id=123)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=123&action=view) [edit]
> 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


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.