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 _str, )) {
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
Endpoint
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
