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

TCP out-of-order and other on a wireless link

1

Hello everybody.

I'm troubleshooting a network with Wireshark and, being new to deep traffic analysis, maybe some of you could give some advice to understand what's happening.

Let me depict the scenario:

            Internet
               |
               |    <-Wired link
               |
            Core LAN
               |
               |
    Branch#1--------Branch#2

           ^
           |
    Wireless 5,8 GHz PMP link</code></pre><p>Branch#1 uses the link only for basic office Internet access, browsing and mail. Branch#2 surfes the Internet and uses an application running on a server in the Core LAN.</p><p>Users in Branch#1 don't report problems for now. User in Branch#2 (only three) complain about "expired connections" when using their TCP application. All I could get from application support was "it is due to lost connectivity to server". But when the issue (randomly) appeared, access to Internet was up, so there was no lost connectivity.</p><p>I used the Packet Monitoring tool in the firewall connecting all networks and exported to Wireshark. One of the samples showed that 28% of captured packets were (almost half) downlink TCP out-of-order, retransmissions, fast retransmissions and lost segments (from Internet to Branch#1) and (the rest) uplink Duplicated ACKs (from Branch#1 to Internet).</p><p>About Branch#2, another sample showed similar statics from or to Application Server, except for Duplicated ACKs, much less than for Branch#1. I know it's not very comprehensive but maybe significant, I still don't want to go deeper without knowing what and where to look for.</p><p>The fact is that, prior to installing the wireless link, users in Branch#2 connected to the application server through an ADSL router and Logmein Hamachi software (I didn't know it, some kind of virtual VPN) and they only complained about slowness. Now, response from server is quick but annoying. I wonder if this issue could be related to the wireless link behaviour and if it's usual on such links. Maybe some of you have some experience with them. I browsed the forum but I didn't find some useful clue in similar cases.</p><p>Thank you all.</p><p>Regards.</p></div><div id="question-tags" class="tags-container tags"><span class="post-tag tag-link-wireless" rel="tag" title="see questions tagged &#39;wireless&#39;">wireless</span> <span class="post-tag tag-link-out-of-order" rel="tag" title="see questions tagged &#39;out-of-order&#39;">out-of-order</span></div><div id="question-controls" class="post-controls"></div><div class="post-update-info-container"><div class="post-update-info post-update-info-user"><p>asked <strong>01 Jun '11, 02:15</strong></p><img src="https://secure.gravatar.com/avatar/7c31c4e7640e4bee439cf0af16eb7201?s=32&amp;d=identicon&amp;r=g" class="gravatar" width="32" height="32" alt="CVA23&#39;s gravatar image" /><p><span>CVA23</span><br />



31●1●1●3

accept rate: 0%

It is possible to determine the direction of the packet loss if you know what to look for. But given that BR1 users are not complaining, I would start with looking at the setup at BR2. For example, do the users have a duplex mismatch? Does the uplink to the wireless router have a duplex mismatch? Also, how did you perform the capture on the FW? Did you capture incoming and outgoing interface at the same time? It’s possible that your wireless signal is weak and is causing this issue, but you have to start to divide and conquer. Start at BR2 and see if the problem is local or not.

(01 Jun ‘11, 17:00) hansangb

It would also help if you can post the binary capture files somewhere (you can use snaplen of 96 or so bytes. There’s no need to see the full packet size.

(01 Jun ‘11, 17:01) hansangb

If packet loss is an issue you want to identify the point where packets are lost. As hansangb pointed out, BR2 configuration might be the key. When it comes to wireless you might have obstacles like trees between sites.

After following hansangb’s advice on duplex mismatch I would pinpoint the traffic-leg where you loose packets by capturing at the core and branch 2 uplink simultaneously. (Guess that’s what he meant with “divide and conquuer”.

(02 Jun ‘11, 06:27) packethunter

One Answer:

1

Sorry for being so late after I posted this question, but I had to park this case for a time while solving another ones.

Thanks to hansangb and packethunter for your answers. In fact, I divided and conquered:

First, I tuned the wireless links, there were too much re-registrations causing the link to be reestablished.

Second, I checked the firewall and found dropped packets caused by "Invalid TCP flag". Through the firewall TAC I tuned the TCP timeout and dropped packets disappeared.

Since then, conflictive packets went down from 28% to 2%. I don't know if even 2% is too much in such configuration, but I know that users don't complain and that's enough for now.

In any case, I'm still monitoring these networks to be sure it's working fine because I'm suspecting of some misconfigured or compromised PC in the Branch#1 or Branch#2 network according to what I could see (one of the earlier captures showed an upload to a "uncommon" url). Unluckly, those networks aren't still under my management and I can't go farther by now. And wireless links are always subject to uncontrolled factors, so I must go on watching.

Thank you all.

Regards.

answered 16 Jun '11, 03:43

CVA23's gravatar image

CVA23
31●1●1●3
accept rate: 0%