After one day of testing - without this test, the modem works, but it freezes very often (no transmission, no response on serial port, etc.). Cutting off power helps.
Oh, sorry. That bp[0] Bit 2 does have a special meaning. Vendors producing "real" devices should not set this, it's reserved for exactly not that purpose (although this isn't as bad as a set broadcast bit).
Ideally this would be fixed in rndis_host upstream. Thing is: how? Is it possible to just sent an object with the randomly assigned ethernet mac back to the device? Or is some AT&T magic required since this is a modem. I do not know.
This doesn't sound very encouraging. I guess I'll dig into history of rndis_host then. Patching the modem itself is totally out of question, even though it runs an OpenWrt fork itself (lol).
Yes, that was why I once thought that code made sense.
But "should not" means nothing to most firmware developers.... So what if a device set that bit? Then we break it for no good reason, unless the device happens to cope with the random address we choose. And some of them won't do that, as demostrated by this discussion.
Another point is that I'm not convinced setting the bit is necessarily wrong in this case. The address might be a random one generated by the device. Which would be fine. This is just for a fake ethernet headers on the USB link between modem and host anyway. There's not going to be any other ethernet device there. We could consider bridging, but that won't really work in general since there can only ever be one IPv4 client behind the modem. Callng a random addess "permanent" is of course wrong, but IIUC that's the only interface we support for address exchange between host and device.
In short: I believe we should drop that part of the rndis_host driver. But it came to be as a simplified fix for an ethernet device using a hard coded address. We still need to have a fix for that.
Yes, random mac address every reboot.
yes, having that local bit set or not is of course not an issue as far as the stack is concerned. The eth_hw_addr_random() sets it as well (eth_hw_addr_random is used a lot)...
From what I understand, that the rndis_host compatible firmware of the modem has no way of updating the fake mac. So you could "break" it accidentally by doing ip link set modem address 02:03:04:05:06. In effect you would also need invent and add a quirk flag to the driver in order to prevent anyone from updating the fake mac? So, you end up with yet another thing because of that. (Or is this not a issue?
rndis_host uses eth_mac_addr() for .ndo_set_mac_address, so I would expect this to be the case since eth_mac_addr() is very generic, it just sets it in the net_device struct)
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..
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