Need help in interpreting the wireshark log

asked 2019-02-04 10:55:54 +0000

Van Kiel gravatar image

updated 2019-02-04 11:48:30 +0000

grahamb gravatar image

Here's the scenario, we have a client connected to our network via IPSEC. In their network, they have printers which are intended to communciate to a print server hosted within our private network. IPSEC tunnels from both ends are up. Both the internet circuits from both ends to which these IPSEC are passing thru are also clean with no packet drops whatsoever. Besides, from both sites perspective, there are other applications passing thru this tunnel and dont have any issues. The main problem is that, our business partner have these printers that needs to communciate to a print server hosted within our private network. Whenever they are using these printers to do batch (continuous) printing, the printers print label-by-label instead which makes the print processing slow.

The business end setup their network in a way in which, the IP addresses of these printers (example 172.26.229.202) are natted to 172.20.104.96/27. And then, this 172.20.104.96/27 is again natted to 172.20.104.26/26 before it goes out of their IPSEC.

At our end, to build the tunnel, we would only allow this 172.20.104.26/26 subnet. We had joint troubleshooting and so far could not find any issue when it comes to the IPSEC connectivity. And so we did a wireshark capture at the switch where the printers are connected via SPAN.

On the packet capture, we are able to see a lot of TCP out of order, TCP Retransmissions, and couple of TCP Dup ACKs between the source 172.20.104.126 (business internal natted IP) and destination 172.26.229.202 (physical IP of the printer).

Although there are a lot of this out of order, retransmissions, and dup Acks, there seems to be no RST and so we wondering if this messages are just normal behavior due to the natting being done at our business end. However, if anyone has different interpretation and can point out what is really causing the printers at our business partner end to do label-by-label printing instead of batch/continuous printing, would really be much appreciated.

Below are samples of TCP Out of Order, TCP Retransmission and TCP Dup ACK messages. Sorry for the long read :) I feel i have the need to explain the whole setup for better feedback.

Many Thanks, Van +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TCP Out-of-order +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Frame 850: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0
    Interface id: 0 (\Device\NPF_{0F213131-B451-48ED-AA0D-C97B2C7BFFD8})
        Interface name: \Device\NPF_{0F213131-B451-48ED-AA0D-C97B2C7BFFD8}
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb  1, 2019 09:08:26.540981000 China Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1548983306.540981000 seconds
    [Time delta from previous captured frame: 0.000022000 seconds]
    [Time delta from previous displayed frame: 0.000596000 seconds]
    [Time since reference or first frame: 30.552559000 seconds]
    Frame Number: 850
    Frame Length: 90 bytes (720 bits)
    Capture Length: 90 bytes (720 bits)
    [Frame is marked: False]
    [Frame is ...
(more)
edit retag flag offensive close merge delete

Comments

Not sure why you think this is a networking issue. What does "label-by-label printing instead of batch/continuous printing" even mean?

Jaap gravatar imageJaap ( 2019-02-04 17:33:36 +0000 )edit

Hi Jaap, thinking this is NOT a network issue is also what we are trying to prove here. But first, need to udnerstand if these TCP out of order, retransission and Dup acks messages in wireshark are normal behaviour due to the NAT'ing being done.

I also dont have the whole idea about the label-by-lable printing and batch/continuous printing. All i know is that these printers are used for SAP applications.

Van Kiel gravatar imageVan Kiel ( 2019-02-06 02:42:33 +0000 )edit