I'm using OpenWRT or derivatives since the stone age, and over the years I never had major problems, until the last week.
In short I decided to upgrade to 5G my connectivity, and I tested various devices, notably a Fibocom FM350, a One plus Nord and a Redmi 10 5G.
I got working all of them w/o much troubles except for the Redmi 10 5G
With that device, the connection over USB is limited to something like 5/10Mbps, while with the Oneplus Nord 5G I got over 300Mbps.
Also I got 300+ Mbps connecting the affected Redmi to Windows.
In short
AR750s <------>One plus nord 5G = Good
AR750s<------->Any 4G device I own = Good
AR750s<------->Redmi 10 5G = Bad (slow)
Windows<------>Any of the above = Good
The only clue I have comes from the result of lsusb -vvv
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 3 RNDIS
iInterface 5 RNDIS Communications Control
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 01
** UNRECOGNIZED: 04 24 02 00
** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
That UNRECOGNIZED part look souspicious to me, but I'm not a coder.
Any Idea?
P.S. that Redmi 10 5G is also the first android phone since 2009 I'm unable to root, so I cant't experiment on the Android side of the matter
Maybe show ubus call system board and restore cut pieces from lsusb -vv - device identifiers and power steps.
Can you explain whats so suspicious about unrecognized attributes? They are in usermode tool without any influence on kernel.
Can you explain whats so suspicious about unrecognized attributes?
I didn't mean it's "so suspicious" I mean is the only thing that to my (not so trained) eye looked different from other devices, say my personal phone, which is a Galaxy A8 2018 (4G device).
I stripped the log just because (for some reasons) the board engine didn't let me to post the whole thing, I'll try again ASAP, given I'm not at home right now.
tl;dr; unrecognized by lsusb but recognized by the drivers if necessary
Those are "communication" class functional descriptors, which are obviously invalid on a "wireless" class funtion. But that's a deliberate and expected breakage. RNDIS is a mess invented by people who ignored the USB class definitions to create their buggy non-standard proprietary USB devices.
So lsusb respects the USB-IF class specs and ignores those descriptors, but the Linux drivers will still interpret the descriptors which make sense. Like that
05 24 06 00 01
which is a CDC Union descriptor tying interface 0 and 1 to this function. Which is necessary since the control interface you're showing only has an interrupt enpoint. We need the two bulk endpoints which I assume are included in interface 1.
This is all completely unrelated to the described issue.
Those are "communication" class functional descriptors, which are obviously invalid on a "wireless" class functions.
Well what you're saying makes sense in theory. But practice tells me that if only one device over four wireless ones shows those urnecognized "things", the matter doesn't look so "obvious"...
To mee that smells more like as an exception rather than a rule.
Below you can read what lsusb has to say about my A8-2018, for comparison.
Bus 001 Device 007: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04e8 Samsung Electronics Co., Ltd
idProduct 0x6860 Galaxy (MTP)
bcdDevice 4.00
iManufacturer 1 SAMSUNG
iProduct 2 SAMSUNG_Android
iSerial 3 ******snip*******
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 mtp
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 5 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 105
bNumInterfaces 3
bConfigurationValue 2
iConfiguration 4 mtp
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 5 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 8 CDC Serial
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 6 CDC Abstract Control Model (ACM)
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 2
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 1
bSlaveInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 7 CDC ACM Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 2
Device Status: 0x0000
(Bus Powered)
P.S. I forgot to say that I tested the affected phone also on a virtual router I use often (a Hyper-V or VMware VM running x86 or x86_64 OpenWRT) using Windows as host. And the situation looks the same, so I tend to exclude problems related to the power supply.
The phone is fast if connected to host, the phone is slow if connected to the VM.
boot openwrt off a flash drive, to bypass the VM layer ...
Given I have native devices that don't work, the point of testing that under virtualization was to check if Windows did some magic initialization that then survived after the device was routed to the VM.
Which is exactly the opposite of what you're suggesting
It wasn't the case.
If I want to test natively on x86 all I have to do is to boot a random linux distro (for the record I did that test as well and the connection was still slow)
Give looks like no one is able to help, I add something that may be useful for other people who land in this thread.
Out of curiosity I tested a FreeBSD VM to see it is slow as Linux and...
It doesn't, I got 100+ mbps, which isn't bad at all for a VM and, while not as fast as a native Windows install, it's still 10x/15x faster than Linux.
So, I guess, I have no hope, the Linux driver must have something broken, and I doubt that the "genius" at kernel.org, who decided to deprecate that driver (used by thousands,if not millions, of people) would care of that problem at all.
I use virtualization since the first beta of vmware, when the current year started by 1 and not 2. So Yes I have half an idea of what virtualization can do.
But the point is, what your sentence has to do with the topic?
The point is the speed of the usb0 connection, not the actual speed of the Host <--->Guest connection.
Unless the latter was limited to a very low speed, say 5/10Mbps, it's irrelevant if I have 100 or 300 Mbps on eth0 if Linux cant get past 10Mbps over usb0
I hoped in a quick solution from people that possibly faced the same problem.
Something like say, "yes sure just do rmmod rndis_host && modprobe rndis_host --force-something"
But I see that's not the case.
For now my phone is in the hand of RRAS, and Openwrt does just the hotspot part. Not what I wanted but It works.
I already explained in the previous messages, but I summarize again.
It works perfectly with windows host
I assume it works perfectly with FreeBSD host
It works poorly with OpenWRT and Linux x86 (both physical or virtualized)
It works poorly with the stock FW
It works poorly with Golden ORB as well
On the other hand the very same router worked decently using a different 5G smartphone using OpenWRT, (around 150Mbps) and perfectly with GoldenORB (around 300Mbps).
USB passthrough for example cannot sustain webcams
Sure... you must explain that to my (virtualized) TVheadend server that manages 4K TV w/o a sweat, using an USB tuner. It used to serve fullHD TV since the day the digital switch happened in my country (2012 IIRC), and does that using USB2 not USB3.
I'm not that skilled in understanding the relationship between the various USB protocols/sub protocols and related drivers, but I believe cdc_ethernet is loaded anyway using rndis, it's a sort of parent driver.
The last phones I remember working with cdc_ethernet alone were the [Sony]Ericsson smartphones and featurephones that are (sadly) matter of the past.
Whatever, like I said there isn't much I can do from the phone side given it's my first not rooted Android in 16 years, so rndis is what I have.
Formore generic usb test try up/downloading huge file.
Speaking of upload... I missed to mention another "funny" fact....
Upload is fine, my provider limits it to 20Mbps and I got 20Mbps transfer on the affected setup. (which is twice the download speed).
