Re: Nmap/Nping bug on udp checksum calculation

["Luis MartinGarcia." <luis.mgarc () gmail com>]

Hi Michael,

This is actually a very good catch. Thanks!

It is my fault. I just assumed that the ipv4_pseudoheader_cksum() solved
all the problems automagically, and forgot to implement that specific
check for UDP. As of r32494, I've patched nping's dev branch (you can
check it out doing "svn co
https://svn.nmap.org/nmap-exp/luis/nmap-npingchanges";.

I have replicated the packet that you mentioned as an example, and now
it shows the correct 0xFFFF checksum. See below.

This also let me discover another bug in that branch (not the one branch
you tried). Nping wasn't setting UDP length properly. It is now fixed
too (r32493).

Please let me know if this solves the issue for you.

Thank you very much for reporting this. Best regards,

Luis MartinGarcia.




luis@aberdeen
~/Desktop/repos/svn.nmap.org/nmap-exp/luis/nmap-npingchanges/nping $
sudo ./nping -v4 -c0 --udp  --delay 0 -g 51623 -c1 -p 9 --data
"0x1111111111111111111111111111111111111111" --id 0x426B -S 192.168.5.2
192.168.5.8 --send-eth -e wlan0 --dest-mac ff:ff:ff:ff:ff:ff

Starting Nping 0.6.26SVN ( http://nmap.org/nping ) at 2013-11-03 18:36 CET
SENT (0.0000s) IPv4[192.168.5.2 > 192.168.5.8 ver=4 ihl=5 tos=0x00
iplen=48 id=17003 foff=0 ttl=64 proto=17 csum=0xACF7] UDP[51623 > 9
len=28 csum=0xFFFF] Payload[20 bytes]
0000   45 00 00 30 42 6b 00 00  40 11 ac f7 c0 a8 05 02  E..0Bk..@.......
0010   c0 a8 05 08 c9 a7 00 09  00 1c *ff ff* 11 11 11 11  ................
0020   11 11 11 11 11 11 11 11  11 11 11 11 11 11 11 11  ................

Raw packets sent: 1 (62B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Tx time: 0.00019s | Tx bytes/s: 333333.33 | Tx pkts/s: 5376.34
Rx time: 1.00129s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
Nping done: 1 IP address pinged in 1.10 seconds





On 11/02/2013 11:38 PM, Michael Weber wrote:
> Hi,
> my name is Michael Weber and I'm a computer science student from Würzburg,
> Germany.
> I'm currently developing some network hardware and applied some tests to it
> using Nmaps Nping to send some custom build frames.
> While tracing them in wireshark I stumbled upon some strange behavior, which
> might be a bug in Nmap/Nping.
>
> Sending UDP data can contain but must not contain a checksum. The checksum,
> must be transmitted as all ones if the calculated value is all zero. An all
> zero value denotes that no checksum has been calculated (see rfc 768)
> In Nmap the checksum is calculated in netutil.cc (ipv4_pseudoheader_cksum)
> called from within UDPHeader.cc (UDPHeader::setSum) as a quick search in the
> sources revealed.
> I think the return value must be checked for zero like it's done in
> ipv6_pseudoheader_cksum before it is returned or, if that will lead to some
> trouble for TCP  checksum calculation, must be checked in UDPHeader::setSum
> before the method returns.
>
> Versions used:
> Windows: nmap 6.40/nping 0.6.40 on win7x64ultimate
> Linux: nmap 0.25/nping 0.6.25 on debian6.0.7
>
> This is a snippet from a wireshark trace on my windows machine; the missing
> dest mac is happening on windows only.
> 0000  00 00 00 00 00 00 90 e6  ba 2d 2e 1c 08 00 45 00   ........ .-....E.
> 0010  00 30 42 6b 00 00 40 11  ac f7 c0 a8 05 02 c0 a8   .0Bk..@. ........
> 0020  05 08 c9 a7 00 09 00 1c  _00 00_ 11 11 11 11 11 11   ........ ........
> 0030  11 11 11 11 11 11 11 11  11 11 11 11 11 11         ........ ......  
>
> The calculated checksum should be 0xffff following the calculation
> instructions in RFCs and on some other sources.
>
> Kind regards,
> Michael Weber
>
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/

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