Go Down

Topic: I Need a TCP/IP sniffer (Read 318 times) previous topic - next topic

red71gto


Hello, I am reaching out for a bit of assistance here, and appreciate any feedback. I troubleshoot my companies' equipment that measures  motlen metal via various thermocouples. We then calculate data and send it to modelling software that allows for chemistry changes in the process for customer requirements. I have many machines that still use rs232, and for sniffing those serial ports I use a "DATABOY"(gameboy with a card made for sniffing) which is super fast and easy to use. What I am asking for is something just as easy and quick to see my data string on the TCP/IP connection we now use more frequently. I have issues bringing laptops into customer sites due to security reasons they implement, as well as it's usually that I am in an area where a laptop may get very dirty, burnt or dropped while I check systems ( think steel mill here). If it could see the string data, that would be great, if I can just verify that a packet has been sent ( size would be cool) with an LED even, that would be atleast something to get me to the next step in troubleshooting a comm problem. I appreciate ANY help here, and even though I have no Arduino experience, I can learn ....I promise. They key here is I need to have other people use this device as well, and they will not even be at my level, so quick an easy it must be.......Thanks again.  Dan

JustGoFly

https://www.wireshark.org/

Awesome app!
Use filters to retrict the traffic.

red71gto

Thank you for the input, I understand that there are many apps such as the one you suggested, but that still presents the issue of me having to utilize a laptop. I have experimented with RaspberryPi to try and build a "pocket sized sniffer", but found it just too buggy and cumbersome for anyone without skills in Pi. I really just need a "James Bond" approach! LOL Thanks again.

horace


davetcc

This is a common problem when you turn up at someone's site to debug a problem on their network.

First you'll need to get your sniffing hardware onto the site, and second (and usually more difficult to arrange) you'll need to put your network adapter in the sniffing device into promiscuous mode so that you can capture traffic not destined for you - unless you are sniffing multicast packets.

There's no easy answer to this and when I've needed to do it in the past, the company has provided the sniffer device. Most companies don't like externally sourced hardware running sniffers on the network.

Capturing Ethernet traffic is much more complex than rs232 and needs software with greater sophistication. Whatever you do the sniffer would have to run in promiscuous mode unless the traffic were multicast. 
Long time Arduino user who enjoys DIY audio and AV equipment.

davetcc

Also I forgot to mention, most network interfaces for Arduino are system on a chip. I'm not sure they could capture and an arduino process all of the traffic on the network.

If we knew more about the type of protocol used on the connection between devices, we could maybe see if there is a solution that doesn't involve sniffing.
Long time Arduino user who enjoys DIY audio and AV equipment.

davetcc

Just a thought: It may also be that the network admins will be able to arrange port mirroring facilities for you, depending on the type of router / switch hardware at the site; I've used this before to verify connectivity.

If that were possible you could mirror the port that the sensor is connected to, and output it as a dump. Removing the need for you to have any hardware on site.
 
Long time Arduino user who enjoys DIY audio and AV equipment.

westfw

There are several problems trying to do this sort of thing:
  • You can't easily tap in to an ethernet connected electrically; the signalling is much more complicated than a serial port.  Normaly, you'd plug into another switch port.
  • Except that switch ports are mostly SWITCHED these days, which means that packets not destined for a particular host don't show up on the other ports of the switch at all
  • (1) and (2) can be addressed by using a product that "taps" the connection between the target and the switch; essentially a 3-port "hub"  For example https://www.amazon.com/midBit-Technologies-LLC-10-100/dp/B00DY77HHK  ($70 !)
  • Once you've achieved that physical connection, you need an ethernet device to do the actual "sniffing"; it needs to be able to work in "promiscuous" mode (receives packets destined for any ethernet address), and it needs to be able to handle the sort of data rates that exist on the network. (close to 1Gb/s)  PC-class hardware can do it these days, but an arduino-class box is pretty useless.  The existing ethernet shields couldn't even sustain 10Mb/s.
  • Actually analyzing packets is much more complicated than dumping serial data.  Wireshark or even tcpdump are fine programs, but they're big by "handheld" standards.

red71gto

Thanks for the great info, I understand the need for a PC to interpret the message, and the issues around connecting. I would not be joining their network, I would just be unplugging my device from them, then trying to see if data is being sent when my instrument gets a good reading. As silly as it may sound, there are LED's on every network card that signify data travel, so couldn't something very basic be made that would simply light up to let me know of a successful data push?......literally it would be a good start to atleast letting me know my data port output is still alive.  Thanks again, Dan

noiasca

your device doesn't have LEDs on the Ethernet-Socket to see if there is traffic?
DE: Wie man Fragen postet:
1. was hat man (Sketch und Hardware)
2. was SOLL es machen
3. was macht es: IST (Fehlverhalten, Fehlermeldungen, Serial.Output ...)
4. Eine Frage stellen bzw. erklären was man erwartet

srnet

As silly as it may sound, there are LED's on every network card that signify data travel, so couldn't something very basic be made that would simply light up to let me know of a successful data push?
If your reading the multitude of packets that can appear on a LAN segment don't forget there can be a fair few broadcasts, to identify a 'successful data push' you probably need to read all the packets and single out a specific one (or sequence) that indicates a 'successful data push'.

By far the easiest way to monitor LAN traffic is with a PC\Laptop equipped with suitable software. No need to lug it around the factory floor, just plug in at a suitable location in the data centre where all the network cables are.

You might want a simple network sniffer, but its going to need a lot more power than an Arduino, maybe a Pi and screen could do it.
$50SAT is now Silent (but probably still running)
http://www.50dollarsat.info/
http://www.loratracker.uk/

msssltd

Thanks for the great info, I understand the need for a PC to interpret the message, and the issues around connecting. I would not be joining their network, I would just be unplugging my device from them, then trying to see if data is being sent when my instrument gets a good reading. As silly as it may sound, there are LED's on every network card that signify data travel, so couldn't something very basic be made that would simply light up to let me know of a successful data push?......literally it would be a good start to atleast letting me know my data port output is still alive.  Thanks again, Dan
Considering the questions you are asking, I am not so sure you do understand.  The device you want to test sends data over TCP/IP - A protocol that, as I speak, is allowing several billion computers to talk to each other.  Connecting 'billions' of devices is never going to be a case of 'just.'  It's bloody complicated stuff!  TCP/IP is a layered protocol 'stack' approximating the OSI 7 layer conceptual model.  The very first question you need to ask yourself is, what layer do I need to decode?  Go look at the OSI model as a starting point.

If you drop down to 10-BaseT (10Mbps) it is fairly easy to drive an LED directly from the wire, at Layer 1 (Physical), with a couple transistors.  It is not very useful though, as it only indicates electrical activity.  Above 10Mbps, the influence of the LEDs and transistors starts to interfere and the test circuit actually creates the fault.

The LED on a network port is at Layer 2 (Data Link).  The LED is connected to the  output of a specialised Ethernet controller chip.  A mass of support electronics is embedded in the controller chip to drive the LED.  The LED indicates a Layer 2 (Ethernet) link has been successfully 'negotiated' and there is activity at that layer.  It tells you nothing of what is happening higher up the stack, in the Transport (IP), Session (TCP) and ultimately Application (payload data) layers.

The first challenge your testing device faces is being able to negotiate the link at Layer 2 - It must carry out a two way conversation using the correct electrical impulses, in the correct sequence, at the correct time, to allow communication at protocol layers further up the stack.  Otherwise, no LEDs can be made to flash, as the device you are trying to test will remain obstinately silent due to Layer1, the physical connection (electrical), appearing to be broken.  Hopefully it is blindingly obvious that your testing device will need an Ethernet controller chip of it's own.

The device you want to test is using TCP/IP to carry it's data.  To get any useful information you need to get way above flashing LEDs at Layer 2.  IP is at roughly Layer3 (transport) and TCP is roughly Layer4 (session).  In fact, the most straightforward way to get visibility into these software layers is to use an Operating System at Layer7 (application) to look down the stack - This is why network engineers reach for Wireshark, TShark and TCP Dump sooner rather than later.  Wireshark is a phenomenal tool, far, far easier to use than the highly expensive and far less capable tools it has come to replace.  But yes, you still need to know how a network works to effectively use Wireshark or any other general purpose protocol sniffer.

If your users do not wish to acquire those skills, you will need some sort of turn-key device.  Beyond spending a million or two developing a bespoke solution from the ground up, your options are pretty much a Linux based SoC (Raspberry Pi) or an Arduino board with an Ethernet shield.  Both will provide the Ethernet controller and decoded payload data through a Sockets interface at the application layer.  The Arduino's is a severely restricted Sockets-a-like however.  The Arduino's restricted functionality is like trying to connect an LED at Layer 1, in so far as the limitations start to interfere with the test.  Which brings us back to a Linux SoC and the Raspberry Pi, you said you believed was too difficult.

No doubt in my mind that a Linux SoC is the most feasible platform for the device you want to build.  I don't used Raspi's for various reasons but I have similar boards in turn-key applications that have been in constant use for over 2 years, with up-times measured in weeks and months.  What you are trying to achieve is a straightforward job on the Linux console, with some bash and systemd scripting to glue things together.  Add WiFi, a webserver and PHP and you can have a pretty GUI accessible from a smart phone.


red71gto

Wow,alot to take in there. I see the issues that you  layed out so  very well, and it just seems odd to me that nobody has developed something small ,quick and able to be used without networking knowledge to just verify satisfactory "packet" transmissions ( regardless of cost- insert FLUKE here).  As my company has begun development of more and more complex instruments to take measurements, the needs for types of communications to the customer ( both for information and PLC interfacing) has been growing.  I have built a MicroPC just a tad larger than RaspberryPi, that will run Windows 7 and has a 4" HDMI LCD,, and since it has networking ability, and I can use off the shelf programs such as Hercules, I guess that's going to be my path of choice at this point. Troubleshooting issues versus setup installations can be very frustrating, as I explain to my engineers that see things only from their lab desk world and not my "everythings on fire here" steelmill location. I have minutes ,not hours to try and resolve equipment failures or diagnose if it's my device or their network, I don't have the luxury of just walking away from an issue and re- attacking it tomorrow. I really appreciate the excellent info , it's a difficult world to be the "Lone Ranger" out here trying to fix things on the fly, and the more weapons I can have in my arsenal of troubleshooting , the better.  Thanks again for the input!  Dan

srnet

it just seems odd to me that nobody has developed something small ,quick and able to be used without networking knowledge to just verify satisfactory "packet" transmissions ( regardless of cost- insert FLUKE here). 
So an ideal business oppertunity, develop such a beast and sell a few at 'Fluke' prices.
 
$50SAT is now Silent (but probably still running)
http://www.50dollarsat.info/
http://www.loratracker.uk/

westfw

Quote
I would not be joining their network, I would just be unplugging my device from them, then trying to see if data is being sent when my instrument gets a good reading ... couldn't something very basic be made that would simply light up to let me know of a successful data push?
Most "TCP/IP protocols" require active participation of the "destination" system, so you can't just unplug your device from the main network, plug it into a passive "monitor", and expect to see anything useful.

It might be possible for the monitor to tap into just the transmissions from the device, with no actual "upstream" connection to "the network", but it wouldn't be obvious that that restriction existed, and I can't imagine that any "IT Guy" who objected to generic network monitors allowing its use.

The "goto ethernet network analyzer" used to be a Network General Sniffer, available in rack-mount and "luggable" form factors:

But that was back in the "shared transmission line" (thinnet, vampire taps; ah the memories!  I had some sitting in my garage for a long time, rescued from dumpsters) and as previously discussed, it's relatively impossible to do something like that in a modern switched XbaseT setup.

Network General was apparently bought by "NetScout" who are still in business and still set network debugging tools.

I can't tell whether it does what we're talking about - it only seems to have a single RJ jack.
"Fluke-like prices" doesn't come close!!


Go Up