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

Microsoft Lync 2013 login problem

0

I am investigating strange behavior of Microsoft Lync login problem. The problem is: "With same client PC(MAC address:c0:3f:d5:b0:a6:0a) and same login account, Lync login failed with IP add 10.212.76.119, while login successed with IP 10.212.76.73"

I have two Wireshark's logs, one for problematic scenario and one for successful. I uploaded them here:

I can see that both in problematic & successful scenario there are series of "TCP Dup Ack" and "TCP Previous segment not captured", while in problematic scenario, no "TCP Retransmission" found.

Could anybody explain why it could be the possible reason for this to happen?

Thanks a lot in advance, Kevin

asked 27 Sep '14, 22:09

hongtj's gravatar image

hongtj
11112
accept rate: 0%


One Answer:

2

Hi,

  1. In 119 client capture after dup ack server 23 is sending reset.
  2. Server 23 IP header consist AF31 assured forwarding qos setting.
  3. If you see in working pcap the pattern was same first packet(1460 bytes - full mss) size is dropped and then retransmission were re-packetised with 3 full 536 bytes packets this indicates possible MTU issue in hops beetween client and server.
  4. But for client 119,server 23 could be keep on sending full mss size packet(note that packets from 23 has DF bit set)and after multiple retransmission 23 gives up and sent RST,could be for several reason,For e.g, Device with lowest mtu not sending icmp fragmentation needed message because of ICMP rate limiting feature.

You can check MTU setting on all hops between client and server.It looks there are 6 hops by looking at TTL of server 10.232.211.23 which is 122.This is just assumption capture at both end will clear the picture.

answered 28 Sep '14, 00:00

kishan%20pandey's gravatar image

kishan pandey
221282936
accept rate: 28%

edited 28 Sep '14, 09:27

Jasper's gravatar image

Jasper ♦♦
23.8k551284

Quite exactly! client 119 is linked with server 23 with GRE tunnel. Server 23 is marked with AF31 for QOS.

So it seems what we should do next is to find out where along the path the ICMP message is blocked or where along the path the DF bit has been setted. Is that correct?

Thanks a lot, Kevin

(28 Sep '14, 07:15) hongtj

The better method of handling this would be to reduce the MSS in the syn packets as the enter the GRE tunnel. https://www.google.de/?gws_rd=ssl#q=adjust-mss+gre

(29 Sep '14, 14:20) mrEEde