[PATCH] Pcap recv time for NSE scripts, qscan.nse update

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey everyone,

I've attached a patch to let NSE scripts obtain the pcap capture time through
pcap_receive() instead of (in the case of qscan.nse) having to resort to using
clock_ms().

For whatever reason it was chosen to have a msec function clock_ms(), I chose
to have the pcap time returned as msecs instead of the usual usec available in
struct timeval.  I don't see a point in having different resolutions here
causing scripts to have to perform conversions.  Unless a usec clock function
is desired, in which case the pcap time should be usec as well.  Personally, I
don't think that's such a bad idea.

Since the clock_ms() and new pcap time are both using milliseconds, I added a
new TIMEVAL_MSECS() macro to nbase.h for them to share.  This converts a
timeval to milliseconds in unsigned long long format.  This integer type is
used in several other places in the codebase so it should not be a problem,
but do correct me if I'm wrong.  A couple of years ago I fixed a bug in Nmap
by using this type, and I don't recall any difficulty.  clock_ms() was
implemented by casting to lua_Number while converting to msecs, and that's
different than this macro because it's unsigned long long until it's pushed
onto the lua stack as lua_Number.

The pcap time is available as another return value from pcap_receive(), after
the layer 3 data.  I think this is fine because having this time can be
important and I don't know how it could get in the way of anything.  It
shouldn't affect other scripts which don't try to grab this because (unless
I've forgotten more Lua than I realize) it should just be discarded without
worry.  Am I missing anything here?

What follows is a sample of test output from qscan.nse showing the rtt
differences (msecs of course) when calculating with clock_ms [clck] vs the
pcap time [pcap] at the same time.  In this script, the initial send time is
recorded with clock_ms() to compare with these times for the rtt.

rtt(clck)=3
rtt(pcap)=2
rtt(clck)=3
rtt(pcap)=2
rtt(clck)=8
rtt(pcap)=3
rtt(clck)=3
rtt(pcap)=3
rtt(clck)=5
rtt(pcap)=4
rtt(clck)=2
rtt(pcap)=2

Notice the one large difference of 8 vs 3 about half way down.  This isn't
typical, but similar has happened a few times that I've seen.  I often see
differences of 1ms here.

The attached patch has pcap_receive() return the pcap time, updates qscan.nse
to use the new time, adds the timeval macro to nbase.h and updates clock_ms()
to use it.

Please let me know what you think and I'll commit soon if there are no issues.

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMR5+CAAoJEEQxgFs5kUfuTfoQAMJow7HF6Oq10M6RpqvH6JTW
GJlxy3ctrdPr9dsA4Dyd72YljdTViLwX5uuLOPuMjaWYDEwV426PliMNlC7utMJ0
CoylI9SNSztjKLwFPDEb/FeYG6TijmIBDCvlwiBcgh48Sc2umv3YWGMivGgHGZEE
96QsAb2TUZgmyQZg4WQpD3Gy6WD9JJnSi71d2F2VjcitJvLvDkt1MrB7DFgi9F3n
BL7RTYeeoeSzIL9PRy2hjCm6gVFlpF67sWCH/QZDAmF9tTZCImBYZ8JWsqvZpPh3
m3t7t7uH/dYt7n/UdgUPy6W/CfcttpKbWBj/H/PCrCMOHpH1M6yPeuqeFPFGxt8i
BFm94dzV0Ac9wZkul8CuKYwh1DZ4mQ4dIjmojlQAuxjVe0NjOrjT2ytJ+EnVx1bP
FhSK6v/5PoEaO2il5uh5h6c3AvndGgEg39vuNkqU81GJRvpkxmBkMJrfjwaDW9aY
hgt43jVDGn3Gmfj4b87cnra+rdObZO3754LOOozOzQHtY5UQgEN5VQhZ/cF8Cbyh
jop0wDmWl8TyFzNY84ORhgAmWeOyyy2jmFL2+cFKFMiyMu903PQFtoQgSLmAb1yp
Ux7KyHgjW1QKr6RxXlYHnuhFBCKRo8z9aImZadKkk7Mm1joP1uNnuRLrgkCxD2Ms
G1yrNbOw8DD093O484an
=pOV8
-----END PGP SIGNATURE-----

Attachment: nsepcaptime.patch
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/