This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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's gravatar image

parvikram
1222
accept rate: 0%

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.

(25 Aug '13, 06:51) SYN-bit ♦♦

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

(26 Aug '13, 00:55) parvikram

Please apply the following filter to the Non-Working file.

ip.addr eq 172.16.8.2 or icmp

You will see a possible reason for the whole problem.

http://www.cloudshark.org/captures/46d040cdbedb?filter=ip.addr%20eq%20172.16.8.2%20or%20icmp

In frame 70 you see the SYN frame.
In frame 80 you see the SYN-ACK 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:

  • Where exactly did you captured the traffic?
  • Is there a firewall involved?
  • How is the system 192.168.42.201 (sender of the ICMP TTL exceeded) involved in the whole game? It seems to be the default gateway in that subnet, as frame 70 is directed to the MAC address of 192.168.42.201.

Regards
Kurt

permanent link

answered 26 Aug '13, 06:40

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

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

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

Ah good one!! I should have checked the TTL. That teaches me once again: Never assume anything ;-))

(27 Aug '13, 03:10) Kurt Knochner ♦

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.

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:

  • 56/168ms for the failing case
  • 61/140ms for the successful case.

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/

permanent link

answered 27 Aug '13, 00:40

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

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 ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×44
×5
×5

question asked: 24 Aug '13, 23:40

question was seen: 11,426 times

last updated: 27 Aug '13, 03:35

p​o​w​e​r​e​d by O​S​Q​A