Hping3 vs. Nmap

An anonymous reader writes "ONLamp.com Security section has published an interesting interview with Salvatore Sanfilippo, the author of hping. Among other things, it talks about nmap, idle-scan, and low level network analisys with simple Tcl scripts."

Nice comment on Tcl

[tcopeland]

> I use Tcl for everything not involving
> low-level things or speed.

I feel the same way about Ruby [ruby-lang.org]. It's just not worth the hassle of plowing thru 20 lines of try catch blocks in Java when I can do something like

File.read(myfile).grep(/foo/).size

with Ruby. Good times!

Re:Nice comment on Tcl

[keesh]

Except that generally, ruby *is* pretty fast for non low-level stuff. Since most of the time is generally spent doing code like sorting, text matching etc (well, for some problems anyway...) it's the speed of the underlying interpreter's code that matters.

Isn't it obvious?

[Palshife]

Hping3 vs. Nmap, the names say it all. I think the victor is quite clear.

A fascinating read

[jd]

Just one thought, though. I don't think it's a case of hping3 versus nmap, as the two are aimed at different problems. I personally like them both, and use them in those areas they're good at. (But, then, I tend to collect tools, as if they were going out of fashion. I've crates of CD Roms of Open Source and Freeware utilities, most of which I'll likely never use, but the seeing what exists is so fun that it makes it worth it.)

Ok, maybe one other thought. TCL is a cool language - though it has a history of incompatiable changes, which I don't like, and it has never been as thread-friendly as other languages. It's not essential, for a networking problem, but it's very handy.

I've not used Ruby, but the example another poster gave was enough to convince me that it's a language worth learning. I like clean solutions to clean problems. I honestly think the maintainer for HPing3 might do well to support additional languages, including Ruby.

Actually, if HPing3 is going to be split into two products - the front interface and the libraries - then it should be possible to split off the API for the Tcl stuff, and provide plugs so that others could supply interfaces to other languages.

Re:A fascinating read

[DavidNWelton]

(Polite) I don't think you are well informed about Tcl.

It handles threads just fine, and has for several years better than languages like Python.

Incompatible changes? Some of the C API has changed over time, but it's still possible to compile older extensions - and updating them usually is pretty easy. As far as the language itself, it hasn't changed that much and none of the changes that come to mind are backwards compatible.

Re:A fascinating read

[jd]

It's true that I've not used Tcl/Tk 8.x as much as I used to use the 3.x and 4.x series, so things may have improved on the API front beyond the changes I'm aware of. I'll happily accept that. (In fact, as Tcl/Tk is probably one of the best scripting languages out there for GUIs, I'd much prefer that to be the case.)

Some things, though, I'm pretty sure on. Many multicasting tools use Tcl/Tk for the interface. NV uses the 3.x series, IIRC. University College of London (UCL)'s "MICE" program used a speciall

Re:A fascinating read

[DavidNWelton]

I maintain the tclthreads package for Debian, have done lots of digging in Tcl's C sources (a very nice read, BTW, if you don't look at the regex related files:-). So I can state that Tcl does do threading without a doubt. Of course, you need to compile it for that (like Debian's is), and you need an extension if you want to do it from Tcl itself.

And you're correct - you use one interpreter per thread. This has some big upsides in terms of robustness and allowing the threads to actually work as they oug

Re:A fascinating read

[auntfloyd]

Ok, maybe one other thought. TCL is a cool language - [...] and it has never been as thread-friendly as other languages.

While I'm not involved in the Scripting Wars, I think it's worth pointing out that TCL's stance on threading is motivated by the fact that its creator thinks that threads are a bad idea [pacbell.net].

why not Perl?

[jeif1k]

Why not make hping a Perl script, with no C code? Perl already has the bindings to libpcap, libdnet, and libnet, so hping would not require any native code installation on many systems. And the kind of people likely to use hping are also a bit more likely to already know perl.

(I'm not making any argument as to the relative merits of Perl or Tcl as languages--as languages, I would prefer something else anwyay. But Perl's extensive collection of libraries often makes it the path of least resistance.)

Re:why not Perl?

[endx7]

mmm...CPAN

Eureka!

[RAMMS+EIN]

``The secret is the inclusion of a Tcl interpreter that interacts with the C core.''

Wow! They have discovered the power of dynamic extension languages! Tomorrow they will want to write the whole thing in the extension language, and next thing you know they're building a Lisp machine!

Seriously, we need more of this.

Salvatore Sanfilipo

[magefile]

Is Salvatore Sanfilippo by any chance related to the doctor who discovered the syndrome of the same name (Sanfilippo Syndrome, a lysosomal storage disorder)?