TCP Analyser Layered on Ethernet Tap Receives Nothing

Hi,

We're using 5.1.2 with an Ethernet Tap, and we'd like to use the TCP Analyser as a layer on the Ethernet Tap. However, when we add this layer to the Ethernet tap, we see nothing in the log other than the various messages to do with opening the hardware - no TCP data is logged at all.

  • If we run just the tap without the TCP analyser we see traffic
  • If we add the TCP analyser as a layer on pcap we see traffic
  • But if we use TCP Analyser with the Tap, we see nothing.

We have no filters set.

The TX and RX counters are live and incrementing in the Information window.

How should we go about diagnosing this?

Some more experiments with layering filters onto Ethernet Tap:

  • UDP Flow Analyser is the same as TCP Flow Analyser - nothing is logged
  • TX/RX Filter layer - the "show Tx/Rx" checkboxes have no effect - everything is logged regardless ( I don't care about this, it was just a test).

It does seem that we have some general problem with using layers on an Ethernet Tap.

Indeed, there's a bug in TCP/UDP analyzer scripts. The fix will be included in the next official release; meanwhile, please use the patch below:

scripts.7z

Simply unpack it overwriting all corresponding *.jnc files. Make sure you overwrite files, not simply unpack it in the scripts folder (thus creating scripts/scripts).

BTW the TX/RX Filter layer shouldn't have any effect on the Ethernet Tap or Pcap Sniffer sessions -- as there are no TX/RX data streams there; just the raw Ethernet packets.

But after reconstructing TCP or UDP conversations with TCP/UDP Analyzer, the TX/RX Filter layer can be applied.

Hi Vladimir - many thanks for looking at this for us. That fix is definitely an improvement in that when we have no filter set, we do now see lots of TCP traffic.

But it seems there is a problem with the filter - apparently entering anything into the flow analyser's filter stops us seeing anything. Am I right in thinking that we should be able to enter an IP address OR a TCP port number into that box? Whatever we enter we see no traffic at all.

BTW, very minor nit, but the placeholder text in the filter box reads "Enter a filter andress...", not "Enter a filter address...".
(There may be better wording anyway if it can also take a port number)

Thanks!

Am I right in thinking that we should be able to enter an IP address OR a TCP port number into that box?

Yes. In that box, you're supposed to enter an IP address with or without a TCP port -- or just a TCP port alone.

Whatever we enter we see no traffic at all.

Hmm, just did a quick test and it seems to work as expected. Could you please share your session (Save -> Save Session, then archive the session folder and attach it to your post) and the filter strings you tried to apply?

BTW, very minor nit, but the placeholder text in the filter box reads "Enter a filter andress...", not "Enter a filter address...".

A typo! Will be fixed.

Thank you for your feedback!

Hi @vladimir - thanks for the reply.

I just tried it again just now and the filters did work, but I think what's happening is this:

  • If you create a session by selecting Ethernet TAP and adding the TCP Flow Layer at session creation, the filters work
  • If you create a simple Ethernet TAP session and then later click on the "gear" button and add the TCP Flow Layer, then the filters don't work. This only really happened because I was adding/removing the TCP layer for testing.

I'll email you the session because I get a privilege error if I try to add it here.

The issue with adding TCP/UDP Analyzer layers via the Layer Pipeline dialog is confirmed. Under these conditions, due to a bug, the filter gets inserted in between the Ethernet Tap and TCP/UDP Analyzer (instead, it must be attached after TCP/UDP Analyzer).

The issue will be fixed in the very next release. Meanwhile, you can add these layers by clicking the down arrow next to the Layer Pipeline toolbar button (a button with a plus icon):

b925e454-b27d-4472-891c-0e05f5f5bd1e-image.png

When added like this, the address filter behaves as expected.