Ask Your Question
0

Unexpected reassembly of packets

asked 2020-08-25 16:11:03 +0000

Jobbers gravatar image

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 51.138.106.75   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=1585 Win=2053 Len=0
38  7.244150772 51.138.106.75   [my host name] TCP  60  443 → 1093 [ACK] Seq=1 Ack=3632 Win=2053 Len=0
39  7.271458649 51.138.106.75   [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    51.138.106.75   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=1585 Win=2053 Len=0
38  7.244161    51.138.106.75   [my host name]  TCP 60  443 → 1093 [ACK] Seq=1 Ack=3632 Win=2053 Len=0
39  7.271470    51.138.106.75   [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    51.138.106.75   [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 ... (more)

edit retag flag offensive close merge delete

Comments

Is the Ubuntu machine configured to do TCP offload?
There would be one less header of bytes if the NIC is doing reassembly.

1506 + 1302 = 2808<br>
2808 - 2754 = 54  (Ethernet:14, IP:20, TCP: 20)
Chuckc gravatar imageChuckc ( 2020-08-25 16:42:22 +0000 )edit
add a comment

1 Answer

Sort by » oldest newest most voted
1

answered 2020-08-25 16:44:43 +0000

SYN-bit gravatar image

This is the effect of some offloading to the NIC in the ubuntu Laptop. With ethtool -k <interface> you can view all the offloading that is enabled. I usually disable all offloading on a laptop I am going to capture with. You can do that by using ethtool -K <interface> <feature> off for each enabled feature :-)

In this case I suspect the generic-receive-offload feature to be enabled and causing multiple packets to be reassembled on the NIC before being passed on up the stack where wireshark (libpcap) is able to capture them.

edit flag offensive delete link more

Comments

Thanks for that. I remembered that the laptop was dual-boot with Windows 10, so I did the same experiment again - that showed differing but different behaviour.

the ethtool suggestion is certainly on the right lines, as the behaviour has changed when turning off that setting. I'll mess with the others and see what changes with them. I've read a few more articles on this, and I am wondering if I am going to be able to achieve what I want - both NICs need to be set up exactly the same to expect the same results, and I'm not convinced I'm going to be able to do that. Thanks again

Jobbers gravatar imageJobbers ( 2020-08-25 17:42:26 +0000 )edit

PLease remember that when you capture on one of the endpoints, things will look different from what you capture with a TAP or spanport, just outside of that endpoint. Partly due to offloading features on the NIC. But even in case you can totally disable all the offloading features, there is still for instance ethernet padding done on the NIC on outgoing packets that will not be visible to wireshark/libpcap on the endpoint itself.

What is it exactly that you want to achieve?

SYN-bit gravatar imageSYN-bit ( 2020-08-25 18:02:52 +0000 )edit

Wanted to see if the TAP worked (although it was new, from the manufacturer, and in its box, it was a lot less than half price), and how far I can push network traffic before it starts to drop frames. In order to know that, I first need to be able to determine that it is NOT dropping traffic at regular network traffic volumes, and i thought, as i said in the OP, counting frames might work. Counting bytes also doesn't work - open to any other suggestions. I've always had access to aggregation TAPs before, and this would never be a problem. it's more out of curiosity than any need to know. mind you, not knowing a TAP is dropping frames would make certain troubleshooting a bit difficult. I know Wireshark would tell you about ACKing unknown segments, but I'd much rather know.

Jobbers gravatar imageJobbers ( 2020-08-25 20:01:21 +0000 )edit
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2020-08-25 16:11:03 +0000

Seen: 450 times

Last updated: Aug 25 '20