Miele devices giving lots of WiFi 'tx failed' entries

Installing and Using OpenWrt
1

For some reason our Miele coffee machine and oven connected to our 2.4 GHz guest WiFi network uniquely show up with lots of 'tx failed' packets using 'station dump' - see the last two devices beginning with MAC addresses in the form 00:1d:63:xx here:

root@OpenWrt-2:~# iw dev wl0-ap0 station dump
Station xxx (on wl0-ap0)
        inactive time:  1850 ms
        rx bytes:       5641259
        rx packets:     36524
        tx bytes:       367638
        tx packets:     3643
        tx retries:     6288
        tx failed:      0
        rx drop misc:   1
        signal:         -72 [-73, -86, -76, -87] dBm
        signal avg:     -71 [-72, -85, -76, -87] dBm
        tx bitrate:     19.5 MBit/s MCS 2
        tx duration:    7403087 us
        rx bitrate:     54.0 MBit/s
        rx duration:    4687324 us
        airtime weight: 256
        expected throughput:    20.782Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    3
        beacon interval:100
        short preamble: yes
        connected time: 94523 seconds
        associated at [boottime]:       43.482s
        associated at:  1706368015041 ms
        current time:   1706462537651 ms
Station xxx (on wl0-ap0)
        inactive time:  130 ms
        rx bytes:       18520208
        rx packets:     512020
        tx bytes:       227847
        tx packets:     3239
        tx retries:     43
        tx failed:      0
        rx drop misc:   1
        signal:         -18 [-27, -24, -19, -30] dBm
        signal avg:     -18 [-27, -24, -19, -30] dBm
        tx bitrate:     72.2 MBit/s MCS 7 short GI
        tx duration:    1021475 us
        rx bitrate:     6.0 MBit/s
        rx duration:    84577198 us
        airtime weight: 256
        expected throughput:    58.868Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    3
        beacon interval:100
        short preamble: yes
        connected time: 94499 seconds
        associated at [boottime]:       67.183s
        associated at:  1706368038742 ms
        current time:   1706462537652 ms
Station xxx (on wl0-ap0)
        inactive time:  22430 ms
        rx bytes:       157298036
        rx packets:     1948779
        tx bytes:       7597021996
        tx packets:     5599557
        tx retries:     1089265
        tx failed:      6
        rx drop misc:   97
        signal:         -46 [-53, -46, -54, -56] dBm
        signal avg:     -45 [-53, -46, -54, -56] dBm
        tx bitrate:     144.4 MBit/s MCS 15 short GI
        tx duration:    1032024357 us
        rx bitrate:     12.0 MBit/s
        rx duration:    92588891 us
        airtime weight: 256
        expected throughput:    101.989Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            yes
        TDLS peer:      no
        DTIM period:    3
        beacon interval:100
        short preamble: yes
        connected time: 94490 seconds
        associated at [boottime]:       76.475s
        associated at:  1706368048035 ms
        current time:   1706462537654 ms
Station 00:1d:63:xx (on wl0-ap0)
        inactive time:  1410 ms
        rx bytes:       7461226
        rx packets:     34005
        tx bytes:       2333161
        tx packets:     16963
        tx retries:     94909
        tx failed:      13072
        rx drop misc:   109
        signal:         -39 [-43, -50, -40, -60] dBm
        signal avg:     -37 [-41, -49, -39, -58] dBm
        tx bitrate:     65.0 MBit/s MCS 6 short GI
        tx duration:    392914162 us
        rx bitrate:     72.2 MBit/s MCS 7 short GI
        rx duration:    4557788 us
        airtime weight: 256
        expected throughput:    20.598Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    3
        beacon interval:100
        short preamble: yes
        connected time: 92426 seconds
        associated at [boottime]:       2140.627s
        associated at:  1706370112187 ms
        current time:   1706462537655 ms
Station 00:1d:63:xx (on wl0-ap0)
        inactive time:  1310 ms
        rx bytes:       5570687
        rx packets:     24090
        tx bytes:       1470571
        tx packets:     11384
        tx retries:     64593
        tx failed:      8658
        rx drop misc:   2
        signal:         -47 [-59, -61, -54, -48] dBm
        signal avg:     -46 [-58, -60, -53, -48] dBm
        tx bitrate:     26.0 MBit/s MCS 3
        tx duration:    244300395 us
        rx bitrate:     72.2 MBit/s MCS 7 short GI
        rx duration:    2985199 us
        airtime weight: 256
        expected throughput:    16.387Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    3
        beacon interval:100
        short preamble: yes
        connected time: 92412 seconds
        associated at [boottime]:       2154.642s
        associated at:  1706370126202 ms
        current time:   1706462537656 ms

All other WiFi devices including IoT devices like cheap smart plugs on the network do not show such high numbers for 'tx failed'. There is good WiFi signal strength between the Miele devices and the nearby AP.

Any ideas?

2

What wifi specs does the miele have in the datasheet?

What wifi protocol do you use? Try nothing newer than N.

And use nothing fancier than wpa2.

Had pretty much the same problem with my Netatmo weater station and took time to this weekend to dig in to the problem. And setting the protocol to N and only wpa2 seems to get it really stable.

3

Manual here: https://www.miele.co.uk/f/uk/manuals-125.aspx?mNo=11859833&asDownload=1 but nothing about the WiFi module unfortunately.

My AP for the 2.4 GHz guest WiFi network is set to mode N and WPA2-PSK.

4

The wifi data on page 90 must probably be the most worthless wifi data in wifi history…

2 Likes
5

Smarthome and IoT devices often include really bad wifi solutions, as long as it's cheap, and often combine that with equally bad configuration options and zero updates; interoperability can be a challenge.

In cases like this, it does help to have options and alternatives, so if you do have an old ath9k based device at your disposal (or ath10k/ ath11k)[0], it would be interesting to see how those work together. I'm not expecting a positive change, but there might be surprises - positive or negative.

Especially with printers, always have wired ethernet (and native postscript support) on the top of your must-have list, WLAN is a nice addon, but given the problems with bad wifi implementations in this kind of devices nothing you should rely upon (if it works, great, but you usually can't change your whole network or drop security just to accommodate it).

--
[0] not because those would be 'better', but because they're 'different'.

1 Like
6

If I look at the Miele official support what to do if you have wifi "issues". Oh dear.

miele
miele1228×516 204 KB

So I would try first to reset wifi on the device itself and see if it helps.

Otherwise that what @slh has written already. Use other router devices. That helps often for crappy IoT devices.

1 Like
7

So from a practical perspective everything seems to work OK notwithstanding, albeit I noticed that the Miele devices kept seemingly losing connection, and, upon looking at the logs of the APs, I realised that in addition to all the 'tx failed' entries, what was happening was that the setting:

option disassoc_low_ack '1'

resulted in constant disconnection and reconnection.

From this post here:

I gather that this option is set by default on hostapd to '0', but in OpenWrt to '1'.

When I set this option to '0', the Miele devices no longer keep losing their connection.

So I have set this option to '0' for the entire GUEST WiFi network for now. I'm not entirely sure about the implications of this, and whether I should consider the same for my main LAN WiFi network too.

Is there no way to set this for specific devices only, rather than globally?

8

Sorry for the delay. ;D

Hostapd itself is just a driver configuration tool which allows you to create "software-based" access points. It cannot be setup in a way to address any client individually. Think of it like the channel selection. One channel per AP.

The issue at hand is clearly a client issue.

To use the option "disassoc_low_ack" the driver has to support it. So your device' driver seems to be capable to use this option.

The option itself disassociates a client due to:

  • inactivity
  • transmission failures
  • other indications of connection loss

So the error messages disappear because the client is forced out. It should not affect other clients as long they are not going "inactiv". This could happen for devices entering battery saving meassures (like a smartphone).

You could prevent clients to be removed due to inactivity by just running a script (on client side) pinging a site or the router itself like every 5 minutes.