I have an IP camera that uses RTSP for it's video/audio feed, and port 80 for it's web management service. Intermittently I lose the feed from the camera and can no longer reach it via the management interface. I am on the same LAN segment with firewall or anything in between. During this time I am still able to receive ping replies from the camera. I was able to get a capture from when the feed stops, and also when it is working properly. Now here's the odd part. In capture where the feed is not working, I show my PC sending the SYN, the camera sending the SYN/ACK, but then my PC doesn't ever send the final ACK. The only thing I see is the camera retransmitting the SYN/ACK and eventually my PC sending out a new SYN. If I didn't know any better, I would say it was a problem with my PC not sending the SYN, however I've tested it on multiple devices with the same results. This is the behavior on both port 554 and port 80. When I compare the SYN and the SYN/ACKs from the working capture, I don't see anything different from the non working capture, same options, same flags, etc. However, I suspect I'm overlooking something. To restore the feed, I simply reboot the camera. Any idea what would cause the 3 way handshake to fail like this? Thanks for your time! asked 21 Dec '16, 18:34  jasonm |
2 Answers:
I see the TCP checksum looks bad in the SYN/ACK packets that are not accepted. Bad TCP stack implementation on the camera? Maybe it calculates the TCP checksum prior to the option, so if the option is present it would be incorrect. There is no intervening device altering the packets? There was nothing obvious, but just be sure there is no other device capable of adding this option in mid stream causing the damage. Filter: tcp.checksum.status == "Bad" answered 22 Dec '16, 16:30  Bob Jones |
%5D.png)
A tracefile would help. And in this situation a good look at the status of your network connections. Try to identify the state of the workstations TCP session with the command Try to disable the firewall from your anti-virus vendor, if present (or disable the Windows firewall). Then re-run the test until the connections fail. Don't forget to re-enable the firewall once you are done. Good hunting. answered 22 Dec '16, 11:52  packethunter Thank you for the advice, I just disabled the firewall and AV and tried again, but still the same results. Netstat shows: SYN_SENT but never goes to ESTABLISHED. Here is the trace file: https://www.cloudshark.org/captures/b28932034bf6 My PC is: 192.168.100.253 Camera is: 192.168.100.224 The first part shows a time period where the camera feed is not working, (no ACKing the SYN/ACK) Then there's some successful pinging happening while the feed is still broken. I reboot the camera around packet 102. Packet 113 shows the SYN/ACK of the successful handshake after rebooting the camera. (SYN = 105, SYN/ACK = 113, ACK = 114) After looking a bit deeper, you can see that the TCP options are different between the SYN/ACKs that weren't ACKed versus the ones that were. For example: Packet 92: It's length is 4 bytes longer, because it has the TCP option for Window Scale set. The "good" SYN/ACK (packet 113) is missing that option. Could that option be the cause? (22 Dec '16, 14:40) jasonm |
Good catch, this was the reason the handshake was failing. I must have disabled the option for Wireshark to calculate the TCP checksum so I completely missed that. I seem to recall at one point it was recommended to disabling validation of this checksum because of the TCP offloading that some NICs had and would cause a lot of false positives. Reenabling it clearly highlighted this problem and none of my other TCP sessions were showing up as false positives. Lesson learned!