search

pycom / pycom-micropython-sigfox

A fork of MicroPython with the ESP32 port customized to run on Pycom's IoT multi-network modules.
MIT License
197 stars 167 forks source link

WLAN initialization problem after reset #351

Open t0000899 opened 4 years ago

t0000899 commented 4 years ago

I have my WLAN connection code in boot.py file but unless I command wlan.deinit() before machine.reset() the WLAN will not reconnect at boot time. If that happen WLAN does reconnect if wlan.connect() is commanded manually after boot. This started when I upgraded the firmware version from 1.18.6 to 1.20.1.

Pycom MicroPython 1.20.1.r1 [v1.11-3138a13] on 2019-10-08; LoPy4 with ESP32 Pybytes Version: 1.1.3 Smart config is disabled.

Clip from my boot.py file


if useWlan == True:
    print('Configure WLAN')
    from network import WLAN
    wlan = WLAN(mode=WLAN.STA, power_save=True)
    wlan.ifconfig(config='dhcp')
    wlan.connect(AP_name, auth=(WLAN.WPA2, AP_password), timeout=30000)
    while wlan.isconnected() == False:
        machine.idle()
oligauc commented 4 years ago

Please can you go to the Pycom Firware updater folder and type the following command to cmd / terminal:

pycom-fwtool-cli.exe -p "your com port" erase_all

t0000899 commented 4 years ago

The behaviour is still the same after "erase_all". wlan.deinit() has to be commanded before reset or wlan is not connecting to the network.

I have soldered a 32,768 kHz crystal + capacitors to RTC pins in pysense board which is connected to Lopy4 but I don't think this has anything to do with this problem.

t0000899 commented 4 years ago

During "Request timed out." Lopy4 reported wlan.isconnected() -> True. I have been using COM port to terminal connection.

Reply from 192.168.11.61: bytes=32 time=61ms TTL=255
Reply from 192.168.11.61: bytes=32 time=69ms TTL=255
Reply from 192.168.11.61: bytes=32 time=78ms TTL=255
Reply from 192.168.11.61: bytes=32 time=86ms TTL=255
Reply from 192.168.11.61: bytes=32 time=95ms TTL=255
Reply from 192.168.11.61: bytes=32 time=103ms TTL=255
Reply from 192.168.11.61: bytes=32 time=111ms TTL=255
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.11.61: bytes=32 time=1ms TTL=255
Reply from 192.168.11.61: bytes=32 time=107ms TTL=255
Reply from 192.168.11.61: bytes=32 time=13ms TTL=255
Reply from 192.168.11.61: bytes=32 time=22ms TTL=255
Reply from 192.168.11.61: bytes=32 time=30ms TTL=255
Reply from 192.168.11.61: bytes=32 time=38ms TTL=255
robert-hh commented 4 years ago

What was the time between two Ping's

t0000899 commented 4 years ago

It is the default Windows 10 ping command. ping 192.168.11.61 -t

There seems to be some random lag with input characters if terminal connection is made with telnet. Same randomnes is with the heartbeat led too.

robert-hh commented 4 years ago

I just tried that with both linux and Windows, telnet window open: not ping loss, average ping response 2-3 ms. Standard firmware 1.20.1.r1

t0000899 commented 4 years ago

Of course I could have network problem in my house :) But the deinit() - init() wlan connection problem was not in the 1.18 firmware.

robert-hh commented 4 years ago

I never experienced that. But I use static IP addresses. To narrow down the problem, could you try to manually set the ip address with: wlan.ifconfig(config=('192.168.11.61', '255.255.255.0', "router-ip", "router-ip") In parallel, will try to use the "power_save=True" option.

robert-hh commented 4 years ago

OK. With the power_save option I see a massive increase in ping time, to an average of about 60 ms. The power consumption difference is ~90mA vs ~45mA net, so about 50% less with power_save.

t0000899 commented 4 years ago

Still wlan.deinit() has to be commaned before reset if static ip or power save on/off

t0000899 commented 4 years ago

It seems that the wlan initialization work every other time.

robert-hh commented 4 years ago

Strange. The only difference to the WLAN init code I use is, that I coded time.sleep_ms(200) instead of machine.idle() in the wait loop. But I remember having too idle() once. The only reason for the call to sleep is, that I print a progress bar. Edit: Idle() is fine too.

t0000899 commented 4 years ago

This is from my wlan router log. I don't know from where the "local deauth request" come from but Lopy is kicked out from the network. Second try is successfull.

2012/07/06 13:14:52 | DHCPS | sending ACK to 192.168.11.61 2012/07/06 13:14:51 | AUTH | wl0: AUTH: PSK authentication successful: 30:ae:a4:4e:5e:80 2012/07/06 13:14:51 | WIRELESS | ath0: had associated successfully : 30:ae:a4:4e:5e:80 2012/07/06 13:13:42 | AUTH | ath0: STA 30:ae:a4:4e:5e:80 IEEE 802.11: deassociated 2012/07/06 13:13:42 | AUTH | ath0: STA 30:ae:a4:4e:5e:80 IEEE 802.11: deauthenticated due to local deauth request 2012/07/06 13:13:39 | WIRELESS | ath0: had associated successfully : 30:ae:a4:4e:5e:80

Edit: wlan.deinit() cause ath0: STA 30:ae:a4:4e:5e:80 IEEE 802.11: deassociated

amotl commented 4 years ago

Dear @t0000899,

we are also observing the same thing on a FiPy 1.2 device sitting on an expansion board. The first time we recognized this problem was on firmware version 1.20.0.rc12.1 already, but it might have occurred even earlier.

In practice this will look like the log at "Connect to WiFi twice" below. First of all, the connection fails, but after you connect() again, it works successfully. Anything but optimal, but that's just how it seems to be. [1]

We still experience WiFi connection problems on the very first attempt after a hard reset. This is deterministic for us on a FiPy sitting on an expansion board on our workbench. Invoking .connect() twice with a short delay in between makes things work. While this feels weird, we haven't been able to find a different workaround. [2]

The workaround we are applying to this problem is to just invoke connect() twice, as outlined within [3].

Personally, I believe this has nothing to do with the Pycom firmware, it is more likely that it's related to the ESP-IDF under the hood. However, we haven't been able to investigate this specific issue further based on these assumptions.

Thanks already for letting us know about the local deauth request as outlined above. This is a good place to start investigating related issues within ESP-IDF. Spoiler: There are lots of these things ;]. Espressif is occasionally working on mitigating them, so there's still hope for us to receive robustness improvements sometimes in the future.

With kind regards, Andreas.

P.S.: The issue might also be related to the access point the device is connecting to, so we shouldn't be fooled by looking at the device only. We are running a FRITZ!Box 7520 here, may I humbly ask you which type of AP you are trying to connect to?

[1] https://community.hiveeyes.org/t/stabilitat-und-langere-testzeitraume-des-terkin-datenloggers/2260/81 [2] https://forum.pycom.io/topic/5379/wlan-scan-not-working-on-fipy/11 [3] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/4cf2c516/terkin/network/wifi.py#L315-L324

t0000899 commented 4 years ago

Hi @amotl, My Wlan router is an old Buffalo WHR-G300N with 1.85 firmware. I haven't had any trouble with other devices connecting. I believe that the router is OK and is following standards well.

My workaround to this has been calling wlan.deinit() before entering deepsleep so that the AP release the association before next wlan.init().

amotl commented 4 years ago

Dear @t0000899,

thanks for confirming the observations on your WiFi router. To be safe on that, we will also implement this appropriately within the Terkin Datalogger we are building these days (https://github.com/hiveeyes/hiveeyes-micropython-firmware/issues/37).

Edit: Hm, it looks like we are doing that already [1] - so nevermind.

Thanks and with kind regards, Andreas.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/0.6.0/terkin/network/wifi.py#L123-L137