Tasmota devices fail to reconnect to network after they are power cycled

Fettkeewl commented 4 years ago

PROBLEM DESCRIPTION

Sonoff devices with Tasmota firmware refuse to reconnect after power cycling them. As evident by serial output the devices just says "fails to connect to AP". The only remedy is to reboot router, then all my tasmota devices that are stuck in a loop will connect instantly.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

[x] Read the Contributing Guide and Policy and the Code of Conduct
[x] Searched the problem in issues
[x] Searched the problem in the docs
[x] Searched the problem in the forum
[x] Searched the problem in the chat
[x] Device used (e.g., Sonoff Basic): Sonoff S55/T1/Mini
[x] Tasmota binary firmware version number used: 8.1.0
- [x] Pre-compiled
- [ ] Self-compiled
- [ ] IDE / Compiler used: _____
[x] Flashing tools used: Tasmotizer

[x] Provide the output of command: Backlog Template; Module; GPIO 255:


Configuration output here:
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"NAME":"Sonoff T1 1CH","GPIO":[17,255,255,255,0,0,0,0,21,56,0,0,0],"FLAG":0,"BASE":28}
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"Module":{"0":"Sonoff T1 1CH"}}
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"GPIO0":{"17":"Button1"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"21":"Relay1"},"GPIO13":{"56":"Led1i"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

- [ ] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:

Rules output here:

- [x] Provide the output of this command: `Status 0`:

STATUS 0 output here: 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS = {"Status":{"Module":0,"FriendlyName":["SonoffT1-01"],"Topic":"OfficeCeilingLamp","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":0,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"7T00:51:52","StartupUTC":"2020-02-15T06:04:23","Sleep":50,"CfgHolder":4617,"BootCount":10,"SaveCount":169,"SaveAddress":"FB000"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS2 = {"StatusFWR":{"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Boot":31,"Core":"2_61","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8285","CR":"364/699"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8008","2805C8000100060000005A00000000000000","00000200","00000000"]}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS4 = {"StatusMEM":{"ProgramSize":566,"Free":436,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00007881"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,29","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS5 = {"StatusNET":{"Hostname":"SonoffT1-01","IPAddress":"","Gateway":"","Subnetmask":"255.255.255.0","DNSServer":"","Mac":"","Webserver":2,"WifiConfig":4}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":,"MqttClientMask":"DVES%06X","MqttClient":"DVES_BDA845","MqttUser":"","MqttCount":7,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS7 = {"StatusTIM":{"UTC":"Sat Feb 22 06:56:15 2020","Local":"Sat Feb 22 07:56:15 2020","StartDST":"Sun Mar 29 02:00:00 2020","EndDST":"Sun Oct 25 03:00:00 2020","Timezone":"+01:00","Sunrise":"07:46","Sunset":"18:21"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS10 = {"StatusSNS":{"Time":"2020-02-22T07:56:15"}} 07:56:15 MQT: OfficeCeilingLamp/stat/STATUS11 = {"StatusSTS":{"Time":"2020-02-22T07:56:15","Uptime":"7T00:51:52","UptimeSec":607912,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":7,"POWER":"ON","Wifi":{"AP":1,"SSId":"","BSSId":"","Channel":11,"RSSI":48,"Signal":-76,"LinkCount":6,"Downtime":"0T05:33:55"}}}

- [ ] Provide the output of the Console log output when you experience your issue; if applicable:
  _(Please use_ `weblog 4` _for more debug information)_

Console output here:



### TO REPRODUCE
Power cycle any connected device

### EXPECTED BEHAVIOUR
I expect the device to reconnect to my network after a powercycle, without having to reboot my router.

### SCREENSHOTS
_If applicable, add screenshots to help explain your problem._

### ADDITIONAL CONTEXT
Router: ASUS RT-AC2900
Stock firmware: 3.0.0.4.384_81351

Theese issues are never a problem when I flash ESP devices with my own custom firmware

**(Please, remember to close the issue when the problem has been addressed)**

Jason2866 commented 4 years ago

Probably your router is too blame. It stores leases (in arp table) which are not valid anymore. Reduce lease time or manually delete stored (not valid) leases

Fettkeewl commented 4 years ago

Why should this be an Tasmota only issue? No other devices experience the same issues. Further more all my tasmota devices are outside of my DHCP range and have static ips configured in the router

s-hadinger commented 4 years ago

There has been some wifi changes lately. Please try with the latest firmware and report if reconnection works.

Also try Reset 3, it may allows the device to reconnect once (I'm mostly curious if it works because I had a similar issue with failed reconnection for 15 seconds)

Fettkeewl commented 4 years ago

Was already on the latest as stated, 8.1.0! Reset 3 did nothing other than reboot the device and now it can't connect. The device shows up in my router for 7-10 seconds then dissappears. It does this indefinitely until I reboot the router. SmartSelect_20200222-124549_Chrome

Jason2866 commented 4 years ago

@s-hadinger the used version from @Fettkeewl is release v.8.1.0. This version uses the wifi set up which now is used again in the development branch. Only in development branch was inbetween a other set up for wifi which was not good for some users.

Without a analysis of the network traffic (via wireshark for example) we cant help because we dont have this issue.

May you give the development version a try, and try the latest development version with (stable!) beta Arduino core. Availiable here http://thehackbox.org/tasmota/ and here http://thehackbox.org/tasmota/pre-2.7/

Jason2866 commented 4 years ago

Static IP in router DOES mean you still use DHCP! If the devices have real Static IPs. The IPs are set in the device AND there is NO entry in router for. For testing delete the entry (in router) for a tasmota device which is behaving weird and configure the static IP ONLY in the device.

Fettkeewl commented 4 years ago

I will try the dev version and get back to you. In the meantime this is from my routers logs.

Feb 22 14:39:50 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:39:50 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:10 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:10 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:18 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:18 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:38 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:38 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)

Fettkeewl commented 4 years ago

Alright, I've tested 8.1.0.9. Sad to say I still have the same issues.. Sometimes power cycling works with reconnect but it would seem that if* the time span between turning it off and then on again grows to big, THEN the reconnect issues occur.

ascillato commented 4 years ago

Seems to be an ARP issue. Some settings in your router are conflicting with the config in your Tasmota device.

Do you have this issue if you delete the static IP entry from your router AND you set DHCP in your Tasmota device?

( to set DHCP in Tasmota use command IPADDRESS1 0.0.0.0 )

ascillato commented 4 years ago

As Tasmota uses MQTT there is no real need for a fixed or static IP. And if you need to access the webui and you don't use mDNS, Tasmota is also reporting its IP by MQTT, so you can see the actual IP on your home automation software.

For example, if you use Home Assistant and autodiscovery, your Tasmota IP is populated automatically on the device properties.

Fettkeewl commented 4 years ago

Seems to be an ARP issue. Some settings in your router are conflicting with the config in your Tasmota device.

Do you have this issue if you delete the static IP entry from your router AND you set DHCP in your Tasmota device?

( to set DHCP in Tasmota use command IPADDRESS1 0.0.0.0 )

I will try it, I have removed the bindings. Will evaluate and return with results :) thank you for your time

Fettkeewl commented 4 years ago

What a bummer.. Undoing my bindings did nothing.

Removed bindings yesterday on multiple devices
After my last post I had to leave so I unplugged my test-device
Prior to writing this I started up my test-device and it could not connect.. untill i rebooted router :< sigh!

Edit: I do not seem to be the only one with this issue, using an ASUS. Going to try and change bandwidth on my 2,4GHz to 20Mhz only and give it a go https://www.snbforums.com/threads/ac86u-384-14_2-tasmota-sonoff-wifi-connection.61326/

crispy78 commented 4 years ago

After updating to 8.1.0.9 I faced similar issues, all devices where acting like an AP instead of connecting to one. I’ve reset my AP’s and Router (UniFi AP-AC-Pro and Unifi Dream Machine) and gave all my devices a power cycle (switched the main circuit breaker in the home). After an unsuccessful attempt I remove the IP assignment from several devices (all devices are DHCP enabled) and did the same thing yet again. After that unsuccessful attempt I connected to the Tasmota devices, entered my WiFi settings and pulled an all-nighter to set things up again. That’s why I commented earlier that the 8.1.0.9 was the best factory reset ever. The best thing that came from this update is that I’ve now documented and automated my settings.

If your troubles came after updating to 8.1.0.9 I can agree that power cycling your AP’s, router and removing IP assignments doesn’t help getting the devices online again. I haven’t opened up my devices to retrieve logging, for that I have to apologize.

Jason2866 commented 4 years ago

Give this version a try. Arduino Core! wifi handling changed. NO change in Tasmota code.

tasmota.bin.gz

arendst commented 4 years ago

Guys, as there are many wifi related configuration options within Tasmota it's no use to reply here with remarks as

I have the same issue

Provide at least your SSID, Wificonfig, Setoption56 and SetOption57 settings to shine a constructive light over your issues.

For what it's worth, my Unifi AP's are perfectly able to re-connect to any power cycled device without issues with my settings of wificonfig 4, SetOption56 1, SetOption57 1 and only SSID1 set to the Unifi wifi network.

Fettkeewl commented 4 years ago

Alright! Post flashing with Tasmotizer I have not done any special Wifi-related settings other than use the configurations available on the device website.

My AP's name is simple with no special characters: Siblin I've only setup one AP on all my Tasmota devices. Connected to a ASUS RT-AC2900 as mentioned before.

wificonfig was default 4. Both SetOption56 -57 were default 0/OFF. Changing -56 -57 to 1 did nothing.

I even had to revert those options as it was causing my Sonoff S55 to behave strange.

I set the highest level serial logging and turned of my device untill I saw the deauth messages in my routers syslog. After that I booted my device with serial monitoring and below is the result, never connecting.

00:00:01 WIF: Checking connection...
00:00:01 WIF: Attempting connection...
00:00:02 WIF: Checking connection...
00:00:02 WIF: Attempting connection...
00:00:04 WIF: Checking connection...
00:00:04 WIF: Attempting connection...
00:00:05 WIF: Checking connection...
00:00:05 WIF: Attempting connection...
00:00:06 WIF: Checking connection...
00:00:06 WIF: Attempting connection...
00:00:06 QPC: Reset
00:00:07 WIF: Checking connection...
00:00:07 WIF: Attempting connection...
00:00:08 WIF: Checking connection...
00:00:08 WIF: Attempting connection...
00:00:08 APP: Boot Count 32
00:00:08 CFG: Saved to flash at FB, Count 82, Bytes 4096
00:00:09 WIF: Checking connection...
00:00:09 WIF: Attempting connection...
00:00:10 WIF: Checking connection...
00:00:10 WIF: Attempting connection...
00:00:11 WIF: Checking connection...
00:00:11 WIF: Attempting connection...
00:00:12 WIF: Checking connection...
00:00:12 WIF: Attempting connection...
00:00:13 WIF: Checking connection...
00:00:13 WIF: Attempting connection...
00:00:14 WIF: Checking connection...
00:00:14 WIF: Attempting connection...
00:00:15 WIF: Checking connection...
00:00:15 WIF: Attempting connection...
00:00:16 WIF: Checking connection...
00:00:16 WIF: Attempting connection...
00:00:17 WIF: Checking connection...
00:00:17 WIF: Attempting connection...
00:00:18 WIF: Checking connection...
00:00:18 WIF: Attempting connection...
00:00:19 WIF: Checking connection...
00:00:19 WIF: Attempting connection...
00:00:20 WIF: Checking connection...
00:00:20 WIF: Connect failed with AP timeout
00:00:20 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:00:21 WIF: Checking connection...
00:00:21 WIF: Attempting connection...
00:00:22 WIF: Checking connection...
00:00:22 WIF: Attempting connection...
00:00:24 WIF: Checking connection...
00:00:24 WIF: Attempting connection...
00:00:25 WIF: Checking connection...
00:00:25 WIF: Attempting connection...
00:00:26 WIF: Checking connection...
00:00:26 WIF: Attempting connection...
00:00:27 WIF: Checking connection...
00:00:27 WIF: Attempting connection...
00:00:28 WIF: Checking connection...
00:00:28 WIF: Attempting connection...
00:00:28 RSL: SonoffS55-01/tele/HASS_STATE = {"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Module":"Sonoff S55","RestartReason":"Power on","Uptime":"0T00:00:30","WiFi LinkCount":0,"WiFi Downtime":"0T00:00:00","MqttCount":0,"BootCount":32,"SaveCount":82,"IPAddress":"(IP unset)","RSSI":"68","LoadAvg":19}
00:00:29 WIF: Checking connection...
00:00:29 WIF: Attempting connection...
00:00:30 WIF: Checking connection...
00:00:30 WIF: Attempting connection...
00:00:31 WIF: Checking connection...
00:00:31 WIF: Attempting connection...
00:00:32 WIF: Checking connection...
00:00:32 WIF: Attempting connection...
00:00:33 WIF: Checking connection...
00:00:33 WIF: Attempting connection...
00:00:34 WIF: Checking connection...
00:00:34 WIF: Attempting connection...
00:00:35 WIF: Checking connection...
00:00:35 WIF: Attempting connection...
00:00:36 WIF: Checking connection...
00:00:36 WIF: Attempting connection...
00:00:37 WIF: Checking connection...
00:00:37 WIF: Attempting connection...
00:00:38 WIF: Checking connection...
00:00:38 WIF: Attempting connection...
00:00:39 WIF: Checking connection...
00:00:39 WIF: Attempting connection...
00:00:40 WIF: Checking connection...
00:00:40 WIF: Connect failed with AP timeout
00:00:41 WIF: Checking connection...
00:00:41 WIF: Attempting connection...
00:00:41 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:00:42 WIF: Checking connection...
00:00:42 WIF: Attempting connection...
00:00:43 WIF: Checking connection...
00:00:43 WIF: Attempting connection...
00:00:45 WIF: Checking connection...
00:00:45 WIF: Attempting connection...
00:00:46 WIF: Checking connection...
00:00:46 WIF: Attempting connection...
00:00:47 WIF: Checking connection...
00:00:47 WIF: Attempting connection...
00:00:48 WIF: Checking connection...
00:00:48 WIF: Attempting connection...
00:00:49 WIF: Checking connection...
00:00:49 WIF: Attempting connection...
00:00:50 WIF: Checking connection...
00:00:50 WIF: Attempting connection...
00:00:51 WIF: Checking connection...
00:00:51 WIF: Attempting connection...
00:00:52 WIF: Checking connection...
00:00:52 WIF: Attempting connection...
00:00:53 WIF: Checking connection...
00:00:53 WIF: Attempting connection...
00:00:54 WIF: Checking connection...
00:00:54 WIF: Attempting connection...
00:00:55 WIF: Checking connection...
00:00:55 WIF: Attempting connection...
00:00:56 WIF: Checking connection...
00:00:56 WIF: Attempting connection...
00:00:57 WIF: Checking connection...
00:00:57 WIF: Attempting connection...
00:00:58 WIF: Checking connection...
00:00:58 WIF: Attempting connection...
00:00:58 RSL: SonoffS55-01/tele/HASS_STATE = {"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Module":"Sonoff S55","RestartReason":"Power on","Uptime":"0T00:01:00","WiFi LinkCount":0,"WiFi Downtime":"0T00:00:00","MqttCount":0,"BootCount":32,"SaveCount":82,"IPAddress":"(IP unset)","RSSI":"60","LoadAvg":19}
00:00:59 WIF: Checking connection...
00:00:59 WIF: Attempting connection...
00:01:00 WIF: Checking connection...
00:01:00 WIF: Attempting connection...
00:01:01 WIF: Checking connection...
00:01:01 WIF: Connect failed with AP timeout
00:01:01 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:01:02 WIF: Checking connection...
00:01:02 WIF: Attempting connection...
00:01:03 WIF: Checking connection...
00:01:03 WIF: Attempting connection...
00:01:05 WIF: Checking connection...
00:01:05 WIF: Attempting connection...
00:01:06 WIF: Checking connection...
00:01:06 WIF: Attempting connection...
00:01:07 WIF: Checking connection...
00:01:07 WIF: Attempting connection...
00:01:08 WIF: Checking connection...
00:01:08 WIF: Attempting connection...
00:01:09 WIF: Checking connection...
00:01:09 WIF: Attempting connection...
00:01:10 WIF: Checking connection...
00:01:10 WIF: Attempting connection...
00:01:11 WIF: Checking connection...
00:01:11 WIF: Attempting connection...
00:01:12 WIF: Checking connection...
00:01:12 WIF: Attempting connection...
00:01:13 WIF: Checking connection...
00:01:13 WIF: Attempting connection...
00:01:14 WIF: Checking connection...
00:01:14 WIF: Attempting connection...
00:01:15 WIF: Checking connection...
00:01:15 WIF: Attempting connection...
00:01:16 WIF: Checking connection...
00:01:16 WIF: Attempting connection...

Jason2866 commented 4 years ago

@Fettkeewl have you tried the version i have uploaded?

Fettkeewl commented 4 years ago

@Fettkeewl have you tried the version i have uploaded?

Sorry Jason, have not had the time, been away most of the day since my last post! Will give it a go either tonight or tomorrow depending on my kid :stuck_out_tongue:

Fettkeewl commented 4 years ago

Alright @Jason2866 , I've been trying it out, the version you provided. No dice. Still the same behaviour. I even tried Wificonfig 0 and 5. Made no difference. There is a timespan of 3-5 minutes of offline activity it seems, before the devices get blocked from reconnecting. If I pull the power and return it within some minutes it does reconnect.

The reason this is a problem, is that I'm thinking of using a 2 device setup. 1 Sonoff S55 to controll the power to my cars engineheater, which in turn is also connected to an outlet inside the car for the coupé heater. The Coupé heater I want to put an Sonoff Basic R3 on and have it only power up when I turn the engine heater(s55) on, this is to controll and monitor temperature inside of the car itself. This will never be possible if the R3 with tasmota can't reconnect to my wifi

It's not desired to be force to: Turn S55 on -> reboot router, only to gain control of the R3 inside the car.

Fettkeewl commented 4 years ago

No other things I can try? Been waiting for a reply @arendst @Jason2866

Jason2866 commented 4 years ago

Take a look in your router docs if there is something you can do how ARP is handeled See issue https://github.com/arendst/Tasmota/issues/7098#issuecomment-565613543 your issue looks similar. Mikrotik routers do not have any problems anymore with enabling ARP treatment The naming (Multicast helper) for Mikrotik is missleading.

miazza99 commented 4 years ago

Just to tell you that I have the same issue with my Tasmota SonOff devices on ASUS RT86U. Switching OFF the 2.4 and again ON after a few seconds seems to fix the problem as rebooting the router. This is not the solution but it might help in uderstanding.

Jason2866 commented 4 years ago

@miazza99 Doing that will probably erase DHCP ARP entrys too.

You cant try lowering the DHCP lease time to 5 minutes. Check if the devices connect after the lease time is over

miazza99 commented 4 years ago

OK. I will try when back home next week. In any case I'm still wondering why the issue seems onlt related to Tasmota devices while all other wifi devices are well connecting. I did not test very much SonOff with original FW but as far as I remember I did not experience any similar problem before flashing Tasmota.

Jason2866 commented 4 years ago

Other Asus routers had already issues before. See https://github.com/arendst/Tasmota/issues/2643#issuecomment-388593601 May you try things helped there. Such problems does only affect clients needing this function(s). So working many other devices does not mean the router has no bug.
AND original Sonoff firmware does not have features needing this functions in router

Jason2866 commented 4 years ago

Can you post a screenshot from the Professional settings page and the IPTV settings page of you Asus router?

Fettkeewl commented 4 years ago

Heres mine, printed as pdf, since I'm not home, this was the easiest way through team viewer on my phone :P ASUS Wireless Router RT-AC2900 - IPTV.pdf ASUS Wireless Router RT-AC2900 - Professional.pdf

Edit: It's all stock settings

miazza99 commented 4 years ago

These are mine.

Wireless Professional IPTV

Fettkeewl commented 4 years ago

These are mine. )

Please change the language while you screenshot it, top right corner :) select english

miazza99 commented 4 years ago

OK. I was already surprised to manage via VPN from outside and I did not realize this . Wireless Professional IPTV

Fettkeewl commented 4 years ago

Worth mentioning, from other threads: I tried disabling airtime fairness and universall beamforming, did nothing!

Jason2866 commented 4 years ago

Okay, lets try: Enable IGMP Snooping, DTIM Interval 1, Disable WMM, Disable WMM APSD, Airtime Fairness Disable, Multiuser MIMO Disable, All Beamforming Disable.

IF (hope :-) ) this does help you can revert options. A good idea in general is to enable IGMP Snooping.

Good Luck.

Jagohu commented 4 years ago

Hi, I'm not using Tasmota, but ended up here looking for a solution on the same problem (clients dropping off or not even connecting) while dealing with Arduino ESP8266s. After a router reboot, most of them connected, and got lost afterwards. For me this is the setup which works:

Additionally it turns out my IPTables and IPSET were both involved in screwing it up, so you might want to look at that too. I am using Firehol ipset lists, which unfortunately contain a few private IP-addresses, including 224.0.0.0/3, so the whole mDNS range -> I guess this screwed it up for me in addition to perhaps something else. Now it works anyway, maybe you can try it too. This is what I've removed from the firehol blacklist: 0.0.0.0/8 @ line 35 10.0.0.0/8 @ line 111 127.0.0.0/8 @ line 2083 172.16.0.0/12 @ line 2535 192.168.0.0/16 @ line 3251 224.0.0.0/3 @ last line Good luck!

Fettkeewl commented 4 years ago

Okay, lets try: Enable IGMP Snooping, DTIM Interval 1, Disable WMM, Disable WMM APSD, Airtime Fairness Disable, Multiuser MIMO Disable, All Beamforming Disable.

IF (hope :-) ) this does help you can revert options. A good idea in general is to enable IGMP Snooping.

Good Luck.

WOOOT WOOOOT 😄 Initial testing seems OK with your settings. I could not change the WMM to disabled though! I´ve done two power cycles with 5 min inbetween which normally would have blocked my tasmota devices from reconnecting, but it worked! Both times =)!

This weekend I'll spend some time reverting some settings to see which one is the culprit! Thanks alot, holding my thumbs that this will be the permanent solution!

ascillato2 commented 4 years ago

Great to know that a solution for your router has been found.

Thanks everyone for helping on this.

RichardUUU commented 4 years ago

I tried Jason2866's suggestions and it seemed to work, but didn't stick. So I tried Jagohu's suggestions and that sticks longer. BUT ... after a router reboot, I also need to reboot my Shelly in order to see it. That's not really a fix.

I have 10 @ Shelly 1 that work flawlessly on 6.7.1. Now I have 3 on 8.2.0 that need to be rebooted whenever the router reboots. Same router.

I'm not sure this issue should be closed.

RichardUUU commented 4 years ago

After a while, Jagohu's suggestions resulted in problems for other devices. So I set my router back to stock and flashed all my devices with 6.7.1. Best solution I've found so far. The tyranny of the tiny wires is over.

But I absolutely think this issue should be reopened.

ascillato commented 4 years ago

But I absolutely think this issue should be reopened.

Sorry, but your problem is not Tasmota but your own router's configuration. Please, address this to the Tasmota support chat for help. Thanks.

RichardUUU commented 4 years ago

This is where Tasmota support chat sent me. I agree there seems to be an incompatibility between Tasmota and my router, but changing the settings as suggested did not work.

My router works with 6.7.1 and not with 8.1.0, Something is different between those two versions and it isn't my router.

Other than the fact that 8.2 works on other routers, Is there any specific reason for concluding that the problem is my router? Thanks.

Jason2866 commented 4 years ago

Tasmota uses Arduino core. The core between 6.7.x and 8.x is different. Going back to a older core is NO option, since older core(s) have security issues and bugs which are solved in the actual (used) core. New features of Tasmota needs actual core too. To make things even more complicated Arduino core is hooked up on Espressif SDK (closed source) So bug hunting is try and error (only). Long story short. Issue is NOT Tasmota related and can NOT be solved in Tasmota. Afaik, only Asus router does have this issue. So ESP82xx and Asus are not a good combination

RichardUUU commented 4 years ago

Thanks, I accept that the issue can not be solved in Tasmota, but that doesn't necessarily mean it's a problem with the router. For all I'm hearing, it could be that the new core has some problem that is only revealed by this router.

Of course, that's irrelevant with respect to Tasmota, but could be very relevant to someone trying to solve this problem since it might not be solvable by playing with the router. Cheers.

miazza99 commented 4 years ago

Finally I used a workaround that seems working (it's stable since about one week). I have put a tasmota sonoff on the router and I have put a daily timer to switch it off for 10 seconds everynight at 3.00 a.m. This , together with the above suggested settings seems to solve the issue. Sometimes Tasmota disconnects and reconnects automatically but this is not creating any issue to the normal operativity of the device.

Sc00bs110 commented 4 years ago

I have Sonoff devices with the standard firmware on them and am having the same issue with my Asus mesh routers RT-AC88U & RT-AC68U. It also does not appear to be all of the sonoff models and is only affecting the basic ones. I no longer have connectivity with them from the app but do to the models with temp, power etc. I have changed to all the suggested wifi setting but doesn't seem to make any difference and I am busy downgrading everything from Merlin 384.16 to 384.15 to see if that sorts the problem out.

Jason2866 commented 4 years ago

Asus should build PCs Motherboards only...

miazza99 commented 4 years ago

With the latest Tasmota 8.2 the problem disappeared. Now all my SonOFF are on line with very good reliability :)

svh1985 commented 4 years ago

I found that in my Draytek 2926 Bandsteering caused issues. No other devices in my network are having issues with bandsteering. Is Tasmota not giving back to the router that it is not 5Ghz capable?

Band Steering Note:

Band steering is used to detect if the wireless client is capable of dual-band or not. If dual-band is detected, the AP will let the wireless client connect to less congested wireless LAN, such as 5GHz to prevent from network congestion.
Band steering would actively block the client's attempts to associate with 2.4GHz Wireless LAN. So the setting of "Check time for WLAN client 5G capability" would cause the delay of 2.4G WLAN connection.

ascillato commented 4 years ago

All ESP8266 devices are only Wifi 2.4GHz, they don't support Wifi 5GHz

svh1985 commented 4 years ago

All ESP8266 devices are only Wifi 2.4GHz, they don't support Wifi 5GHz

I know, but it seems like the Router doesn't get that from the Tasmota device and kicks it to 5GHz because it thinks it's 5GHz capable. Not sure what device is to blame tbh. 🤷‍♂️

ascillato commented 4 years ago

Band steering is a new feature of some new routers. As soon as that feature was shipped, some networking magazines talked about this and that problem. Some devices are being sent to 5Ghz and they are not capable of that connection. Is not a problem of the ESP8266. It is just that config on the router. The router manual said to disable that feature if you have devices that are only 2.4GHz. AFAIK, it is recommended to have 2.4GHz and 5GHz as separated networks with different SSID as to avoid this type of issues.

svh1985 commented 4 years ago

Cool, thanks for the explanation. Maybe it is good to add it to the documentation, that band steering will cause issues. Took me a while to figure out 😅

arendst / Tasmota