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)
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?
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
(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.
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
(In reply to Kubilay Kocak from comment #1) Hi Kubilay, The code was built and tested with FreeBSD 11.2 (targeting OPNsense 19.7).
(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.
(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.
Maybe there is a missing drain/flush of that callback function?
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
(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
(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?
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.
Can you obtain the so-called backtrace of that panic?
(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
(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 ?? ()
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
(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
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.
(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!
(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.
I've added myself as a cc. Please try it on 14.0. If it works I'll review and commit
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
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.
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.
(In reply to Pierre Pronchery from comment #24) This looks good.... I'd like to commit this... I don't see a umb(4) man page in the latest set of attachments. Did I miss something?
Created attachment 251587 [details] 0001-Introduce-the-USB-umb-4-network-driver.patch
(In reply to Warner Losh from comment #25) I am updating the patch, adding the manual page I had adapted for NetBSD. I haven't build-tested it yet for any missing steps for integration, and I am not yet familiar with possible differences for manual pages in FreeBSD compared to NetBSD. Unfortunately in my latest tests, the driver still panics when attaching, and if I remember right it happens in if_mediainit() when initialising a list. (I do not have access to the hardware of to my notes at the moment, sorry)
(In reply to Pierre Pronchery from comment #27) Pierre, I can provide access to a VM with a modem attached if that would help development.
(In reply to Matt Latin from comment #28) Thanks; I have working hardware now, but the driver crashes upon initialisation and I simply do not understand why. Any ideas welcome.
(In reply to Pierre Pronchery from comment #29) I'll do some testing on my end to see if I can potentially figure it out.
^Triage: clear unneeded flags. Nothing has yet been committed to be merged.
`if_alloc()` never fails. All supported branches ( main, stable/14, stable/13 ) now have the same behavior. So no need to do NULL check any more. ``` sc->sc_if = ifp = if_alloc(IFT_MBIM); - if (ifp == NULL) { - device_printf(sc->sc_dev, "Could not allocate a network interface\n"); - goto fail; - } ``` FYI https://reviews.freebsd.org/D45740 .
If we juggle the Nd a bit in umbctl.8, we can get "cellular modem" in the description keeping the complete listing within a standard console line, which would allow for discoverability via "apropos cellular" or "apropos modem". Rendered: "umbctl(8) - display or set MBIM cellular modem interface parameters (4G/LTE)"
Created attachment 255103 [details] 0001-Introduce-the-USB-umb-4-network-driver.patch - Remove useless check for NULL in umb_attach_task() - Update the title of umbctl(8) as suggested
For the backtrace, > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x28 ... > 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 A quick look at `usb_process()` and `umb_attach_task()`, I suspect that the vnet is not correctly set. With the option INVARIANTS or VNET_DEBUG on, the recent change [1] ( has been MFCed to stable/14 and stable/13 branches ) can easily spot that. I do not have hardware to test. Can someone re-test the driver against latest main or stable branches ? 1. https://cgit.freebsd.org/src/commit/?id=d1d839d0b593541174ca48c675c9eff4ddb4715e
I am willing to buy hardware to test this, what are the most recommended modules? I have a full size mPCIe slot, but I am willing to get adapters.
(In reply to Alexander Ziaee from comment #36) My test hardware is the Sierra Wireless MC7304, but anything supporting the MBIM protocol should work and is in scope.
I have Panasonic Toughbook CF-MX4 (can be purchased low price now) with Sierra Wireless EM7305 and can help testing :-) I have another broken one maybe I could resurrect it for remote SSH access for development if anyone is interested :-)
(In reply to Zhenlei Huang from comment #35) Thanks for the hint about VNET, I have now added this to the code: > CURVNET_SET_QUIET(vnet0); just before calling if_alloc(), and I get a different panic: > # umb0: version 1.0 > panic: _mtx_lock_sleep: recursed on non-recursive mutex umb0 @ /home/khorben/Projects/FreeBSD/src/sys/dev/usb/net/if_umb.c:1022 > > cpuid = 2 > time = 1732160066 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00688e3ba0 > vpanic() at vpanic+0x136/frame 0xfffffe00688e3cd0 > panic() at panic+0x43/frame 0xfffffe00688e3d30 > __mtx_lock_sleep() at __mtx_lock_sleep+0x482/frame 0xfffffe00688e3dc0 > __mtx_lock_flags() at __mtx_lock_flags+0xd8/frame 0xfffffe00688e3e10 > umb_newstate() at umb_newstate+0x11b/frame 0xfffffe00688e3e50 > umb_get_response_task() at umb_get_response_task+0x3c/frame 0xfffffe00688e3ec0 > usb_process() at usb_process+0xf0/frame 0xfffffe00688e3ef0 > fork_exit() at fork_exit+0x82/frame 0xfffffe00688e3f30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00688e3f30 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 15 tid 100182 ] > Stopped at kdb_enter+0x33: movq $0,0x1057302(%rip) I'm investigating further.
(In reply to Pierre Pronchery from comment #39) > panic: _mtx_lock_sleep: recursed on non-recursive mutex I'm not sure if the following is proper for drivers, but you may give it a try, ``` static int umb_attach(device_t dev) { ... - mtx_init(&sc->sc_mutex, device_get_nameunit(dev), NULL, MTX_DEF); + mtx_init(&sc->sc_mutex, device_get_nameunit(dev), NULL, MTX_DEF | MTX_RECURSE); ... } ```
I think it was a matter of avoiding a sleep when holding a mutex, more than about the ability to lock the mutex recursively. With this in mind, I have updated the working copy of the patch on GitHub at https://github.com/freebsd/freebsd-src/compare/main...khorben:freebsd-src:khorben/umb with a version that no longer crashes when attaching. (For me at least) > umb0 on uhub4 > umb0: <Sierra Wireless, Incorporated product 0x68c0, class 0/0, rev 2.00/0.06, addr 3> on usbus2 > umb0: version 1.0 > umb0: bpf attached Unfortunately I am not able to confirm that it works yet: > # ifconfig umb0 > umb0: flags=1008811<UP,POINTOPOINT,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 > options=0 > media: <unknown type> > status: > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > # umbctl umb0 > umb0: state down, mode unknown, registration unknown > provider "", dataclass none, signal #-999 > phone number "", roaming "" (denied) > APN "", TX 0, RX 0 > firmware "", hardware "" This is after entering the pin code with "umbctl umb0 pin 1234" as per usual, with no success so far.
Created attachment 255765 [details] 0001-Introduce-the-USB-umb-4-network-driver.patch After reviewing the whole driver for the proper use of mutexes, this no longer crashes for me. I do not have a valid spare physical SIM at the moment to complete my tests; can someone confirm if this works? What I get at the moment: # ifconfig umb0 umb0: flags=1008811<UP,POINTOPOINT,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 media: <unknown type> status: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> umb0: state radio on, mode automatic, registration not registered provider "", dataclass GPRS, signal #-999 phone number "", roaming "" (allowed) APN "internet.t-mobile", TX 0, RX 0 firmware "SWI9X15C_05.05.58.00", hardware "MC7304"
(In reply to Pierre Pronchery from comment #42) Do you know what the AT+ command is to put the modem in that mode ? I have a number of Sierra Wireless units here I can test with (7354,7700,7455)
(In reply to mike from comment #43) I would try the following: ATV1 OK AT!ENTERCND="A710" OK AT!UDUSBCOMP=? The "!ENTERCND" command is necessary only once, in order to enable the password-protected commands. The latter command is the one allowing switching modes. It has provided me with this output on my MC7304: 0 - reserved NOT SUPPORTED 1 - DM AT SUPPORTED 2 - reserved NOT SUPPORTED 3 - reserved NOT SUPPORTED 4 - reserved NOT SUPPORTED 5 - reserved NOT SUPPORTED 6 - DM NMEA AT QMI SUPPORTED 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED 8 - DM NMEA AT MBIM SUPPORTED 9 - MBIM SUPPORTED 10 - NMEA MBIM SUPPORTED 11 - DM MBIM SUPPORTED 12 - DM NMEA MBIM SUPPORTED 13 - Config1: comp6 Config2: comp8 NOT SUPPORTED 14 - Config1: comp6 Config2: comp9 SUPPORTED 15 - Config1: comp6 Config2: comp10 NOT SUPPORTED 16 - Config1: comp6 Config2: comp11 NOT SUPPORTED 17 - Config1: comp6 Config2: comp12 NOT SUPPORTED 18 - Config1: comp7 Config2: comp8 NOT SUPPORTED 19 - Config1: comp7 Config2: comp9 SUPPORTED 20 - Config1: comp7 Config2: comp10 NOT SUPPORTED 21 - Config1: comp7 Config2: comp11 NOT SUPPORTED 22 - Config1: comp7 Config2: comp12 NOT SUPPORTED You can then choose a mode depending on your device and your wishes. Here I am using mode 8 from this list: AT!UDUSBCOMP? !UDUSBCOMP: 8 OK You can obtain lots of information from this vendor at https://source.sierrawireless.com/resources/.
(In reply to Pierre Pronchery from comment #44) thanks looks like the mc7700 I have doesnt support that mode :( ati Manufacturer: Sierra Wireless, Incorporated Model: MC7700 Revision: SWI9200X_03.05.10.02AP R4684 CARMD-EN-10527 2012/02/25 11:58:38 IMEI: 012626001657426 IMEI SV: 8 FSN: CDC0684044310 3GPP Release 8 +GCAP: +CGSM OK AT!ENTERCND="A710" OK AT!UDUSBCOMP=? 0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS SUPPORTED 1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED 2 - HIP DM NMEA AT NIC1 MS SUPPORTED 3 - HIP DM NMEA AT MDM1 NIC1 MS SUPPORTED 4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS SUPPORTED 5 - HIP DM NMEA AT ECM1 MS SUPPORTED 6 - DM NMEA AT QMI NOT SUPPORTED 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 NOT SUPPORTED 8 - Win8 Std Net NOT SUPPORTED On the MC7455, it looks like the command is AT!USBCOMP=? AT!USBCOMP? Config Index: 1 Config Type: 1 (Generic) Interface bitmask: 0000050D (diag,nmea,modem,rmnet0,rmnet1) OK AT!UDUSBCOMP=? Obsolete command - not supported AT!USBCOMP=? !USBCOMP: AT!USBCOMP=<Config Index>,<Config Type>,<Interface bitmask> <Config Index> - configuration index to which the composition applies, should be 1 <Config Type> - 1:Generic, 2:USBIF-MBIM, 3:RNDIS config type 2/3 should only be used for specific Sierra PIDs: 68B1, 9068 customized VID/PID should use config type 1 <Interface bitmask> - DIAG - 0x00000001, NMEA - 0x00000004, MODEM - 0x00000008, RMNET0 - 0x00000100, RMNET1 - 0x00000400, MBIM - 0x00001000, e.g. 10D - diag, nmea, modem, rmnet interfaces enabled 1009 - diag, modem, mbim interfaces enabled The default configuration is: at!usbcomp=1,1,10F OK
Some progress. I can kld it, but it panics. - - - Fatal trap 12: page fault while in - - - cpuid = 1; apic id = 02 - - - fault virtual address = 0x28 - - - fault code = supervisor read data, page not present - - - instruction pointer = 0x20:0xffffffff80ceee03 - - - stack pointer = 0x28:0xfffffe00acc30cd0 - - - frame pointer = 0x28:0xfffffe00acc30d60 - - - 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) - - - rdi: fffff8010e85b480 rsi: 0000000000000000 rdx: fffffe00acc30d98 - - - rcx: 0000000000000000 r8: fffff8010e42e000 r9: fffff8010e85b480 - - - rax: fffff8010e85b508 rbx: fffff8010974f800 rbp: fffffe00acc30d60 - - - r10: 0000000000000000 r11: 000000007ffb251d r12: fffff8010e85b510 - - - r13: fffff8010e85b530 r14: fffff8010974f9c0 r15: fffff8010e42e000 - - - trap number = 12 - - - panic: page fault - - - cpuid = 1 - - - time = 1733954200 - - - KDB: stack backtrace: - - - #0 0xffffffff80b8d16d at kdb_backtrace+0x5d - - - #1 0xffffffff80b3f151 at vpanic+0x161 - - - #2 0xffffffff80b3efe3 at panic+0x43 - - - #3 0xffffffff8102ca7b at trap_fatal+0x40b - - - #4 0xffffffff8102cac6 at trap_pfault+0x46 - - - #5 0xffffffff810035b8 at calltrap+0x8 - - - #6 0xffffffff8316b942 at umb_add_inet_config+0x142 - - - #7 0xffffffff8316b209 at umb_decode_cid+0x8b9 - - - #8 0xffffffff83169596 at umb_get_response_task+0x386 - - - #9 0xffffffff8094d45e at usb_process+0xfe - - - #10 0xffffffff80af8311 at fork_exit+0x81 I did a load of the kld umbctl umb0 umb0: state open, mode automatic, registration home network provider "ROGERS", dataclass GPRS, signal #-999 phone number "", roaming "" (denied) APN "", TX 0, RX 0 firmware "SWI9X30C_02.20.03.00", hardware "MC7455" cu -l /dev/cuaU0.1 Connected at+csq +csq: 21,99 OK at!GSTATUS? !GSTATUS: Current Time: 10083 Temperature: 46 Reset Counter: 4 Mode: ONLINE System mode: LTE PS state: Attached LTE band: B4 LTE bw: 15 MHz LTE Rx chan: 2025 LTE Tx chan: 20025 LTE CA state: NOT ASSIGNED EMM state: Registered Normal Service RRC state: RRC Idle IMS reg state: No Srv PCC RxM RSSI: -70 RSRP (dBm): -105 PCC RxD RSSI: -95 RSRP (dBm): -138 Tx Power: 0 TAC: 73D2 (29650) RSRQ (dB): -16.2 Cell ID: 009D0101 (10289409) SINR (dB): -2.8 OK # ifconfig umb0 umb0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 2048 options=0 media: <unknown type> status: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> # umbctl umb0 apn m2minternet.apn # ifconfig umb0 up and then panic
(In reply to mike from comment #46) Thanks for testing! It is progress indeed. For the moment I do not see what can cause the panic (maybe related to VNET again?) but I will let you know as soon as I figure anything out on my side. In the meantime you can try to add this in the code: static int umb_add_inet_config { [...] mtx_unlock(&sc->sc_mutex); +CURVNET_SET_QUIET(vnet0); rv = in_control(NULL, SIOCAIFADDR, (caddr_t)&ifra, ifp, curthread); +CURVNET_RESTORE(); mtx_lock(&sc->sc_mutex); [...] } If this solves the problem, I suspect there will be another panic when the link goes up and down; basically for the other two calls of in_control(). The same procedure will apply. Let me know if you would like me to provide a tentative patch instead. HTH, -- khorben
(In reply to Pierre Pronchery from comment #47) # umbctl umb0 apn m2minternet.apn # umbctl umb0 umb0: state open, mode automatic, registration home network provider "ROGERS", dataclass GPRS, signal #-999 phone number "", roaming "" (denied) APN "m2minternet.apn", TX 0, RX 0 firmware "SWI9X30C_02.20.03.00", hardware "MC7455" # ifconfig umb0 up umb0: state up, mode automatic, registration home network provider "ROGERS", dataclass GPRS, signal #-999 phone number "", roaming "" (denied) APN "m2minternet.apn", TX 50000000, RX 300000000 firmware "SWI9X30C_02.20.03.00", hardware "MC7455" # ifconfig umb0 umb0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1460 options=0 inet 10.155.111.104 --> 10.155.111.105 netmask 0xfffffff0 media: <unknown type> status: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> # route add 8.8.8.8/32 10.155.111.105 add net 8.8.8.8: gateway 10.155.111.105 # ping 8.8.8.8 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80c85434 stack pointer = 0x28:0xfffffe00834dfd40 frame pointer = 0x28:0xfffffe00834dfd80 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 (usbus0) rdi: 0000000000000001 rsi: 0000000000000000 rdx: fffff80059ab0b00 rcx: 0000000000000000 r8: 0000000000000800 r9: 0000000000000000 rax: 0000000000000000 rbx: fffff80001a80000 rbp: fffffe00834dfd80 r10: 0000000000000800 r11: 0000000000000000 r12: 0000000000000001 r13: fffffe00834dfe00 r14: fffff80059ab0b00 r15: 0000000000000000 trap number = 12 panic: page fault cpuid = 3 time = 1734013310 KDB: stack backtrace: #0 0xffffffff80b8d16d at kdb_backtrace+0x5d #1 0xffffffff80b3f151 at vpanic+0x161 #2 0xffffffff80b3efe3 at panic+0x43 #3 0xffffffff8102ca7b at trap_fatal+0x40b #4 0xffffffff8102cac6 at trap_pfault+0x46 #5 0xffffffff810035b8 at calltrap+0x8 #6 0xffffffff8316c0b4 at umb_input+0x44 #7 0xffffffff83168edf at umb_rxeof+0x44f #8 0xffffffff80952626 at usbd_callback_wrapper+0x8a6 #9 0xffffffff80953c76 at usb_command_wrapper+0x96 #10 0xffffffff809528d9 at usb_callback_proc+0xb9 #11 0xffffffff8094d45e at usb_process+0xfe #12 0xffffffff80af8311 at fork_exit+0x81
Created attachment 255811 [details] 0001-Introduce-the-USB-umb-4-network-driver.patch (In reply to mike from comment #48) I suppose the same applies to handling incoming packets, which means adding CURVNET_SET_QUIET(vnet0);/CURVNET_RESTORE(); around ifp->if_input(ifp, m); as per the updated patch. (Right after/before unlocking/locking) Note that in the meantime I have started looking at how to reflect the media in ifconfig(8) (e.g., GPRS/EDGE/LTE...) which explains the presence of new changes in sys/net/if_media.* and lib/libifconfig; this bit is in progress, you can ignore it for now. (It should not harm anything either way)
(In reply to Pierre Pronchery from comment #49) Hello! I compiled the UMB(4) and UMBCTL(8) modules for my pfSense RELENG_2_7_0, which is based on FreeBSD 14.0-CURRENT. I confirm that the module almost worked with my Sierra MC7355. My Sierra is recognized as the interface umb0, and I can set the APN and list it: [2.7.0-RELEASE][admin@router.home]/root: ./umbctl umb0 umb0: state open, mode automatic, registration home network provider "Oi", dataclass GPRS, signal #99 phone number "", roaming "" (denied) APN "", TX 5742000, RX 42200000 firmware "SWI9X15C_05.05.58.00", hardware "MC7355" [2.7.0-RELEASE][admin@router.home]/root: ./umbctl umb0 apn claro.com.br [2.7.0-RELEASE][admin@router.home]/root: ./umbctl umb0 umb0: state open, mode automatic, registration home network provider "Oi", dataclass GPRS, signal #99 phone number "", roaming "" (denied) APN "claro.com.br", TX 5742000, RX 42200000 firmware "SWI9X15C_05.05.58.00", hardware "MC7355" [2.7.0-RELEASE][admin@router.home]/root: ifconfig umb0 up [2.7.0-RELEASE][admin@router.home]/root: ./umbctl umb0 umb0: state attached, mode automatic, registration home network provider "Oi", dataclass GPRS, signal #99 phone number "XXXXXXXXXXXXX", roaming "" (denied) APN "claro.com.br", TX 5742000, RX 42200000 firmware "SWI9X15C_05.05.58.00", hardware "MC7355" I confirmed via AT commands that the APN I set using umbctl is reflected on the Sierra. However, when I try to check the IP of the umb0 interface, it is empty: [2.7.0-RELEASE][admin@router.home]/root: ifconfig umb0 umb0: flags=8811<UP,POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500 media: <unknown type> status: nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> As a result, when I try to use the interface, it fails: [2.7.0-RELEASE][admin@router.home]/root: curl --interface umb0 http://ipecho.net/plain curl: (7) Failed to connect to ipecho.net port 80 after 1048 ms: Couldn't connect to server I compiled the module on a virtual machine using the patch sent by Pierre Pronchery on 2024-12-12 17:48:31 UTC, and then copied the umbctl files to /sbin and umb.ko to /boot/modules on my pfSense router. Did I do something wrong? Should I have copied other files? I would appreciate any help. I would like to note that when I connect to the Sierra using the PPP protocol on my pfSense, the connection works without issues. I would like to use MBIM to see if I can achieve better performance. Additionally, I noticed that umbctl is recognizing my dataclass as GPRS; however, when I use the command AT!GSTATUS?, I confirm that I am actually connected to a WCDMA network. I'm not sure if this could be causing the issue of not receiving an IP address on the umb0 interface. Thank you all for your efforts on this port!
(In reply to Helder Filho from comment #50) Hi Helder, thank you for testing the driver, and for your detailed feedback! There are still some known issues affecting the driver, even on the latest version of FreeBSD. With the latest version (which I usually push in the khorben/umb branch at https://github.com/khorben/freebsd-src/tree/khorben/umb) the driver is capable of obtaining an IP address, but crashes with the first packet sent or received. I ported the driver back in 2019-2020 with OPNSense as the target, where it worked just fine for me; it was not affected by the current issues with VNET or mutexes (or at least it was not crashing, even though some bugs were certainly there). This might have been because of some differences between FreeBSD and pfSense/OPNSense. You might also have run into an incompatibility between pfSense and the VM; it is difficult to evaluate from here, even with your detailed output. I am currently getting help for testing the driver in different situations (thanks!) and hope to be able to make further progress soon. I will update this bug report as soon as I make any significant update.
Created attachment 255918 [details] 0001-Introduce-the-USB-umb-4-network-driver.patch This patch is known to have worked in a test environment.
(In reply to Pierre Pronchery from comment #52) A slightly simplified version of this patch is now available for review at https://reviews.freebsd.org/D48167. Let me know if I can add you as reviewer!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e5f3620a3e12c0febab7e4125da526c59a5a195b commit e5f3620a3e12c0febab7e4125da526c59a5a195b Author: Adrian Chadd <adrian@FreeBSD.org> AuthorDate: 2025-01-20 23:44:03 +0000 Commit: Adrian Chadd <adrian@FreeBSD.org> CommitDate: 2025-01-20 23:44:03 +0000 sys: add MBM device ioctl() values This is part of the upcoming USB umb(4) work. It implements the control ioctl(4)s that MBM devices will need to implement. Differential Revision: https://reviews.freebsd.org/D48167 Approved by: adrian, zlei Sponsored by: FreeBSD Foundation PR: kern/263783 Submitted by: Pierre Pronchery <khorben@defora.org> sys/sys/sockio.h | 4 ++++ 1 file changed, 4 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=86bfbaf1002c88b5c1a6d3ed261becedb533490b commit 86bfbaf1002c88b5c1a6d3ed261becedb533490b Author: Adrian Chadd <adrian@FreeBSD.org> AuthorDate: 2025-01-20 23:39:17 +0000 Commit: Adrian Chadd <adrian@FreeBSD.org> CommitDate: 2025-01-20 23:39:17 +0000 sys: add MBIM (mobile broadband interface module) interface type. This is part of the upcoming USB umb(4) work. Differential Revision: https://reviews.freebsd.org/D48167 Approved by: adrian, zlei Sponsored by: FreeBSD Foundation PR: kern/263783 Submitted by: Pierre Pronchery <khorben@defora.org> sys/net/if_types.h | 1 + 1 file changed, 1 insertion(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0f1bf1c22a0c97e84a4db19197a75952487aa20b commit 0f1bf1c22a0c97e84a4db19197a75952487aa20b Author: Adrian Chadd <adrian@FreeBSD.org> AuthorDate: 2025-01-20 23:46:15 +0000 Commit: Adrian Chadd <adrian@FreeBSD.org> CommitDate: 2025-01-20 23:46:15 +0000 umb: Introduce the USB umb(4) network driver This includes the port of a driver originally from OpenBSD, later ported to NetBSD by the author: * The umb(4) kernel driver * The umbctl(8) companion tool This driver supports USB network devices implementing the Mobile Broadband Interface Model (MBIM), often found in modern (internal) USB models for 4G/LTE mobile broadband access. It is currently limited to IPv4. umbctl has to be used to display or set MBIM cellular modem interface parameters (4G/LTE). Differential Revision: https://reviews.freebsd.org/D48167 Approved by: adrian, zlei Sponsored by: FreeBSD Foundation PR: kern/263783 Submitted by: Pierre Pronchery <khorben@defora.org> sbin/Makefile | 1 + sbin/umbctl/Makefile (new) | 8 + sbin/umbctl/umbctl.8 (new) | 161 ++ sbin/umbctl/umbctl.c (new) | 557 +++++++ share/man/man4/Makefile | 1 + share/man/man4/umb.4 (new) | 119 ++ sys/conf/files | 1 + sys/dev/usb/net/if_umb.c (new) | 2930 ++++++++++++++++++++++++++++++++++++ sys/dev/usb/net/if_umbreg.h (new) | 443 ++++++ sys/dev/usb/net/mbim.h (new) | 727 +++++++++ sys/modules/usb/Makefile | 2 +- sys/modules/usb/umb/Makefile (new) | 33 + 12 files changed, 4982 insertions(+), 1 deletion(-)
Thank you!
Fantastic to see it in the tree. I am guessing this will eventually be MFC'd to 14? Also, Pierre do you or any of the FreeBSD folks still need the test box in our server room ?
(In reply to mike from comment #58) Hi Mike, thank you again for the access to your hardware! So far I made no plan to MFC to -14, however I believe the changes should apply cleanly and work without much effort. Should we investigate this? I expect to have access to my own hardware again within two weeks; it would be great to be able to use your setup in the meantime in case anyone finds an issue, but I do not want to be in the way of your own plans!
I have some Panasonic Toughbook laptops with Sierra modems ans 14.1/14.2 RELEASE.. it would be great to test the driver code and have that modem up and running if not a big problem.. thank you!! :-)
(In reply to Pierre Pronchery from comment #59) Hi Pierre, Happy to leave it on the rack for now. I might just power it down via IPMI so it does not use electricity and cooling needlessly. Feel free to power it up as needed to test against.
(In reply to Tomasz "CeDeROM" CEDRO from comment #60) Can you test the branch at https://github.com/khorben/freebsd-src/commits/khorben/umb-14/? It built cleanly for me, but I haven't tested it yet.
Is it planned to transfer the settings from umbctl to ifconfig (and expand them) in the future? It would be very convenient. Is it possible to expand the diagnostic parameters issued by ifconfig? Or are these limitations of such a connection via a driver?
(In reply to ev from comment #63) That would be extremely elegant and consistent!