One of the best features that Tcl gives you is that you can specialize it so
much to have a domain-specific language designed to play with packets. The
limitation of all this flexibility is speed. For example, in theory you can use
hping3 to write a firewalling engine, but in reality you can't go beyond a
"prototype" because a firewall needs to be fast.

Tcl is designed to communicate with C, so it's pretty simple. The entire
hping engine is exported to Tcl as a single Tcl command, so hping3 scripts are
just Tcl scripts with a unique new command able to do a lot of new things
related to packets and TCP/IP that are not possible with plain Tcl.

How does the C core work?

The C core is the sum of the hping2 code, used to provide command-line
compatibility in this initial stage, and the new hping3 code. I'll focus on the
latter. The core is comprised of different layers; the first layer is called
ARS, which provides low-level packet construction and analysis. It works
describing packets as different layers. For example, a packet can have two
layers: IP and TCP. These layers are then "compiled"--the compilation
will take care of computing checksums and dependencies between layers, so that,
for example, the IP layer will get the total length field set according to the
following layers, and so on. This way users of the library don't need to do too
much and can just create a packet adding layers, and finally compiling the
packet. The packet can be created as you like, but still the checksums, option
paddings, and lengths will be OK. As I stated, ARS is also able to do the reverse--given a binary packet, it can be split into layers, modified, and then
recompiled and possibly re-sent.

The higher level API is APD (ARS packet description). Basically this layer
uses strings to represent ARS layers, so complex packets can be generated
starting from human readable descriptions of layers like
ip{saddr=1.2.3.4,daddr=5.6.7.8}+icmp{type=3,code=3} and so on, or
binary packets can be translated into the string representation.

Given that APD packets are just strings, they are very natural to bind to
Tcl, which is a language mainly based on strings.

Does hping3 take advantage of multi-CPU hardware?

No, for now at least, but there aren't plans to add support for threads
because Tcl is mainly event driven in design. (Actually, Tcl is able to support
threads pretty well; I just like more the event-driven way.)

I saw a lot of names in the credits page; could you tell us who did
what?

Most of the contributions are limited to bug fixes or the addition of minor
features, so I don't remember exactly who did what, with the exception of
Nicolas Jombart, who provided significant help and code for the BSD port.

I tested hping3-alpha2 on FreeBSD and OpenBSD, and I found out that
some scripts and docs are completely Linux oriented. Can we say that there's
space in the development team for some BSD experts to improve the portability,
especially on *BSD systems?

The goal of hping3 is to fully support at least Linux, *BSD, and Mac OS X. Currently most of the work is focused on Linux because that's the main
development platform I use, but as happened for hping2, the BSD port will become
more stable after some time. Actually hping3 is already working on BSD and
Mac OS X, but there was far less testing on those platforms--what I mean
is that most of the BSD port is already in the source code.

Do you plan to port hping3 to commercial systems like Solaris, Mac
OS X, and Windows?

OS X for sure; it already works as well as the BSD port itself. I received
some reports that hping3 is almost working on Solaris, which will eventually be
semi-supported, but we will never claim to aim for Solaris support. Windows is
a much more interesting target because of the big user base, and because there
is already a working hping2 port (wiki.hping.org is where to go if you want to
try it in your Win32 box), and most of hping3's OS-dependent code is either on
the Tcl side, which is perfectly supported on Win32, or in functions for packet
transmission and reception that can be easily extracted from hping2.

Are you looking for any developer? Which area would you like to add
manpower to?

Now that hping3 is a programming environment, I'm looking for developers to
provide interesting scripts written utilizing hping3 itself. Another
interesting area is IPv6. hping3 is based on the ARS library, which is designed
to be modular, so adding IPv6 shouldn't be hard.

Do you plan to create a repository for .htcl scripts created by the
community like Nessus does?

Yes, it's one of my main goals once hping3 is widely used enough.

I've read some short docs on wiki.hping.org and some in the hping tarball.
Are you looking for people to write more extensive documentation?

Yes! The goal of the Wiki is just that, to build a collaborative site in
order to document hping directly online.

When do you think that hping3 will be stable enough to be released?
I'm a little suspect that the release process could require a mythological
time like Doom 3 did.

[Laughing] Actually it has already taken a lot of time, but now it's
in the classic 98 percent done stage. The last 2 percent is very hard to do, but I think that
the next time I don't have a big workload it will take another little jump. I
hope that in 6 to 12 months at most I'll find the time to push hping to 3.0
stable.