Re: UDP 'bytes=' option with comm.exchange()

[Kris Katterjohn <katterjohn () gmail com>]

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

Brandon Enright wrote:
> In testing a script I'm working on fixing/updating I noticed that the
> the comm.exchange() call in dns-test-open-recursion.nse doesn't behave
> properly.
>
> Right now the line is:
>
> local status, result = comm.exchange(host, port, request, {proto="udp"})
>
> When this script is run it appears to hang.  A packet capture shows
> that the DNS server does, indeed, respond.
>
> If I add the bytes=1 option to the call the script behaves properly.  I
> propose changing the comm call to:
>
> local status, result = comm.exchange(host, port, request, {proto="udp", bytes=1, timeout=10000})

This was one of the scripts I couldn't test while converting them over to use
the comm library, but it looked OK to me.  Whoops :)

> So my question is, can comm.exchange be used with UDP without
> specifying a byte count?  If so, how and under what circumstances?  Is
> this by design?

I think the problem is that if no line or byte values are passed, the library
defaults to reading as many lines as possible.  While I thought this was good
behavior when initially writing comm (because of the typical line-based
protocols I figured would be used most), I think defaulting to reading as many
bytes as possible seems like better behavior to me now (for this very reason).

Unless there is any objection to this change, I will make it later tonight.

> Brandon

Thanks,
Kris Katterjohn

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

iQIVAwUBSIz5PP9K37xXYl36AQIQBA//UHNvtY7fQrlMT1NkJHqygxbGsyT1WiNW
iqh/dWP+r/yezuiTWC64iFmO3gENBM0jbASHMnwSbNnOgZQ2RDuqLBBNwbZDth5f
B84WBS82CHNBt5mfZrF7BAHXfSNAJxGxwbP5PaWd+gCugfw7ZJBWZ2eYo09Qo+sO
uZ2OR/rd0QEkVwkuRcE0/HDwL9ZTaNAiPfkp046QCreG533s0Phu2DJtQ+euF91T
uEmkaDcvPTVuAyeFbNYTdhQ2mbJ0roPMOElA0V8pxpqlPsd1A3+GsfHicEjqLOjt
FuiEzSz8QPGDGg5r0CzRToH09+4K2C09WML0p0DhOiPKJXnog0e9n2zOjnayV6/3
zZ5uTjxNtjmf+f15yc2BrHcf6lh6PpwwYCKm4j5j+YsGjtCuZZFuX8t3fv+Qkekw
fYoWmcTCMmP2PFSV08Qpm6ksxzBalX1KitzIyRxkSBjdbpPz11duM7W7NI6u1gbG
5LvFUNBm/AkQy3wz1stt5MkZMJLvjio1CP82IqPXXumlOaWZHC54LHoHVLQCzSB2
5+X75a4tZ17UV6YxnP2hP+NpIhdeJQksUmUShTs7KROH+rOPSjPlg/KEQWlAWecX
R3yKPEx8/yydI55VhIKKqfqwlBPL3SB5U/3SpLRB4kBmYr9nY6MncZvI9uwuEBt3
irnGaCRnjw4=
=n4Vu
-----END PGP SIGNATURE-----

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