Brother printers getting in a bad state after upgrading OpenWRT

Installing and Using OpenWrt
1

I recently upgraded my router (TP-Link Archer C7 v5) from (probably?) 22.x¹ to 25.12.1 (and then 25.12.2). Since the upgrade, both of my wireless Brother printers (HL-L2380DW and MFC-L8850CDW) have exhibited the exact same bizarre behavior:

  • After connecting to the router (2.4GHz), they work perfectly for a few hours (usually in the 3-6 range, though once I saw them work for 11 hours). "Works perfectly" means they broadcast their presence over mDNS, they respond to ARP requests, and they respond to unicast traffic (pings, print jobs, web UI, etc).
  • "Something" happens and both printers get into a bad state at exactly the same time (even if I connected them to the network hours apart)
  • When they're in the bad state, they stop responding to ARP requests and they stop broadcasting mDNS, but they continue handling unicast traffic just fine. Any computer on the network (wired or wireless) which already has the printer defined and which already has the printer's IP in its ARP table is able to ping, access the web ui, print, etc, but any computer which doesn't already know the printer's details can't find it. Manually adding the IP to the ARP table allows prints to go through.
  • Forcing a printer to reconnect to the router (e.g. by telling hostapd to kick it) makes that printer work fine again.

I've tried just about every option in both wifi-iface and wifi-device I (or AI) can think of (see below). The only way I've found to keep the printers from getting into the bad state is to enable multicast_to_unicast, but I don't like that since it automatically turns on AP isolation.

I've used tcpdump on the router when the problem shows itself, and I can see ARP requests coming in from other clients and going out over the wireless network, so I'm pretty sure the router isn't eating the multicast packets. Even weirder, if I run an arping from another host, I get very occasional ARP replies, so the traffic can get through.

I upped the hostapd logging to "info," and nothing gets logged at the moment the printers enter the bad state.

Given that the printers always fail at the same moment, I figure it has to be something on the router itself, but I have absolutely no idea what it could be.

For now, I've worked around the issue by creating a separate "printers" AP with multicast_to_unicast set to 1, but I'd love not to need a workaround at all.

Attempted options (mostly suggested by AI):

  • ieee80211w '0'- I think this is the default, but tried it anyway
  • ocv '0'
  • wmm_enabled '0' and wmm '0' - I actually had to hack the uc and sh scripts because they normally force this to 1
  • wpa_group_rekey '0'
  • uapsd '0'
  • dtim_period '1'
  • wnm_sleep_mode '0'
  • bss_transition '0'
  • rrm '0'
  • disassoc_low_ack '0' - Not that I expected this to do anything, since the printers stay associated with the AP even in their bad state
  • multicast_to_unicast '1' - The only one that actually did anything; with this set, the printers never seem to go bad.

I also added the following to the radio's configuration:

  • htmode 'HT20'
  • country 'US'
  • cell_density '0'
  • legacy_rates '1'

I'm using the non-CT drivers, but as I understand it that only affects 5GHz networks, and this is 2.4GHz.

(Cross-posted from Reddit)

¹ Yes, I know it was massively out-of-date. I'm guessing about the old version; I can't find a version number in the config backup, but most of the files were created 2022/08/16.

2

When both printers enter bad state at the same moment, then I wonder if they get some strange broadcast. You could connect another client to the same AP, and start logging with WireShark.

3

My configuration, that works with Brother printer:

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'MySSID_2G'
        option encryption 'psk2+ccmp'
        option key 'test1234test'
        option disassoc_low_ack '0'

I tried various configuration, but in the end, I finished with a config where only WPA2 and force CCMP works.

4

That is expected for older equipment and many IoT stuff.
I make a separate SSID for those with only WPA2 psk2+ccmp security

5

Well, I never did figure out what changed on the router side of things; but someone suggested updating the firmware on the printers, and that actually fixed the problem. Both printers are now happily on the same standard 2.4GHz network along with the rest of my devices and are working fine.

6

Glad you solved the problem. I basically encountered the exact same problem as yours back in OpenWrt 23.05.5 on a MT7621A router (Linksys EA8100).

My research suggested Brother printer uses mDNS for advertising its presence to rest of the network. So my belief was it definitely had something to do with multicasting (DNS) packet being dropped. Others had argued it was ARP broadcast packet being dropped - I am not very sure since I haven’t been able to do a wireshark traffic capture on that front.

Your workaround to enable 2.4g AP signal with multicast_to_unicast set to 1 was what I found to be working too. Another way is to enable IGMP snooping in the br-lan switch, which seems to achieve a similar result.

However, I have not touched that system since then. Maybe upgrading to OpenWrt 25.12.x would require me reopening the investigation again.