AC86U 384.14_2 - Tasmota Sonoff wifi connection.

[miazza]

Hi all.
I am facing some issues in connecting my Tasmota Sonoff wifi switch to the router.

I see that the switch is connecting for about 15 seconds and after that it is disconnecting.
This behaviour continues for some times and after that no further connection attempt is visible.
If I unplug/plug the Tasmota, the process restart.
During the 15 seconds conection, the device web-if is not available even if the IP is correctly assigned as reserved in the DHCP.

If I switch off the router and reboot, the device is well connected and stable; this until the switch is again power cycled.

As soon as I power cycle the switch, the issue comes up again.

The issue is the same for all these kind of devices while all other wifi stuff are all well connecting.


I tried to disable Diversion but it seems not related.
I tried to disable the 5GHz wifi but again it seems not related.

Is there anything that can be responsible of this strange behaviour ?

 

[ligeza]

Did you try change channel? For me the best is 6 with tasmota devices and on channel 1 I also had problems. You can also try update you tasmota devices, maybe it would also help.

 

[miazza]

I have already tried to change channels, to switch off the 5 GHz.
I have also made OTA reflash but I have the same behaviour only with Tasmota Devices.

There must be something tricky just for that diveces.
Probably related to ESP8286 authentication on DNS over TLS or something else.

May be someone is experiencing similar issues and found a solution.

The point is that after router reboot, the connection becomes far and reliable for days.

 

[JipHop]

With my RT-AC86U on firmware 384.13 I also have problems connecting my Tasmota device.
It connects without issues to the hotspot I make with my iPhone and I was able to update and configure it just fine.
But when I configure it to use the WiFi network from my RT-AC86U, the device keeps reconnecting.
It shows up briefly with a static ip address in the client list, but I can't connect to it on this ip address (10.10.10.214).

This is what I see in the log on the Asus router:

Jan 24 14:39:05 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:05 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:05 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:05 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:07 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:07 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:11 WLCEVENTD: eth5: Disassoc 60:01:941:64:F1
Jan 24 14:39:15 WLCEVENTD: eth5: Assoc 60:01:941:64:F1
Jan 24 14:39:15 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:15 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:17 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:17 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:21 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:21 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:23 WLCEVENTD: eth5: Disassoc 60:01:941:64:F1
Jan 24 14:39:37 WLCEVENTD: eth5: Assoc 60:01:941:64:F1
Jan 24 14:39:41 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:41 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:41 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:41 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:43 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:43 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:46 WLCEVENTD: eth5: Disassoc 60:01:941:64:F1
Jan 24 14:39:50 WLCEVENTD: eth5: Assoc 60:01:941:64:F1
Jan 24 14:39:50 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:50 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:52 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:52 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:56 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:39:56 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:39:58 WLCEVENTD: eth5: Disassoc 60:01:941:64:F1
Jan 24 14:40:13 WLCEVENTD: eth5: Assoc 60:01:941:64:F1
Jan 24 14:40:16 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:40:16 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:40:16 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:40:16 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:40:18 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:40:18 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1
Jan 24 14:40:21 WLCEVENTD: eth5: Disassoc 60:01:941:64:F1
Jan 24 14:40:25 WLCEVENTD: eth5: Assoc 60:01:941:64:F1
Jan 24 14:40:25 dnsmasq-dhcp[800]: DHCPDISCOVER(br0) 60:01:94:d1:64:f1
Jan 24 14:40:25 dnsmasq-dhcp[800]: DHCPOFFER(br0) 10.10.10.214 60:01:94:d1:64:f1

 

[miazza]

Just to verify if we are having the same issue: what happens if you reboot the router (power cycle) while the Tasmota device keeps reconnecting ?
In my case this solve the issue.

 

[JipHop]

I tried rebooting the router, which didn't seem to help in my case. I changed the wifi password to "testtest", and then the device would connect... When I use a longer password without any special characters it doesn't work. But the password I use for the hotspot on my phone is even longer (the longest I've tried), and that one works without issues. So that seems to exclude max password length as the issue.

 

[miazza]

I cannot change the router wifi passowrd because this would require a major reconfiguration of the house hahaha !
In any case for me the issue is not the password type/lenght; it seems more related to something that is causing the tasmota continuous reset.

 

[JipHop]

I didn't want to change my wifi password either, but as an experiment it could be interesting to know if using "testtest" would allow your devices to connect normally.

For me this worked. If it works for you too then I guess there's an issue inside Tasmota that causes it to reconnect on certain passwords.

Sounds strange but the only thing I did was change wifi password and it worked. I had to change back the password afterwards of course, so now it still doesn't work.

 

[Woody]

I have Tasmota on Sonoff S20's, S26, POW, Basic, T1 and even the new Mini and no issues on an AC86U for me.

However, these are 2.4GHZ devices - so I have 24/40 mhz channel bandwidth set. Wouldn't surprise me if they would struggle if you had set 40mhz channel b/w ONLY.

 

[JipHop]

I flashed the same device with Espurna instead of Tasmota, and now it connects without issues to the AC86U with SSID+password combination which didn't work before...

 

[miazza]

This is the reason why I do not have connection but I don't know hoe to debug.
If I reboot the router I have good and stable connection.

Jan 26 17:32:18 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth D8:F1:5B:8C:BE:8B, status: 0, reason: d11 RC reserved (0)
Jan 26 17:32:22 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jan 26 17:32:22 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth D8:F1:5B:8C:BE:8B, status: 0, reason: d11 RC reserved (0)
Jan 26 17:32:22 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc D8:F1:5B:8C:BE:8B, status: 0, reason: d11 RC reserved (0)
Jan 26 17:32:22 dnsmasq-dhcp[2091]: DHCPDISCOVER(br0) d8:f1:5b:8c:be:8b
Jan 26 17:32:22 dnsmasq-dhcp[2091]: DHCPOFFER(br0) 192.168.1.161 d8:f1:5b:8c:be:8b
Jan 26 17:32:24 dnsmasq-dhcp[2091]: DHCPDISCOVER(br0) d8:f1:5b:8c:be:8b
Jan 26 17:32:24 dnsmasq-dhcp[2091]: DHCPOFFER(br0) 192.168.1.161 d8:f1:5b:8c:be:8b
Jan 26 17:32:28 dnsmasq-dhcp[2091]: DHCPDISCOVER(br0) d8:f1:5b:8c:be:8b
Jan 26 17:32:28 dnsmasq-dhcp[2091]: DHCPOFFER(br0) 192.168.1.161 d8:f1:5b:8c:be:8b
Jan 26 17:32:36 dnsmasq-dhcp[2091]: DHCPDISCOVER(br0) d8:f1:5b:8c:be:8b
Jan 26 17:32:36 dnsmasq-dhcp[2091]: DHCPOFFER(br0) 192.168.1.161 d8:f1:5b:8c:be:8b
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc D8:F1:5B:8C:BE:8B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:36 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind D8:F1:5B:8C:BE:8B, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jan 26 17:32:40 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth D8:F1:5B:8C:BE:8B, status: 0, reason: d11 RC reserved (0)
Jan 26 17:32:40 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc D8:F1:5B:8C:BE:8B, status: 0, reason: d11 RC reserved (0)

Finally I made a Reset 5 of the SonOff and added credential for SSID2 (same as SSID 1( in the Tasmota wifi menu. This seems to have solved the issue and the SonOff connects using SSID 2 (this at least is what I see in the onsole).
I made several try with two devices and all went OK.

 

[miazza]

However, these are 2.4GHZ devices - so I have 24/40 mhz channel bandwidth set. Wouldn't surprise me if they would struggle if you had set 40mhz channel b/w ONLY.

Quite interesting. Where is this setting in the router FW ?

 

[Woody]

Quite interesting. Where is this setting in the router FW ?

Wireless -> General -> Band 2.4 Ghz and 6th setting down is Channel Bandwidth.

 

[miazza]

Wireless -> General -> Band 2.4 Ghz and 6th setting down is Channel Bandwidth.

View attachment 21081

I have Smart Connect activated and Channel Bandwidth is only Automatic... everything is Automatic when SC is activated.

 

[AlexHK]

I am having the exact same issues for a while with my 20+ Tasmota devices and AC86U. Only today I had the glorious idea of checking here

When I updated some setting (unrelated to Wireless/Network) on all my devices earlier today, they failed to connect afterwards with the log looking quite similar to yours above. Rebooting the router solved the problem.

My devices are by different manufacturers (Sonoff, Gosund, etc) but exact same Tasmota 8.1.0.4 firmware, and all show the same symptoms.

I flashed the same device with Espurna instead of Tasmota, and now it connects without issues to the AC86U with SSID+password combination which didn't work before...

Did this solve the problem for good?

I am going to try changing the channel too, since I am using 2.4GHz. mostly for these devices. I will switch to static IP if nothing helps.

-- // --

I am still on Tasmota 8.1.0.4 so I might try to update, but only if I find a bug was actually fixed etc.

I may be wrong, but I changed to WifiConfig 4 from WifiConfig 2 (was default on my devices) a while ago to avoid reboots and because I have no use for the Wi-Fi Manager, but I believe only then the issue got real serious.

2 = set Wi-Fi Manager as the current configuration tool and start Wi-Fi Manager (web server at 192.168.4.1) for 3 minutes, then reboot and try to connect Wi-Fi network.
4 = disable Wi-Fi Manager but retry the other AP without rebooting.