• Please review our updated Terms and Rules here

Network Packet Sniffer Recommendations

SpidersWeb

Veteran Member
Joined
Feb 16, 2012
Messages
2,701
Location
New Zealand
I've been having difficulty getting my IBM RT (AIX 2.2.1) communicating with my DOS/Windows machines.
It sends packets out, but incoming packets get marked by AIX as errors. So I want to compare what's sent by each machine for differences.

Can anyone recommend a good packet sniffer - that will run in DOS or Windows 3.11 - that will identify the packets and let me look inside? even if they're invalid packets?

(Side note, I also have a Network General sniffer card with an Intel i860 CPU on it, but no driver/application software to make use of it)
 
Tongue-in-cheek here, but the answer to your question about a recommendation for DOS or Windows is - NO!

Use tcpdump under Linux. It doesn't even have to be a new version of Linux - any version in the last 10 to 15 years is going to have enough smarts to decode those packets.

(A lot of my initial mTCP debugging was done using a Linux machine, first as a target and then as a transparent bridge.)
 
Tongue-in-cheek here, but the answer to your question about a recommendation for DOS or Windows is - NO!

Use tcpdump under Linux. It doesn't even have to be a new version of Linux - any version in the last 10 to 15 years is going to have enough smarts to decode those packets.

(A lot of my initial mTCP debugging was done using a Linux machine, first as a target and then as a transparent bridge.)

I was hoping for something simplier, as that room is already networked with DOS PCs (XT to 486), but it's not the first time it's crossed my mind that one Linux server in there would be useful. Might be a weekend project - I'll need to find the hardware, then an applicable version of Linux, then check the network drivers are available and find a version of tcpdump suitable for it.

Will a 486DX2-50 or Pentium 100 fit the bill? Or will I need to dig up a P3 or P4? (actually I do have a spare P3-600, just haven't built it yet)


Cheers. Snoop worked and it shows the packets coming from the RT as "unknown" but I can't actually see the packet data. I want to check it's not just throwing out random bytes (as I think it may have a hardware fault in the card).

It must be close because both my Windows and AIX 'ping' packets were 60 bytes in length, but the Windows packet shows "ARP" while the AIX packet is just "unknown".
 
Over the years I've had three Linux boxes that I've used for this kind of thing:

  • 486DX/2 66 running RedHat 6.1
  • Pentium 233 running Fedora Core 2
  • Some big Athlon monstrosity running a relatively recent OpenSuse. (I set this up last year but I'm still using the Pentim 233 more.)

All of them are fast enough to run tcpdump and keep up with an old PC or your PC RT. A PC RT is not a speed demon.

tcpdump and many other networking tools are included in the operating system.

If you are using this as an occasional tool you might try running a "live" CD that has the networking utilities on it instead of installing and dedicating a machine from scratch. A fast machine is not necessary for tcpdump, but it does make booting or installing much more tolerable. And if you learn to like Linux, you'll find other uses for it.
 
Can anyone recommend a good packet sniffer - that will run in DOS or Windows 3.11 - that will identify the packets and let me look inside? even if they're invalid packets?

Being that this is the Vintage Computer forums, I thought talking about Vintage sniffer software might be cool.

Years ago (1990-92 timeframes) I used a DOS packet sniffer called NetCapt/NetCure fron the DNPAP at the Technical University of Delft. NetCure will run on an XT and just needs a packet driver for the card you have. I used it to troubleshoot some 802.3 10BASE5 LANs running NetWare 2.15/2.2 at a factory. IPX is a great LAN protocol, and since the MAC address is the IPX station address, it made finding issues and narrowing them down to the actual NIC involved a lot easier. Broadcast storms were the biggest problem, especially with all the eight port Cabletron multiport AUI repeaters (eight AUI's to workstations; one AUI to the 10BASE5 vampire tap). But the DNPAP software allowed real-time display as well as historical recording of traffic, and saved the day more than once. I had a 386DX/16 just to run the DNPAP software by the time I left there.

NetCure spawned The Beholder, Gobbler, and BTNG (Beholder the Next Generation). None of the followons were anywhere near as easy to use as the original NetCure, in my opinion.

Finding it today was a bit of a challenge, as I had forgotten the name of the program. But the acronym DNPAP I remembered; see https://web.archive.org/web/19971007193012/http://dnpap.et.tudelft.nl/DNPAP/dnpap.html for the earliest Wayback Machine archived page.

Now I am going to go all 'Vintage' on you, as it was a gopher site where I found it originally, years ago, through a dialup internet service called Eskimo North (still there as eskimo.com)). The actual software is archived in a few places; one of them is ftp://ftp.fh-koblenz.de/pub/pc/msdos/networking/dnpap/

But that's just keeping with the Vintage theme, and keeping in on DOS..... for modern analysis, I use the webified wireshark interface provided by the Network Security Toolkit Linux distribution ( http://www.networksecuritytoolkit.org/nst/index.html ). It's based on Fedora and has a snazzy web interface that allows you to do some nice packet analysis, among other things. It's meant to be run by a tap appliance with separate capture and admin NICs, but works ok with a local GUI console (although the default console is not a GUI). Yes, I know it's not DOS or Windows, but it works very well and has relatively modest hardware requirements.
 
Connect your machines with an Ethernet hub, not a switch, so all of the packets are visible on all of the ports. Connect a Windows machine to the hub, and run WireShark.

WireShark will capture all of the packets on the network, show you any errors, interpret the contents of each packet, and allow you to see inside of each packet.
 
All of them are fast enough to run tcpdump and keep up with an old PC or your PC RT. A PC RT is not a speed demon.
Hey now, it's got the Enhanced Advanced Processor Card (not kidding, that's what it's called)!

Thanks for the list - I ended up pulling out an old Penitum 200 MMX machine I haven't used in years - powered it up (no pops) and found I had an unused 8GB HDD as secondary - so it's now dual booting RedHat 6.1 (which was the first Linux distro I ever used too btw - around 99/00). I use Debian on a daily basis (home server (seperate network) + servers at work) - but always the latest on modern hardware, this was my first time turning back the clock with Linux.

Installation was a complete breeze, and tcpdump was in there. It picks up the packets, appears the headers are mostly full of FF FF FF FF FF FF - I'll need to install or find a hex editor to view the actual packet but I think I have a hardware fault.

I'll play more with it over the weekend, but due the noise the RT makes, I can't use it when my partner is sleeping (it's midnight here).

Thanks to everyone else who replied :)

m_thompson - yeah the room is all 10Base2, plus a 10BaseT/10Base2 hub - no switches or routers :) tcpdump appears to be doing the job for now software wise.
 
Check your options on tcpdump. I believe that with -v, -vv, or -vvv to make the output more verbose you get much more detail on the packets. Tcpdump is great because not only does it capture the packets, but it also shows the contents and tries to interpret packets that it recognizes. At a minimum you'll have the IP and TCP headers nicely mapped out.
 
Hey now, it's got the Enhanced Advanced Processor Card (not kidding, that's what it's called)!

Thanks for the list - I ended up pulling out an old Penitum 200 MMX machine I haven't used in years - powered it up (no pops) and found I had an unused 8GB HDD as secondary - so it's now dual booting RedHat 6.1 (which was the first Linux distro I ever used too btw - around 99/00). I use Debian on a daily basis (home server (seperate network) + servers at work) - but always the latest on modern hardware, this was my first time turning back the clock with Linux.
Doesn't look like you had a too terribly traumatic experience either ;) What's the other OS you're dual booting with Jonno? Got RH 7.3 running on my 200mmx box.
 
What about WinDump? It's the Windows port of tcpdump.

Cheers, sounds good but I've got Linux setup in there now which is doing it's job. I'll probably leave the machine headless under a desk long term and control it remotely.

Doesn't look like you had a too terribly traumatic experience either ;) What's the other OS you're dual booting with Jonno? Got RH 7.3 running on my 200mmx box.
It's my Compaq Presario I grabbed from work many years ago from out the back. So it has the original install on C (Windows 95) that was restored from the Compaq Resotration CD (which also creates the partition for the BIOS setup etc) and then it was upgraded to Windows 98.

Currently using LILO, and suffering the "LI" issue (which I actually remember having back then) - so need to fix that - currently just using a boot floppy to kick start it. Other than that, it was a complete breeze.

Check your options on tcpdump. I believe that with -v, -vv, or -vvv to make the output more verbose you get much more detail on the packets. Tcpdump is great because not only does it capture the packets, but it also shows the contents and tries to interpret packets that it recognizes. At a minimum you'll have the IP and TCP headers nicely mapped out.

Cheers, I'll try -vv and -vvv. I'm fairly confident my RT network card is having a memory issue though, just from what I did see it was mostly "FF FF FF FF FF" etc, but I'll use this to see if anything changes when I change the configuration on it.
 
One really nice thing that you can do with a Linux box is to add a second network card to it and use the two cards in "bridge" mode. Bridge mode allows the Linux machine to be transparent to whatever is being sniffed; it's logically like a direct tap. I prefer to use bridge mode rather than introduce a hub onto the network, which has the bad trait of broadcasting everything to every port.

For your Linux box I'd use something with at least a 2.4 or 2.6 kernel on it. RH 6.1 was reasonably in 1998 but it is based on kernel 2.2. The big change is moving from ipchains to iptables, which has more function.
 
Back
Top