Problem with modem in ZTE MF286R

One more thing: does anyone here have MF823/MF831/MF910, and could share output of cat /sys/kernel/debug/usb/devices for them? rndis_host can match drivers for two classes, one of them being USB_CLASS_WIRELESS_CONTROLLER like here:

       /* ZTE WWAN modules */
                                     USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
       .driver_info = (unsigned long)&zte_rndis_info,

Which is the one I'd like to match against, but I'm not sure if the modems I mentioned don't report the other one - to avoid regression.
Chiming in @kristrev as the author of original patches.

I will give it a try, let's see how far I can get..

@kristrev @bmork kind reminder, it seems that Discourse doesn't notify on post edits.

Hi @Leo-PL,

I am happy to see that MF823 & Co are still in use. While I haven't touched any of those modems in years (USB-dongles aren't really used in Norway any more), I still have a sweet spot for them. A lot of time was spent on making the modules play nice.

I don't have an opinion on the correct solution for rndis_host (its been a while since I looked at that driver), the issue I experienced with cdc_ether was similar to what you experience. The dongle would accept traffic from any source mac address, but a static destination mac address was used on all traffic sent from the dongle. And because the destination mac does not match that of the device, the Linux kernel discards the traffic.

Going through my old notes, when I worked with these devices then rndis_host used the updated destination MAC address (also for MF823) and that is why I didn't add an rx_fixup (or another fix) to that driver. If you would like to apply a temporary fix and avoid updating the driver for now, you can try to change the device type that the modem exports. The REST API has a hidden URL allowing you to control/force the device type. I don't know if the URL/API-call still works, but I described it in a blog-post I wrote.


Hi Kristian,
I asked about MF823 et al, to avoid regression for them, as I wanted to limit the scope of workaround to just ZTE modems. Issue with MF286R which I encountered is, that it does not use the updated MAC address, just as MF823/MF910 did on RNDIS.

Is there any chance you still have any of those dongles, and could show the interface descriptors they report via /sys/kernel/debug/usb/devices? Thing with RNDIS is, that it can bind two types of interfaces: one of type "CDC" with subclass 2, and the second one, like here, typically used for WWAN style devices:

	/* ZTE WWAN modules */
	.driver_info = (unsigned long)&zte_rndis_info,

Whole patch for kernel is here:
Maybe it is safer to just bind this to both interface types, actually, if we can't determine what dongles report.

As for switching interface type, MF286R's internal modem, does not expose a web interface, but maybe there is an AT command to manipulate that. Some of them expose both, but funnily enough, activating a connection through standard way, does it on RNDIS part - I looked inside through ADB, and ECM gadget isn't added to the internal bridge, like RNDIS gadget. I really wonder what the authors of the firmware did to break it, because the modem itself is running an OpenWrt fork, and Linux RNDIS gadget should handle MAC updates just fine - the same is true for ECM gadget.

Edit: Indeed it seems, that I need to bind both types of RNDIS interfaces, as I found this example for MF823 here:

T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1403 Rev=f0.70
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE WCDMA Technologies MSM
S:  SerialNumber=MF8230ZTED000000
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=(none)
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

This one shows as 02/02/ff, while MF286R's internal modem shows up as e0/01/03, as noted above. I'll update the patchset and send it upstream, then.

I've been using both RC6 and the latest snapshot, but I'm experiencing modem instability. I've noticed very limited uptimes of the router and it seems that it reboots every few hours after the modem gets disconnected.

Fri Aug 19 23:30:59 2022 kernel: [15399.291123] usb 1-1: USB disconnect, device number 2
Fri Aug 19 23:30:59 2022 daemon.notice netifd: Network device 'usb1' link is down
Fri Aug 19 23:30:59 2022 daemon.notice netifd: Network alias 'usb1' link is down
Fri Aug 19 23:30:59 2022 daemon.notice netifd: Interface '4gwan_4' has link connectivity loss
Fri Aug 19 23:30:59 2022 kernel: [15399.299881] rndis_host 1-1:1.0 usb1: unregister 'rndis_host' usb-1b000000.usb-1, ZTE RNDIS device
Fri Aug 19 23:30:59 2022 kernel: [15399.325379] cdc_ether 1-1:1.6 usb0: unregister 'cdc_ether' usb-1b000000.usb-1, ZTE CDC Ethernet Device
Fri Aug 19 23:31:00 2022 ModemManager[25173]: hotplug: remove network interface usb1: event processed
Fri Aug 19 23:31:00 2022 daemon.debug ModemManager[25173]: hotplug: event reported: action=remove, name=usb1, subsystem=net

And this unprovoked crash, which did not result in a reboot.

Sat Aug 20 09:28:19 2022 [3090]: <info>  [base-manager] couldn't check support for device '/sys/devices/platform/ahb/19000000.eth': not supported by any plugin
Sat Aug 20 09:28:20 2022 [3090]: <info>  [base-manager] couldn't check support for device '/sys/devices/platform/ahb/18100000.wmac': not supported by any plugin
Sat Aug 20 09:28:20 2022 [3090]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:00.0': not supported by any plugin
Sat Aug 20 09:28:25 2022 [3090]: <info>  [device /sys/devices/platform/ahb/1b000000.usb/usb1/1-1] creating modem with plugin 'zte' and '3' ports
Sat Aug 20 09:28:26 2022 daemon.warn [3090]: <warn>  [plugin/zte] could not grab port usb1: Ignoring net port in ZTE modem
Sat Aug 20 09:28:26 2022 daemon.warn [3090]: <warn>  [plugin/zte] could not grab port usb0: Ignoring net port in ZTE modem
Sat Aug 20 09:28:26 2022 [3090]: <info>  [base-manager] modem for device '/sys/devices/platform/ahb/1b000000.usb/usb1/1-1' successfully created
Sat Aug 20 09:28:28 2022 daemon.warn [3090]: <warn>  [modem0] couldn't load unlock retries: Unknown error
Sat Aug 20 09:28:28 2022 daemon.warn [3090]: <warn>  [modem0/sim0] couldn't load list of emergency numbers: Failed to parse CRSM query result '+CRSM: 105,129'
Sat Aug 20 09:28:29 2022 [3090]: <info>  [modem0] state changed (unknown -> disabled)

Modem version is BD_MF286RMODULEV1.0.0B04.

Um... yeah. The modem in MF286R is somewhat unstable under OpenWrt according to reports I was hearing recently. I don't own the device (only MF286{,A,D}), nor do I use ModemManager with it, so it seems I can't help much.
The only thing I can recommend is to ensure that your modem FW is most up-to-date available, by upgrading stock FW before installing OpenWrt.

1 Like

Hi. Please add support for MF286C too.

How am I supposed to do that? I don't own the device and it's not available at all in my region. Let alone the fact, that there is an ath79 variant and mt7621 variant in the wild, with same appearance.

Hi. Just wanted to drop a message after seeing recent activity.

I own a ZTE MF286R for more than a year, and used it with my operator's(Turkcell) stock firmware, as well as some other vendor(TMobile poland) firmware i found on some random italian forum. It is overall a nice device, but stock vendor firmare I use is really restrictive, and the other vendor firmware does not work with LTE-A somehow so I reverted to stock firmware. I currently use it as a dumb AP, and did some googling on this device and a random blog post explaining an exploit which gave me telnet access on router. Then did some more googling and found -and read all messages on- this forum post.

In short I want to ask that if there's any intention to release openwrt for this device, and if there is, what's the progress, and is there anything I can do to contribute? (i'm not a developer or anything but i think i can pull off some technical stuff on this device if instructed)

ps: If I forget about this forum and for some reason and you really need to contact me, shoot me an email at But I'll check back in via mail notifs i guess.

What? MF286R is fully supported - router, modem etc. Just install and use it.

Are you sure, because I am sure I looked up "zte mf286r openwrt" multiple times today and past, and now too, and didn't see any. Also checked the official hardware table here but sadly couldn't see MF286R. Maybe you're talking about MF286D, a differrent device with differrent LTE modem.

I am sorry if it is something obvious that I can't just see..

PS: if it requires some compiling or something, I can probably pull that off, I don't really want to look like I am asking for too much. Just show me something to follow and I'll happily install and test everything

Yes, sure, I have one :slight_smile:


No, it doesn't require recompilation.

1 Like

OMG You made my day literally! Thank you so much, I'll (hopefully) install and use it when I'm back home. Thanks again.

Now I'm wondering why it's nowhere to be found on official hardware table or via google. Probably wiki needs updating or sth.

Also, after I test it a bit, I will probably publish this fw to the turkish forums where I know a lot of users of this specific box, mostly users of Turkcell Superbox service.

Thanks again. Really. cuz stock fw is bad, and turkcell fw is worse lol

For installation read

1 Like

I will check it out when I start installing the fw this night, I can't just pull it out at the moment until I put a replacement AP on the second floor for the meanwhile. Will probably come back here after install. Thanks

Hi. Uhh, I got the root shell, and backed up the original FW to a flash drive, then put firmware on another(both fat32). After issuing the nandwrite command, replacing the firmware mtd according to the cat output, I got this error;
hobb ss aldim 517

Since I already have the backups, I think i'll try the 3rd method.(edit: couldnt figure out how to "deliberately wipe the kernel") Any other suggestions?

Just power-cycling the router before another attempt should be enough - some process (possibly stock FW) may have locked some pages in that partition.
If this doesn't help then you can proceed with method 3. By "deliberately wipe the kernel" I meant using flash_erase command on that MTD node.

1 Like

Until now, nobody has created a dataentry for the MF286R. Without dataentry, it will not show up in the ToH.

If someone wants to create a dataentry: (need to be logged in to the wiki in order to access this page).

1 Like

Tried that, tried flashing t-mobile poland firmware via official tools(tmobile poland firmware DOES NOT have the url exploit one way or other) and back to turkcell, that didn't help either. I'll buy a TTL cable or borrow from my dormmates within today to trying again, just to be on the safe side.