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

WiFi transfer issue causes loss of data after retransmission request

0

On my late 2011 Macbook pro (running OSX 10.9) a connection to a device that is streaming physiologic data can be established via an adhoc wifi network. Everything is running fine, i.e., data is correctly streamed, however, after some random time interval (in the range of 10-60 minutes) suddenly the wifi network entirely stops doing anything for a period of approximately 3 seconds and then continues working again. However, unfortunately at that moment physiologic data has been lost. Monitoring the incoming and outgoing TCP packets revealed the information shown below. After t=1459 s. (frame number 419728) there is a silent traffic period where no packets arrive at all. Anybody an idea what might cause the issue and more important how can it be solved?

Thanks in advance! Philip

No.     Time           Source                Destination           Protocol Length Info

419719 1458.952962000 10.11.12.13           10.11.12.14           TCP      806    4242 > 49977 [PSH, ACK] Seq=125104919 Ack=843 Win=3600 Len=752


419720 1458.952983000 10.11.12.14           10.11.12.13           TCP      54     49977 > 4242 [ACK] Seq=843 Ack=125105671 Win=65535 Len=0


419721 1458.983557000 10.11.12.13           10.11.12.14           TCP      1514   [TCP Previous segment not captured] 4242 > 49977 [ACK] Seq=125106207 Ack=843 Win=3600 Len=1460


419722 1458.983630000 10.11.12.14           10.11.12.13           TCP      54     [TCP Dup ACK 419720#1] 49977 > 4242 [ACK] Seq=843 Ack=125105671 Win=65535 Len=0


419723 1458.983921000 10.11.12.13           10.11.12.14           TCP      1514   4242 > 49977 [ACK] Seq=125107667 Ack=843 Win=3600 Len=1460


419724 1458.983947000 10.11.12.14           10.11.12.13           TCP      54     [TCP Dup ACK 419720#2] 49977 > 4242 [ACK] Seq=843 Ack=125105671 Win=65535 Len=0


419725 1458.999807000 10.11.12.13           10.11.12.14           TCP      1514   4242 > 49977 [ACK] Seq=125109127 Ack=843 Win=3600 Len=1460


419726 1458.999863000 10.11.12.14           10.11.12.13           TCP      54     [TCP Dup ACK 419720#3] 49977 > 4242 [ACK] Seq=843 Ack=125105671 Win=65535 Len=0


419727 1459.002706000 10.11.12.13           10.11.12.14           TCP      1514   [TCP Fast Retransmission] 4242 > 49977 [ACK] Seq=125105671 Ack=843 Win=3600 Len=1460


419728 1459.002751000 10.11.12.14           10.11.12.13           TCP      54     49977 > 4242 [ACK] Seq=843 Ack=125107131 Win=65535 Len=0


419729 1461.982928000 10.11.12.13           10.11.12.14           TCP      1514   [TCP Retransmission] 4242 > 49977 [ACK] Seq=125107131 Ack=843 Win=3600 Len=1460


419730 1461.983046000 10.11.12.14           10.11.12.13           TCP      54     49977 > 4242 [ACK] Seq=843 Ack=125110587 Win=65535 Len=0


419731 1461.983110000 10.11.12.14           10.11.12.13           TCP      60     49977 > 4242 [PSH, ACK] Seq=843 Ack=125110587 Win=65535 Len=6


419732 1461.986651000 10.11.12.13           10.11.12.14           TCP      1514   4242 > 49977 [ACK] Seq=125110587 Ack=843 Win=3600 Len=1460

asked 04 May ‘14, 08:50

phpvdb's gravatar image

phpvdb
11●1●1●2
accept rate: 0%

edited 04 May ‘14, 11:05

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237

One Answer:

0

Anybody an idea what might cause the issue and more important how can it be solved?

Well ... That could be almost anything.

  • the client stops sending or processing data due to a bug or overload
  • the server stops sending or processing data due to a bug or overload
  • there is packet loss due to a bug or overload in a network device (switch, router, firewall, etc.)
  • there is packet loss in the wifi/wlan network due to a bug or overload of the wifi/wlan AP/router, or one of the clients in your adhoc wifi network
  • there is packet loss in the wifi/wlan network due to interfering radiation (microwave, other medical devices), disturbing the wifi/wlan signals
  • there is packet loss in the wifi/wlan network because the radios signal gets absorbed by something with a lot of water in it (like a 'heavy' person sitting between the AP and the wifi/wlan clients - don't laugh, I have seen that in the field ;-))

The list goes on and on.

Unfortunately the '[TCP Retransmission]' shown in your capture output could have several of the reasons mentioned above.

So, you should try to eliminate some things by applying logic and/or by doing tests to rule out

  • the wifi/wlan network
  • the client and/or server
  • the network

Regards
Kurt

answered 04 May '14, 09:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 04 May '14, 11:05

Thank you Kurt for your detailed answer and suggestions. I was wondering, could there also be a (Mac OS X related) setting that might cause the network to "stop" (between packet numbers 419728 and 419729) for about 3 seconds (for example scanning for new wifi networks), assuming both sender and receiver are still actively sending and receiving data?

Regards Philip

(04 May '14, 14:32) phpvdb

Well, everything seems possible. However if that was standard behavior, one would have heard of that earlier, so I don't think that's the reason. On the other side, ad-hoc networks are not that common, so maybe it is standard behavior. Sorry, never heard of it.

Can you use ethernet instead of wifi/wlan to rule out the wireless network as the source of the problem?

(04 May '14, 15:43) Kurt Knochner ♦