Fwd: SPP feature request (or bug report?)

[Michael Welzl < >]

Hi,

FYI - I don’t know if this is interesting for you folks at this point or not…

For SPP, you take a pcap trace on the sender host, and a pcap trace on the receiver host, and feed both in, and then the tool gives you *precise* RTT values.

Of course we can get RTT values out of ns-3 in a different way, but this way is perhaps more trustworthy… and exactly the same as what I’d get from real life in the TEACUP testbed. When I tried, it didn’t work for me, and here’s an explanation on how to fix it.  That’s just in case you even need it…

Cheers,

Michael

Begin forwarded message:

From: grenville armitage < " class=""> >

Subject: Re: SPP feature request (or bug report?)

Date: December 22, 2017 at 5:52:58 AM GMT+1

To: Michael Welzl < " class=""> >, Sebastian Zander < " class=""> >

Cc: David Hayes < " class=""> >

Resent-From: < " class=""> >

Michael,

Sorry for delayed reaction, was travelling and then lost track.

I believe the problem is "they contain PPP". Within instance.c:createInstance() there's a switch statement that parses each pcap frame's encapsulation, and PPP isn't one of the known encaps. (However, this function should be complaining loudly that PPP is unknown encapsulation, and exiting. I'm not sure why you're not seeing that error message.)

Per http://www.tcpdump.org/linktypes.html you could probably patch instance.c:createInstance() to add a case for DLT_PPP that indexes 2 bytes into the pcap frame, and SPP should then decode your ns-3 pcap files.

cheers,
gja

On 12/06/2017 23:10, Michael Welzl wrote:

" type="cite" class="">

Dear Grenville, dear Sebastian,

I’m cc’ing David because I know he also worked on SPP and he and I were chatting about this issue in Skype - but according to http://caia.swin.edu.au/tools/spp/  you two are the “program members”, so I guess you’re the people to ask…

I’ve recently begun to use ns-3 (which, btw, I don’t recommend much - it’s really painful! long story for why I’m doing this), which can produce pcap files (one of its good things).  I’m attaching two pcap files from a simple TCP test, taken close to the sender and close to the receiver, as recommended for SPP - and I’d like to use SPP to get the RTT from this. The benefit, for me, would be to have a uniform way of obtaining RTTs and then creating plots for real-life tests as well as simulations.

The problem is, these files seem to be fine for several tools (such as wireshark or tcpdump), but not for SPP:
running:

spp -a 10.1.1.1 -A 10.2.1.1 -f new1.pcap -F new2.pcap -cp

produces no output at all.
I tried e.g. -v10, to use a large number for the verbosity level (I also couldn’t find the numbers specified anywhere). This gave me a long list of lines saying “INFO: Searched through 0 instances”.
It seems that SPP has a problem in reading these files and just can’t parse the packets.

I tried several conversion tools, but none of them helped me - e.g. tcprewrite (from the tcpreplay suite) says that it can’t handle the files, if I understood correctly that’s because they contain PPP which tcprewrite doesn’t support.
LibTrace’s “traceconvert” can only produce erf or pcap output on my Mac; for erf, it fails for some reason. When creating pcap, it gives me new, different pcap files (that look the same to me in Wireshark though), yet spp still doesn’t work on them.

If you have a simple idea on how to convert these files, I’d be very thankful as well - but for convenience of ns-3 users out there, it might be a good idea to fix this. And, who knows, maybe this is a deeper problem: maybe the pcap format IS fine, and it’s just that spp doesn’t like PPP, for example?   This might be a tiny little thing for you folks to fix…  or not, who knows. Anyway, I thought it won’t hurt to send this email  :)

Thanks, cheers,
Michael

-- 
Professor Grenville Armitage
School of Software and Electrical Engineering
Faculty of Science, Engineering and Technology
Swinburne University of Technology, Australia
http://i4t.swin.edu.au/people/garmitage