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!
Sorry it's taken me so long to get to testing this. I'm using the current khorben/umb-14 repo, but I'm getting the below error on my MC7700: umb0 on uhub0 umb0: <Sierra Wireless, Incorporated MC7700, class 239/2, rev 2.00/0.06, addr 1> on usbus1 umb0: version 1.0 umb0: error: no data interface found device_attach: umb0 attach returned 6 I'm currently using UDUSBCOMP 8, which should have an AT interface, but I don't seem to have any cuaUXXX devices, so I'm guessing that's where the issue is.
(In reply to Matt Latin from comment #65) After some more investigation, somehow it's not finding the CDC interface as that stays at -1. ud = usbd_find_descriptor(sc->sc_udev, id, uaa->info.bIfaceIndex, UDESC_CS_INTERFACE, 0xff, UDESCSUB_CDC_UNION, 0xff); if (ud != NULL) { data_ifaceno = ud->bSlaveInterface[0]; }
I know this PR is closed but I don't know where to go... :-) I have copied the relevant bits from -CURRENT to 14-STABLE. The good news is that it works using a Sierra EM7455 in MBIM mode. But one must have device netmap in the kernel. Without it you don't get packets back when pinging 8.8.8.8. With UMB_DEBUG enabled, we find: Aug 4 12:27:14 kernel: init: reached state UP Aug 4 12:27:14 kernel: umb_rxeof(0): state=0 Aug 4 12:27:14 kernel: umb0: link state changed to UP Aug 4 12:27:15 kernel: umb_txeof(0) state=0 Aug 4 12:27:15 kernel: umb_txeof(0) state=1 Aug 4 12:27:15 kernel: umb_rxeof(0): state=1 Aug 4 12:27:15 kernel: received 112 bytes in 1 frames Aug 4 12:27:16 kernel: umb_txeof(0) state=0 Aug 4 12:27:16 kernel: umb_txeof(0) state=1 Aug 4 12:27:16 kernel: umb_rxeof(0): state=1 Aug 4 12:27:16 kernel: received 112 bytes in 1 frames I can't test what happens in -CURRENT w/o netmap...
(In reply to Andre Albsmeier from comment #67) Hi Andre, Wow thank you for the tip, I have been trying to make umb(4) work on 14.x for quite a while, without being able to understand why I did not get any traffic, while everything looked like it should just work. I should be able to test this again within a couple weeks, and request a MFC for the next major release. I also need to review and import some patches from upstream for good measure.
(In reply to Pierre Pronchery from comment #68) Just wondering: Did it work for you on -CURRENT but w/o "device netmap"? I spent a few minutes poking around in the kernel sources to find out what other drivers do differently when (not) using netmap -- hoping to find what's missing but got lost...
(In reply to Andre Albsmeier from comment #69) Device netmap became included by default in GENERIC kernels in FreeBSD 15.0 for amd64,arm64, and ppc64.
(In reply to Alexander Ziaee from comment #70) As I don't run -current, I have to ask: Does umb depend on netmap? If yes, will someone who compiles a custom kernel with umb but w/o netmap receive an error? How about loading it as a module? Does it complain if netmap is not available?
Created attachment 263112 [details] umb_no_netmap (In reply to Andre Albsmeier from comment #71) I'd argue umb(4) should not depend on netmap. Can you please have a try with this patch ? You can disable netmap in kernel config, or you may test against stable/14, without netmap, surely.
(In reply to Zhenlei Huang from comment #72) Commented out the lines mentioned in your patch and now it works on STABLE-14 without netmap. Thanks a lot!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e921d2842ee8ca9e3dae8952e1cf2645cee785aa commit e921d2842ee8ca9e3dae8952e1cf2645cee785aa Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2025-09-03 17:19:37 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2025-09-03 17:19:37 +0000 umb: Fix setting the input routine This driver does not depend on netmap, and umb_input() works greatly without netmap. Remove the #ifdef DEV_NETMAP so that when "device netmap" is not configured this driver can still correctly pass the inbound packets to the net stack. Otherwise the input routine will be if_input_default() which will silently drop all inbound packets. PR: 263783 Reported by: Andre Albsmeier <mail@fbsd2.e4m.org> Tested by: Andre Albsmeier <mail@fbsd2.e4m.org> Differential Revision: https://reviews.freebsd.org/D52182 sys/dev/usb/net/if_umb.c | 4 ---- 1 file changed, 4 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=80ab8a4beeb812adfbf1cb823ab7476d4a17659a commit 80ab8a4beeb812adfbf1cb823ab7476d4a17659a Author: Alexander Ziaee <ziaee@FreeBSD.org> AuthorDate: 2025-09-03 18:50:58 +0000 Commit: Alexander Ziaee <ziaee@FreeBSD.org> CommitDate: 2025-09-03 18:59:00 +0000 umb.4: Remove device netmap from synopsis This driver was recently improved to no longer require DEV_NETMAP. PR: 263783 Reported by: zlei Fixes: e921d2842ee8 (umb: Fix setting the input routine) share/man/man4/umb.4 | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Thanks. I think a lot of people would be happy if umb was merged into STABLE-14. This shouldn't be a lot of work since all I did was copying the files over and, apart from that netdev issue which is now resolved, it worked out of the box...
(In reply to Andre Albsmeier from comment #76) +1 pretty please :-) I am on 14.2 and would love to use the driver on my Panasonic Toughbook(s) :-)
(In reply to Andre Albsmeier from comment #76) The MFC is straightforward so I expect to take care of it in a bit. I can give you a staged stable/14 branch to try if you like.
That would be great! Thank you Ed :-)
MFC available in the "stable-14-umb" branch in my GitHub repo: https://github.com/emaste/freebsd/tree/stable-14-umb
TANK U SIR! =)
I have good feedback :-) Writing this from 14.2-p5 on Panasonic Toughbook CF-MX4 over buit-in USB MBIM modem, I am on a trip this weekend so I had a few moments in a train to build and test in real world environment :-) :-) BIG THANK YOU!! :-) Thank you Ed for the testing branch, looks like it is targeted towards 14.3 so I had to add few defines to build on 14.2 but it works :-) I also created simple /etc/rc.d/umbim script that brings up the connection on boot. This is just an example that works. Can be extended with verification if the provided interface works, maybe also implement several interfaces and configurations per interface if necessary :-) # uname -a FreeBSD cfmx4 14.2-RELEASE-p5 FreeBSD 14.2-RELEASE-p5 #4 releng/14.2-n269542-a14e765aa11a-dirty: Sat Sep 6 09:49:09 CEST 2025 root@cfmx4:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # umbctl umb0 umb0: state up, mode automatic, registration home network provider "Orange", dataclass GPRS, signal #99 phone number "", roaming "" (denied) APN "internet", TX 50000000, RX 100000000 firmware "SWI9X15C_05.05", hardware "EM7305" diff --git a/sbin/umbctl/Makefile b/sbin/umbctl/Makefile index 35afb1bcfd4b..e7d6eab1ba3f 100644 --- a/sbin/umbctl/Makefile +++ b/sbin/umbctl/Makefile @@ -1,4 +1,4 @@ -CFLAGS+= -I${SRCTOP}/sys/dev/usb/net +CFLAGS+= -I/usr/src/sys -I${SRCTOP}/sys/dev/usb/net PROG= umbctl MAN= umbctl.8 diff --git a/sys/modules/usb/Makefile b/sys/modules/usb/Makefile index 6dc4963594af..e9f0a6024a78 100644 --- a/sys/modules/usb/Makefile +++ b/sys/modules/usb/Makefile @@ -49,9 +49,7 @@ SUBDIR += ${_rum} ${_run} ${_runfw} ${_uath} upgt usie ural ${_zyd} ${_urtw} SUBDIR += atp cfumass uhid uhid_snes ukbd ums udbp uep wmt wsp ugold uled \ usbhid SUBDIR += ucom u3g uark ubsa ubser uchcom ucycom ufoma uftdi ugensa uipaq ulpt \ - umct umcs umodem umoscom uplcom uslcom uvisor uvscom umb umct umcs umodem umoscom uplcom uslcom uvisor uvscom SUBDIR += cp2112 SUBDIR += udl SUBDIR += uether aue axe axge cdce cdceem cue ${_kue} mos rue smsc udav uhso \ diff --git a/sys/net/if_types.h b/sys/net/if_types.h index 17227726a663..dee71af80a5d 100644 --- a/sys/net/if_types.h +++ b/sys/net/if_types.h @@ -256,6 +256,7 @@ typedef enum { IFT_PFLOG = 0xf6, /* PF packet filter logging */ IFT_PFSYNC = 0xf7, /* PF packet filter synchronization */ IFT_WIREGUARD = 0xf8, /* WireGuard tunnel */ + IFT_MBIM = 0xf9, /* Mobile Broadband Interface Model */ } ifType; /* diff --git a/sys/sys/sockio.h b/sys/sys/sockio.h index e0f2ab697168..a3988c393494 100644 --- a/sys/sys/sockio.h +++ b/sys/sys/sockio.h @@ -148,5 +148,8 @@ #define SIOCSIFCAPNV _IOW('i', 155, struct ifreq) /* set IF features */ #define SIOCGIFCAPNV _IOWR('i', 156, struct ifreq) /* get IF features */ +#define SIOCGUMBINFO _IOWR('i', 157, struct ifreq) /* get MBIM info */ +#define SIOCSUMBPARAM _IOW('i', 158, struct ifreq) /* set MBIM param */ +#define SIOCGUMBPARAM _IOWR('i', 159, struct ifreq) /* get MBIM param */ #endif /* !_SYS_SOCKIO_H_ */ ===> /etc/rc.conf: umbim_enable="YES" umbim_config="/etc/umbim.conf" umbim_interface="umb0" ===> /etc/rc.d/umbim: #!/bin/sh # PROVIDE: umbim . /etc/rc.subr . /etc/network.subr name="umbim" desc="UMBIM Cellular Modem Interface" rcvar="umbim_enable" command="/sbin/umbctl" pidfile="/var/run/${name}.pid" start_cmd="umbim_start" stop_cmd="umbim_stop" status_cmd="umbim_status" load_rc_config $name umbim_start() { if [ -z "${umbim_config}" ]; then echo "umbim_config not provided!" return 1 fi if [ -z "${umbim_interface}" ]; then echo "umbim_interface not provided!" return 1 fi ${command} -f ${umbim_config} ${umbim_interface} ifconfig ${umbim_interface} up route add default -interface ${umbim_interface} } umbim_stop() { route del default -interface umb0 ifconfig ${umbim_interface} down delete } umbim_status() { ${command} ${umbim_interface} ifconfig ${umbim_interface} } run_rc_command "$1"
> looks like it is targeted towards 14.3 so I had to add few defines to build on 14.2 but it works :-) The additions to sys/sys/sockio.h and sys/net/if_types.h are needed on 14.3 as well. I forgot to mention this explicitly...
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=06d08e6e758df2114111af415c67623ea3c1825b commit 06d08e6e758df2114111af415c67623ea3c1825b Author: Pierre Pronchery <khorben@FreeBSD.org> AuthorDate: 2025-01-20 23:44:03 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2025-09-14 19:25:39 +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> (cherry picked from commit e5f3620a3e12c0febab7e4125da526c59a5a195b) sys/sys/sockio.h | 4 ++++ 1 file changed, 4 insertions(+)
(In reply to commit-hook from comment #84) Thanks! Please do not forget to MFC https://cgit.freebsd.org/src/commit/sys/net/if_types.h?id=86bfbaf1002c88b5c1a6d3ed261becedb533490b
Okay, so I got another weekend outside, had some more conditions to test: 1. Modem does not always connect to LTE, even though my mobile phone has the internet connectivity. Restarting interface, reseting usb device, etc, does not help. Once the connectivity is lost it is not regained again on its own. 2. Actually I did not get any connection over the UMBIM modem this weekend :-( I had to use wifi from the phone ap. In theory modem connects to the nerwork (Orange), the IP tunnel is set up (two IP addresses on the ifconfig where internal responds to ping but the other does not), but no outgoing ping (i.e. to 1.1.1.1 nor 8.8.8.8) was achieved. 3. My SIM has disabled PIN check. But before I made sure of that there was no way to see if the PIN is required, was the pin entered correct, do I need to enter PUK, etc. Something like the AT commands in U3G modem seems to be missing here in UMBIM. This is observation from last weekend I did not mention sorry. But this weekend such test utilities would come even more handy. Thanks :-) Tomek
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=70caaeb8b63f9e11e1f495ab3918119c537a8677 commit 70caaeb8b63f9e11e1f495ab3918119c537a8677 Author: Pierre Pronchery <khorben@FreeBSD.org> AuthorDate: 2025-01-20 23:39:17 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2025-09-15 13:51:43 +0000 sys: add MBIM (mobile broadband interface module) interface type. This is part of the upcoming USB umb(4) work. PR: 263783 Approved by: adrian, zlei Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48167 (cherry picked from commit 86bfbaf1002c88b5c1a6d3ed261becedb533490b) sys/net/if_types.h | 1 + 1 file changed, 1 insertion(+)
(In reply to Tomasz "CeDeROM" CEDRO from comment #86) Just out of curiosity: What modem type is it? I used the Sierra EM7455. I had to change the NVRAM settings to enable MBIM but apart from that, it always worked ("always" means the 5 to 10 times I tried for a few minutes). > But before I made sure of that there was no way to see if the PIN is required, So at+cpin? didn't work? I had no problems using this (and all other commands) on the Sierra EM7455.
Thanks Andre, this is Sierra (now Semtech) EM7305 on Panasonic Toughbook CF-MX4. Now I cannot connect even at home. Trains are good for testing because of frequent connectivity loss. The SIM card is operational I just put it into a smartphone and all works fine. Thus some additional diagnostics would be nice to have :-) I do not have /dev/cuaUx even after module load so I do not have AT commands. # umbctl umb0 umb0: state up, mode automatic, registration home network provider "Orange", dataclass GPRS, signal #99 phone number "", roaming "" (denied) APN "internet", TX 50000000, RX 100000000 firmware "SWI9X15C_05.05", hardware "EM7305" Maybe this is modem firmware issue, I am just downloading latest Build4837-Approved-Only-7305-SPK.zip from [1]. Now I need to find a way to upgrade firmware :-P [1] https://source.sierrawireless.com/resources/airprime/software/airprime-em73xx_mc73xx-fw-package-latest-release/
Looks like [1] can be used to talk with the qmi modem and upgrade firmware according to hints provided in [2]. Will try to port this one but it does not build out of the box :-P [1] https://gitlab.com/linux-mobile-broadband/libqmi [2] https://github.com/danielewood/sierra-wireless-modems
My EM7455 gave me a serial... I just attached an EM7305 to see what this does but MBIM is not enabled and I can't enable it since AT!ENTERCND="A710" doesn't let me in :-(. Wonder if the PW is different on EM7305 or some moron changed it (I have removed it from a Fujitsu S904).
(In reply to Tomasz "CeDeROM" CEDRO from comment #90) Shame on me, but I used your [2] on a Notebook with Ubuntu to update my EM7455...
Okay so meson.build file needs tiny update to find stuff at /usr/local/include location (like #include <linux/types.h>). I can see there were reports for that in meson upstream but still not added? diff --git a/meson.build b/meson.build index 85266d18..0b7d6d38 100644 --- a/meson.build +++ b/meson.build @@ -74,6 +74,7 @@ cc_flags = cc.get_supported_arguments([ '-Wno-cast-function-type', # all message protocol structs are packed, never complain about it '-Wno-packed', + '-I/usr/local/include', ]) # strict flags to use in debug builds Then project can be generated for ninja build at build-bsd with: meson setup build-bsd -Dmbim_qmux=false -Dqrtr=false -Dcollection=basic -Dintrospection=false -Dman=false -Dudev=false -Drmnet=false -Dmm_runtime_check=false -Dbash_completion=false But it fails at: ../src/libqmi-glib/qmi-net-port-manager-rmnet.c:24:10: fatal error: 'linux/if_link.h' file not found 24 | #include <linux/if_link.h> We do not seem to have this header provided anywhere? % pkg which -g if_link.h if_link.h was not found in the database After that there are lots of linux includes related issues so I give up for now. Will try vbox win7 and vendor tools to update firmware maybe this will work ;-)
Okay so vbox with win7 did not work - device shows up but does not start even though drivers are installed. So i tried with lubuntu 24.04 usb-bootable system. It has libqmi by standard. Upgraded firmware from SWI9X15C_05.05.26.00 r21289 carmd-fwbuild1 2014/04/02 18:24:16 (CarrierID: 01) to latest: 1. SWI9X15C_05.05.58.00 r27038 carmd-fwbuild1 2015/03/04 18:38:46 (CarrierID: 204) that is dedicated to Orange that I use. This one did not even connect to operator. 2. SWI9X15C_05.05.78.00 r34310 CARMD-EV-FRMWR3 2017/09/17 00:43:17 (CarrierID: 01) that is Generic image. Tried to connect to Orange right after update on lubuntu and it did work. But on FreeBSD it looks like connection is made but no packets come in/out :-( umb0: state up, mode automatic, registration home network provider "Orange", dataclass GPRS, signal #99 phone number "", roaming "" (denied) APN "internet", TX 50000000, RX 100000000 firmware "SWI9X15C_05.05.78.00", hardware "EM7305" umb0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1430 options=0 inet 10.77.17.230 --> 10.77.17.229 netmask 0xfffffffc media: <unknown type> status: nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Also looks like it would be good to have this libqmi-utils ported to play with firmware upgrades on FreeBSD :-)
Ah even with those latest firmwares I do not see any serial modem /dev/cuaUx. Maybe some additional AT configuration is required under Linux to work on FreeBSD? But the strangest thing is that it was working last week :D
(In reply to Tomasz "CeDeROM" CEDRO from comment #95) What does AT!UDUSBCOMP? say (after AT!ENTERCND="A710" )
(In reply to Tomasz "CeDeROM" CEDRO from comment #95) The device composition affects whether or not you get a serial port for AT commands: https://www.freedesktop.org/software/libqmi/man/latest/qmicli.1.html
(In reply to Tomasz "CeDeROM" CEDRO from comment #95) The device composition affects whether or not you get a serial port for AT commands. You can view and change it with qmicli: https://www.freedesktop.org/software/libqmi/man/latest/qmicli.1.html --dms-swi-get-usb-composition Get current and supported USB compositions (Sierra Wireless specific) --dms-swi-set-usb-composition=[#] Set USB composition (Sierra Wireless specific)
Well, yes, of course. If he hasn't got a serial device, he can't try AT!UDUSBCOMP?... Sorry for the confusion...
(In reply to Tomasz "CeDeROM" CEDRO from comment #89) FWIW, I was able to hack my EM7305 to reset the ENTERCND password to the default (A710). Now I could change the USB composition to 8 (DM, NMEA, AT, MBIM) and it immediately got probed as umb0. However, after setting the APN it does not connect (no IP on umb0). I will try the next days to find out whats going on. Another interesting thing: Before it had USB composition 14 which is "Config1: comp6 Config2: comp9". I don't know what this means but it could be that you can select between two configurations: 6, which is "DM NMEA AT QMI" and 9, which is "MBIM" So _maybe_ your device is configured similarly but gives you Config2 (MBIM only) for whatever reasons...
(In reply to Andre Albsmeier from comment #100) Hmm on my laptop there is a hidden menu in BIOS SETUP under the password "toughkit" where you can set "Wireless WAN ID" to 15 in order to get the modem running. Maybe this is the configuration number you are mentioning? What happens when you set configuration 15? Looks like these are more complex devices and some sort of diagnostics utility would be helpful :-) Maybe the one from Linux but I do not have time right now to play sorry :-(
(In reply to Tomasz "CeDeROM" CEDRO from comment #101) Well, can you change the "15" you are seeing? I have no idea what a "Wireless WAN ID" is, but if it has to do with the USB composition, it _might_ be: 15 - Config1: comp6 Config2: comp10 NOT SUPPORTED with comp6: 6 - DM NMEA AT QMI SUPPORTED and comp10: 10 - NMEA MBIM SUPPORTED at least on my 7305. I don't dare to change my 7305 to 15 - I am happy to have an MBIM mode right now (although it doesn't work yet). FWIW, this is the complete list of my USB compositions: at!udusbcomp=? 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
Short story: The EM7305 works in MBIM mode with the MBIM stuff ported to 14-STABLE. Long story: I've taken another EM7305 which had an USB composition (at!udusbcomp?) of 14. This is: 14 - Config1: comp6 Config2: comp9 SUPPORTED which are: 6 - DM NMEA AT QMI SUPPORTED 9 - MBIM SUPPORTED As default, #6 (with 4 serial ports) was active. Using usbconfig -d ugen0.4 set_config 1 I changed it to the other config (#9). Now the serial ports were gone but I had an umb0 interface. After configuring the APN with umbctl and "ifconfig up umb0" I had an IP. After changing the route I could ping the world. After that, I changed the USB composition to 8 which is: 8 - DM NMEA AT MBIM SUPPORTED This gives me one serial and the umb0 at the same time w/o the need to change the configuration using usbconfig. The umb0 interface worked as before. So what you might want to try is to play with "usbconfig dump_all_desc" and check if there is another configuration which could give you a serial port. If yes, you can change the USB composition to 8 so you have an umb0 AND a serial at the same time. This might help revealing what's going on. FWIW, the other EM7305, which didn't receive an IP before, was updated to the latest FW (SWI9X15C_05.05.78.00) and now it works as well. No idea if the fw update or some side effect fixed it...
And another one: The EM8805 work as well (on 14-STABLE).
(In reply to Andre Albsmeier from comment #103) > After configuring the APN with umbctl and "ifconfig up umb0" And this should have read: "ifconfig umb0 up" of course...
Another success story: The Fibocom "L830 LTE Module" works as well (14.3-STABLE). However, after umbctl and "ifconfig up" the radio has to be toggled off and on using at+cfun=4 and at+cfun=1. I spent hours checking why I didn't get an IP after "ifconfig up" and suspected another drive/modem issue just to find out that at+cfun is needed. Probably the cleanest way is to do at+cfun=4 umbctl umb0 apn bla.bla ifconfig umb0 up at+cfun=1
(In reply to Tomasz "CeDeROM" CEDRO from comment #101) >Hmm on my laptop there is a hidden menu in BIOS SETUP under the password "toughkit" where you can set "Wireless WAN ID" to 15 in order to get the modem running. This is a Panasonic-proprietary setting which determines which devices the BIOS will accept, and possibly configures the multiplexing (WLAN and WWAN onto the same antennae). 13 also works, but I don't know the difference between the two. For those who have locked Sierra modules (FCC or ENTERCND or both), there is an online keygen at https://sierra-keygen.uu.sg/ (a hosted version of what is linked below) which can be used as follows: Figure out the modem ID required for the challenge/response (and more info here): https://github.com/bkerler/edl/blob/master/sierrakeygen_README.md AT!ENTERCND="A710" AT!PCFCCAUTH? If FCC lock is 1: AT!OPENLOCK? AT!OPENLOCK="xxxxxxxxxxxxxxxx" AT!PCFCCAUTH=0 AT!PCFCCAUTH? AT!RESET On the other hand, if ENTERCND != "A710": AT!OPENLOCK? AT!OPENLOCK="xxxxxxxxxxxxxxxx" AT!SETCND="A710"
The Sierra modems are quite malleable; the following is sure to help anyone working with them: https://github.com/danielewood/sierra-wireless-modems?tab=readme-ov-file
Is there a viable path towards IPv6 support? This was added to the original OpenBSD code after the NetBSD port (which the FreeBSD port is based on). I recently tested this with a TCL / Alcatel IK41VE1. It now works in all three BSDs, but only NetBSD has IPv6 support.
(In reply to Maurice Walker from comment #109) Correction: Only OpenBSD has IPv6 support.
The Quectel EM060K-GL ugen0.4: <EM060K-GL Quectel Wireless Solutions Co., Ltd.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x2c7c idProduct = 0x6008 bcdDevice = 0x0504 iManufacturer = 0x0001 <Quectel> iProduct = 0x0002 <EM060K-GL> iSerialNumber = 0x0003 <1582f7ef> bNumConfigurations = 0x0001 is also working with the umb driver. In order to get a serial port, you need https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290688 Thanks to Alexander Burke for providing the modems to me!