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."

Comments

Nice comment on Tcl

[tcopeland]

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

I feel the same way about Ruby. 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

[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.

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 specially modified Tcl/Tk for supporting all the features they wanted. Again, IIRC, that was around the Tcl/Tk 8.0/8.1 mark.

Porting NV to a current Tcl/Tk would be a nightmare, because I'm absolutely certain the API has changed enough that you'd have to rewrite a lot of the code. (If someone wants to take me up on that, PLEASE DO! NV allowed multicast streaming from any X11 source, making it one of the most powerful videoconferencing tools out there. I would absolutely love to see the program revived.)

For threads, I researched the Tcl/Tk's website to double-check. My experience has been that Tcl/Tk was good on events, but didn't actually support threads per-se.

Well, their documentation seems to support both of us, so take that as you will. Their documentation says that "only the thread that created the TCL interpreter can use that interpreter". I'm not exactly sure what the overheads of their method is, in practice, but creating a new instance of the interpreter (as opposed to a new state machine) would seem to be a little more brutal on the resources.

They also say they provide no special API for creating threads, that they provide no support for creating multithreaded scripts and that you should use the POSIX APIs for creating threads. The implication is that something outside of the TCL code has to actually do the multi-threading.

HOWEVER, and this is the part that backs your argument up, they do state very clearly that TCL is thread-safe, that there is an API for supporting mutex locks, and that they are working on finalizing the API for creating threads from within TCL.

Their website does seem to be in the process of overhaul, so I cannot be certain that the documentation is 100% up-to-date. However, the implication is that "pure" thread support (as opposed to merely being re-entrant code) is relatively recent. So maybe I wasn't quite as far off as all that.

One last thing on threads - they seem to be aiming towards the basic POSIX 1:1 threading model. That's fine - most of the M:N threading work for Linux has been abandoned, and OpenMP is far from a popular system in Linux. If, as you say, Tcl/Tk is better on threads than Python or other scripting languages, then I'd say that scripting as a whole has a serious problem. I don't know if anyone really monitors debates that are no longer "current", but if anyone does and they're active in the scripting community, then I'd urge them to redress this. Multithreading is valuable, scripting is valuable, so it's important to be able to do both.

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 ought to, rather than doing stuff like using the One Big Lock that Python had for a while.

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.

Why not Java?

[Anonymous Coward]

If he used the Java VM, he would got TCL for free. And he could have used all the other languages for the Java VM.
It's like Mono/DotNET, but with more languages.

Re:Why not Java?

[Anonymous Coward]

You don't even need a Java VM. With newer versions of GCC you can mix Java and C/C++ Code.

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)?