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

TCP DUP and resetting phone

0

We have a couple of mitel phones connected to a brocade switch stack having issues. The phones are resetting and dropping randomly. When I do a wireshark sniff on the traffic between the PBX and phones I see lots of TCP DUP ACK messages, which seems to be corresponding to phone outages.

Anyone have ideas what could be causing it?

Capture here: https://www.cloudshark.org/captures/5ea68460fb66

I stripped it down to just the traffic between one set and the PBX. Multiple random phones seem to be affected. The phone and PBX or connected to the same L2 switch.

asked 26 Sep '14, 16:09

webman's gravatar image

webman
11112
accept rate: 0%


2 Answers:

1

How was this capture taken? I guess via SPAN port? Did the phones reset during the time of capture? I'm asking because there is no TCP session reset in the trace.

If you filter for "tcp.stream==1" you'll see that there is a pattern of of duplicate ACKs with suspicious delta timings of almost 10 seconds for every second ACK. Maybe this is some weird way of the devices doing a session keep alive.

The other stream ("tcp.stream==0) has some curious retransmissions, starting in frame 126. Curious, because they start coming in 48 seconds (!!!) after the original packet (which does not get acknowledged for some reason), which is a retransmission time out I have never seen before.

From what I see the TCP stacks of the devices do strange things - if the captures where created on a SPAN port my next move would be to capture the PBX with a real full duplex TAP, because when things are weird you need to make sure it's not the SPAN session that is responsible for some of it.

answered 26 Sep '14, 17:48

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

It was done with a span port. Will try a tap and see if the results change. Thanks

(26 Sep '14, 18:23) webman

0

Sorry Jasper, but I don't see the 48 seconds retransmission timer and I don't agree with the TCP stream 1 is an idle connection with the PBX sending zero length keepalives so all those duplicate acks are a false alert and can be ignored. The phone is acking with tcp.ack 2 but PBX keeps on sending empty packets with tcp.seq 1
- Nothing weird here, TCP keepalive without a garbage byte) - List item

The problem starts in packet 125 with the phone sending 176 bytes which doesn't get through so slow retransmission kicks in with increasing rxmit intervals (0.239 - 0.719 - 1.679 - 3.593)
Packet 130 is the ACK of the retransmitted packet, so the PBX has finally received the 176 bytes.
The sequence number in packet 130 however indicates that the PBX in the meantime also sent 176 bytes which did not arrive at the phone. The missing 176 with seq 2641 finally arrive after another 1.089 seconds and the phone acks the data. alt text

So this is an indication that we had a connectivity issue in both directions between 16:03:38.188 and 16:03:41.782 UTC. While this is not nice on a local LAN it is certainly not a reason to 'reset or drop' the phone.

answered 27 Sep '14, 06:14

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

If its a connectivity issue in both directions and its on the same switch, then that would have to be a overloaded port on either the PBX or phone, or a problem with the L2 switch. Correct?

(27 Sep '14, 06:53) webman

Right @mrEEde, I overlooked that packet 112 has an empty TCP payload, I just looked at the sequence number - it was probably just too late in the night for me :-)

(27 Sep '14, 09:13) Jasper ♦♦