unexpected network behavior with release 1.9

[Capstan]

I've written a little web app for the ESP8266 that is intended to let you see what WiFi access points are visible, whether or not they are open, and type in the password for restricted access points. This data gets written to a file so that other programs could read it and hook up to an AP requiring a password. The app establishes the 8266 as an access point itself that you can connect with using your cellphone, and then bring up the initial web page in a browser (good old 192.168.4.1).

Ideally you would test the password by attempting to hook up to that selected remote access point, otherwise you are just hoping.

This does require that the 8266 be active and connected in both station mode (network.STA_IF) and access point mode (network.AP_IF) simultaneously while the test is attempted. I had this working well with firmware prior to 1.9, and could validate a remote connection while still maintaining cellphone connection to the 8266 access point.

However, with 1.9 I am seeing an odd failure occur. The remote station connection can be successfully accomplished, but when that happens the access point seems to drop. The cellphone's loses connection and the web app can't be reached. Console messages as follows, with comments;

Code: Select all

connected with (redacted SSID) , channel 1
dhcp client start...
ip:192.168.1.239,mask:255.255.255.0,gw:192.168.1.254
checkLoop result: True  (<< my code detects successful connection)
err already associed!      (<< this odd message from somewhere)
station: 84:10:0d:4c:55:fe leave, AID = 1   (<< cellphone drops?)

You can see the client connection succeeds, and then there is "err already associed!" but no exception is thrown. Did simultaneous connection capability disappear in 1.9? Or is there some technique I am missing?

[mcauser]

Side note, shouldn't "associed" be "associated"?

[mcauser]

Similar issues for Arduino IDE, leading me to believe it's SDK related.
https://github.com/esp8266/Arduino/issues/2433
https://github.com/esp8266/Arduino/issues/2176
Edit: Theres a lot of issues on github with the term "err already associed!"

[Capstan]

Similar issues for Arduino IDE, leading me to believe it's SDK related.
https://github.com/esp8266/Arduino/issues/2433
https://github.com/esp8266/Arduino/issues/2176
Edit: Theres a lot of issues on github with the term "err already associed!"

Yeah I am thinking that too. 1.9 apparently incorporated a new SDK version, the message is probably printed out from within that. But I am wondering if this is a deliberate new limitation. Or perhaps there is something I can do to prevent it. Seems like it should throw an exception if I am trying something not allowed.

[pfalcon]

Yeah I am thinking that too. 1.9 apparently incorporated a new SDK version

It absolutely did not, or viewtopic.php?f=16&t=2140#p19545 would have mentioned it. And there's no hurried SDK switchovers exactly because it's well known that each vendor release brings issues, until proven otherwise. As there're no good, automated process to test new SDK releases, adopting a new release may take long time. For example, there're currently no plans for switching from well-tested SDK 2.0.0 to recently released 2.1.0.

[Capstan]

Yeah I am thinking that too. 1.9 apparently incorporated a new SDK version

It absolutely did not, or viewtopic.php?f=16&t=2140#p19545 would have mentioned it.

Hmm, thought I had seen that mentioned somewhere. But if not, then I think this is a regression in Micropython and may therefore be fixable. The exact same application code behaves differently between pre and post 1.9 firmware releases. It can maintain connections in AP mode while attempting to initiate connections in station mode prior to 1.9. Has this been tested?

[Damien]

@Capstan: are you using pre-built firmware from micropython.org/download, or are you compiling it yourself?

[Capstan]

@Capstan: are you using pre-built firmware from micropython.org/download, or are you compiling it yourself?

I am pulling it and compiling it myself due to need to freeze modules into the firmware. But that shouldn't make a difference, should it?

[Capstan]

I did a fresh pull tonight, built it and flashed it. The problem has mysteriously disappeared, my same code is now able to connect to an access point as a client (and subsequently disconnect) while maintaining a connection to a client as an access point itself. Cool!