Re: [NSE] firewalk.nse updated

[Henri Doreau <henri.doreau () gmail com>]

2010/9/28 David Fifield <david () bamsoftware com>:
> On Wed, Sep 08, 2010 at 08:51:01PM +0200, Henri Doreau wrote:
> > I've been working on adding UDP support to my initial firewalk.nse
> > script. The path-mtu.nse script was a nice reference to achieve this.
> > I've also rewritten function "definitions" to use the : "local
> > function something(arg)" syntax instead of "local something =
> > function(arg)". I find the former more readable. I can see both used
> > in nmap scripts, so I assume there is no (or no big) difference
> > between them.
> >
> > The script doesn't have an option to specify ports to scan yet.
> > Currently, it selects every tcp-filtered and udp-open|filtered port.
> >
> > Please find attached this new version for review.
>
> Thanks, I have committed it.
>
> I want to suggest a different structure. Since you handle both TCP and
> UDP, many of the functions have the same if/else structure:
>
>        local function func(proto)
>                if proto == IPPROTO_TCP then
>                        ...
>                elseif proto == IPPROTO_UDP then
>                        ...
>                end
>        end
>
> The problem here is that when someone adds a new protocol or makes a
> change in one place, they have to remember to change or at least check
> all the if/elses in the file. You can centralize the information better
> using "protocol objects" that have a list of all their functions.
>
>        tcp_funcs = {
>                func = function()
>                        ...
>                end,
>                -- More functions...
>        }
>        udp_funcs = {
>                func = function()
>                        ...
>                end,
>                -- More functions...
>        }
>        protos = {
>                tcp = tcp_funcs,
>                udp = udp_funcs,
>        }
>
> Then you would make calls like
>
>        protos[proto].func()
>
> And of course you can cache protos[proto] if the protocol stays the same
> throughout the script execution.
>
> David Fifield
Hi,

Thanks for the advice. This would be definitely bettter and I'll try
to find out some time to do this as soon as possible.

I'm just beginning a C++ implementation to parallelize the process
within nmap (and take advantage of the features and API of nmap). I've
already mentioned my willing to do this in a previous mail. This is
the very beginning, but I hope that this new version will deprecate
the slow script soon!

Regards

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