Ask Your Question

What is this TCP error telling me?

asked 2020-05-21 18:02:21 +0000

DL93 gravatar image

I'm trying to connect to a game server using port 5555 but it's having issues and I'd like to find out what's causing the problem. I get TCP Retransmissions in Wireshark, but I don't know what they mean. I'm hoping someone here could give me a quick answer. Here is the data of the packet.


Frame 305331: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface \Device\NPF_{78344E59-C372-4D54-900B-BE42F3EC5985}, id 0
    Interface id: 0 (\Device\NPF_{78344E59-C372-4D54-900B-BE42F3EC5985})
        Interface name: \Device\NPF_{78344E59-C372-4D54-900B-BE42F3EC5985}
        Interface description: Ethernet
    Encapsulation type: Ethernet (1)
    Arrival Time: May 21, 2020 18:48:17.416156000 GMT Summer Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1590083297.416156000 seconds
    [Time delta from previous captured frame: 0.008649000 seconds]
    [Time delta from previous displayed frame: 8.000461000 seconds]
    [Time since reference or first frame: 445.970354000 seconds]
    Frame Number: 305331
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp]
    [Coloring Rule Name: Bad TCP]
    [Coloring Rule String: tcp.analysis.flags && !tcp.analysis.window_update]
Ethernet II, Src: Micro-St_f7:4f:2a (4c:cc:6a:f7:4f:2a), Dst: Technico_aa:8e:62 (e0:b9:e5:aa:8e:62)
    Destination: Technico_aa:8e:62 (e0:b9:e5:aa:8e:62)
        Address: Technico_aa:8e:62 (e0:b9:e5:aa:8e:62)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Micro-St_f7:4f:2a (4c:cc:6a:f7:4f:2a)
        Address: Micro-St_f7:4f:2a (4c:cc:6a:f7:4f:2a)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src:, Dst:
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 52
    Identification: 0x00e9 (233)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]

Transmission Control Protocol, Src Port: 52488, Dst Port: 5555, Seq: 0, Len: 0
    Source Port: 52488
    Destination Port: 5555
    [Stream index: 82]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Sequence number (raw): 169458021
    [Next sequence number: 1    (relative sequence number)]
    Acknowledgment number: 0
    Acknowledgment number (raw): 0
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x002 (SYN)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...0 .... = Acknowledgment: Not set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..1. = Syn: Set
            [Expert Info (Chat/Sequence): Connection establish request (SYN): server port 5555]
                [Connection ...
edit retag flag offensive close merge delete


telnet 5555 does report that it cannot open a connection to the host. I'm just not sure why.

DL93 gravatar imageDL93 ( 2020-05-22 14:38:08 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2020-05-21 22:28:52 +0000

Guy Harris gravatar image

The retransmissions probably mean some program on your machine is repeatedly trying to make a connection to the server on port 5555; the packet is an "initial SYN", which is the first packet in a TCP connection attempt, and it's probably being reported as a "(suspected) retransmission" because there were previous similar connection attempts.

Are you seeing any packets coming back from, such as one where "Flags:" includes both SYN and ACK (that's a response to an "initial SYN")?

edit flag offensive delete link more


@Guy Harris: Just to understand: does Wireshark say that it is a "(suspected) retransmission", when it sees a SYN/ACK from the server side? For my understanding in this case the SYN packet is ACKed and everything is fine until this point.

JasMan gravatar imageJasMan ( 2020-05-22 10:13:25 +0000 )edit

Yes, it is a repeated connection attempt. It's a game that is trying to connect to it's game server through port 5555. I do not get any packets back, at least from the destination of the re-transmitted packets. There are other packets but that could be from any number of things.

DL93 gravatar imageDL93 ( 2020-05-22 14:15:32 +0000 )edit

answered 2020-05-21 21:36:33 +0000

JasMan gravatar image

This means that your client is not able to establish a connection to the server on TCP port 5555 . According to a check from my side server and port are reachable. So maybe a local firewall, your router or your provider blocks the access to that IP or port.

edit flag offensive delete link more


That is what I initially suspected so I played around with the firewalls.

I disabled Windows Firewall and that did not help. I also allowed port 5555 as outbound and inbound with Windows Firewall enabled.

I added a firewall rule on my router src zone: lan, dst zone: wan, src ip:, dst ip: This ip can be different - the game has multiple game servers that it can connect to. This firewall rule did not help either. The Medium preset for my routers firewall allows all outbound connections anyway and an outbound connection seems to be what the issue is.

I've contacted my ISP and they claim to block no ports.

I am however using an unmanaged ethernet switch, and a powerline adapter. Does anything suggest either of those could be the culprit? If that's even possible, I'm not sure.

DL93 gravatar imageDL93 ( 2020-05-22 14:29:12 +0000 )edit

Switch and powerline adapters are layer-2 devices. They shouldn't block ports or IP addresses. Can you post the output of "tracert" please.

JasMan gravatar imageJasMan ( 2020-05-22 15:45:28 +0000 )edit

Tracing route to [] over a maximum of 30 hops:

  1     3 ms     2 ms     2 ms  dsldevice.lan []
  2     4 ms    14 ms     3 ms
  3    18 ms     3 ms     3 ms
  4    30 ms    24 ms    20 ms
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11    20 ms    22 ms    19 ms
 12     *        *        *     Request timed out.
 13    20 ms    20 ms    33 ms
 14    19 ms    19 ms    19 ms
 15    22 ms    23 ms    21 ms
 16    23 ms    21 ms    21 ms
 17     *        *        *     Request timed out ...
DL93 gravatar imageDL93 ( 2020-05-22 16:43:57 +0000 )edit

Traceroute looks the same from my side. We can assume that you can reach the IP address itself. But it's difficult to confirm this for sure, because the address don't response to ping querys. At least the IP is not blocked on your client or router.

Are you able to capture the traffic on your router so that we can verify if a SYN/ACK is reaching you or not?

JasMan gravatar imageJasMan ( 2020-05-22 20:46:33 +0000 )edit

My Router does allow for a TCP dump. I have 5 Ethernet ports, with 1 of them coming from the ONT and I assume they are 0 indexed. I'm assuming the eth4 interface is the one that connects to the ONT.

I did a TCP dump on eth4, and while there were other packets intended for other devices on the network, there were no packets returned from At least it adds to the confirmation that my packets are being sent into the ONT at the very least.

In case I'm doing the TCP dump on the wrong interface, these are my options: br-guest, br-lan, eth0, eth1, eth2, eth3, eth4, pppoe-wan, vlan_eth0, vlan_eth1, vlan_eth2, vlan_eth3, wl0, wl0_1, wl1, wl1_1

I'm not sure if they would, but on Monday I can ask if my ISP can trace any packets just in case there is an ...(more)

DL93 gravatar imageDL93 ( 2020-05-23 03:39:08 +0000 )edit

Your Answer

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

Add Answer

Question Tools


Asked: 2020-05-21 18:02:21 +0000

Seen: 54 times

Last updated: May 21