Problem with modem in ZTE MF286R

Found the original thread on LKML - I see no universal solution yet - it seems that we stumbled upon the "false negative" case here, for which we would also need a quirk list.
https://lore.kernel.org/all/CAKfDRXhDp3heiD75Lat7cr1JmY-kaJ-MS0tt7QXX=s8RFjbpUQ@mail.gmail.com/T/

@cezary, could you restart the router a few times, with patch from post 18 applied and, and list the MAC addresses reported by modem? Maybe we can spot some kind of pattern.

usb0      Link encap:Ethernet  HWaddr EA:2C:E3:71:77:6F  
usb0      Link encap:Ethernet  HWaddr E6:20:F1:7F:A5:40  
usb0      Link encap:Ethernet  HWaddr 72:F4:53:55:85:3D  
usb0      Link encap:Ethernet  HWaddr 86:A1:0A:2D:29:88  
usb0      Link encap:Ethernet  HWaddr C6:1D:95:ED:4A:1C 
usb0      Link encap:Ethernet  HWaddr AE:29:A6:5D:61:D4  
usb0      Link encap:Ethernet  HWaddr AA:28:22:CF:EE:36  
usb0      Link encap:Ethernet  HWaddr AE:29:A6:5D:61:D4  
usb0      Link encap:Ethernet  HWaddr AA:28:22:CF:EE:36  
usb0      Link encap:Ethernet  HWaddr BA:2D:10:2B:E2:C2  
usb0      Link encap:Ethernet  HWaddr C6:F6:F7:67:46:7C  
usb0      Link encap:Ethernet  HWaddr 66:47:7D:4E:A9:A0  
usb0      Link encap:Ethernet  HWaddr AA:A5:08:6E:93:05  
usb0      Link encap:Ethernet  HWaddr 6E:9F:8B:D5:6A:EB  
usb0      Link encap:Ethernet  HWaddr 9A:BF:B1:5A:FA:CD  
usb0      Link encap:Ethernet  HWaddr 1E:8C:5F:E8:A5:FF

Wow. This looks bad, really bad. There are two repeating entries found twice, other than that it looks completely random, only with "local" bit set. The only two solutions I see are:

  • find a way to configure the random MAC set by kernel at the modem side somehow,
  • introduce a quirk to actually use the reported local MAC, but not by reported MAC of course, but using USB ID, if that's even possible.

Edit: @cezary, maybe we could set up a Wireguard tunnel to that router (over wired WAN of course) somehow, so I could play around with that modem. What do you think?

I made a minor update here: https://github.com/Leo-PL/openwrt/tree/zte_mf286r_modem
Some fixes for comgt-ncm which allow the modem to connect, even with the variant exposing both RNDIS and CDC-ECM interfaces simultaneously, plus the kernel hack.
@bmork, @chunkeey, do you think that introducing a quirk per modem's USB ID, to accept the locally-administered MAC is a viable solution?

We could also set the MAC over ADB interface, through which modem exposes its root shell, but this would be really, really crude. It's based on old OpenWrt fork, probably CC, but with a lot of custom stuff, like AT command parser, etc. I've gathered a lot of information for reverse-engineering it, though, I don't own such a device myself.

I think we should go back to accepting any mac address from rndis devices, and only implement a quirk for the original ZTE MF910 problem. There is no reason we shouldn't accept those random addresses if that's required to make this modem work.

I fear this is only the top of the ice berg. There are probably many modems with similar firmware. This is not the kind of bug report that gets through. Most users give up long before sending an email to the netdev list...

But this is only my opinion, of course. The decision is up to Jakub or David.

Ok then, I'll prepare a RFC patch in that fashion soon-ish, and make sure to CC you and everyone necessary on LKML. If this way isn't accepted, we can always go back to adding quirk to MF286R instead of MF910.

Edit: And when digging around, I found this: https://lore.kernel.org/lkml/1468844691-8222-1-git-send-email-kristian.evensen@gmail.com/
Came looking for copper, and found gold. The same thing can probably be applied to fix MF286R as well if the MAC fixup from cdc_ether is ported to rndis_host. I whipped up a RFC patch here: https://github.com/Leo-PL/openwrt/commit/1b875ae9e9d13cc3761b912fb1267db536d009a3
Do you think this approach makes sense? In the meantime, I asked folks at eko.one.pl to do some testing.

Edi2: @faloyeh, you might want do do some tesitng. If it works for you, I'll go forward with upstreaming this to the kernel and to OpenWrt as well. I updated the link above, previously the interface to match the modem with ZTE quirks was wrong.

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_VENDOR_AND_INTERFACE_INFO(0x19d2,
                                     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.

Kristian

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 */
	USB_VENDOR_AND_INTERFACE_INFO(0x19d2,
				      USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
	.driver_info = (unsigned long)&zte_rndis_info,

Whole patch for kernel is here: https://github.com/Leo-PL/openwrt/commit/9ff9bc75dd0a2318e21cc2bf56b08bd590c8c87f
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: https://tplinkforum.pl/t/tl-mr3220-v2-1-i-zte-mf823-nie-chca-wspolpracowac/6821/9

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 kern.info 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 kern.info 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 kern.info 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 daemon.info 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 daemon.info [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 daemon.info [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 daemon.info [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 daemon.info [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 daemon.info [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 daemon.info [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 priority@pcislocked.net. 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:

See https://firmware-selector.openwrt.org/?version=22.03.0&target=ath79%2Fnand&id=zte_mf286r

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