ASUS router connection issue (workaround)

[Jason2866]

You can build a Tasmota ESP8266 version with the Arduino (PR8319) which maybe fixes the DHCP issues with some ASUS routers. Please give us or the Arduino crew feedback if this PR does solve the issue. Thx!

Copy the text box below in platformio_tasmota_cenv_sample.ini somewhere and rename the file to platformio_tasmota_cenv.ini
After restarting VSC you can compile it with platformio run -e tasmota-core3 from the terminal or as described in the Tasmota documentation.

; *** Esp8266 core Arduino 3.0.x with lwIP213rc1 (PR8319) Asus issues DHCP fix???
[env:tasmota-core3]
platform                = espressif8266
platform_packages       = framework-arduinoespressif8266 @ https://github.com/d-a-v/Arduino.git#lwIP213rc1
                          platformio/tool-esptoolpy @ ~1.30100
build_unflags           = ${env.build_unflags}
build_flags             = ${env.build_flags}
                          -D PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED

Edit: added precompiled firmware with above settings.
tasmota-core3.bin.gz

EDIT 2 (2022/09/05): There is no "clean" solution possible. Only the workaround(s).

[miazza99]

Thank you for this ticket. I answer just to subscribe the discussion.

[eipporko]

Firmware Compiled and devices upgraded. Firmware 10.0.0.2 using the recipe you mentioned
Also I enabled the smart connect option in the Asus Router.
I'm testing on 3 Sonoff mini, 3 sonoff mini r2, 2 swa11 plug & 1 nx-sm100 plug
Normally with this configuration begin to have issues in the next 24 hours after being connected, so I will I will keep you informed.

[rolupusoru]

Not at home now, but I will give it a try this evening @barbudor .

[eipporko]

I talked with Theo we will probably enable gratuitous ARP by default with 60 seconds for ESP8266.
This aligns with ESP32, since this setting is default there.

I enabled the gratuitous ARP as you mentioned in all the devices, I will keep you posted.

[TD-er]

I'm trying to get some capture with wireshark filtering by the mac of the device unaccesible, but I don't see anything.

This speaks for the ARP problematic. Device is "forgotten"

Could be, but it is also possible you simply didn't get the disconnect event and thus the ESP still assumes it is connected, where the AP doesn't.
This is more likely to happen on APs that may switch channels, but it can also happen on APs which are set to operate on a fixed channel.
I think the source of this may be the same as why ARP requests are not always received by the ESP (and thus not replied) and the symptoms may also appear similar. But sending Gratuitous ARP is not the fix for when that is happening. On the other hand, it doesn't hurt sending Gratuitous ARP. It may make it harder to reproduce the issue though ;)

[eipporko]

Today I woke up with 2 devices unaccesible even though the gratuitous ARP as you mentioned was stablished :(

[Jason2866]

So the issues is something different. Maybe what TD-er is assuming. This problems can not be solved in Tasmota. Sorry.

[rolupusoru]

I've updated to the latest development firmware 10.0.0.2 from tasmota. On the WebGUI it says 10.0.0.3. After setting ip address to DHCP and rebooting the device, it goes into a continuous DHCP loop.

ASUS WiFi logs:

Nov 13 23:17:17 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:17 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:25 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:03:9F:17:88:28, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 13 23:17:29 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:29 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:36 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:03:9F:17:88:28, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 13 23:17:40 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:40 wlceventd: wlceventd_proc_event(556): eth5: Assoc 70:03:9F:17:88:28, status: Successful (0), rssi:0
Nov 13 23:17:48 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 70:03:9F:17:88:28, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Took a tcpdump from Asus router and I still can see the same problem. ESP continuously sends DHCP_DISCOVER even if the router replies with a DHCP_OFFER.

[Jason2866]

@1d4rk This is a test of the Arduino PR which maybe fixes the issues with some ASUS devices.
There is already feedback that it does NOT solve problems with Arduino ESP8266 and ASUS.
Providing a precompiled version makes imho no sense in this case.

[1d4rk]

Sorry @Jason2866
but @rolupusoru used the latest development firmware 10.0.0.2 from tasmota so, if I am not wrong, there is no fix.
I don't see other feedbacks that it doesn't solve problems with ASUS, the problem seen by @eipporko seems different...
IMHO a precompiled version could help to test, but if it is not possible no problem.
Thanks for your feedback.

[TD-er]

@1d4rk Please be aware that there are numerous possible issues which may show the same symptoms.
This makes it very hard to tell if some fix is "the fix" as it is really hard to tell if users experience the same issue.

[Jason2866]

Sorry @Jason2866 but @rolupusoru used the latest development firmware 10.0.0.2 from tasmota so, if I am not wrong, there is no fix. I don't see other feedbacks that it doesn't solve problems with ASUS, the problem seen by @eipporko seems different... IMHO a precompiled version could help to test, but if it is not possible no problem. Thanks for your feedback.

tasmota-core3.bin.gz
@1d4rk

[1d4rk]

@Jason2866
Thanks, I let you know.

[TD-er]

@rolupusoru Can you see what is the actual beacon interval of the Asus AP? (typical is 102.4 msec)
And what is the DTIM interval?
Is it possible to derive those from the Wireshark dumps? Does Wireshark also show what DTIM interval is reported by the AP?
Does the AP have a fixed channel? Is WiFi mesh enabled?
Is there a RSSI threshold set in the AP? Can you see the RSSI of the ESP's as seen by the AP?

[TD-er]

It is.
And a lot of effort has been put into making it work.

There a long running issues on GitHub regarding WiFi on the ESPs. There is something fundamentally wrong with the ESP WiFi. Either in the software/SDK or in the hardware, as the internal state does quite often not correspond with reality.

[eipporko]

I do see you have "Roaming Assistance" enabled, which will disconnect clients with RSSI worse than -70 dBm.
Can you first disable this, to see if it will make a difference?

Disabling Roaming Assistance... I will keep you posted. =)

[Jason2866]

@TD-er Full acknowledge in every point. Theo did invest many hours (as you did) to get the wifi part in Tasmota for the ESP8266 stable. Luckily we have now a setup which works since a long time stable even when code changes are done. So the golden rule. Do not touch wifi code of the esp8266.
"Just" the ASUS problematic is left, whatever it is. Theo (and the rest of the team) will avoid, as much as possible, to do this fiddling work again, which will happen when the nonos-sdk build is changed.
We would really happy, if a solution is found which is working keeping the current nonos-sdk.
If a different nonos-sdk solves the issues for Asus users, we will provide a easy platformio setup for Tasmota to compile this special build. So yes we are all interested to find the reason for the problem.
Sadly to say there is a high chance, that this solution (if ever) will not a general useable one.

[miazza99]

Well, at the end for ASUS we have an experimental work around and, at least in my case, this is quite stable and not disturbing the daily use of all my Tasmota devices (I have 5 Tasmota SonOff ... 6 when I will fix my last R3...) .

For me it is already a good point the fact that now the problem is somehow located in this wifi code of the esp8266.

[eipporko]

Just disabling roaming assistance does not work :( I'm going to test compiling tasmota with another nonosdk framework.

[1d4rk]

I have updated to the firmware shared by @Jason2866 but the problem is not solved, DHCP issue (Sonoff Tasmota sends DHCP_DISCOVER even if the router replies with a DHCP_OFFER).
Sorry no dice...

[Jason2866]

@TD-er

why ESPEasy does have some "alt WiFi" builds as some units may not run well on one SDK but may run fine on the other

Could you try Tasmota on this wonky hardware, if it has the same bad behaviour?

[TD-er]

The sad truth is that it sometimes even is a "tik-tok" of creating a new build may fix it.
A build with exactly the same code, or maybe leave out some completely unrelated code or just change a string to a different length.
Or switching between building on Windows vs. Linux.

Sometimes it is even a fix to flash it via serial instead of OTA upgrade.
Which makes me think it may be so extremely time critical that slightly slower flash access or a cache miss may make a huge difference in WiFi stability.
One of the things that seem to differ between those SDK versions is a timing threshold (or slightly longer listening window).
That's why I now also show time wandering of the crystal on the sysinfo page, as it seems to correlate with the quality of the used crystals.
According to the Espressif datasheet, the crystal should be stable within 10 ppm, but I have seen units which are an order of magnitude off. Ticking too fast isn't really a problem, but too slow is. => very critical timing.

I think that this extremely timing critical may play a role (just assuming it isn't WMM related) here with these new and/or high end APs like those Asus ones. But also (very expensive) Netgear ones show this behavior.

Just one more example of clearly changed parameters between SDK-versions.
The allowed range to correct for antenna tuning has changed. At least between 2.4.x and 2.6.x
I do have nodes on my desk which work perfectly with 2.4.x and only work on newer builds if I press my thumb on the antenna (which does feel warm)
So the antenna either isn't matched 1:1 to the used frequency, or maybe a tuning capacitor on the antenna has the wrong value.
Changing TX power does seem to help only a bit, which -to me- indicates the reflected signals of the antenna signal may interfere with the signal actually being sent.

[Jason2866]

Maybe some will find my suggestion to solve such issues shirt-sleeved. Try a other (but same looking) device from a different seller / batch. If it works, trash the other. As TD-er wrote to many unknow variables to track...

[TD-er]

Well the smaller range for antenna tuning may also hurt well designed nodes (like my own designs ;) ) as sticking a sticker antenna close to the ABS of an enclosure also detunes the antenna.
So it is also important to know why things may not work.

[Jason2866]

With this setup everyone can try all supported current available nonos-sdk versions for Arduino Esp8266.
Just (un)comment the one you want to use to compile Arduino/Tasmota
Please do not ask for precompiled firmwares. Compiling is easy. Read Tasmota docs how to do.

; *** Esp8266 core Arduino 3.0.x with lwIP213rc1 (PR8319) Asus issues DHCP fix???
[env:tasmota-core3]
platform                = espressif8266
platform_packages       = framework-arduinoespressif8266 @ https://github.com/d-a-v/Arduino.git#lwIP213rc1
                          platformio/tool-esptoolpy @ ~1.30100
build_unflags           = ${env.build_unflags}
build_flags             = ${env.build_flags}
                          -D PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED
; NONOSDK22x_190703 = 2.2.2-dev(38a443e)
                            -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703
; NONOSDK22x_190313 = 2.2.2-dev(c0eb301) 
;                            -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190313
; NONOSDK22x_191024 = 2.2.2-dev(5ab15d1)
;                            -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191024
; NONOSDK22x_191105 = 2.2.2-dev(bb83b9b)
;                            -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191105
; NONOSDK22x_191122 = 2.2.2-dev(a58da79)
;                            -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191122

[eipporko]

Testing with NONOSDK22x_190313

[eipporko]

NONOSDK22x_190313 was not the solution, I will test another one.

[KF042020]

As you can see this build is stable for almost a day. On other firmware versions including "old" core3 there were problems even with simple device restart. After it I was almost always forced to toggle 2,4GHz on my Asus to make my device connect. Now I can restart without any problems. Device is set do use DHCP. Now I'm flashing other device and let both rest for a few days to test connection stability

EDIT:
My config (remember that it's for tasmota-ir and for Windows compiler environment - had to modify toolchain-xtensa):
platform = espressif8266
platform_packages = mcspr/toolchain-xtensa@^5
framework-arduinoespressif8266 @ https://github.com/d-a-v/Arduino.git#lwIP213rc1
platformio/tool-esptoolpy @ ~1.30100
build_unflags = ${env.build_unflags}
build_flags = ${env.build_flags} -DFIRMWARE_IR
-D PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED
; NONOSDK22x_190703 = 2.2.2-dev(38a443e)
; -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703
; NONOSDK22x_190313
-DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190313
; NONOSDK22x_191024 = 2.2.1+111-dev(5ab15d1)
; -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191024
; NONOSDK22x_191105 = 2.2.1+113-dev(bb83b9b)
; -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191105
; NONOSDK22x_191122 = 2.2.1+119-dev(a58da79)
; -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_191122
lib_extra_dirs = lib/lib_basic

[Jason2866]

Please have a look at MqttCount. After one week it should still be 1.

[KF042020]

After 3.5 days it has disconnected :( Dispite of this:
{"SetOption41":60}
I'll try other NONOSDK and let you know

[KF042020]

Unfortunately for me only NONOSDK22x_190313 is acceptable. It has disconnected after 3.5 days but at least it survives software restart. All other versions after restart require several power cycles to connect :( So for me it's over. I'll check once more how long connection will last and probably return to static IP :(

[Jason2866]

This matches with our experience. Only 190703 is stable (for all non ASUS users).

[suzsuzuki]

I just saw issue 1137 and I agree with @jaymemaurice about setoption41:

here

Please don't. Don't encourage fixing some broken networking devices by shipping default broken network protocols. I personally don't want ARP broadcasts from all of my Tasmota devices waking up all the devices on my network because someone else's junk router/switch can't handle IGMP or keep it's ARP state. If we didn't want our switches to be switches, we'd still buy hubs.

Gratuitous ARP every minute is crazy. Default off is much better and I agree with @Jason2866 :

here
Thats why Setoption41 is off by default. This will not be changed.

[Jason2866]

@KF042020 If you have the need to provide a specific toolchain your platformio setup is messed up.
You can fix easily by deleting the hidden folder .platformio in your user folder.
The setup i provided is verified 100% working.

[Jason2866]

@suzsuzuki Sadly there are so many crappy APs / Routers out there which have non working ARP treatment we decided to enable by default. It is not a big deal to switch off. Just do so41 0
Btw. for Arduino ESP32 Gratuitous ARP is hardcoded to 60 seconds too and can not be switched off since this setting is fix defined in the underlying compiled Arduino IDF libs.

[ascillato]

From #7770 (comment)

Please, using latest standard Tasmota, go to the console and type wifi 3 so as to disable Wi-Fi 11n. Make sure that you have 11b or 11g enabled in your router.

[miazza99]

I can't beleve we have never tried :) 👍 It seems working.

[eipporko]

Is this configuration only available on esp32 devices or also it is supported on esp8266 devices?

[ascillato2]

ESP8266 Only

[Jason2866]

@eipporko with a ESP8266 device

22:02:59.830 CMD: wifi
22:02:59.837 MQT: stat/sonoff-17DBAE/RESULT = {"Wifi":"ON","Mode":"11n"}
22:03:11.285 CMD: wifi 3
22:03:11.400 RSL: RESULT = {"Wifi":"ON","Mode":"11g"}
22:03:11.405 MQT: Attempting connection...
22:03:11.610 MQT: Connect failed to mqtt.lan:1883, rc -2. Retry in 10 sec
22:03:24.295 MQT: Attempting connection...
22:03:24.315 MQT: Connected
22:03:24.319 MQT: tele/sonoff-17DBAE/LWT = Online (retained)
22:03:24.322 MQT: cmnd/sonoff-17DBAE/POWER = 

[TD-er]

I wasn't suggesting to build a newer version, but just to verify using an older (ancient) build of Tasmota to verify the node itself is connecting to that specific AP, just to make sure it is an issue in the software and that we're not looking at some other completely unrelated issue.

[drrossum]

The latest version before core 2.6.0 is Tasmota v6.6.0, I see, though that uses Core v2.3.0 and not v2.5.2... I read that downgrading to such an old version is difficult, so let me do esptool.py erase_flash and start from scratch with v6.6.0. Let me get back to you with my findings in a couple of days

[drrossum]

After some experiments, it appears that the choppy connection issue I was seeing was caused by the "wifi 3" mode. I guess my Asus ax58u disables 11b for performance and Tasmota in "wifi 3" mode doesn't like that.

So I'm back experimenting with 10.1.0 in default 'wifi 4' mode. Initial DHCP seems to work well so far, which is great to see!

I'll report back in a few days if lease renewals succeed reliably as well

[ascillato]

wifi 3 is 11b/g, so your router is configured to disable both (in other words, your router is configured as 11n-ONLY). If you want, you can try disabling 11n-only option in your router.

[5ocworkshop]

Just to add another data point for someone who discovers this via searching in the future, the 'wifi 3' command via the console seems to have resolved my WIFI association and DHCP DISCOVER then DHCPOFFER (br0) then DHCPDISCOVER (br0) issues. The three smart plugs now come online in about 4s from powerup.

I am running the stock firmware image for Tasmota 11.0.0.

The router is an ASUS RT-86U running the MerlinWRT 386.5 fork of the ASUS firmware. I did not need to change anything on it.

The devices are 00:00:00.002 HDW: ESP8266EX in the console at boot. The commercial model is TECKIN SP20.

All I needed to do was open the web UI once the devices did (eventually) come online on the 11n network, and type 'wifi 3' in to the console. It reported switching to the 11g network then I unplugged and replugged them to confirm. Just 4s to boot now. Lovely.

[Tomps1]

Noob Question: What is that, please?? Tried to get it with platform.io but failed:

Executing task: C:\Users\xxx.platformio\penv\Scripts\platformio.exe run --environment tasmota-core3 <

Processing tasmota-core3 (platform: espressif8266; framework: arduino; board: esp8266_1M)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Tool Manager: Installing git+https://github.com/d-a-v/Arduino.git#lwIP213rc1
git version 2.36.1.windows.1
Cloning into 'C:\Users\xxx.platformio.cache\tmp\pkg-installing-k9r7ko74'...
warning: Could not find remote branch lwIP213rc1 to clone.
fatal: Remote branch lwIP213rc1 not found in upstream origin
Error: VCS: Could not process command ['git', 'clone', '--recursive', '--depth', '1', '--branch', 'lwIP213rc1', 'https://github.com/d-a-v/Arduino.git', 'C:\Users\xxx\.platformio\.cache\tmp\pkg-installing-k9r7ko74']
Der Terminalprozess "C:\Users\xxx.platformio\penv\Scripts\platformio.exe 'run', '--environment', 'tasmota-core3'" wurde mit folgendem Exitcode beendet: 1.

[Tomps1]

Hi, yes git is installed and pulling the repository (in case i provide correct branch). It seems that this branch has been deleed in Jan 2022 after merging into esp8266:master... unfortunately i dont know how to retrieve a valid and working version there...

[Jason2866]

esp8266 main repo does include this fix.

; *** Esp8266 core Arduino 3.0.x with lwIP213rc1 (PR8319) Asus issues DHCP fix???
[env:tasmota-core3]
platform                = espressif8266
platform_packages       = framework-arduinoespressif8266 @ https://github.com/esp8266/Arduino.git
                          platformio/tool-esptoolpy @ ~1.30100
build_unflags           = ${env.build_unflags}
build_flags             = ${env.build_flags}
                          -D PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED

[Tomps1]

mmhhh.. unfortunately not really knowing what exactly i am doing... but now trying to compile creates error:

Compiling .pio\build\tasmota-core3\lib221\bearssl-esp8266\codec\ccopy.c.o
xtensa-lx106-elf-gcc: error: unrecognized command line option '-std=gnu17'
Compiling .pio\build\tasmota-core3\libce0\ESP8266WiFi\ESP8266WiFiAP.cpp.o
*** [.pio\build\tasmota-core3\src\xsns_62_esp32_mi_homekit.c.o] Error 1
Compiling .pio\build\tasmota-core3\libce0\ESP8266WiFi\ESP8266WiFiSTA.cpp.o
xtensa-lx106-elf-g++: error: unrecognized command line option '-std=gnu++17'
*** [.pio\build\tasmota-core3\libce0\ESP8266WiFi\ESP8266WiFiGratuitous.cpp.o] Error 1

btw. also tested the above options for ; NONOSDK22x_xxxxxx
similar issues while compiling

[Jason2866]

Ahh, right. This is verified working.

[env:tasmota-core3]
platform                = https://github.com/Jason2866/platform-espressif8266.git#tasmota302
platform_packages       = framework-arduinoespressif8266 @ https://github.com/esp8266/Arduino.git
                          platformio/tool-esptoolpy @ 1.30300.0
build_unflags           = ${env.build_unflags}
build_flags             = ${env.build_flags}
;                          -DPIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED
lib_ignore              = ESP Mail Client

[Tomps1]

Now, please notice I am entirely new, i have no overview over logs/topics/things/directories i can check for....
I am getting the following error now:

C:/Users/xxx/Downloads/Tasmota-11.1.0/tasmota/xdrv_58_range_extender.ino:120:10: fatal error: dhcpserver.h: No such file or directory

Not happening in the other environment, though. So the other env should have this file somewhere, right??
Where can I check to be able to find it?
And to which dir to copy this or what to do?

[Jason2866]

For compiling a range extender version you can do this way

[env:tasmota-core3-rangeextender]
platform                = https://github.com/Jason2866/platform-espressif8266.git#tasmota302
platform_packages       = framework-arduinoespressif8266 @ https://github.com/esp8266/Arduino.git
                          platformio/tool-esptoolpy @ 1.30300.0
build_unflags           = ${env.build_unflags}
build_flags             = ${env.build_flags}
;                          -DPIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED
                          -DFIRMWARE_RANGE_EXTENDER
                          -DPIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH
                          -DUSE_WIFI_RANGE_EXTENDER
                          -DUSE_WIFI_RANGE_EXTENDER_NAPT
lib_ignore              = ESP Mail Client

[Tomps1]

well, actually thats what I did. Added

#ifndef USE_WIFI_RANGE_EXTENDER
#define USE_WIFI_RANGE_EXTENDER
#endif
// Optionally, to enable NAT/NAPT
#ifndef USE_WIFI_RANGE_EXTENDER_NAPT
#define USE_WIFI_RANGE_EXTENDER_NAPT
#endif 

to user_config_override.h.. anyways, tested the above one, facing unfortunately the same error...

[Jason2866]

So the Tasmota code of rangeextender is not compatible with actual Arduino ESP8266 stage.

[Jason2866]

I can not test at the moment, you can try to include LwipDhcpServer-NonOS.h instead of dhcpserver.h in file xdrv_58_range_extender.ino line 120.

[Tomps1]

OK, I think this will go far now :-D
I added the include you told and got "some function was not declared"
Then changed back to dhcpserver.h, downloaded the dhcpserver.h from https://github.com/espressif/esp-idf/tree/master/components/lwip/include/apps/dhcpserver (dont ask why - this was just the only sensefull file i found on the web) and put it into local include path
Now complaining about sdkconfig.h not found
then uncommented all (local) includes and put your Lwipdhcpserver-nonos.h on top instead
Now complaining about multiple definitions and still missing functions...
After all, I just wanted to check this out. As my initial problem is that the range extender does not route any packages, and in some other thread it was told that possibly i could find some info for solving the prob in this thread...

[sfromis]

Don't know if this is "interesting", but very recently, I did a simple range extender test setup, by strictly following the docs, and running in NAPT mode for simplicity. I was able to successfully connect both an unmodified other Tasmota device (both ESP8266), and running a regular browser on a tablet connected to the range extender AP. Speed was only about 3 Mbit/sec, but still able to do useful browsing.

[phildabill]

Problem still exists!

Quick workaround is to set 2.4ghz mode to Legacy, then go in the Tasmota Console and set "wifi 2". You can the reset 2.4ghz to Auto in Asus router.

Shame this is an issue in 2022.

[sfromis]

Asus has landed itself a firm no-go on my mental list of router vendors... They seem to focus too much on specs-filler stuff of marginal (if any) utility for other than benchmarking...

[phildabill]

If anyone knows how to fix it, maybe you can contact the person making the Merlin firmware to have him patch it in his releases?

[miazza99]

I guess Merlin cannot do anything about the ASUS wifi that is legacy fro the original FW and not patched.
I believe a similar post is present in the Merlin forum.

[MF-Bra]

I have 4 Sonof Minis running without any issue on stock firmware for about one year, when I flashed them (OTA) to tasmota, this wifi issues started to happen immediatelly... Not sure if it may helps anyways, but seems to be related to the firmware, not hardware at all. Running version 12.3.1

[MF-Bra]

Testing here and yet to post long term results, but after adjusting all of them to wifi 2 and in the AX router 2,4G professional config changed the modulation scheme to "up to MCS 7 ( 802.11n)" seems to have solved at least the issues to reconnect after software resets.

[Jason2866]

We know it is the espressif software part. It is the closed source part from espressif which has to be used when programming via Arduino. Feature less software like the stock firmware uses a different framework (non Arduino). So in short the info does not help.

[MF-Bra]

Sad to hear, hopefully espressif may address it in the future. But so far with the settings I mentioned, seems to be working. Thank you !

[TD-er]

Not only "closed source" but also no changelog, nothing. Just a binary blob and the devs may try and spend an infinite amount of time on finding out what may or may not work.

[drrossum]

#7770 (comment)

Exciting to see how the new espressif NonOs version is going to affect this problem!

[Jason2866]

@drrossum No reason for being excited. Just another attempt. Since the buggy beta build NonOs SDK version 3.0.x is used which maybe!! solves this WiFi problem. It will introduce other problems. We had used this already and dropped it, since it decreases esp8266 performance a lot. If the performance problem is not solved it is not an option.

[drrossum]

@Jason2866 You had identified the problem being the NonOs closed-source code that Tasmota relies on and regretted that it was EOL. Now, how is it not exciting to see a new version coming out that even explicitly addresses the missing WMM support, since WMM is no longer optional on 802.11ax APs?

I'll be happy to try a custom build but what "performance issues" do I need to look out for (in addition to checking for wifi connectivity and re-connectivity issues)?

[TD-er]

I'll be happy to try a custom build but what "performance issues" do I need to look out for (in addition to checking for wifi connectivity and re-connectivity issues)?

To list a few (not limited to these):

• increase in memory usage
• Slower execution of code (on Tasmota, this probably means higher load percentage)
• Increase in build size
• WiFi connection less predictable -> varying ping times for no clear reason, taking longer to connect, more frequent disconnects

[Jason2866]

@drrossum this is not a newer build, just a try to use the existing versions 3.0x

@TD-er what you listed and WDTs for unknown reasons. But the most problematic is the big performance hit.

[TD-er]

Those WDTs can almost all be related to the less predictable WiFi connection.
Having less memory available doesn't make it better as it can lead to more instability in the WiFi connection, but also throw in some crashes as a result of failed memory allocations.
N.B. Having a more fragmented heap, will increase time needed to perform the memory allocations, so that's why low free memory may make those WiFi connection issues even worse.

[cmiguelcabral]

I'm having the same problem. My configuration is an RT-AX92U as a router with the Wifi turned off and two ZenWifi Mini (XD4) as nodes, with wifi turned on.
I have many Sonoff and Shelly devices running Tasmota and some NodeMCU running WLED. I noticed that this was only happening to ESP8266 devices but not to ESP32 ones. Don't know if WLED also has the problem, as all the NodeMCUs I have are ESP32 (so these never drop).
I already tested many different things found around on the internet, and all failed. But yesterday I read somewhere about forcing Tasmota to use Wifi G instead of Wifi N, issuing the command wifi 3 to Tasmotas.
It's now running for more than 24H without a single drop. I'll let it run like this for some more days and report back.

[Stonator]

Had the same problem, wifi 3 solved it. Switched back the Asus router to standard settings, after a lot of experiments, and no connection problems anymore.

[radudorurus]

Because I experienced this issue as well, I subscribed to this topic with the hope there will be some solution.

I set up another device as DHCP server in my network about two weeks ago and I see no more interruption and kick out for the wifi smart devices.
(I had lying on a shelf a WR1043 tp link router. Set IP fixed, activate DHCP and did the ip reservation as I had on ASUS, 32 items maximum in the list.
On Asus router I just disabled the DHCP server)

In the past, first I thought it is the AImesh problem and set up the network as router + AP in classic manner, each AP having different channel. (3 x Lyra AC2200 as APs)
No improvement.

I was about to go crazy since I have also three Mitsubishi Air condition units ("Winstron" wifi chipsets) which also were kick out of the network.
A lot of disconnection issues.

I set up lease time in RTAC66Ub1 to 7 days hoping it will be less issues.
After 3-4 days starts again some tasmotas and the ACunits to get disconnected.
The router and the APs must be rebooted in order to have tasmotas connected again.

I know this is a workaround and probably does not work if there is an AiMesh setup.

[cmiguelcabral]

I'm having the same problem. My configuration is an RT-AX92U as a router with the Wifi turned off and two ZenWifi Mini (XD4) as nodes, with wifi turned on. I have many Sonoff and Shelly devices running Tasmota and some NodeMCU running WLED. I noticed that this was only happening to ESP8266 devices but not to ESP32 ones. Don't know if WLED also has the problem, as all the NodeMCUs I have are ESP32 (so these never drop). I already tested many different things found around on the internet, and all failed. But yesterday I read somewhere about forcing Tasmota to use Wifi G instead of Wifi N, issuing the command wifi 3 to Tasmotas. It's now running for more than 24H without a single drop. I'll let it run like this for some more days and report back.

After 72H I had no drops from Tasmotas.
Before forcing Tasmotas to use Wifi G, I disabled Smart-Connect, and IGMP Snooping and changed security to WPA2-Personal.
Yesterday I turned on Smart-Connect, for 12H now without any drop. Will let it run for 1 or 2 days and then I'll change security back to WP3-Personal, and then after 1 or 2 more days, I'll change IGMP Snooping back to enable.
I'll do it progressively as I don't want to make more than one change at a time.

I'll report back here as I change configs.

[kizzed]

Man I have been waiting ap long time to see if this works! Hurry up already and let us know! lol

[radudorurus]

How I solved the situation...
Maybe others will choose this way.

First I set-up an old TPlink wr1043n in the network as DHCP server and stopped the service on Asus.
The issue solved 98%.
Still some ESP's got disconnected sporadically but reconnect back after few minutes.
Rarely I had to restart the smart thing if the reconnect would not happen.

So the main problem seems to be the DHCP Asus protocol.

After that I took the radical way (in the beginning of May2024)
Switched to TP-link Omada sistem.

• router ER605
• 2 x EAP613 AX1800

I have no more this disconnection issue.
I sold those 3x Lyra AC2200
My Asus AB66Ub1 is still in the network as it holds 2 HDD as samba/ftp server but I have in work a Promox server on a low power HP T520 which runs Omada server and I will add TurnKey as Samba/ftp (which is very light and the miniHP Proxmox can run it)

[JonAnder83]

What fixed it for me.
This is my setup:
RT-AC86U + RT-AC68U

Wireless - Enable Smart Connect: Off
Wireless - Band: 2.4Ghz: Disable 11b (For security purposes)
Wireless - Wireless MAC Filter - 5Ghz: Enable Mac Filter - Reject mode: Input the MACs of your tasmota devices.

On the tasmota devices (Sonoff Basic):
Backlog WiFi 3; SaveData 1

Since then, after 3 days, I had no further issues with my devices.

[radudorurus]

It is good it worked for you.

Still I dont't get what is the purpose of blacklisting the tasmotas for 5Ghz since it is phisically impossible for it to try to enroll 5Ghz network (no 5Ghz transceiver)

On my side I do not use "smart connect" since I have different ssid for 2.4 and 5Ghz networks.

Regarding the Wifi mode 3, I remember I have tried without improvement.

[MF-Bra]

I know it's a complex situation, my tasmotas (Sonoff Mini R2) have been pretty stable for at least a year and even after migrating from RT-AX88u (router) + 2 Meshs (AX88u - AC86u) to BE-96U + 2Meshs (Ax88u) I had no issues.
They jump from router to mesh and keep stable in the closest AP.

They are in a 2.4ghz guest network, no smart connect, their Mac addresses are listed on /jffs/configs/dnsmasq.conf.add (Merlin FW), here a print of my professional tab and example of dnsmasq.conf
dhcp-host=MAC,NAME,192.168.x.x
dhcp-host=MAC,NAME,192.168.x.x

this is the backlog configuration I apply to any new tasmotas coming to the network

Backlog Wifi 4; NTPSERVER1 192.168.x.x; Timezone -3:00; mqtthost 192.168.x.x; mqttport xxx; mqttuser xxxx; mqttpassword xxx; SSID2 xxx; Password2 xxxxx; topic xxxx; savedata 1

I know there are many controversies possible within this configuration, but it's stable and even migrating to a newer router was pretty simple. They SSID2/Password2 was a fallback network (with and very old router) I had to deal with issues, it's off for a long time but still configured within all tasmotas is case any failure occurs.

I hope it may help.