you might just need to ./MAKEDEV ttyU4 in /dev. there's only 4 (0 to 3) dev
entries for ucom devices by default, which look to be all taken by the quectel.
if you flip the ec25 to mbim mode and reboot then it should only take 3 ucom
slots. iirc you connect to interface 2 (cu -s 115200 -l /dev/cuaU2) on the
quectel and issue 'AT+QCFG="usbnet",2' to change the mode.
dlg
> On 7 May 2025, at 05:37, Manuel Kuklinski <m...@asdfghasdfgh.de> wrote:
>
> Hi!
>
> I have a CC2652RB Zigbee stick, which I cannot access via /dev/cuaU*,
> despite attaching at ucom(4), at least according to dmesg. It is
> initially recognized as uslcom(4):
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> uslcom0 at uhub3 port 5 configuration 1 interface 0 "Silicon Labs slae.sh
> cc2652rb stick - slaesh's iot stuff" rev 1.10/1.00 addr 2
> ucom4 at uslcom0 portno 0: usb3.0.00005.0
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> A Quectel EC25 is showing up properly at ucom{0,1,2,3} and can be
> accessed via /dev/cuaU{0,1,2,3}:
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> umsm0 at uhub1 port 1 configuration 1 interface 0 "Android Android" rev
> 2.00/3.18 addr 2
> ucom0 at umsm0: usb1.0.00001.0
> umsm1 at uhub1 port 1 configuration 1 interface 1 "Android Android" rev
> 2.00/3.18 addr 2
> ucom1 at umsm1: usb1.0.00001.1
> umsm2 at uhub1 port 1 configuration 1 interface 2 "Android Android" rev
> 2.00/3.18 addr 2
> ucom2 at umsm2: usb1.0.00001.2
> umsm3 at uhub1 port 1 configuration 1 interface 3 "Android Android" rev
> 2.00/3.18 addr 2
> ucom3 at umsm3: usb1.0.00001.3
>
> - - - - - - - - - - %< - - - - - - - - - -
>
> FWIW I can access the stick via macOS Sequoia 15.4.1 - I flashed a
> coordinator firmware via this machine on the stick. I'd be happy about a
> solution to access the stick on OpenBSD - if needed, I can provide more
> info...
>
> --
> Mit besten Wünschen /
> With best wishes,
>
> Manuel Kuklinski
>
