View Full Version : More Ethernet tools . . .

January 6th, 2010, 01:28 AM
During the past hollydays i had enough time to do some more work on my series of ethernet tools. Some of the already published programs were slightly improved but now there are also three more ones. As a consequence of the size limit, i had to split-up the package into three archives, all of them attached to this posting:

In the Archive ETHTOOL1.ZIP one finds three tools for general network analysis:


Is a program that tries to generate a who-is-who of your ethernet LAN (with bus-topology). It lists in tabular form the source and destination ethernet adresses of the packets passing by and counts who is sending whom how many packets. The content of this table is optionally exported into a csv-file (character separated value) from where it can be further processed in what ever way, e.g. be imported into an excel table. (The updated version now can optionally count transmitted bytes instead of just packets)


Is a program that watches your (bus topology) ethernet and tries to figure out what game they are playing. It analyzes the packets passing by, according to frame-type and protocol used (IP, IPX, ...) and displays statistics about it. In addition, if it finds IP-traffic, it tries to guess the basic configuration parameters from the found data. (The new version has some marginal improvements)


This program watches the traffic on the ethernet and lists every HTTP request from eather a distinct or any computer on the local LAN, sent to a server "out there" in the WWW. If you ever wondered what kind of files or data your computer fetches from the internet, this program may help you to find the anwer.

The Archive ETHTOOL2.ZIP contains programs for detailed packet analysis:


Is a program that sends a single raw ethernet packet out to the LAN. As such, it is not terribly usefull for everday (network-) life, but for experimental and testing purposes it can be quite handy. It helped me a lot in writing the other programs.


Is just another packet sniffer. This isn't terribly innovative, but for me it was a pre-requisite for writing the other programs. As it therefore had to be done anyway, why not give it a decent user-interface and turn it into something usefull?

It basically duplicates the functionality of the program ETHCAPT, written by Yusuf Motiwala, many years ago. However it allows to display the data already while recording, with two levels of verbosity (headers only or full data as raw hex dump). In addition it has some filtering capabilities which its predecessor hasn't got. It can optionally write the captured data to a binary file in the same format as ETHCAPT would do, so it can later be visualized by ETHVIEW (also by Yusuf).


Is basically a stripped-down version of ETHDUMP with a fixed built-in filter to capture only those ethernet_II frames, that carry IP packets where eather the source- or the destination-(IP-)address is outside the local LAN and the other one is inside. In other words: it records everything that comes from or goes to the internet, ignoring local traffic. It can also write this data to a binary file, in the same format as ETHCAPT or ETHDUMP would do.


Is a program to visualize the data that were captured by ETHDUMP, ETHCAPT or ETHWATCH. As such, it replaces the program ETHVIEW, written by Yusuf Motiwala. It offers however some more features. One can browse through the files, scroll forward and backward and there are some tiny built-in tools that help in dissecting the data. Furthermore, it can invoke ETHDUMP (or ETHCAPT or ETHWATCH) to capture new data and thus can be used as a handy neat little protocol analyzer.

Of course it cannot compare with commercial products nor with the ethereal/wireshark project. But it's free, runs under (MS-)DOS and with little more than 50KB program size it easily fits on any disquette. It's basic design philosophy is not to attempt to replace a good book on networking protocols or even your own brain, but to assist you as much as possible in inspecting the data that passed over the wire.

In my opinion it has a rather good "usefullness to program-size ratio". But of course every mother loves her own child, so try it yourself and make up your own mind.

In the Archive ETHTOOLs.ZIP one can find all the source codes of the above programs.

There still is no further documentation, sorry, but all programs have a built-in help function which can be invoked by the /? (or/h or -h) command line switch. And of course i keep-on appreciating many comments :)

January 13th, 2010, 11:26 AM
Any experience made so far? :?:

January 16th, 2010, 06:38 AM
Sorry WiWa ..

We are in a very limited universe. And I think the potential interest in diagnostic tools is even smaller than it is in the general purpose apps. (I think I can count my mTCP users on my fingers. On one hand.)

How does your WWWATCH program work? Have you started implementing TCP/IP so that you can properly parse the headers and find the TCP payload before parsing the HTTP request?


January 16th, 2010, 01:25 PM
Oh yes, this universe seems indeed to be very limited,
but i keep on hoping to find intelligent life out there in some remote galaxy :)

And no, i did not implement TCP/IP. But as you might have noticed, the package also contains tools to analyze network data and, what you might not know is, that theese programs were developed in sequence, where the successor employed experiences made during writing the predecessor. So there is some rudimentary TCP/IP knowledge built-into it, as far as it takes to locate the IP header and the TCP/UDP headers and to (hopefully correctly) calculate the header size.

Apart from this, WWWATCH simply lives from the assumption (or rather the observation) that an ethernet frame carrying a package where the source IP-address is inside the local LAN, the destination address is outside, the destination port is 80 and the size of the packet (rather what remains, after subtracting the header size) exceeds a limit of about eight, simply is a http request. Starting from that point, the program simply shows everything up to the second blank character. This way you get the actual command (GET, POST or HEAD) and the name of the requested resource.

The much trickyer part was the resolution of the IP-addresses into URLs. As WWWATCH doesn't have a proper TCP/IP stack, and its design philosophy demands purely passive operation anyway, it cannot issue (reverse) DNS-requests. But it can track DNS-requests issued by others and store their results. And that's what it does.

Ole Juul
January 16th, 2010, 02:25 PM
Oh yes, this universe seems indeed to be very limited,
but i keep on hoping to find intelligent life out there in some remote galaxy

There's not that much networking interest here. Actually, I wouldn't be surprised if there was more interest in some of the BBS forums. Fido, Dove, etc. They're still pretty active. Synchronet seems to have brought things to life a bit. Have you been involved there yet?

January 17th, 2010, 05:50 AM
Do they still exist? And how can one access them nowadays?
I once was attached to FIDO net, but that was some 15 years
ago and the local mailbox via which the access was accomplished
is gone since long.

Ole Juul
January 17th, 2010, 02:49 PM
Certainly they still exist. Hundreds and hundreds. I even saw a couple of German ones. There are even a few dialup ones left - most use telnet now. I notice that Maximus and Spitfire etc, have mostly been replaced by Synchronet. You can get a bit of a rundown on my Voxigo Blog (http://voxigo.wordpress.com), although I intend to do a couple of follow up articles with more detail. To get you started here are two big sites you can telnet into:
Use the standard port 23.

PS: If you want to get involved on the software side, you can give these guys (http://www.mbse.eu/mbse/mbsebbs/index.html) a hand. :)
PPS: Pick up a copy of Mike's very excellent telnet client here (http://www.brutman.com/mTCP/mTCP_Telnet.html).

January 19th, 2010, 11:42 AM
Thank you for the hints. I gave the two links a short try yesterday using the standard telnet client of windows and it seemed to have a problem with the character set.

But apparently there are even webinterfaces to the fido net. As far as i could find out during a short visit, the messages in most of the news groups (how was the correct term in fido-speak?) dealing with (MS-)DOS were several years old. :(

By the way, i do not only write networking programs. I also wrote programs, that could be usefull in batchfiles. Should anyone be interested . . .

January 19th, 2010, 12:06 PM
PPS: Pick up a copy of Mike's very excellent telnet client here (http://www.brutman.com/mTCP/mTCP_Telnet.html).

Ole, Thanks for the plug ...

Everybody else - Ole has been my best source of testing lately, especially with the telnet BBSes. And I could always use more testing help!