Ask Your Question

Revision history [back]

Unexpected reassembly of packets

I have purchased a DualComm ETAP-2003 and I have been looking into what it is doing. I have the unit correctly connected, and I am monitoring a Windows 10 system capturing the TAP output on an Ubuntu laptop. the TAP appears at first glance to not be forwarding all traffic, seems to be dropping about 20%. This is not a utilisation issue, as I'll explain. I captured the same activity from the source PC and the monitor port, using items I could cross-reference in both. there's a discrepancy in number of reported frames of about 20%. I started to compare the two traces frame by frame and, at the first discrepancy, the trace on the monitored port seems to show one frame containing the data from two frames that were going to the monitored machine. The reassembled packets are inbound to the monitored machine. This is from the TAP capture:

37  7.244138594   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=1585 Win=2053 Len=0
38  7.244150772   [my host name] TCP  60  443 → 1093 [ACK] Seq=1 Ack=3632 Win=2053 Len=0
39  7.271458649   [my host name]  TLSv1.2 2754    Application Data

The data in frame 39 is the same as the data in the separate frames 39 and 40 below, which came from the machine i was monitoring.

37  7.244161   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=1585 Win=2053 Len=0
38  7.244161   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=3632 Win=2053 Len=0
39  7.271470   [my host name] TCP  1506    443 → 1093 [ACK] Seq=1 Ack=3632 Win=2053 Len=1452 [TCP segment of a reassembled PDU]
40  7.271470   [my host name]  TLSv1.2 1302    Application Data

I have been using Wireshark and Ethereal for many years, and I've not seen this before, although I have probably never been looking for it, as I've never actually done this particular test (comparing two traces) before. I am by no means an advanced user of the tool either.

In the trace, there are 4 patterns of similar interaction with the server (I don't want to say 'similar behaviour' because it isn't). On only one of the occasions does the TAP show the same as the original, and that inconsistency is confusing too.

The interface I'm using on the Ubuntu system is has no IP bindings (v4 and 6 are both disabled).

I guess my main interest is in understanding what might be reassembling this (Wireshark, Ubuntu stack, TAP etc), and if I can make the two captures look the same. It may even be that I have messed something fundamental too (hope not!). The Ubuntu system is using WireShark v2.6.8 [edit: upgraded to 3.2.5, same issue] , the monitored machine is running 3.2.5.

My actual aim in doing this is to see how far I can push the volume of network traffic before the TAP actually starts dropping frames through lack of capacity - counting frames seems like a logical way of doing it, but it's not worked out that way. The tap is not an aggregation tap (they're a bit out of my price range sadly, ) The filtered captures are here if anyone wants them.