Re: Huawei K5161h 4G dongle
On Tue, Jan 23, 2024 at 11:52:01AM +, Alex Frolkin wrote:
> Hi all,
>
> Has anyone had any success with getting a Huawei (Vodafone-branded)
> K5161h 4G dongle working on OpenBSD?
>
> It looks like it should work with the umb(4) driver, but the problem is
> getting it into the right mode. When I plug it in, it appears as a USB
> CD drive, and there are magic commands you can send to it to make it
> appear either as an Ethernet interface (where it does NAT and DHCP for
> you, should be supported by the cdce(4) driver) or as an MBIM device
> plus three USB serial ports (which should be supported by umb(4) and
> hopefully ucom(4)).
>
> On FreeBSD and Linux, the mode switching is done by usb_modeswitch,
> which supports switching it to either mode. usb_modeswitch compiles
> fine on OpenBSD, but fails to actually send the magic command, and the
> error code (from the usb_bulk_io function in libusb) says "unsupported
> on this platform".
umsm(4) does the equivalent in the kernel. DEV_UMASS5 seems most
likely, but there are other methods to try as well.
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 - 1.125
+++ sys/dev/usb/umsm.c 24 Jan 2024 00:40:54 -
@@ -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},
Re: Asynchronous write()/send()?
On Tue, 23 Jan 2024 22:31:25 +, illegalcod...@proton.me wrote: > I'm writing a program that uses sockets, and am facing a problem where I thin > k some threads block on a send() forever. I thought I could solve this by usi > ng an asynchronous write, and setting a timeout, but I cannot find anything a > bout this on OpenBSD. Is this just not available? I installed the POSIX manpa > ges and I can see aio stuff there, but it tells me to include a header that g > cc and clang won't find. Apparently FreeBSD has aio_write(), but seemingly Op > enBSD doesn't. What are the alternatives? Is there really no way to do this? The normal way to do this is to mark the socket non-blocking, use something like poll(2) for the event loop and handle partial read/write appropriately. Many of the system daemons use libevent to help abstract this. - todd
Asynchronous write()/send()?
Hi, I'm writing a program that uses sockets, and am facing a problem where I think some threads block on a send() forever. I thought I could solve this by using an asynchronous write, and setting a timeout, but I cannot find anything about this on OpenBSD. Is this just not available? I installed the POSIX manpages and I can see aio stuff there, but it tells me to include a header that gcc and clang won't find. Apparently FreeBSD has aio_write(), but seemingly OpenBSD doesn't. What are the alternatives? Is there really no way to do this? Best, illegalcoding
Re: drm on MacBook Air (M1)
On Jan 23 21:09:10, h...@stare.cz wrote: > these are the errors drm reports: > > Jan 23 15:03:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 15:27:35 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:05:40 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:09:07 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:20:30 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:20:49 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:30:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 16:32:23 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 16:44:46 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:19:17 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 17:33:51 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:35:18 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 17:47:09 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 17:49:58 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 18:02:08 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 19:20:16 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > Jan 23 19:30:34 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* > dcp_poweroff() done > Jan 23 19:41:14 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* > dcp_poweron() starting > > That pid is the X process. The times are when the screensaver kicks in. > After 'xset s blank s activate', the screen blanks for a moment, > but lights backup up almost immediately, dimmed; after Fn+F2 > (on this macbook) it lights up fully. How can I debug this? Also, video does not light back up after closing and opening the lid. This is with machdep.lidaction=0: Jan 23 21:59:02 mb /bsd: drm:pid60117:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 21:59:02 mb /bsd: uhub0 detached Jan 23 21:59:02 mb /bsd: uhub1 detached Jan 23 21:59:27 mb /bsd: uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Jan 23 21:59:27 mb /bsd: uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 Jan 23 21:59:27 mb /bsd: drm:pid60117:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 21:59:27 mb /bsd: aplsmc0: system 1.03 W After opening the lid, the machine apparently gets operating again, as witnessed by the pinging ping pinging the pings again (to another machine), but the screen remains black. Jan
drm on MacBook Air (M1)
This is current/arm64 on an M1 MacBook Air; current dmesg and previous dmesg below. The biggest difference seems to be drm replacing simplefb (thank you): -"dcp" at simplebus0 not configured -"display-subsystem" at simplebus0 not configured +apldcp0 at simplebus0 +apldrm0 at simplebus0 +drm0 at apldrm0 -simplefb0 at mainbus0: 2560x1600, 32bpp -wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation), using wskbd0 -wsdisplay0: screen 1-5 added (std, vt100 emulation) +"framebuffer" at mainbus0 not configured +apldrm0: 2560x1600, 32bpp +wsdisplay0 at apldrm0 mux 1: console (std, vt100 emulation), using wskbd0 +wsdisplay0: screen 1-5 added (std, vt100 emulation) Now that this works, should apldrm(4) be mentioned in the drm(4) manpage like the other drms? Index: drm.4 === RCS file: /cvs/src/share/man/man4/drm.4,v retrieving revision 1.13 diff -u -p -r1.13 drm.4 --- drm.4 7 Jan 2022 00:44:17 - 1.13 +++ drm.4 23 Jan 2024 19:11:41 - @@ -33,6 +33,9 @@ .Cd "amdgpu* at pci?" .Cd "drm* at amdgpu?" .Cd "wsdisplay* at amdgpu?" +.Cd "apldrm* at fdt?" +.Cd "drm* at apldrm?" +.Cd "wsdisplay* at apldrm?" .Pp .Cd "# amd64, i386" .Cd "inteldrm* at pci?" I am adding this to the "# arm64" section; is apldrm also relevant to the other Apple platforms? (I am not at my macppc machine now.) While here, is fdt some generic "device tree" pseudodevice? My apldrm is at simplebus. Please excuse my devtree ignorance. A lot of devices are configured at fdt in the GENERIC config, but no fdt appears in any of my dmesgs on any machine. Also, while it runs, apparently without problems, these are the errors drm reports: Jan 23 15:03:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 15:27:35 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:05:40 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:09:07 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:20:30 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:20:49 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:30:49 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 16:32:23 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 16:44:46 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:19:17 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 17:33:51 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:35:18 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 17:47:09 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 17:49:58 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 18:02:08 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 19:20:16 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting Jan 23 19:30:34 mb /bsd: drm:pid35173:iomfb_poweroff_v12_3 *ERROR* dcp_poweroff() done Jan 23 19:41:14 mb /bsd: drm:pid35173:iomfb_poweron_v12_3 *ERROR* dcp_poweron() starting That pid is the X process. The times are when the screensaver kicks in. After 'xset s blank s activate', the screen blanks for a moment, but lights backup up almost immediately, dimmed; after Fn+F2 (on this macbook) it lights up fully. How can I debug this? Thank you for the continuous improvements. Jan before: OpenBSD 7.4-current (GENERIC.MP) #0: Wed Dec 27 11:51:08 CET 2023 h...@mb.stare.cz:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 7991373824 (7621MB) avail mem = 7619371008 (7266MB) random: good seed from bootblocks mainbus0 at root: Apple MacBook Air (M1, 2020) efi0 at mainbus0: UEFI 2.10 efi0: Das U-Boot rev 0x20230700 cpu0 at mainbus0 mpidr 0: Apple Icestorm r1p1 cpu0: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu0: 4096KB 128b/line 16-way L2 cache cpu0: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR cpu1 at mainbus0 mpidr 1: Apple Icestorm r1p1 cpu1: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu1: 4096KB 128b/line 16-way L2 cache cpu1: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,VH,CSV3,CSV2,DIT,SBSS+MSR cpu2 at mainbus0 mpidr 2: Apple Icestorm r1p1 cpu2: 128KB 64b/line 8-way L1 VIPT I-cache, 64KB 64b/line 8-way L1 D-cache cpu2: 4096KB 128b/line 16-way L2 cache cpu2: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,A
Re: Huawei K5161h 4G dongle
On Tue, Jan 23, 2024 at 11:52:01AM +, Alex Frolkin wrote: > Hi all, > > Has anyone had any success with getting a Huawei (Vodafone-branded) > K5161h 4G dongle working on OpenBSD? > > It looks like it should work with the umb(4) driver, but the problem is > getting it into the right mode. When I plug it in, it appears as a USB > CD drive, and there are magic commands you can send to it to make it > appear either as an Ethernet interface (where it does NAT and DHCP for > you, should be supported by the cdce(4) driver) or as an MBIM device > plus three USB serial ports (which should be supported by umb(4) and > hopefully ucom(4)). > > On FreeBSD and Linux, the mode switching is done by usb_modeswitch, > which supports switching it to either mode. usb_modeswitch compiles > fine on OpenBSD, but fails to actually send the magic command, and the > error code (from the usb_bulk_io function in libusb) says "unsupported > on this platform". > > The other approach is to find a magic AT command that would switch it to > MBIM mode permanently, but I've failed to find anything online for this > model, and AT commands that I've found for other models don't work on > this one. > This may sound silly, but does ejecting it (e.g. "eject /dev/cd0") make a difference? I seem to recall some devices that (temporarily) switched mode after being ejected. --
Huawei K5161h 4G dongle
Hi all, Has anyone had any success with getting a Huawei (Vodafone-branded) K5161h 4G dongle working on OpenBSD? It looks like it should work with the umb(4) driver, but the problem is getting it into the right mode. When I plug it in, it appears as a USB CD drive, and there are magic commands you can send to it to make it appear either as an Ethernet interface (where it does NAT and DHCP for you, should be supported by the cdce(4) driver) or as an MBIM device plus three USB serial ports (which should be supported by umb(4) and hopefully ucom(4)). On FreeBSD and Linux, the mode switching is done by usb_modeswitch, which supports switching it to either mode. usb_modeswitch compiles fine on OpenBSD, but fails to actually send the magic command, and the error code (from the usb_bulk_io function in libusb) says "unsupported on this platform". The other approach is to find a magic AT command that would switch it to MBIM mode permanently, but I've failed to find anything online for this model, and AT commands that I've found for other models don't work on this one. What it looks like in dmesg: - umass0 at uhub0 port 1 configuration 1 interface 0 "HUAWEI_MOBILE HUAWEI_MOBILE" rev 2.00/1.02 addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets, initiator 0 scsibus3 targ 1 lun 0: removable serial.12d11f1d456789ABCDEF not configured - What usbdevs -v says: - addr 02: 12d1:1f1d HUAWEI_MOBILE, HUAWEI_MOBILE high speed, power 2 mA, config 1, rev 1.02, iSerial 0123456789ABCDEF driver: umass0 - What usb_modeswitch says: - # usb_modeswitch -v 12d1 -p 1f1d -X Look for default devices ... Found devices in default mode (1) Access device 002 on bus 000 Get the current device configuration ... Current configuration number is 1 Use interface number 0 with class 8 Use endpoints 0x01 (out) and 0x81 (in) Using alternative Huawei switching message Looking for active drivers ... Can't do driver detection on this platform. Set up interface 0 Use endpoint 0x01 for message sending ... Trying to send message 1 to endpoint 0x01 ... Sending the message returned error -12. Try to continue Read the response to message 1 (CSW) ... Response reading failed (error -12) Device is gone, skip any further commands -> Run lsusb to note any changes. Bye! - I don't think it should make a difference, but I'm trying to do this on the Octeon platform (EdgeRouter 6P). Any ideas appreciated. Many thanks, Alex
