On Wed, Jan 24, 2024 at 11:47:53AM +1100, Jonathan Gray wrote:
> Index: sys/dev/usb/umsm.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> diff -u -p -r1.125 umsm.c
> --- sys/dev/usb/umsm.c 2 Apr 2023 23:57:57 -0000 1.125
> +++ sys/dev/usb/umsm.c 24 Jan 2024 00:40:54 -0000
> @@ -147,6 +147,8 @@ static const struct umsm_type umsm_devs[
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MU609 }, DEV_TRUINSTALL},
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_K4510 }, DEV_UMASS5},
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_K4511 }, DEV_UMASS5},
> +#define USB_PRODUCT_HUAWEI_K5161H 0x1f1d
> + {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_K5161H }, DEV_UMASS5},
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E1750 }, DEV_UMASS5},
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E1752 }, 0},
> {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E3372 }, DEV_UMASS5},
So, this works. This enables a third mode, of which I was previously
unaware: it turns into product ID 0x1442, which is a Huawei E3372, and
is supported by umsm(4).
For the record (for the benefit of others searching the Internet for
info about this device), this device can present four product IDs (all
with the same Huawei 0x12d1 vendor ID):
- 0x1f1d: the default fake CD drive mode, when it's first plugged in
- 0x1442: Huawei E3372 mode, what the above patch turns it into,
which appears to work with umsm(4) (usb_modeswitch apparently
doesn't support this mode; -H/--huawei-mode just fails)
- 0x1591: I believe this is called "Hilink" mode; it appears as a
cdce(4) Ethernet interface and runs a DHCP server and does NAT for
you, like tethering to a phone (this is usb_modeswitch
-J/--huawei-new-mode)
- 0x155e: MBIM mode, which should be supported by umb(4)
(usb_modeswitch -X/--huawei-alt-mode)
For completeness, I've now tried ejecting the fake CD; this has no
effect.
It would be nice to also find a way to switch it into 0x155e/MBIM mode
on OpenBSD, so it can be used with umb(4).
Alex
