Bug 263783 - USB MBIM: Support for LTE/4G USB modems (MBIM)
Summary: USB MBIM: Support for LTE/4G USB modems (MBIM)
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-usb (Nobody)
URL:
Keywords: feature, needs-qa
Depends on:
Blocks:
 
Reported: 2022-05-05 07:00 UTC by Pierre Pronchery
Modified: 2024-05-21 04:40 UTC (History)
16 users (show)

See Also:
pi: maintainer-feedback-
koobs: mfc-stable13?


Attachments
umb(4), umbctl(8), OPNsense plug-in (36.08 KB, application/x-gzip)
2022-05-05 07:00 UTC, Pierre Pronchery
no flags Details
0001-Introduce-the-USB-umb-4-network-driver.patch (144.15 KB, patch)
2024-04-30 19:24 UTC, Pierre Pronchery
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Pronchery 2022-05-05 07:00:25 UTC
Created attachment 233735 [details]
umb(4), umbctl(8), OPNsense plug-in

Dear FreeBSD developers,

I have just been authorised to publish the source code of the implementation of a kernel driver, support binary, and OPNsense plug-in for USB MBIM interfaces, as offered by some LTE/4G USB modems.

The original code was taken from the OpenBSD project, where it is known as the umb(4) driver. I had already ported this code pretty much as-is for NetBSD, as umb(4) as well, and added the support binary umbctl(8) (instead of ifconfig) when I was contracted by ADISTA SAS (https://www.adista.fr) to create a version for FreeBSD, suitable for deployment in OPNsense. While I originally based this effort on the OpenBSD and NetBSD versions, this required heavy changes to the kernel driver; the name is still umb(4), completed with an extended version of umbctl(8) (with JSON output).

I am therefore glad to upload this version here as an attachment, with the additional copyright and license information as requested by ADISTA. I believe these terms are fully compatible with the original license terms (3-clause BSD) and with FreeBSD's own license terms, adding ADISTA's own copyright/credit where applicable.

You are welcome to adapt, test, and integrate this code into FreeBSD's latest development branch and releases. Let me know if you would need any additional help from my side.

HTH,
-- Pierre Pronchery <pierre@defora.net> for ADISTA (aka khorben@NetBSD.org)
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-05 23:55:36 UTC
Thank you for the report Pierre. Can you confirm/detail what version of FreeBSD the code was built/tested again? Also, is this something you can usher (either drive, or support with questions, etc) into the kernel via a differential/review via Phabricator?

@Hans Are you able to assist here?
Comment 2 Hans Petter Selasky freebsd_committer freebsd_triage 2022-05-06 09:26:28 UTC
Hi,

I can help do review.

We probably want to have this piece of code in base and not in ports.

Can you upload the base code to https://reviews.freebsd.org and add hselasky at least.

--HPS
Comment 3 mike 2022-05-09 15:09:09 UTC
(In reply to Pierre Pronchery from comment #0)

Thanks for publishing this!  I was going to give it a try with a MC7700 modem, but the driver doesnt seem to attach. I put the device into MBIM mode (I think)

AT!ENTERCND="A710"
OK
AT!UDPID=68A2
OK
AT!RESET
OK

It comes back as 

ugen2.3: <Sierra Wireless, Incorporated MC7700> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (0mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1199 
  idProduct = 0x68a2 
  bcdDevice = 0x0006 
  iManufacturer = 0x0003  <Sierra Wireless, Incorporated>
  iProduct = 0x0002  <MC7700>
  iSerialNumber = 0x0004  <012810001234846>
  bNumConfigurations = 0x0001 

(instead of 0x68a3 where u3g attached to the device)

But when I load if_umb, no new devices or interfaces get created nor is there anything in dmesg.  This is on RELENG13 if that makes a difference.
Comment 4 mike 2022-05-09 15:37:29 UTC
Made it a little farther on RELENG_13. With a MC7455, I did the following

at!entercnd="A710"
at+cpin?
at!custom="IPV6ENABLE",1
at+cgdcont=1,"ipv4v6","myapn"
at!usbcomp = 1,1,1009
at!reset


Then booting it starts to attach, but I get a panic

umb0 on uhub4
umb0: <Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm Snapdragon X7 LTE-A, class 0/0, rev 2.10/0.06, addr 3> on usbus2
umb0: version 1.0
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x28
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff8075c134
stack pointer           = 0x28:0xfffffe0061bf7e50
frame pointer           = 0x28:0xfffffe0061bf7e80
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 15 (umb0)
trap number             = 12
panic: page fault
cpuid = 0
time = 1652110164
KDB: stack backtrace:
#0 0xffffffff806986f5 at kdb_backtrace+0x65
#1 0xffffffff8064ba2f at vpanic+0x17f
#2 0xffffffff8064b8a3 at panic+0x43
#3 0xffffffff80997f15 at trap_fatal+0x385
#4 0xffffffff80997f6f at trap_pfault+0x4f
#5 0xffffffff80971088 at calltrap+0x8
#6 0xffffffff8120b7b7 at umb_attach_task+0x37
#7 0xffffffff804d0880 at usb_process+0x100
#8 0xffffffff8060931e at fork_exit+0x7e
#9 0xffffffff809720fe at fork_trampoline+0xe



Same if I manually load it

 kldload ./if_umb.ko
umb0 on uhub4
umb0: <Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm Snapdragon X7 LTE-A, class 0/0, rev 2.10/0.06, addr 3> on usbus2
umb0: version 1.0
#

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x28
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff8075c134
stack pointer           = 0x28:0xfffffe008a186e50
frame pointer           = 0x28:0xfffffe008a186e80
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 15 (umb0)
trap number             = 12
panic: page fault
cpuid = 2
time = 1652110585
KDB: stack backtrace:
#0 0xffffffff806986f5 at kdb_backtrace+0x65
#1 0xffffffff8064ba2f at vpanic+0x17f
#2 0xffffffff8064b8a3 at panic+0x43
#3 0xffffffff80997f15 at trap_fatal+0x385
#4 0xffffffff80997f6f at trap_pfault+0x4f
#5 0xffffffff80971088 at calltrap+0x8
#6 0xffffffff815357b7 at umb_attach_task+0x37
#7 0xffffffff804d0880 at usb_process+0x100
#8 0xffffffff8060931e at fork_exit+0x7e
#9 0xffffffff809720fe at fork_trampoline+0xe
Comment 5 Pierre Pronchery 2022-05-11 10:50:35 UTC
(In reply to Kubilay Kocak from comment #1)

Hi Kubilay,

The code was built and tested with FreeBSD 11.2 (targeting OPNsense 19.7).
Comment 6 Pierre Pronchery 2022-05-11 15:23:50 UTC
(In reply to mike from comment #4)

I suspect the kernel does not like to attach the same device twice.
Is there a way in FreeBSD to detach a device? (drvctl in NetBSD)
If yes, can you try again after detaching the existing driver?

In my development environment, the MBIM card was configured to go straight into MBIM mode, and not expose other interfaces.

I cannot look deeper into this issue at the moment, I no longer have the corresponding equipment ready.
Comment 7 mike 2022-05-12 14:32:34 UTC
(In reply to Pierre Pronchery from comment #6)
Hi, I did actually try and remove u3g.ko and usie.ko which both try to attach so that only your kld attached, but still a crash.
Comment 8 Hans Petter Selasky freebsd_committer freebsd_triage 2022-05-12 14:39:07 UTC
Maybe there is a missing drain/flush of that callback function?
Comment 9 Marcel 2022-05-16 18:28:50 UTC
Hey everybody! 

These are amazing news for FreeBSD and my usecase!
I did want to use my card with pfSense or OPNsense, but did not get anywhere in 2018. I ended up using the ISP router in bridge mode or running OpenWRT on x86_64, both isn't the best and I've had many issues along the way.

I would like to help as much as possible, as I have a build system for the current version OPNsense 22.1.6 ready (FreeBSD 13) and a Sierra Wireless EM7565 WWAN card.
I was able to build everything and install it, but I do not see the WWAN card connected correctly (no cuaU0 entry). It should be in MBIM mode, as I used it this way with OpenWRT last time.

Please see the logs (build is in the FreeBSD VM, the rest on my OPNsense router):
Build: https://pastebin.com/ruY16esu
usbconfig dump: https://pastebin.com/754P7CLV
ls /dev/: https://pastebin.com/MMZi2GGF
dmesg: https://pastebin.com/2YUFvBpS
kldstat: https://pastebin.com/5ViikMzq

Note: If this is not fitting here, I will wait for the release ;)

Have a nice day! 
- Marcel
Comment 10 Pierre Pronchery 2022-05-16 21:32:04 UTC
(In reply to Marcel from comment #9)

Hi Marcel,

If your card is solely in MBIM mode, it is perfectly normal and expected that it will not cause a cuaU0 to appear. It should expose a network interface instead (umb0). You can then use ifconfig(8) and umbctl(8), as provided, in order to configure and use the network connection.

HTH,
-- Pierre Pronchery
Comment 11 Marcel 2022-05-17 18:28:59 UTC
(In reply to Pierre Pronchery from comment #10)
Thank you for the fast response and sorry for mixing up the modes with communication port or without it.

In the last post I forgot to add the ifconfig output and what I tried with umbctl.

ifconfig: https://pastebin.com/2GcqE2jH
umb:
Command:  umbctl umb0
Response: umbctl: umb0: Device not configured
Command:  umbctl umb0 apn drei.at username no password no
Response: umbctl: umb0: Device not configured

As you see, no response and no entry in the list.
Any ideas?
Comment 12 hendrik 2022-10-29 12:36:40 UTC
Same issue here using a Sierra Wireless EM7565.
After some research I actually found a way to "detach" a device using the "set_config 255" flag for usbconfig:

> The special value of 255 unconfigures the device, detaching the interface drivers and reducing the power consumption to minimum, but without going into power saving mode or detaching from the bus.

I'm now able to load the kernel module without a crash (kldload if_umb) however no new network interface umb0 is created. "show_ifdrv" also shows no driver attached.
usbconfig also provides a "detach_kernel_driver" flag:

> Detach kernel driver for the selected interface and USB device.

Using this the kernel still crashes.
Comment 13 Hans Petter Selasky freebsd_committer freebsd_triage 2022-10-29 15:31:41 UTC
Can you obtain the so-called backtrace of that panic?
Comment 14 hendrik 2022-10-29 17:26:44 UTC
(In reply to Hans Petter Selasky from comment #13)

umb0 on uhub2
umb0: <Sierra Wireless, Incorporated MC7455, class 0/0, rev 2.10/0.06, addr 3> on usbus3
umb0: version 1.0


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address   = 0x28
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80d2cdc4
stack pointer           = 0x28:0xfffffe011db43e50
frame pointer           = 0x28:0xfffffe011db43e80
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 15 (umb0)
trap number             = 12
panic: page fault
cpuid = 4
time = 1667064094
KDB: stack backtrace:
#0 0xffffffff80c694a5 at kdb_backtrace+0x65
#1 0xffffffff80c1bb5f at vpanic+0x17f
#2 0xffffffff80c1b9d3 at panic+0x43
#3 0xffffffff810afdf5 at trap_fatal+0x385
#4 0xffffffff810afe4f at trap_pfault+0x4f
#5 0xffffffff81087578 at calltrap+0x8
#6 0xffffffff82b0c7b7 at umb_attach_task+0x37
#7 0xffffffff80a36bd0 at usb_process+0x100
#8 0xffffffff80bd8a9e at fork_exit+0x7e
#9 0xffffffff810885ee at fork_trampoline+0xe
Comment 15 hendrik 2022-10-29 17:46:48 UTC
(In reply to hendrik from comment #14)
kgdb backtrace:

#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:399
#2  0xffffffff80c1b75c in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487
#3  0xffffffff80c1bbce in vpanic (fmt=0xffffffff811b4fb9 "%s", ap=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:920
#4  0xffffffff80c1b9d3 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:844
#5  0xffffffff810afdf5 in trap_fatal (frame=0xfffffe011db43d90, eva=40) at /usr/src/sys/amd64/amd64/trap.c:944
#6  0xffffffff810afe4f in trap_pfault (frame=0xfffffe011db43d90, usermode=false, signo=<optimized out>, ucode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:763
#7  <signal handler called>
#8  0xffffffff80d2cdc4 in if_alloc_domain (type=250 '\372', numa_domain=<optimized out>) at /usr/src/sys/sys/sx.h:166
#9  0xffffffff82b0c7b7 in umb_attach_task () from /boot/modules/if_umb.ko
#10 0xffffffff80a36bd0 in usb_process (arg=arg@entry=0xfffff8012907d078) at /usr/src/sys/dev/usb/usb_process.c:178
#11 0xffffffff80bd8a9e in fork_exit (callout=0xffffffff80a36ad0 <usb_process>, arg=0xfffff8012907d078, frame=0xfffffe011db43f40) at /usr/src/sys/kern/kern_fork.c:1093
#12 <signal handler called>
#13 mi_startup () at /usr/src/sys/kern/init_main.c:322
#14 0x0000000000000000 in ?? ()
Comment 16 Hans Petter Selasky freebsd_committer freebsd_triage 2022-10-29 18:10:50 UTC
Right, this driver is not in base yet, and needs a review. Please upload it for review first. Maybe the panic will be fixed.

--HPS
Comment 17 andrey.kiselev 2023-01-07 15:48:58 UTC
(In reply to hendrik from comment #14)
I can confirm panic on OPNSense 22.7.10_2 (OpenSSL). My module is LT4112 and panik happens when I put it into MBIM config. Here are some details:

umb0 on uhub2
umb0:  on usbus0
umb0: version 1.0


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x28
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff80dbed44
stack pointer	        = 0x28:0xfffffe006abeae50
frame pointer	        = 0x28:0xfffffe006abeae80
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 15 (umb0)
trap number		= 12
panic: page fault
cpuid = 0
time = 1673105862
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe006abeac10
vpanic() at vpanic+0x17f/frame 0xfffffe006abeac60
panic() at panic+0x43/frame 0xfffffe006abeacc0
trap_fatal() at trap_fatal+0x385/frame 0xfffffe006abead20
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe006abead80
calltrap() at calltrap+0x8/frame 0xfffffe006abead80
--- trap 0xc, rip = 0xffffffff80dbed44, rsp = 0xfffffe006abeae50, rbp = 0xfffffe006abeae80 ---
if_alloc_domain() at if_alloc_domain+0xa4/frame 0xfffffe006abeae80
umb_attach_task() at umb_attach_task+0x37/frame 0xfffffe006abeaeb0
usb_process() at usb_process+0x100/frame 0xfffffe006abeaef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe006abeaf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe006abeaf30
--- trap 0xcb1bc018, rip = 0xffffffff80c313af, rsp = 0, rbp = 0xfffff8000355d200 ---
mi_startup() at mi_startup+0xdf/frame 0xfffff8000355d200
??() at 0/frame 0xfffff8000353c000
null_method() at null_method/frame 0xffffffff81b03fb0
bus_generic_new_pass() at bus_generic_new_pass/frame 0xffffffff81b03fa8
bus_new_pass_desc() at bus_new_pass_desc
KDB: enter: panic
panic.txt0600001214356310706  7136 ustarrootwheelpage faultversion.txt0600007414356310706  7541 ustarrootwheelFreeBSD 13.1-RELEASE-p5 stable/22.7-n250270-9d1c26e8548 SMP
Comment 18 Alexander Burke 2023-11-19 10:59:02 UTC
Has there been any movement on this that isn't reflected here? I have a Sierra EM7355 which I'd be happy to tinker with on 14.0-RELEASE, if that would help, or I could ship a card to one of the developers.
Comment 19 Pierre Pronchery 2023-11-19 13:29:35 UTC
(In reply to alex-freebsd-bugs from comment #18)

Not on my side recently, sorry. I still have in mind to make it work again though, any help appreciated!
Comment 20 Kurt Jaeger freebsd_committer freebsd_triage 2024-01-13 18:01:42 UTC
(In reply to alex-freebsd-bugs from comment #18)
unfortunatly, hps died a few month ago, so the usb code in freebsd is
in need of a new care taker.
Comment 21 Warner Losh freebsd_committer freebsd_triage 2024-01-13 18:05:24 UTC
I've added myself as a cc. Please try it on 14.0. If it works I'll review and commit
Comment 22 Maurice Walker 2024-01-16 17:08:57 UTC
I've tested this on FreeBSD 13.2-RELEASE-p7 with an Alcatel IK41VE. This modem is in permanent MBIM mode, no mode switch required. If it's already plugged in before power on, the kernel panics during boot. If it's not plugged in, the system boots normally. When the modem is then hot-plugged, the system crashes and reboots within seconds.

I have several of these LTE modems and would gladly send one to whomever wants to work on this.

Cheers
Maurice
Comment 23 Pierre Pronchery 2024-04-30 19:17:15 UTC
I have just published a branch for freebsd-src.git at https://github.com/khorben/freebsd-src/tree/khorben/umb, with the patch adapted for direct integration in this repository. I have only built-tested this code so far.
Comment 24 Pierre Pronchery 2024-04-30 19:24:03 UTC
Created attachment 250309 [details]
0001-Introduce-the-USB-umb-4-network-driver.patch

The current diff for https://github.com/khorben/freebsd-src/tree/khorben/umb.