WIFI AP Mikrotik with Sonoff Devices

RouterOS Wireless Networking
1

Hello,

in my home I have to Mikrotik APs installed, one HAP AC, which is connected to the physical LAN and one HAP AC lite, which is connected via wireless bridge to the HAP AC. (manual configuration, no capsman manager)
For the wireless bridge (VLAN-trunk mode) I use the 5GHz-Channels (wlan2) and the wlan1 I use for three WifiNetworks (one SSID on wlan1 and two virtual AP’s)

Never had any issues with the above mentioned configuration in the past, but since I installed additional devices (Sonoff T1EU2CH flashed with tasmota) my WIFI drives my crazy.
At first I installed only one of those devices and there wasn’t any issues therefore I ordered 3 additional to automate my roller shutters.

After some time (x-minutes until approx. 6h) the devices couldn’t be reached with the static ip addresses, but on the AP they are still listed in the registration tab (winbox). When I am going to kick the device from the AP it will reconnect and it will be pingable again. I do not really believe that this happens because of a bad network coverage, because one device is only few meters away from the AP.

Already tried some settings to get rid of this issue, but unfortunately no actions solved the issue:

  1. Disabled one AP (turned off)
  2. reduced the TelePeriod (Communication period) of one sonoff device (from 300s to 29s)
  3. Set some special wifi options on one of the devices
    SetOption56 to ON
    SetOption57 to ON


    Do you have any hints for me?

Thanks in advance!

BR
Michael

2

I would guess it’s related to this http://forum.mikrotik.com/t/devices-are-not-reliably-responding-to-arp-requests-wifi-power-saving/135282/1

Are you using Tasmota?

3

Hello,

yes, all devices are flashes with tasmota v6.7.1.
Have you found any solution or improvement for this issue?

Thanks!

BR

4

Disabling sleep with

sleep 0

hides the underlying issue but can cause other problems - if devices don’t sleep they use more power / release more heat. I’ve seen one report that the Sonoff Basics will overheat if they do not sleep.

If you have time can you run nping and post your redacted wifi config in the thread mentioned above?

Thanks

5

Hello,

now changed to “sleep 0”, SetOption60 is also 0 ok?
I will post results into your thread when I am at home.

BR
Michael

6 
sleep 0

should be fine I believe.

SetOption60

is only relevant when there’s a sleep time configured.

7

Hello,

attached a linux comuter to the same wifi, you are right, I am facing the same issue with the non replied ARP request.
When I am change to sleep 0 every request will receive an answer. (sent: 60 Rcvd: 61)

But the Load of the sonoff devices T1EU2C is now at 97 and figure is still rising (now at 999)
What exactly do you mean by overheat? I won’t burn down my house :frowning:

BR
Michael

8

unfortunately the error happened again.
I read that a permanent ping will keep the devices alive, what about the idea to create a script on the mikrotik AP’s?

BR

9

What exactly do you mean by overheat? I won’t burn down my house

Overheat as in the MCU will reboot and become unstable. It probably won’t burn your house down but don’t hold me to that. I’ve seen mixed messages whether this is a general problem or a specific batch of Sonoff Basics.

I read that a permanent ping will keep the devices alive, what about the idea to create a script on the mikrotik AP’s?

It won’t prevent them from sleeping and it won’t help with the ARP issue - the device doing the pinging will probably maintain an ARP entry, but other devices will not.

10

Hello,

tried to implement a scheduled script (ping) for one device, will keep you informed.

BR

11

Hello,

as already expected the ping script do not solve this issue.
Because of ongoing issues with my WiFi and those devices I disabled the authentication checkbox for all those devices.
(other clients on virtual AP are effected)

As far as I understand there will be a workaround implementation in tasmota (Gratuitous ARP) in the near future.
Will give it a try when finished…

BR
Michael

12

Michael,

perhaps you should test your tasmota devices on a NON virtual AP and try if the problem still excists …
I am running 10+ tasmota devices on my MT AP’s and do not have any problems.

13

Multiple uses are reporting the same issue. My devices are connected to the primary SSID with the same problem.

If you get time please could you confirm your ROS version, redacted wifi config, and possibly redacted the output from status 0 a the Tasmota device? If you could run an nping test even better.

Thanks

14

Here you go …

RouterOS stripped to essential

# dec/13/2019 06:34:03 by RouterOS 6.46
# software id = TNXU-TVMJ
#
# model = RouterBOARD 962UiGS-5HacT2HnT
/interface bridge
add admin-mac=xx:xx:xx:xx:xx:xx auto-mac=no name=bridge
/interface wireless channels
add band=2ghz-g/n frequency=2412 list=2.4GHZ name=ch1 width=20
add band=2ghz-g/n frequency=2437 list=2.4GHZ name=ch6 width=20
add band=2ghz-g/n frequency=2462 list=2.4GHZ name=ch11 width=20
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" \
    group-key-update=1h management-protection=allowed mode=dynamic-keys name=\
    Fake supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=3 band=2ghz-g/n country=\
    netherlands disabled=no disconnect-timeout=15s distance=indoors \
    frequency=auto frequency-mode=regulatory-domain installation=indoor mode=\
    ap-bridge preamble-mode=long radio-name=hap scan-list=2.4GHZ \
    security-profile=Fake ssid=Fake wireless-protocol=802.11 \
    wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac \
    channel-width=20/40mhz-Ce country=netherlands disabled=no frequency=5260 \
    frequency-mode=regulatory-domain installation=indoor max-station-count=50 \
    mode=ap-bridge preamble-mode=long radio-name=hap security-profile=\
    Fake ssid=Fake wireless-protocol=802.11 wps-mode=disabled
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=wlan1
add bridge=bridge interface=wlan2
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
/ip dhcp-client
add disabled=no interface=bridge
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes

output of status 0 on a TH10 with temp sensor

06:44:41 CMD: status 0
06:44:41 MQT: stat/temp3/STATUS = {"Status":{"Module":4,"FriendlyName":["temp3"],"Topic":"temp3","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
06:44:41 MQT: stat/temp3/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/tasmota.bin","RestartReason":"Software/System restart","Uptime":"2T20:16:02","StartupUTC":"2019-12-10T09:28:39","Sleep":50,"CfgHolder":4617,"BootCount":1,"SaveCount":687,"SaveAddress":"F9000"}}
06:44:41 MQT: stat/temp3/STATUS2 = {"StatusFWR":{"Version":"7.1.2.4(3d2e77f-tasmota)","BuildDateTime":"2019-12-09T19:00:09","Boot":31,"Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8266EX","CR":"245/1151"}}
06:44:41 MQT: stat/temp3/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":2,"LogHost":"192.168.6.242","LogPort":1514,"SSId":["Fake",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005AFF000000000000","00000000","00000000"]}}
06:44:41 MQT: stat/temp3/STATUS4 = {"StatusMEM":{"ProgramSize":563,"Free":440,"Heap":23,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"1420C2","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"}}
06:44:41 MQT: stat/temp3/STATUS5 = {"StatusNET":{"Hostname":"temp3-4394","IPAddress":"192.168.6.171","Gateway":"192.168.6.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.6.246","Mac":"xx:xx:xx:xx:xx:xx","Webserver":2,"WifiConfig":4}}
06:44:41 MQT: stat/temp3/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.6.241","MqttPort":1883,"MqttClientMask":"temp3","MqttClient":"temp3","MqttUser":"DVES_USER","MqttCount":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
06:44:41 MQT: stat/temp3/STATUS7 = {"StatusTIM":{"UTC":"Fri Dec 13 05:44:41 2019","Local":"Fri Dec 13 06:44:41 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"08:35","Sunset":"16:53"}}
06:44:41 MQT: stat/temp3/STATUS10 = {"StatusSNS":{"Time":"2019-12-13T06:44:41","SI7021":{"Temperature":15.0,"Humidity":53.4},"TempUnit":"C"}}
06:44:41 MQT: stat/temp3/STATUS11 = {"StatusSTS":{"Time":"2019-12-13T06:44:41","Uptime":"2T20:16:02","UptimeSec":245762,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"Fake","BSSId":"xx:xx:xx:xx:xx:xx","Channel":1,"RSSI":100,"Signal":-38,"LinkCount":1,"Downtime":"0T00:00:06"}}}

nping output (even tried running with -c 600 and no drops whatsoever …)

nping --arp-type ARP 192.168.6.171 -c 10            
Starting Nping 0.7.70 ( https://nmap.org/nping ) at 2019-12-13 06:52 CET
 
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 10 (420B) | Rcvd: 11 (308B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 9.03 seconds
15

Hey eddieB, I dont have any tasmanian devils or komodo dragons or their offspring Tasmoto’s but just wanted to say thanks for assisting others and trying to solve their issues!!! Good on ya mate!

16

Hello,

I have resetted both mikrotik devices to factory setting and reconfigured for my purposes. I believe that my issues wasn’t only related to the sonoff devices, because I also experienced a ping loss with a linux NTB connected to my virtual AP. (looks like a loop in the network)
During the reconfiguration I found out, that I had the same MAC address for the master and one virtual AP, corrected manually. (was automatically assigned)
On the second AP I disabled the wlan1 adapter, therefore its only acting as bridge on wlan2 and enables local attached devices to communicate with my network.

Now all sonoff devices (sleep=0) are reachable over WIFI, will keep this situation for some days and then I will enable wlan1 on the second AP again.

BR
Michael

17

Thanks for your fellow heads-up.
Most of the so called problems are just configuration issues …
Keep your configs as simple as possible and try to exclude problems works for me :wink:

Eddie