--packet-trace errors on BSD

[David Fifield <david () bamsoftware com>]

Hi,

Running OS detection on Mac OS X with --packet-trace gives this
anomalous output. Note the ?? in the T2, T4, and T6 probes (subid 1, 3,
and 5; the "Send probe" line follows the SENT it refers to).

SENT (1.1530s) TCP 127.0.0.1:?? > 127.0.0.1:?? ?? ttl=51 id=10632 iplen=15360 frag offset=512  (incomplete)
Send probe (type: OFP_T1_7, subid: 1) to 127.0.0.1
SENT (1.1830s) TCP 127.0.0.1:45969 > 127.0.0.1:22 SFPU ttl=46 id=64202 iplen=15360  seq=3578210164 win=256 <wscale 
10,nop,mss 265,timestamp 4294967295 0,sackOK>
Send probe (type: OFP_T1_7, subid: 2) to 127.0.0.1
SENT (1.2140s) TCP 127.0.0.1:?? > 127.0.0.1:?? ?? ttl=47 id=1533 iplen=15360 frag offset=512  (incomplete)
Send probe (type: OFP_T1_7, subid: 3) to 127.0.0.1
Got a valid response for probe (type: OFP_T1_7 subid: 3) from 127.0.0.1
SENT (1.2440s) TCP 127.0.0.1:45971 > 127.0.0.1:7 S ttl=48 id=37148 iplen=15360  seq=3578210164 win=31337 <wscale 
10,nop,mss 265,timestamp 4294967295 0,sackOK>
Send probe (type: OFP_T1_7, subid: 4) to 127.0.0.1
Got a valid response for probe (type: OFP_T1_7 subid: 4) from 127.0.0.1
SENT (1.2750s) TCP 127.0.0.1:?? > 127.0.0.1:?? ?? ttl=59 id=30344 iplen=15360 frag offset=512  (incomplete)
Send probe (type: OFP_T1_7, subid: 5) to 127.0.0.1

The --packet-trace code thinks that those probes are IP fragments (frag
offset=512). See also the too-big iplen of 15360 (0x3c00) in each
packet. The reason for this is this code in tcpip.cc:

  /* Equally bogus is that the IP total len and IP fragment offset
     fields need to be in host byte order on certain BSD variants.  I
     must deal with it here rather than when building the packet,
     because they should be in NBO when I'm sending over raw
     ethernet */
#if FREEBSD || BSDI || NETBSD || DEC || MACOSX
  ip->ip_len = ntohs(ip->ip_len);
  ip->ip_off = ntohs(ip->ip_off);
#endif

The ip_len and ip_off are stored in host byte order; i.e., opposite the
way you would expect them to be. This works fine for sending, the
problem happens when the values are read back later for --packet-trace.
Because the values are backwards, 0x003c becomes 0x3c00 (15360), and the
don't fragment flag makes ip_off 0x4000, which is read back as 0x0040,
which when multiplied by 8 appears as a fragment offset of 512.

Like the comment suggests, this happens only with raw sockets and goes
away when using --send-eth.

I fixed this in r14020 by unswapping the values after sending, and
calling PacketTrace::trace with the unswapped values.

David Fifield

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