administrators

Hello Sunny,

Serial Tap Pro is a next-generation serial sniffer; the functional differences that distinguish it from the original Serial Tap (https://ioninja.com/hardware/serial-tap.html) are as follows.

Serial Tap Pro features:

• Galvanic isolation (for robustness and protection of all electrical circuits involved)
• Twice as high baud rates (2.5 Mbps in Serial Tap Pro vs 1 Mbps in Serial Tap)
• Automatic detection of baud rates and UART frame size (aka, ABR)
• Guaranteed correct sequencing of all events with hardware-generated microsecond timestamps (in contrast, Serial Tap uses two independent USB-to-UART channels, timestamped at the PC side)
• 9-bit data frame support (used by some industrial equipment)
• Half-duplex (two-wire) RS485 packet direction detection
• Data and status line injection (so Serial Tap Pro can effectively be used in lieu of any USB-to-RS232/485/TTL adapter)

Read more at the product page: https://ioninja.com/hardware/serial-tap-pro.html

A simple TX/RX Filter could be sufficient in many cases. If you want to "de-interlace" the traffic by accumulating TX/RX data and postponing adding it to the log until a certain character (CR/LF) arrives -- a simple custom layer plugin could work. Finally, you can save captured data streams into an .njlog file and post-process it with any scripting language of your choice.

Could you please share an .njlog or at least a screenshot of communications? That would help to choose the best approach.

A new blog post is out: https://ioninja.com/blog/walking-your-log/

Have questions or comments? Leave them here!

Here is a blog post on the subject: https://ioninja.com/blog/walking-your-log/

It doesn't dive into the internals of parsing Modbus RTU frames themselves, but you'll be able to enumerate and extract all Modbus RTU master and slave frames from your .njlog file -- and take it from there.

We've just launched a new blog:

https://ioninja.com/blog/welcome-to-io-ninja-blog/

Feel free to use this forum thread for comments & discussion.

Hi Paul,

Thank you for your feedback, I really appreciate it!

We released Serial Tap Pro two months ago, and a new revision for Ethernet Tap (Ethernet Tap Pro?) is our next goal! At the very least, it should include Gigabit Ehternet support, automatic port speed selection, optional packet injection (which could be disabled at hardware level via jumpers -- just like in Serial Tap Pro), guarantee of non-disrupting the original link in case of power loss, high-precision (at least 1 microsecond) hardware timestamps, optional enclosure -- and more (hopefully, Automotive Etherent, too). We are still in the research & design stage, so there's no strict release date set -- sorry about that. As soon as we have a more definitive timeline, we will definitely post an update on this!

Hello Jason,

I've replied to this request over email, but let's cover it here, too -- in case anyone else bumps into a similar problem.

Support for Serial Tap Pro was added recently, in IO Ninja 5.8.0 -- therefore, please make sure that you are on a version higher than this. Generally speaking, you always want to be running the latest and greatest version of IO Ninja.

Also, on Windows, for Serial Tap Pro and other hardware sniffers to function correctly, the official hardware driver is required. This driver is actually nothing more than a manifest telling Windows to use the system winusb.sys for devices with our VID/PIDs (vendor and product IDs). Nevertheless, this step is essential -- without it, IO Ninja won't be able to communicate with the taps (and taps will have an exclamation mark in Windows Device Manager).

If you install IO Ninja via the "FULL" MSI installer, those drivers should be installed automatically. Otherwise (e.g., you prefer a portable .7z archive), please download drivers separately at Download -> IO Ninja Hardware Drivers; install them either (a) using dpinst64/dpinst32 or (b) through the standard Update Driver process in Device Manager.

After driver installation completes successfully, the taps in Device Manager should show no exclamation mark and use winusb.sys as a kernel-mode driver.

Greetings! The fact that IO Ninja doesn't enumerate this port on Windows means that its driver doesn't belong to the "Ports" device class:

Could you please share the .inf file for this driver? Or better yet, can you provide a download link for this virtual serial port driver so that we can play with it locally?

When on evaluation, you can use absolutely everything -- including Pipe Terminal and scripting.

However, the your script is not a valid Jancy script.

A simple echo script looks something like this:

void main() {
	char buffer[256];
	for (;;) {
		size_t size = receive(buffer, sizeof(buffer));
		transmitAll(buffer, size);
	}
}

Of course, you can modify the reply packet before transmission as you like, e.g.:

void main() {
	char buffer[256];
	for (int i;; i++) {
		size_t size = receive(buffer, sizeof(buffer));
		string_t reply = $"received block %1: '%2'"(i, string_t(buffer, size));
		transmitAll(reply);
	}
}

You can also try our stock scripts ("Load stock script" in the drop-down next to the "Open" button on the Script pane) -- they can be used as a starting point for something more meaningful.

Also, check in-app scripting tutorials here:

https://ioninja.com/doc/developer-manual/tutorials.html

Hi Jeremy,

Apologies for the delayed response.

You are 100% correct -- the hostname resolver should respect the IPv4 address when present. IPv6 should not be required when IPv4 is available.

Actually, the logic here is a bit more complex -- all socket-based plugins can optionally bind to local IPv4 or IPv6 adapters. So, when this binding is in place, the hostname resolver should choose the corresponding address family and ignore everything else.

We'll add this for the upcoming release in June. I'll share a link to the internal build after we have it done if you wish to try it before the official release.