Re: Call for testers: Nping 0.1BETA1 Released.

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

Hi Ron,


Ron wrote:
> When giving --flags, I actually prefer the way Hping does it with
> -S/-A/-R/--syn/--ack/--rst/etc. Would it be possible to support that
> syntax in addition to the --flags? I also tried doing --flags=SAR,
> which would be equally good, but that didn't work the way I was
> hoping. In fact, when I did that I noticed an issue -- there's no
> error message if I give invalid flags. It may also be interesting to
> allow a 8-bit integer for the --flags field for people hardcore enough
> to memorize flags, but that wouldn't be all that useful :)
You are right, Nping should be more flexible in flag specification. I'm
not going to allow hping style (--syn, --rst, etc.) because flag ack
will have to use option "--ack" and that is already being used for the
TCP Acknowledgement number. However I'ver been working on this and I've
come up with a new approach. Now TCP flags may be specified in any of
the following ways:

As a 8 bit hex number with the format "0xNN" (e.g: 0x20 sets the URG flag)
As a comma separated list of flags "syn,ack,ecn"
Using flag initials (e.g:  SAE sets flags SYN ACK and ECN).
Additionally users may specify the word "random" to set flags randomly,
word "ALL" to set all flags and word "NIL" to set none.

Please let me know what you think. Btw, if you want to try it you'll
have to download the nping-ipv6 branch from the SVN because that is what
I'm working on at the moment.  (Actually I haven't committed the changes
yet because svn server seems to be down but I will asap).




> Also, in the 'help' text displayed when I run 'nping -h', it doesn't
> list the possible flags. I was specifically looking for PSH to see the
> list, and couldn't find it. It might be helpful to have them,
> especially for the two less standard flags (I think hping calls them
> XXX and YYY or something?)
Ok, I've included some of the flags in -h output, I cannot include all
of them because it has to fit into a 80-character-wide terminal. That
still doesn't exactly explain how flags can be specified so users will
have to read the man if they wanna know ;-)

   --flags <flag list>                 : Set TCP flags
(ACK,PSH,RST,SYN,FIN...)

By the way, the two less standard flags are also supported, they are
called ECN (explicit congestion notification) and CWR (congestion window
reduced).


> Speaking of help, I'd suggest a more logical order for the help:
> either going up or down the TCP/IP stack. Right now it's mostly in
> that order, except the IP/IPv6 is under Ethernet.
I also agree with that. I'll move the Ethernet section so it comes after
the network layer stuff.

> A feature of Hping that I really like, that may or may not be trivial
> to implement, is the ability to change the port/ttl using the keyboard
> during a scan. That lets me do a manual traceroute or portscan, which
> I like.

Well, there is not enough time to implement this at the moment but I
will add it to the TO-DO list so it gets implemented at some point in
the future.

> Speaking of traceroutes, something else I miss is DNS resolution. As
> much as I normally use -n on most programs to stop them from resolving
> DNS, there are times, such as on a traceroute, when I'd actually like
> the program to do reverse DNS lookups. Is that something that's
> possible/useful? I'm not sure if I'd default to doing resolutions, but
> the standard for networking tools seems to be doing reverse DNS unless
> -n is given.
Added to the TO-DO list.
> And finally, this command doesn't work as I'd expect:
> sudo ./nping --tcp -p 80 --flags syn --ttl 5 www.google.ca
>
> The reason being, Nping doesn't seem to print the 'TTL Expired'
> message. Would it be difficult to add that?

Yes, that's a bug. Nping is only telling the packet filter to capture
TCP packets, not ICMP responses. I'll fix it.


> And finally, having a delay and rate are nice, but it'd be helpful to
> have pre-set rates; for example, --fast, --faster, --flood, --slow,
> --slower, --paranoid. Something like that, where --flood and
> --paranoid are the extremes.

I'll also add that to the TO-DO list.

> That's what I noticed from ~10 minutes playing with it. Hope that's
> helpful!

Yes, your comments were very helpful, thank you very much. Feel free to
share any other comments or suggestions.

> Thanks for the tool!
> Ron

Luis.




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