Page 1 of 1

slightly odd behaviour with WLAN.config()?

Posted: Sat Oct 15, 2016 6:14 pm
by woodat
Breaking into 1.8.4 (been a while since I've had time to build anything) I've noticed some strange behaviour with the network library. Specifically I'm having trouble changing the essid of the AP wifi on my little wemos d1 mini.

I've tested this in both the REPL and webREPL and have had odd results. Here's roughly the commands used:

Code: Select all

import network
lan = network.WLAN(network.AP_IF)
At first the REPL just kept reporting:

Code: Select all

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: can't set AP config
Now, I had already used the command to set the ssid once (but the board had since been powered down and up again as I moved from work to home).

There was a reference here on the boards to it not working in repl but did work for someone in webREPL so I then attempted that. Surprisingly, the commands above worked.... once. I would get a numbered ets_task() line report back after typing in the .config() line.

Code: Select all

#6 ets_task(4020e374, 29, 3fff74f8, 10)  
I then tried again immediately with lan.config(essid='testnet2') and it worked. But Then I tried the first command again

Code: Select all

And nothing happened. No error, no ets_task(), nothing. It took a minute but I finally realised if the new essid string was inside the old one ('testnet2' obviously contains 'testnet') then it would just ignore the command. So at least now there's a workaround for this specific issue.

But at the moment I don't know what caused the initial error message when attempting from REPL. Since I enabled webREPL (and disabled it again) the commands in REPL are working once more.

Curious if anyone else has experienced this (and any warnings on if regularly changing the essid is going to cause problems in any way once I move all this to a code file and run on startup?)

Re: slightly odd behaviour with WLAN.config()?

Posted: Mon Oct 17, 2016 8:40 am
by platforma
You might have hit a bug. There's no limit to changing the APs as far as I know. I will try to reproduce the issue this evening.