Re: U-blox MPCI-L210 LTE modem: cdce(4) unable to get the MAC address of the device
>>> On Sun, Nov 14, 2021 at 10:40:28PM +0100, na...@poczta.fm wrote:
>>> 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 {
>>> -
>>
>> Can you find out what happens on Linux?
>>
>> Their cdc_ether driver seems to be doing exactly the same thing. So with
>> this driver you would also end up with a random MAC if the device fails
>> to respond to a mac address query. In this case I have no idea what else
>> could be done apart from using the workaround you have already found.
>>
>> But Linux has more CDC sub-drivers than we do, and runs some devices in
>> specialized modes.
>> Perhaps Linux performs a mode switch and uses a different driver for e.g.
>> MBIM mode? If that is the case then we could change our drivers to try to
>> switch this device into a mode where it works better.
>>
>>
>
> Hi Stefan,
>
> Thank you for your prompt reply.
>
> Good point -- I remember that I tried to use this modem on Linux some time
> ago and it worked with no noticeable issues. I will take a closer look again
> on Friday this week, and I will summarize my findings in my next email.
>
> Best wishes,
> Andrzej
>
>
Hi Stefan, hi misc@,
Since my last email, I followed your suggestion and investigated how Linux
(Debian 11) handles the same modem operating in the CDCE mode, on the same
hardware platform. Please find below the corresponding summary.
On system startup (or whenever the modem device is restarted using the
following AT command: echo "AT+CFUN=16" > /dev/ttyACM0), the modem is
detected and attached properly by the cdc_ether/cdc_acm drivers (associated
with the data and control interfaces, respectively), as shown below:
-
usb 1-1.3: new high-speed USB device number 11 using ehci-pci
usb 1-1.3: New USB device found, idVendor=1546, idProduct=1143, bcdDevice= 1.00
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3: Product: MODEM-LTE
usb 1-1.3: Manufacturer: u-blox
usb 1-1.3: SerialNumber: 0100
cdc_ether 1-1.3:1.0 wwan0: register 'cdc_ether' at usb-:00:13.0-1.3, \
Mobile Broadband Network Device,
cdc_acm 1-1.3:1.2: ttyACM0: USB ACM device
cdc_acm 1-1.3:1.4: ttyACM1: USB ACM device
cdc_acm 1-1.3:1.6: ttyACM2: USB ACM device
cdc_ether 1-1.3:1.0 wwx: renamed from wwan0
-
At this point, the corresponding network interface can be configured
automatically using dhclient, and then, the Internet connection works as
expected.
I confirm that during my experiments on Linux, the network interface backed
by the cdc_ether driver was always assigned the same MAC address that could
be found in the dmesg/lsusb output related to the modem device (at the same
time, you may recall from my initial email that OpenBSD would assign
a semi-random MAC address instead, due to the stalled USB transfer following
an attempt to fetch the MAC string from the device).
To take a closer look at what exactly was happening during the device
attachment on Linux, I first analyzed the source code of the cdc_ether
driver and found the usbnet_cdc_bind() function in which the
usbnet_get_ethernet_addr() function is called:
-
https://github.com/torvalds/linux/blob/master/drivers/net/usb/cdc_ether.c
442 int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
443 {
(...)
453
454 status = usbnet_get_ethernet_addr(dev, info->ether->iMACAddress);
455 if (status <
Re: U-blox MPCI-L210 LTE modem: cdce(4) unable to get the MAC address of the device
>
> > On Sun, Nov 14, 2021 at 10:40:28PM +0100, na...@poczta.fm wrote:
>> 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 {
>> -
>
> Can you find out what happens on Linux?
>
> Their cdc_ether driver seems to be doing exactly the same thing. So with
> this driver you would also end up with a random MAC if the device fails
> to respond to a mac address query. In this case I have no idea what else
> could be done apart from using the workaround you have already found.
>
> But Linux has more CDC sub-drivers than we do, and runs some devices in
> specialized modes.
> Perhaps Linux performs a mode switch and uses a different driver for e.g.
> MBIM mode? If that is the case then we could change our drivers to try to
> switch this device into a mode where it works better.
>
>
Hi Stefan,
Thank you for your prompt reply.
Good point -- I remember that I tried to use this modem on Linux some time ago
and it worked with no noticeable issues. I will take a closer look again on
Friday this week, and I will summarize my findings in my next email.
Best wishes,
Andrzej
Re: U-blox MPCI-L210 LTE modem: cdce(4) unable to get the MAC address of the device
On Sun, Nov 14, 2021 at 10:40:28PM +0100, na...@poczta.fm wrote:
> 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 {
> -
Can you find out what happens on Linux?
Their cdc_ether driver seems to be doing exactly the same thing. So with
this driver you would also end up with a random MAC if the device fails
to respond to a mac address query. In this case I have no idea what else
could be done apart from using the workaround you have already found.
But Linux has more CDC sub-drivers than we do, and runs some devices in
specialized modes.
Perhaps Linux performs a mode switch and uses a different driver for e.g.
MBIM mode? If that is the case then we could change our drivers to try to
switch this device into a mode where it works better.
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
