[prads-devel] difference in prads.[c|pl] synack

[Edward Bjarte Fjellskål]

Big Big Big Sorry!
(Now, prads.pl should be correct)

As I went through the code today with kacper, I started
doing a QA of the prads.pl matching, compared to p0f matching.

I spent some time reading through how prads.pl parses the
TIMESTAMP option and reading rfc1323... As I found out,
prads.pl lacked a correct implementation of the TIMESTAMP
parsing routine.

I my opinion, p0f also does this in a "not correct way",
as you get a T quirk in a SYNACK package, which is normal
if the timestamp option is set, hence not a QUIRK...
(thoughts are welcome!)

What I did:

# Timestamp.
# Fields: TSTAMP LEN T0 T1 T2 T3 A0 A1 A2 A3
# T(0-3) = our timestamp...
# A(0-3) = Acked timestamp (the ts of the recieved package)
# See http://tools.ietf.org/html/rfc1323 :
# Kind: 8
# Length: 10 bytes
#  +-------+-------+---------------------+---------------------+
#  |Kind=8 |  10   |   TS Value (TSval)  |TS Echo Reply (TSecr)|
#  +-------+-------+---------------------+---------------------+
#      1       1              4                     4
# The Timestamp Echo Reply field (TSecr) is only valid if the ACK
# bit is set in the TCP header; if it is valid, it echos a times-
# tamp value that was sent by the remote TCP in the TSval field
# of a Timestamps option.  When TSecr is not valid, its value
# must be zero.
   my ($c, $t, $ter, $tsize) = (0,0,0,$size);
   ($c, $t, $ter, $rest) = unpack("CNN a*", $rest);