Wifi access point dropouts under wifi load

[SS_Di]

We are observing strange (and to us very problematic) wifi dropouts on Edison. I wonder if anybody else has seen these and knows of a possible solution or workaround.

Use case

The Edison's wifi is in access point mode, and we are continuously sending data (like ~1MB/s).

Problem

What we observe are sudden stalls in the transmitted data. During these stalls only the beacon frames are send. The Edison cannot be reached/pinged from any associated device.

After some time (2..~60sec) the Edison starts sending data again.

Observations

The dropouts/stalls can be resolved by trying to associate another device to the access point (works also with incorrect password).

It seems that how often it appears is related to wifi conditions and/or client types. With some clients it is more noticeable than with others. It can be reproduced very well with Ubuntu 14 using intel wifi card, but it also appears with certain Android and iOS devices.

To reproduce we tested using vanilla Edison images with just access point enabled and generating traffic using netcat.

We tried some things already, but they did't work:

• Using different distributions: yocto 1.7.2 and 1.7.3, ubilinux (150309)
• Updating hostapd to v2.5
• Using different carrier board (Arduino, Mini, and our own custom board)
• Using different antenna's (internal, several external types)
• Try using a more recent driver for the chip. It seems Intel has made significant modifications to it, so that path was abandoned.

Any help on this will be much appreciated.

[idata]

Hello Thors,

The issue you are describing is very similar to behaviors reported by several users using netcat. Please check this thread: https://communities.intel.com/thread/104985 https://communities.intel.com/thread/104985? Could you please verify if the issue described in there is the same one you are experiencing? Also, could you please let us know the steps (as detailed as possible) required to replicate the behavior you are describing? They might be of much help for us. -Peter.

[SS_Di]

Hi Peter,

Yes, that post seems to describe the same issue we're experiencing (I searched extensively before that was posted). I was hoping on a fix or workaround.

We used a similar approach to test. The steps described in that post already describe in detail how to replicate.

Let me know if you need more info. I can also do a wifi capture to show the packages going around when needed.

Best.

[idata]

Hello Thors,

Thanks a lot for confirming that indeed you are experiencing the same behavior. Please do send us a Wi-Fi capture, it'd be of much help. Also, if there is any other information that you consider useful, please post it here. If you could provide us a step by step guide to replicate the issue would also be of great help. We are currently working on finding a solution for this issue but there's no ETA on when a fix might be made available. I apologize for the issues this might cause. -Peter.

[SS_Di]

Thank you, we will also keep investigating. I will do a capture soon and send the results.

- Thors

[idata]

Thanks, it would be of much help for us. We truly appreciate your patience and understanding.

-Peter.

[SS_Di]

The capture that shows the issue is recorded, along with a description of how it was done and a description of the key times stamps in the capture. What is the preferred way to get this to you? (100MB capture)

[idata]

Thanks a lot for your help. If it's possible, you could upload it to any cloud storage service (such as Drive, Dropbox, OneDrive, etc…) and send us the link. In case you don't want to maek the link public you can send it to me in a private message.

We truly appreciate your cooperation and your patience.-Peter.

[SS_Di]

Hello Peter, I send you a private message with the link.

If anybody else is interested, let me know.

[idata]

Hello Thors,

I have replied to you in a private message, could you please check it?Once again, we really appreciate your help and your patience.-Peter.