On Mon, Jan 28, 2019 at 02:33:14PM +0000, Stuart Henderson wrote: > On 2019/01/28 16:59, James Hebden wrote: > > The patch should allow the device to register a cdce interface, rather > > than USB serial devices, allowing the device to be used at full > > capacity. > > > > Patch follows. > > Does this remove the AT command interface, or supplement it? > > If it removes, then it's difficult to know how best to proceed with a kernel > diff for this. Some people use these devices for SMS rather than internet > access. Sometimes they're used for providing access to a machine that is > somewhere inaccessible and a change in mode will either mean they need to > arrange access, or just stick with an old OS version.. >
Unfortunately this is a hard question for me to answer definitively, as I only have access to one device, and your point that not everyone has the same use for these devices is well taken. To your first question around the AT command interface - the switch message this patch sends is slightly changed from the original, to put the device into 'hilink' mode, and in hilink mode there are no USB endpoints which retain the serial converter required for sending AT commands / sending SMS. To your point about broader usage specifically, at least for my specific device, the device was not switching into a usable mode at all. I mentioned the AT command interface, as enabling these devices to function for Internet access with OpenBSD means getting the AT command interface configured for use with PPP, or getting HiLink mode configured for use as a USB Ethernet device. Regardless for me at least, this device was sitting in mass storage mode prior to these patches presenting a volume containing the Windows & OSX driver software. I'm not sure how to resolve the different uses. For folks running these in remote locations, the switchover could be riskier depending on their setup, I agree. For folks using these to send SMS messages - if they had a device that was previously switching into the AT command interface, then using this patch would see them lose access to the AT command interface. I'll look into seeing if we can retain an AT command interface in addition, because I believe that would be the best of both worlds. With that in mind, it is hard to tell what the behaviour is across devices, as the switching logic is shared amongst all 'UMASS5' devices, i.e. the new mode Huawei devices, from what I can tell.
