Tasmota device (esp8266) has high packet loss but good signal strength

Installing and Using OpenWrt
1

I'm having a problem with a Tasmota device with high packet loss, causing it to reconnect to MQTT. The problem only occurs on one Tasmota device, the other (connected to another AP) doesn't have this issue. This is my /etc/config/wireless:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:00.0'
        option channel 'auto'
        option band '5g'
        option htmode 'VHT80'
        option cell_density '0'
        option txpower '22'
        option country 'RO'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/ahb/18100000.wmac'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option txpower '18'
        option log_level '2'
        option channel 'auto'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option ssid 'Andrei'
        option encryption 'psk2'
        option key '***'
        option network 'lan'
        option disassoc_low_ack '0'
        option ieee80211k '1'
        option time_advertisement '2'
        option time_zone 'EET-2EEST,M3.5.0/3,M10.5.0/4'
        option wnm_sleep_mode '1'
        option bss_transition '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'Andrei'
        option encryption 'psk2'
        option key '***'
        option network 'lan'
        option disassoc_low_ack '0'
        option ieee80211k '1'
        option time_advertisement '2'
        option time_zone 'EET-2EEST,M3.5.0/3,M10.5.0/4'
        option wnm_sleep_mode '1'
        option bss_transition '1'

ubus call system board:

{
        "kernel": "5.15.134",
        "hostname": "OpenWrt",
        "system": "Qualcomm Atheros QCA956X ver 1 rev 0",
        "model": "TP-Link Archer C6 v2 (EU/RU/JP)",
        "board_name": "tplink,archer-c6-v2",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.0",
                "revision": "r23497-6637af95aa",
                "target": "ath79/generic",
                "description": "OpenWrt 23.05.0 r23497-6637af95aa"
        }
}

I've tried it with another AP, so I'm sure it's not the device.

2

What tamota is saying about this?
You have artificially reduced power and no country in 2.5ghz
You need more logs, eg wnm sleep mode dares station to switch off transmitter for spec time, then with inaccurate clock it may legitimately miss the packet it is supposed to wake for.

1 Like
3

Apparently some devices don't like a country code, if I set one they will also have problems with high packet loss.

Do you suggest turning off WNM sleep mode?
It's weird that it's only happening with this device, the other device doesn't have this issue and the config is the same for both APs

4

What do you mean by this?

  • You tried it with another AP and it worked perfectly
  • You tried it with another AP and the same symptoms occurred

If the first, what were the configuration differences?
If the second, it's probably the ESP itself, or the power supply to it.

(I've had to bin a small number of ESP8266 boards over the years because they were unstable compared to others bought at the same time).

The ESP isn't sitting on a mains cable, by any chance? I recently had one that couldn't hold a connection because I'd foolishly tucked it behind a cable inside a heat pump without realising that it was a 240V supply to a rectifier!

5

Yes

It was just my phone's hotspot

Well, it's connected to a relay, so it is. But I doubt this could be affecting it.

6

It seems after disabling WNM sleep mode the issue went away. I'll keep an eye on it for the next few days, but I think this was the culprit.

1 Like
7

Increase hostap log level, small devices are very bugg^H^H^H^Hpicky with protocols.
https://openwrt.org/docs/guide-developer/debugging#logging_hostapd_behaviour

8

Spoke too soon. It's frustrating that changing any setting NOT related to the 2.4GHz radio causes this issue to come back. It was working fine, then I changed the 5GHz channel and it started again.
Note to self: ESP8266 doesn't like 2.4GHz channel 1. Changed to 13 and no problems

10

So it is clearly iot problem. AP side logs may help discover them better, remember - new firmware of iot and you have to do it all again.

11

Interesting. That's either a very slightly damaged antenna or DSP circuit feeding the microcontroller, or channel 1 is just really noisy and "polluted" with other nearby devices.

Remember that 2.4GHz WiFi has to coexist not just with other APs and clients outside your network, but also with Bluetooth and ZigBee devices & networks. And microwave ovens too.

2 Likes
12

There's another problem: Disabling WNM sleep mode makes my AC have high packet loss, enabling it makes Tasmota have high packet loss. Now I have to pick between my AC and Tasmota??
So it seems disabling WNM sleep mode and Time advertisement across all 4 radios fixed the issue (for now).

13

select the channel manually, neighbors may interfere
channel 1, 6, 11 do not overlap with other channels
and do not try to put the 13th channel, because there will be losses of packages
since the devices themselves are not friendly with channel 13 ))

14

The correct country code needs to be set, there's no way around that - if you transmit 802.11d or not is another question (although any client stumbling over 802.11d would be blatantly broken, as it's common place, even in OEM firmwares and required for contemporary wifi standards), but your router must be configured with the correct region.

15

High packet loss again after restarting the router. I think the problems lie somewhere else as the whole network is unstable, not just this device. After changing the channel to auto it started working again, it's really strange, like someone aimed a microwave antenna at my house...

16

Also, does OpenWRT take into account other sources of interference when choosing the Wi-Fi channel or just the other networks? It's kinda strange it chose channels 11 and 12 instead of 6 and 11

17

You can use

option channels '1 6 11'

or better

option country 'RO'
option acs_chan_bias '1:0.8 5:0.8 9:0.8 13:0.9'
18

Yeah, but the problem was using adjacent channels on both routers interfering with one another.

19

Thats rather uncommon, like all band is full of other AP-s.

20

Weird. This is what I see in channel analysis (Andrei is the other AP):

Screenshot_20240717_140412_com.android.chrome
Screenshot_20240717_140412_com.android.chrome1080×2240 181 KB

21

Get the written confirmation from tasmota that they lose packets is ACS misfires.