U-blox MPCI-L210 LTE modem: cdce(4) unable to get the MAC address of the device
Hi misc@, While testing the U-blox MPCI-L210 LTE modem on OpenBSD -current (the modem is attached as a cdce(4) device, the router mode is enabled; other modes are also available), I noticed that the automatic configuration via DHCP works correctly, but the MAC address assigned to the corresponding cdce0 network interface is different from the MAC address reported by lsusb -v. Unfortunately, due to this mismatch, incoming Ethernet frames having the actual MAC address of the device set as the destination address in the header are dropped by the kernel in the ether_input() function (/src/sys/net/if_ethersubr.c). Based on an analysis of the source code (/sys/dev/usb/if_cdce.c) and the results of the subsequent experiments, I was able to confirm that the cdce driver is unable to get the MAC address of the device (in particular, the usbd_get_string_desc() function returns USBD_STALLED instead of USBD_NORMAL_COMPLETION), and as a result, a semi-random fake Ethernet address is set: - 306 if (!ethd || usbd_get_string_desc(sc->cdce_udev, ethd->iMacAddress, 0, 307 &eaddr_str, &len)) { 308 ether_fakeaddr(ifp);// < Set a semi-random MAC address 309 } else { - As a temporary workaround, I manually set the MAC address of the cdce0 interface to the value reported by lsusb -v using ifconfig(8). I would appreciate your comments and suggestions about how this issue could be investigated further, and I would be happy to provide additional information that might be helpful in the preparation of the corresponding fix. Meanwhile, please find below the related output of the 'lsusb -v' command. Thank you very much for your time. Best wishes, Andrzej - Bus 001 Device 003: ID 1546:1143 U-Blox AG Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1546 U-Blox AG idProduct 0x1143 bcdDevice1.00 iManufacturer 1 u-blox iProduct2 MODEM-LTE iSerial 3 0100 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 278 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 4 CDC Ethernet Control Model (ECM) CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface0 bSlaveInterface 1 CDC Ethernet: iMacAddress 6 bmEthernetStatistics0x wMaxSegmentSize 1514 wNumberMCFilters0x bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 5 CDC Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endp
Re: dhcpleased: interface "stalls" during Renewing
Peter Gorsuch(gorsu...@cfw.com) on 2021.11.13 08:25:00 -0500: > Hi All, > > As [Renewing] begins and during the renewing cycle (as I view > configuration with dhcpleasectl -l fxp0) about halfway through the > ISP'one hour dhcp lease, the external interface seems to become "stalled". > > "Stalled" is a term that describes the experience of using a host on the > lan, as one's video is fine, then stops, then starts up again after some > period of time. > > This on a dual homed i386 GENERIC installation planned to be a router > and run unbound and dhcp for the lan. > Subject to my understanding, I'm informed by > https://www.mail-archive.com/misc@openbsd.org/msg180064.html and I > imagine there is some interplay with the dhcp rebinding/renewing > timer(s) and name resolution. Have you tried the fix suggested by florian@ in that thread? If not you can upgrade to the latest snapshot, that change was commited yesterday.
Re: Question to usbdevs and dmesg
Hi! There is also sysutils/usbutil which provides usbgen package With that you could get the USB descriptors with something like: doas usbgen -D -v -f /dev/ugen1 on OpenBSD. However AFAICT it works with generic ugen devices. I don't know how to debug for example a USB mass media device. That being said, I have missed many times non-existing verbosity level for usbdevs which would dump at least device descriptor. Would this be desirable enhancement? Best regards, Hannu Vuolasaho 2021-11-14 16:46 UTC+02.00, Kenneth Gober : > On Sun, Nov 14, 2021 at 9:18 AM Sven Wolf > wrote: > >> I've attached an XBOX 360 controller to my system. >> The controller gets detected as: >> usbdev: >> addr 02: 045e:028e \M-)Microsoft Corporation, Controller >> >> dmesg: >> uhidev1 at uhub1 port 1 configuration 1 interface 0 "\M-)Microsoft >> Corporation Controller" rev 2.00/1.14 addr 2 >> >> ugen1 at uhub1 port 1 configuration 1 "\M-)Microsoft Corporation >> Controller" rev 2.00/1.14 addr 2 >> >> Do you have an idea why the controller is detected as >> "\M-)Microsoft Corporation, Controller" and not as >> "XBOX 360 Controller" as it is defined in >> /usr/src/sys/dev/usb/usbdevs >> "vendor MICROSOFT 0x045e Microsoft" >> "product MICROSOFT XBOX360_CONTROLLER 0x028e XBOX 360 Controller" >> > > That is probably the name reported by the controller itself. > > Ben Eater has a pretty good video on YouTube covering USB device discovery: > https://www.youtube.com/watch?v=N0O5Uwc3C0o > > The bit about retrieving descriptors from the device is about 16 minutes > in. > > -ken >
Re: Question to usbdevs and dmesg
On Sun, Nov 14, 2021 at 9:18 AM Sven Wolf wrote: > I've attached an XBOX 360 controller to my system. > The controller gets detected as: > usbdev: > addr 02: 045e:028e \M-)Microsoft Corporation, Controller > > dmesg: > uhidev1 at uhub1 port 1 configuration 1 interface 0 "\M-)Microsoft > Corporation Controller" rev 2.00/1.14 addr 2 > > ugen1 at uhub1 port 1 configuration 1 "\M-)Microsoft Corporation > Controller" rev 2.00/1.14 addr 2 > > Do you have an idea why the controller is detected as > "\M-)Microsoft Corporation, Controller" and not as > "XBOX 360 Controller" as it is defined in > /usr/src/sys/dev/usb/usbdevs > "vendor MICROSOFT 0x045e Microsoft" > "product MICROSOFT XBOX360_CONTROLLER 0x028e XBOX 360 Controller" > That is probably the name reported by the controller itself. Ben Eater has a pretty good video on YouTube covering USB device discovery: https://www.youtube.com/watch?v=N0O5Uwc3C0o The bit about retrieving descriptors from the device is about 16 minutes in. -ken
Question to usbdevs and dmesg
Hi list, I've attached an XBOX 360 controller to my system. The controller gets detected as: usbdev: addr 02: 045e:028e \M-)Microsoft Corporation, Controller dmesg: uhidev1 at uhub1 port 1 configuration 1 interface 0 "\M-)Microsoft Corporation Controller" rev 2.00/1.14 addr 2 ugen1 at uhub1 port 1 configuration 1 "\M-)Microsoft Corporation Controller" rev 2.00/1.14 addr 2 Do you have an idea why the controller is detected as "\M-)Microsoft Corporation, Controller" and not as "XBOX 360 Controller" as it is defined in /usr/src/sys/dev/usb/usbdevs "vendor MICROSOFT 0x045e Microsoft" "product MICROSOFT XBOX360_CONTROLLER 0x028e XBOX 360 Controller" Thanks, Sven
Re: X.org segmentation fault - snapshot amd64
On Sat, Nov 13, 2021 at 06:31:24PM -0800, ariel a wrote: Please repoprt bugs on bugs@ instead of on misc@, not all developers read misc@ -Otto