I'm facing a situation where a client establish a TCP connection via telnet (or netcat) in order to connect to a linux server. The server must then send back a banner containing some text info...

In each host, I launched Tcpdump to capture traffic.

First, the two machines did the traditional TCP handshake. the server then sent a PUSH packet containing the banner in the direction of the client and received an ACK of it from the client.

The weird part is that the client never received the banner (nothing showed in telnet/nc) and the tcpdump launched on client side didn't capture any PUSH packet from the server nor an ACK in the direction of the server. While the tcpdump on server side captured all packets.

I did this several times and each time nothing changed, seems not a tcpdump problem.

I wonder if this is caused by the firewall since between the 2 machines there is one (but how come the server is receiving the ACK!?)

Beside that, it is possible that when the client received the PUSH packet, instead of sending it to the 7th OSI layer (telnet) it stoped it for some reason in the 4th layer (TCP) and sent back an ACK ? Does this have to do with some application filtering in client side?

Nb: Both machines use a Linux From Scratch and do not use iptables. I don't know which TCP implementation they are using.


Here is a schema of the communication:

Server view:


    <-----------------------------------SYN (Ip ID=3333)---------------------------

    ----------------------------------SYN-ACK (IP ID=4444)--------------------------->

    <---------------------------------ACK (Ip ID=2222)-------------------------------

    -----------------------------PUSH (data) (100 bytes, IP ID=4445)------------------->

    <----------------------------ACK (Ip ID=2223, ack-num=101)------------------------

Client view:


<---------------------------------SYN (Ip ID=3333)-----------------------------

---------------------------------SYN-ACK (IP ID=4444)--------------------------->

<--------------------------------ACK (Ip ID=3334)-----------------------------

Inside all packets, everything matchs except IP packet Identifier, Ack number and sequence number.

  • TCP/IP doesn't use the OSI model. (The OSI model is used in X.509.) Also, what's a PUSH packet? The normal TCP connection establishment sequence is SYN -> SYN ACK -> ACK. (The initiating host sends a SYN, then the connected-to host sends a SYN ACK back, then the initiating host sends an ACK back.)
    – user
    Nov 24, 2018 at 8:08
  • First, between OSI & tcp/ip model, there are a lot of similitudes (for example, they both have Network & Transport layer). I always see OSI as a global model that encompasse tcp/ip model. Secondly, The PUSH operation comes here after the Syn/Syn-ack/Ack. I don't know why you are mentioning this, because in my question i never mentioned the opposite!
    – Dimareal
    Nov 24, 2018 at 12:16

1 Answer 1


The problem is not on the 7th layer, it is on the network layer.

Assuming your tcpdump on the client works correctly, the client doesn't receive the data from the server, so there is no question whether it can pass data or not.

As you already know there is a firewall in between, try it without a firewall. It's possible to do many things with a firewall. If the client doesn't receive the data packet and therefore doesn't send an ACK, but the server receives an ACK, it must come from the firewall.

  • 1
    I don't have access to the Firewall. Today I analyzed more the captured packets. The first 2 packets (syn & syn-ack) seems OK. Starting from the 3 packet, each packet received (sent) have a different IP Identifier than the corresponding sent (received) one. Ack number & sequence number do not respect logic also. I think theses evidence prove that the firewall (or a third machine) is behind this mess.
    – Dimareal
    Nov 23, 2018 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.