I have two captures. In one, I see a handshake from the phone to the Voice Server (working capture). In the non-working one, I do not see an ACK from the client after the SYN/ACK from the Voice Server. Initially I thought it might be a routing issue since maybe the SYN/ACK from the server is not reaching the client or the ACK from the client is not reaching the server. But traffic other than Voice is going fine back and forth between the client and the server. There is no FW between them. Any idea why we do not see any ACK from the client back only for the Voice traffic. I thought maybe something in the SYN/ACK which the phone is not liking perhaps. I saw the TCP options , exactly the same except MSS which is higher in the working one (1380 in the working one and 960 in the non-working one). asked 24 Aug '13, 23:40  parvikram |
2 Answers:
Please apply the following filter to the Non-Working file.
You will see a possible reason for the whole problem.
In frame 70 you see the SYN frame. In frame 112 you see a ping request (ICMP ECHO request) from 192.168.42.115 to 172.16.8.2. This client is (probably) in the same subnet as the client in frame 70 (192.168.42.230). Now, in frame 113 you see an ICMP Time-to-live exceeded for the packet in frame 112. This means there is either a routing loop somewhere or an intermediate device (firewall, IDS, etc.) dropped the packet and sent this rather unusual ICMP message. The same problem could cause the missing ACK frame, if the SYN-ACK frame did not reach the client. If you did not capture on the client (or very, very near the client), you would see the frame in the capture, but you have no idea if it really reached the client! So, here are some questions:
Regards answered 26 Aug '13, 06:40  Kurt Knochner ♦ edited 26 Aug '13, 06:41 Some observations from the "nonworking" capture The ICMP TTL Exceeded messages are validly issued because a Dell PC at 192.168.42.115 is sending PING requests with a TTL of 1 at 1-second intervals: http://bit.ly/15eZVre This machine is also sending other PING requests with higher (random) TTLs none of which ever gets an ECHO REPLY. So, I'd say there IS a FW involved that blocks those ICMP ECHO REQUEST packets and also ICMP TTL EXCEEDED messages as even a TTL of 2 does not result in such a message. 192.168.42.201 is the default gateway (Hewlett-_6d:2a:c0) for the Mitel 5312 IP Phone as this is the first ARP request/reply after the reboot of the phone : http://bit.ly/18hg2qd The trace must have been taken at the HP switch Hewlett-_6d:2a:c0 So, I don't think the TTL Exceeded messages are related to the problem of the Mitel IP Phone not reacting to the SYN_ACK (27 Aug '13, 00:08) mrEEde Kurt, thanks for the response. But I don't think ICMP has got to do anything with the Phones not replying with an ACK. The captures have been taken ON the client itself. This clearly indicates that the SYN/ACK is reaching the phone but its still not responding with the ACK. Please filter the communication between 192.168.42.230 and 172.16.8.2. You can safely ignore the ICMP. (27 Aug '13, 00:33) parvikram
Ah good one!! I should have checked the TTL. That teaches me once again: Never assume anything ;-)) (27 Aug '13, 03:10) Kurt Knochner ♦
Well, then either the capture process is broken (not recording the ACK - rather unlikely as there are several SYN-ACK because of the missing ACK) or the TCP stack is broken (not sending the ACK). (27 Aug '13, 03:14) Kurt Knochner ♦ |
"I saw the TCP options , exactly the same except MSS which is higher in the working one" This is not true. In the failing case the order of appearance of the TCP options is different. The fingerprint of the failing scenario shows the windowscale option first, followed by MSS and NOP. The successful scenario shows MSS,NOP,Windowscale Also, the TTL and RTT of the Server's packets are different:
I merged the 2 traces's SYN and RST packets to the server and put it here: http://www.cloudshark.org/captures/3fd12a6976d8 I think you should address this problem in the mitel forum: http://www.mitelforums.com/ answered 27 Aug '13, 00:40  mrEEde That is correct. The order is different. And thanks for directing me to this forum. I'm pretty sure its something this phone is not liking. (27 Aug '13, 01:38) parvikram The MSS in the SYN-ACK packet is also different (Working: 1380, No-Working: 960 - same as the client), as already mentioned by the OP. Looks like a bug in the TCP stack of the phone. (27 Aug '13, 03:35) Kurt Knochner ♦ |
It would help if you could upload both the working and the non-working 3-way-handshake to http://www.cloudshark.org and then paste the links to the files here.
Here are the working and non-working captures.
http://www.cloudshark.org/captures/440d3545a7a4 : Working
http://www.cloudshark.org/captures/46d040cdbedb : Non-working
The Voice server is 172.16.8.2