Ask Your Question
0

back to back to back...ACKs with no SYN,ACK response

asked 2023-11-07 18:55:43 +0000

sug4fr33 gravatar image

updated 2023-11-08 15:14:27 +0000

I am troubleshooting your typical "slow network connection". Two devices seem to be trying to perform the TLS handshake but neither is responding with a SYN. I wouldn't even consider myself a "noob" at WireShark. What is below a "noob"? I've got one device, 10.12.10.12 sending an ACK to 10.3.20.120 in Frame 1. In Frame 2 I have 10.3.20.120 sending a PSH,ACK to 10.12.10.12. In Frame 3 I have 10.3.20.120 sending another PSH,ACK to 10.12.10.12. In Frame 4 I have 10.12.10.12 sending an ACK to 10.3.20.120. In Frame 5 10.12.10.12 is sending another ACK to 10.3.20.120. And finally in Frame 6 10.3.20.120 is sending a PSH,ACK to 10.12.10.12.

I tried to upload the pcap file but I am also new to this community and when I tried to upload I was told that I need >60 pts to upload files...

edit retag flag offensive close merge delete

Comments

SYN is never a response. It is the opening of a conversation. Based on the description of the packets there is however nothing wrong with them. Just 2 machines having a conversation.

First describe in more detail the problem you are experiencing. Just how the user sees the problem.

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2023-11-08 08:12:24 +0000 )edit

The user is complaining about slow internet connectivity. Again this is a dispatch call center for a state department. The customer stated that when call volume is high that the computers connected to the phones slow down considerably. Every department uses a VoIP phone where the phone is basically a switch.

I though the 3-way handshake was machine 1 sending an ACK to machine 2 and machine 2 responding with a SYN-ACK and then machine 1 finishing the handshake with a FIN-ACK. I will have to go back refresh my memory on TLS.

sug4fr33 gravatar imagesug4fr33 ( 2023-11-08 13:58:25 +0000 )edit

A capture can be added to a public share and a link to it can be added back here.

grahamb gravatar imagegrahamb ( 2023-11-08 17:38:42 +0000 )edit

public share?

sug4fr33 gravatar imagesug4fr33 ( 2023-11-08 18:35:16 +0000 )edit

Something like Google Drive, DropBox etc.

grahamb gravatar imagegrahamb ( 2023-11-09 09:10:47 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2023-11-10 08:55:51 +0000

Jim Young gravatar image

With your current capture setup you are capturing data from multiple vlans concurrently. Some of the tcp sessions are captured twice because the two peer hosts are on different vlans. Capturing the same packet on both vlans will confuse the TCP analysis.

In the capture file Forestry_MX_LAN.pcap, the display filter tcp.stream==0 shows packets from ip.addr==10.12.10.12 && ip.addr==10.3.20.120. The session appears to have lots of retransmissions. But if you look more closely you will see that the packets are actually captured twice, once on vlan.id==500 and the other on vlan.id==111.

If you apply a display filter for vlan.id==111 and then use the main menu option Edit -> Ignore All Displayed then all the displayed packets will disappear. Now update the display filter to just tcp.stream==0and you will see just the vlan.id==500 copies of the tcp.stream==0 without all of the duplicates. You can restore the ignored packets by reloading the capture file.

Regarding your capture file Forestry_MX_LAN_1182023.pcap it shows evidence of massive packet loss likely due to the capture setup. In both capture files you have captured Spanning Tree Protocol (STP) packets. These are normally sent at 2 second intervals. In the Forestry_MX_LAN.pcap with a display filter of stp we can see STP packets at regular 2 second intervals, but in the Forestry_MX_LAN_1182023.pcap file we see irregular gaps between between the STP packets. With any sort of packet capture one has to consider the possibility that the capture file itself could be missing packets that were in fact sent but simply were not captured because of the capture setup itself.

edit flag offensive delete link more

Comments

@Jim Young Can't thank you enough for this explanation. Definitely helped me rule out these two devices causing congestion.

Also thanks to everyone who posted comments to my first question.

sug4fr33 gravatar imagesug4fr33 ( 2023-11-14 17:27:39 +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

1 follower

Stats

Asked: 2023-11-07 18:55:43 +0000

Seen: 168 times

Last updated: Nov 10 '23