- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting observation.
We have a WICED development board configured to connect to an AP with DHCP. Before network up, app registers for link and ip change events. After successful connection, the application stays idle. The AP is D-Link DAP-1350.
After an hour or so being idle, it keeps cycling periodically from link down, ip change, link up, ip change states. It keeps cycling until it stops getting the ip change and stops. No other device on this AP is experiencing this behavior, as far as we can tell.
Any suggestion is appreciated.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FYI. we figured this out. You need to turn on WiFi keep-alive when it is just sitting idle. For some reason, it works fine without keep-alive when joined to an Apple AP, but the rest seem to require it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FYI. we figured this out. You need to turn on WiFi keep-alive when it is just sitting idle. For some reason, it works fine without keep-alive when joined to an Apple AP, but the rest seem to require it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am going to try this. We are spontaneous link down and deauth events at no specific time interval. It can be anywhere from 5 minutes after connection to 2 hours after connection. If it resolves our issue, I will post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It did not resolve our issue since we were never idling.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bummer. Our experience has been pretty good after adding keepalive.
I am interested in the final solution for your project, just to make sure we don't release a final product that has issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our issue was caused by stalling the socket. The reason for the stalls was because we had 2 tasks in our OS operating on the same socket at once. One task sent data and one received asynchronously. We've moved to a windowing scheme that pushed all the data out, then attempts to receive before finally turning low power back on.
This seems to have resolved our issue (at least in 99% of observed cases)