This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Difference in captured packets on Ubuntu 14.04 VS. Debian 8

0

In order to resolve a reoccurring communications problem of a HMI (former Ubuntu 14.04; now Debian 8) with LTi ServoOne controllers, network traffic was captured on the HMI.

SETUP

The HMI is connected to its clients, via a standard 5-port consumer switch.
When using such a cheap switch, which was around the first time simulating this, the communication error was observed more frequently. (This seems to simulate a bad transmission line)

Using a "port-mirroring" capable switch

As I doubted the caps, I tried capturing on a 3rd machine, through an expensive switch with port-mirroring capabilities. Within 48hours, I was not able, to recapture retransmissions.

OBSERVED BEHAVIOR

Ubuntu:

  • After a retransmission of a HMI request, the client would respond more quickly (~3ms) than it would on a normal request (5..7ms).
  • The client ACKs with an incorrectly raised SEQ number
  • After a long delay (500..700ms) it would finally send a valid response to the retransmission request

Debian:

!Client config has not changed!

Now the client handles the retransmission request as intended:

  • normal response time
  • ACK is correct

QUESTIONS

  • How can the clients respond correctly under Debian?

  • Does Wireshark miss something, that would explain the different behavior of the clients?
    (Would the different kernel-configs prevent Wireshark from capturing any (invalid) packets?)

  • Is there any sane explanation for the difference in this behavior?

PCAP

Of course, are the captures available:
https://hitzkopf.at/d/4fd35313da/

asked 29 Jan '15, 05:23

Florian's gravatar image

Florian
6●1●1●3
accept rate: 0%

edited 29 Jan '15, 08:41

Where were these captures taken? I believe they were captured directly on the two systems (since TCP checksums errors are present)? If so, they're not good enough for any analysis, because when it comes to stack behavior only 3rd device captures are valid - I'd even go as far as making a TAP capture mandatory for useful results.

This blog post explains to some extend why local captures are problematic: https://blog.packet-foo.com/2014/05/the-drawbacks-of-local-packet-captures/

(29 Jan '15, 07:32) Jasper ♦♦

@Jasper ofc, they are captured on the HMI. I tried using a Switch providing Port-Mirroring - I could not capture any retransmissions with that setup within 48hours.

I'm well aware that these captures are not perfect, still the response time of the client puzzles me a lot. (which led to my assumption that, in this case, the captures are at least partially valid)

(29 Jan '15, 08:39) Florian

@Florian well, if a much better capture setup doesn't show retransmissions that is an interesting fact in itself, because maybe the additional strain of the capture process caused them for the local capture in the first place. So no, unfortunately I am still quite convinced that the capture files are not valid enough for any kind of deduction process.

Have you observed the slower response times during the SPAN capture? Or was everything running smoothly?

(29 Jan '15, 10:24) Jasper ♦♦

@Jasper We have a RT-Kernel running RT-Tasks with 5ms cycle time. No difference in Jitter observeable. The most demanding part of the HMI application itself is the GTK-Visualisation. That HMI program and wireshark are the only notable programms running on i5 2nd gen, 4GB RAM and SSD. As you see, network traffic is quite low. I'm afraid, I can't spot any bottleneck here?

(29 Jan '15, 10:50) Florian