Ask Your Question
0

Application Hangs, Need help with packet Analysis

asked 2021-08-10 12:15:22 +0000

jjosh823 gravatar image

updated 2021-08-10 12:50:49 +0000

grahamb gravatar image

Hi,

I am troubleshooting an issue with an POS\Restaurant application that is hanging and has slow performance. Vendor had me send the a packet capture from one of the terminals. They are saying it looks like the firewall is causing the disconnects with the hosted system, but for troubleshooting we have firewall wide open. Can someone take a look at the following stream and let me know if it looks like the firewall would be causing an issue? To me, it looks like the terminal (10.215.50.101) is sending the RST after the communication was ended with a FIN packet and the server tried to send Encrypted Alert. I'm just not the greatest at Analysis.

 1.  10.215.50.101  64.79.134.26    TCP 66  61398 → 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256
 2.  10.215.50.101  64.79.134.26    TCP 66  61398 → 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256
 3.  10.215.50.101  64.79.134.26    TCP 54  61398 → 443 [ACK] Seq=1 Ack=1 Win=66048 Len=0
 4.  10.215.50.101  64.79.134.26    TLSv1.2 426 Client Hello
 5.  64.79.134.26   10.215.50.101   TCP 60  443 → 61398 [ACK] Seq=1 Ack=373 Win=15872 Len=0
 6.  64.79.134.26   10.215.50.101   TLSv1.2 163 Server Hello, Change Cipher Spec, Encrypted Handshake
 7.  10.215.50.101  64.79.134.26    TLSv1.2 575 Change Cipher Spec, Encrypted Handshake Message
 8.  64.79.134.26   10.215.50.101   TCP 60  443 → 61398 [ACK] Seq=110 Ack=894 Win=16896 Len=0
 9. 10.215.50.101   64.79.134.26    TLSv1.2 464 Application Data
 10. 64.79.134.26   10.215.50.101   TCP 60  443 → 61398 [ACK] Seq=110 Ack=1304 Win=17920 Len=0
 11. 64.79.134.26   10.215.50.101   TLSv1.2 436 Application Data
 12. 64.79.134.26   10.215.50.101   TLSv1.2 612 Application Data
 13. 10.215.50.101  64.79.134.26    TCP 54  61398 → 443 [ACK] Seq=1304 Ack=1050 Win=65024 Len=0
 14. 10.215.50.101  64.79.134.26    TCP 54  61398 → 443 [FIN, ACK] Seq=1304 Ack=1050 Win=65024 Len=0
 15. 64.79.134.26   10.215.50.101   TLSv1.2 85  Encrypted Alert
 16. 10.215.50.101  64.79.134.26    TCP 54  61398 → 443 [RST, ACK] Seq=1305 Ack=1081 Win=0 Len=0
 17. 64.79.134.26   10.215.50.101   TCP 60  443 → 61398 [FIN, ACK] Seq=1081 Ack=1305 Win=17920 Len=0

Thanks in advance!

edit retag flag offensive close merge delete

Comments

Without the frame times it's a little difficult to be sure, but it certainly seems as though it's the client initiating the connection close in frame 14.

Where was the capture made, client, server or somewhere in between?

grahamb gravatar imagegrahamb ( 2021-08-10 12:52:25 +0000 )edit

The capture was made on the client. That's is what it seems like to me as well. Thank you for responding.

jjosh823 gravatar imagejjosh823 ( 2021-08-10 13:47:23 +0000 )edit
add a comment

1 Answer

Sort by » oldest newest most voted
0

answered 2021-08-10 14:13:21 +0000

hugo.vanderkooij gravatar image

In a TCP session toy will see RST packets if you try to send anything else when the first FIN is seen.

But if you only see the client end you may see what the firewall is enforcing instead of what the server is doing. So the best thing to do is do a capture at least on the client and the server and compare notes.

edit flag offensive delete link more

Comments

Thank you! It ended up being a device called a COMBOX that acts as an unmanaged switch to share the ethernet connection with a credit card encoder. Once we removed that device and connected a standard 5 port unmanaged switch the connection was no longer resetting.

jjosh823 gravatar imagejjosh823 ( 2021-08-12 12:10:06 +0000 )edit
add a comment

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

subscribe to rss feed

Stats

Asked: 2021-08-10 11:58:44 +0000

Seen: 357 times

Last updated: Aug 10 '21