osscan2.cc ACK/URG anomaly

["Gisle Vanem" <gvanem () yahoo no>]

Regarding my message:
 http://seclists.org/nmap-dev/2014/q1/169

I think I've found the cause of this ACK/URG anomaly. But would 
like to ask here first...

void HostOsScan::sendTEcnProbe(HostOsScanStats *hss) {
...
 send_tcp_probe(hss, o.ttl, false, NULL, 0,
                tcpPortBase + NUM_SEQ_SAMPLES + 6, hss->openTCPPort,
                tcpSeqBase, 0,
                8, TH_CWR|TH_ECE|TH_SYN, prbWindowSz[6], 63477,  << line 1791
                prbOpts[6].val, prbOpts[6].len, NULL, 0);
}

Why does it send a URG-value without the TH_URG flag set here?
IMHO, this should be:
                8, TH_CWR|TH_ECE|TH_SYN|TH_URG, prbWindowSz[6], 63477,

The same problem with the ACK-flag; in several places the 'tcpAck != 0' member 
can be sent with no TH_ACK set. Is this an oversight or working as designed?

So now after a local patch to osscan2.cc, the 'nmap -sT -ddd ...' output for call at
line 1791 gives:
 SENT (6.3910s) TCP [10.0.0.6:39171 > 10.0.0.1:22 SUEC seq=250798708 ack=0 
 off=8 res=8 win=3 csum=0xC6B7 urp=63477 <wscale 10,nop,mss 1460,sackOK,
 nop,nop>] IP [ver=4 ihl=5 tos=0x00 iplen=52 id=63235 foff=0 ttl=49 proto=6 csum=0x7eba]
Send probe (type: OFP_TECN, subid: 0) to 10.0.0.1

The 'U' says the URG-value is !=0. Makes more sense?

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