Arduino
Arduino copied to clipboard
esp8266
no more 802.11n connection since 2.6.0
Basic Infos
- [x] This issue complies with the issue POLICY doc.
- [x] I have read the documentation at readthedocs and the issue is not addressed there.
- [x] I have tested that the issue is present in current master branch (aka latest git).
- [x] I have searched the issue tracker for a similar issue.
- [x] If there is a stack dump, I have decoded it.
- [x] I have filled out all fields below.
Platform
- Hardware: ESP-12
- Core Version: 2.51 , 2.6.0, 2.7.4
- Development Env: Arduino IDE 1.8.13
- Operating System: Windows
Settings in IDE
- Module: Wemos D1 mini r2
Problem Description
sketch is "Udp NTP Client" included with release core.
I recently noticed that I had 802.11n and 802.11g devices on my network. and I noticed that those which were connected in 802.11n are old modules on which I did not make any change in their codes and which were compiled with a core version lower than 2.5.0 (2.4.2 for the majorities)
I therefore put the supplied program "Udp NTP Client" and I tested with different versions of the cores, starting from 2.4.2.
up to version 2.5.1 included, it appears in 802.11n on the wifi router of my box. except since version 2.6.0 until the last 2.7.4, it appears in 802.11g ...
do you have any idea why?
Really a firmware problem? My 8266 modules connect well with 2.7.4:
NB: 72 MBit is only possible with N not with G
that's why I'm asking for advice! I don't change anything, it's the same Lolin module (original V3.10) it's the same code (delivered with the core, I didn't write anything more) no change of config on my router I install the 2.42 core, I am recognized in 802.11n on the router, ditto in 2.5.1. as soon as I install the 2.6.0 core I am recognized in 802.11g, ditto until the current version 2.7.4.
for me there is something that has changed with the passage of 2.6.0
You can try with other/older firmware version in the IDE menu: You need to select the board "generic esp8266" and match its configuration with your board. A new menu entry will propose several versions of the closed nonosdk firmware.
And if possible do it with the current source code. There are three ways for doing so: latest git master / PlatformIO staging version / arduino board manager snapshot release 0.0.1.
so: core 2.74 card configured in generic esp8266, with flash DIO mode.
with the nonos-sdk versions "2.2.1 + 100", "111", "113", "119" I am connected to the router in 802.11g. with the versions "nonos-sdk 2.2.1 (legacy)" and "nonos-sdk pre-3 (180626 known issues)" I am connected in 802.11n !!! on as I configure in "LOLIN (WEMOS) D1 R2 & mini" I go back to 802.11g.
I did not find where is to configure the version of the nonos-sdk for the lolin?
Well that's interesting !
This menu is disabled for non generic boards. There are three possibilities:
- Use the generic board and add the content of
variants/d1_mini/pins_arduino.hin your sketch (selecting a board wemos-d1 in the menu is just a matter of selecting default values in the generic esp8266 board menu entries and including the right variant file for pin naming) - Enable this FW menus for all boards
- Allow users to add this menu entry by using the
tools/boards.txt.pyscript
I think 1) is the easiest. The newer versions fixed some bugs and we settled to the current menu status a while ago after some discussions.
yes i will do that, thanks
on the other hand, how to know which version of nonossdk is used when precisely a non generic card is used?
It's the same one as the default value (= the first) for the generic board.
You can also read its (default when not overwritten by menu selection) value in platform.txt:
build.sdk=NONOSDK22x_190703
(which is nonos-sdk 2.2.1+100 (190703) you can see that in boards.txt).
Indeed interesting your experience with the different SDK releases, because I´m using V 119 (including some Wemos D1 Mini as generic 8266 to change SDK version). Have to tried deleting WiFi settings during flash?
En effet intéressant votre expérience avec les différentes versions du SDK, car j'utilise V 119 (y compris certains Wemos D1 Mini comme générique 8266 pour changer de version SDK). Avez-vous essayé de supprimer les paramètres WiFi pendant le flash?
i test this, with generic, v119, and erase sketch +wifi settings... and 802.11g too
I can confirm it. 2.6 and later can't use n-mode at all. If I enable "option require_mode 'n'" in OpenWrt (so called "Greenfield" mode when only n-capable clients can connect) esp with core 2.5.1 can connect to the AP, more recent ones - can't connect at all.
"Core":"2_7_4","SDK":"2.2.2-dev(38a443e)" - G-mode, no MCS value
iwinfo wlan0 assoclist
3C:71:BF:29:60:CF -59 dBm / unknown (SNR -59) 250 ms ago
RX: 48.0 MBit/s 77 Pkts.
TX: 5.5 MBit/s 64 Pkts.
expected throughput: unknown
"Core":"2_5_1","SDK":"2.2.1(cfd48f3)" - N-mode indicated by "MCS 6"
iwinfo wlan0 assoclist
3C:71:BF:29:60:CF -58 dBm / unknown (SNR -58) 40 ms ago
RX: 54.0 MBit/s 201 Pkts.
TX: 58.5 MBit/s, MCS 6, 20MHz 73 Pkts.
expected throughput: 4.5 MBit/s
Could it be that OpenWRT only advertises a limited set of HT MCS modes and the ESP only supports a different subset? In MikroTik APs you can see the advertised modes and I guess you can also enable/disable them although the checkboxes in my MikroTik units are greyed out.
I've tested 802.11n with default configuration, single channel bandwidth, no limitations or restrictions for specific MCS, etc... same board with the same code (just a simple WiFi connect) is able to connect to the same WiFi AP with an old core and unable with a recent one.
Can not reproduce. Core 2.7.4
00:00:03.970 WIF: Connecting to AP1 Jason_Home_WLAN Channel 12 BSSId 00:A0:57:2A:BD:19 in mode 11n as sonoff-71C254-0596...
00:00:06.268 WIF: Connected
have tested with new 3.0.0 arduino esp8266 i have only connect 802.11n with nonos sdk 2.2.1 legacy, not with other
Tried with core 3.0.0 connects in mode 11n
00:00:00.065 Project tasmota Tasmota Version 9.4.0.4(lite)-STAGE(2021-05-28T14:25:30)
00:00:00.520 WIF: Connecting to AP1 Jason_Home_WLAN Channel 12 BSSId 00:A0:57:2A:BD:19 in mode 11n as tasmota_D4407C-0124...
00:00:02.751 WIF: Connected
Core 2.7.4 connected to a OpenWRT device
00:00:00 I2C: BME280 found at 0x76
00:00:04 WIF: Connecting to AP1 Jason_Home_WLAN Channel 4 BSSId 88:C3:97:B1:1D:56 in mode 11N as sonoff-17DBAE-7086...
00:00:06 QPC: Reset
00:00:06 WIF: Connected
Tried with core 3.0.0 connects in mode 11n
Those logs are from ESP and they lie. It reports mode n but connects as mode g actually. You should check the access-point itself which mode is used by it's clients. In OpenWrt you can check with 'iwinfo wlan0 assoclist', if esp client's MAC is missing any MCS value than it is in mode g.
And yes, I confirm, with Core 3.0.0 it's the same issue - no mode N. My guess it is related to SDK 2.2.2, not Arduino core.
So you're telling me that if I configure the access point to only allow 802.11n clients, it is impossible to connect to an access point using current builds based on SDK 2.2.2?
My MAC address of an ESP: FC:F5:C4:8B:71:60 SDK: ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support Stated wifi connection: 802.11g (RSSI -57 dBm)
Mikrotik AP it is connected to:
I will now set it to 'n' mode to see....
Set to connect via "n" mode:
WiFi Connection: 802.11n (RSSI -55 dBm)
TX rate is > 54 Mbps, so this can't be "g".
As a test, the WiFi mode is set to "2GHz-only-N" (cleared the password field for the screenshot)
As you can see, the same node is connecting just fine.
where do you find the nonos sdk 2.22 ?
with the instalation of the arduino 3.0.0 esp8266 core
I have version 2.2.1
2.2.2 is not and will probably never be out.
2.2.1+n (git versioning) is noted 2.2.2-dev by espressif's system_get_sdk_version() in their 2.2.x git branch.
So you're telling me that if I configure the access point to only allow 802.11n clients, it is impossible to connect to an access point using current builds based on SDK 2.2.2?
yes, that is exactly what I see. Need to make sure that b/g modes are completely disabled.
Are you able to get the details of ESP client's MCS used? TX bandwidth might be confusing, only MCS index used could indicate which modulation type of N mode is used.
Do not have RouterOS devices at hand to test, but I've checked the docs and it seems that "2GHz-only-N" actually means all 2.4 b/g/n Modes.
Pls, test it carefully if possible. That issue seems very tricky.
I don't know how to see what MCS's are used. But if I set my ESP to use 'G' only, and the MikroTik to "2GHz-only-N", the ESP cannot connect to the AP, unless it switches back to "n" mode. I have it programmed to go to "n" mode as fallback if it cannot connect in "g" mode after 10 attempts (or xx seconds)
So to me it looks like it is working in "n" mode.
The table you posted seems odd, as it does share the "2GHz-only-N" option along with the "b/g/n" options.
Here the settings of the Wlan adapter:
I have it programmed to go to "n" mode as fallback if it cannot connect in "g" mode after 10 attempts (or xx seconds)
So by default it always connects in G mode for you, right? And you have to switch it to N with WiFi.setPhyMode(WIFI_PHY_MODE_11N) to connect with N, right?
The table you posted seems odd, as it does share the "2GHz-only-N" option along with the "b/g/n" options.
It's from the official doc, I guess that GUI and CLI might have some syntax differences. I used CLI with Mikrotik's quite some time ago, do not have it now unfortunately.
Yep, I made it configurable to what mode should be used to start with and as a fallback it switches to "n" mode after set number/time of failed attempts.
https://github.com/letscontrolit/ESPEasy/blob/f3ce88eaef3f88d7a525eb017ac9dec718c5578f/src/src/ESPEasyCore/ESPEasyWifi.cpp#L1062-L1070
I've played around with wifi_set_phy_mode(PHY_MODE_11N); not that it changed anything. For the SDK 2.2.1 it works as expected, for 2.2.2-git (arduino core >2.5.1) it makes no difference - MCS and WMM is not available and it does not connects at all in GreenField mode. Maybe it is AP hardware specific, but the fact is the same ESP board with the same user code works differently depending on on build env.
@TD-er BTW, I've noticed that your settings screenshots contains 2GHz-only-N and WMM disabled at the same time. This is completely wrong, for HT rates in N mode WMM is mandatory if I remember WiFi 4 specs correctly. Not sure if it should even work at all in greenfield mode without WMM.
This is a ESP client build with SDK 2.2.1 and AP in greenfield N mode
iw wlan0 station dump
Station 5c:cf:7f:02:50:f9 (on wlan0)
inactive time: 20 ms
rx bytes: 38408
rx packets: 1506
tx bytes: 2060
tx packets: 15
tx retries: 5
tx failed: 0
rx drop misc: 0
signal: -56 [-57, -56] dBm
signal avg: -57 [-57, -59] dBm
tx bitrate: 6.5 MBit/s MCS 0
rx bitrate: 6.0 MBit/s
rx duration: 150093 us
expected throughput: 4.394Mbps
authorized: yes
authenticated: yes
associated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:100
short preamble: yes
connected time: 680 seconds
It does connect in mode "n". Because we had issues with routers only supporting mode "n". When STA and AP mode is active ESP8266 can only use 11b and 11g. When only using STA mode device connects without an issue to router supporting only mode "n". The whole discussion with solution https://github.com/arendst/Tasmota/discussions/12512#discussioncomment-963099
I have also been having significant WiFi issues in 2021.
With a Ubiquiti 802.11n access point, it connects and disconnects successfully a few times,
but at some point, it stops being able to connect and stay connected; it goes from connected
to connection_lost almost immediately and once that happens, it will not be able to
connect again until it is reset.
This is highly reproducible with 2.7.4. Interestingly, with 3.0.x it also springs a huge memory leak,
when this happens, losing 2-2.5K with each scan/connection attempt.
Here's a trace below showing the connect attempt failure in case it is of any use:
scandone state: 0 -> 2 (b0) *** IDLE->SCAN_COMPLETED *** state: 2 -> 3 (0) *** CONNECTED *** state: 3 -> 5 (10) *** CONNECTION_LOST *** add 0 aid 6 cnt *** CONNECTED *** <<< Everything above is normal; when things work properly, the next line will be connected with mySSID, channel 1 However once things start failing, it looks like what's below >>>> state: 5 -> 2 (2c0) *** CONNECTION_LOST -> SCAN_COMPLETED *** rm 0 wifi evt: 1 STA disconnect: 2 state: 2 -> 0 (0) del if0 usl mode : null
I have also been having significant WiFi issues in 2021. With a Ubiquiti 802.11n access point, it connects and disconnects successfully a few times, but at some point, it stops being able to connect and stay connected; it goes from connected to connection_lost almost immediately and once that happens, it will not be able to connect again until it is reset. This is highly reproducible with 2.7.4. Interestingly, with 3.0.x it also springs a huge memory leak, when this happens, losing 2-2.5K with each scan/connection attempt. Here's a trace below showing the connect attempt failure in case it is of any use:
scandone state: 0 -> 2 (b0) *** IDLE->SCAN_COMPLETED *** state: 2 -> 3 (0) *** CONNECTED *** state: 3 -> 5 (10) *** CONNECTION_LOST *** add 0 aid 6 cnt *** CONNECTED *** <<< Everything above is normal; when things work properly, the next line will be connected with mySSID, channel 1 However once things start failing, it looks like what's below >>>> state: 5 -> 2 (2c0) *** CONNECTION_LOST -> SCAN_COMPLETED *** rm 0 wifi evt: 1 STA disconnect: 2 state: 2 -> 0 (0) del if0 usl mode : null
this is a major problem I am having. #8292 at some point the ESP stops responding to WiFi until a router reboot or until the ESP reset itself.
the funny things is that the latest Asus firmware upgrade prevent my ESP8266 devices from connecting on 802.11G, 802.11N works.
Maybe the latest firmware now has some default setting which makes the AP effectively "n-only" ? Could be that it is hard to recognize because of its label. For example (just made up now, no idea what Asus is using) calling it "enhanced stability", "gaming mode" or something similar. Side effects of an AP allowing both 'b/g' and 'n' devices is that it may decrease responsiveness. So it would make sense to refer to it as some kind of "gaming mode".
@TD-er thank you for the answer, I appreciate it.
the router is set in Legacy mode and they clearly shows:
I think that they just scrambled everything since the previous firmware let the ESP to connect to the 802.11G.