Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SoftAP mode persisting when setup complete #971

Closed
m-mcgowan opened this issue Apr 20, 2016 · 7 comments · Fixed by #972

Comments

@m-mcgowan
Copy link
Contributor

commented Apr 20, 2016

https://community.particle.io/t/listening-mode-persisting-past-softap-setup/19928/6

Test case:

SYSTEM_MODE(SEMI_AUTOMATIC);

void setup()
{
    WiFi.listen();
}
  • start up the photon - connect to the softAP, e.g. curl http://192.168.0.1/device-id
  • connect via serial and send 'x' to cause listening mode to exit
  • connect to the softAP, e.g. curl http://192.168.0.1/device-id - the AP network is still available

Workaround:

void setup()
{
    WiFi.on();
    WiFi.listen();
}

Completeness:

  • Minimum test case added
  • Device, system and user firmware versions stated
  • Particle confirmed

@m-mcgowan m-mcgowan added this to the 0.6.x milestone Apr 20, 2016

m-mcgowan added a commit that referenced this issue Apr 20, 2016
when the wifi module was not active (and so made active in the listen…
… method) the on_stop_listning() method was not called due to short-circuit evaluation when `started` was false. Swapping the order fixes this. Fixes #971.
@pomplesiegel

This comment has been minimized.

Copy link

commented Apr 21, 2016

I believe @karlhenricksen has seen this as well - shown as the SoftAP WiFi network still broadcasting while the Photon is breathing cyan, and successfully connected to a network.

@karlhenricksen

This comment has been minimized.

Copy link

commented Apr 21, 2016

Yes, I've seen this twice but haven't been able to find a reliable way to reproduce and only occurred when doing some irregular steps. Here are my notes from the 2nd time:

2nd occurrence after sending incorrect pw (returns to blinking blue):

  • allow the 10min timeout (returns to blinking green) **this is a user timeout to exit listening mode
  • tried to reset up wifi (even though was in blinking green), follow normal setup process
  • eventually it successfully connected (breathing cyan)
    ==> so seems it connected and new wifi creds actually went through.
    ==> now it's in an in-between state where it's connected AND broadcasting?
@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2016

The key trigger condition is that WiFi is off when entering listening mode. This caused the softAP tear down code to not be executed.

@pomplesiegel

This comment has been minimized.

Copy link

commented Apr 21, 2016

Hmm - that's interesting. In our code we never turn the WiFi chip off, yet we saw this occur twice.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2016

In semi automatic mode the wifi chip starts in an off state, so if the first thing that happens is WiFi.connect() with no credentials, then it will enter listening mode with WiFi being initially off.

@pomplesiegel

This comment has been minimized.

Copy link

commented Apr 21, 2016

Interesting! OK, looking forward to this fix.

On Thu, Apr 21, 2016 at 2:14 PM Matthew McGowan notifications@github.com
wrote:

In semi automatic mode the wifi chip starts in an off state, so if the
first thing that happens is WiFi.connect() with no credentials, then it
will enter listening mode with WiFi being initially off.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#971 (comment)

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 21, 2016

The fix is in the PR linked above if you'd like to pull and integrate it. It will be released with 0.6.0.

technobly added a commit that referenced this issue Jul 12, 2016
when the wifi module was not active (and so made active in the listen…
… method) the on_stop_listning() method was not called due to short-circuit evaluation when `started` was false. Swapping the order fixes this. Fixes #971.

@technobly technobly removed the in progress label Aug 9, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.