Change modem mode by UDEV

dev_odyssey · October 15, 2021, 8:57pm

Thanks for sharing! Honestly this is quite ironic, as I was literally referring to their documentation here (Section 2.2.2 Driver option)

And I saw that command! But when I typed it out, I did the following:

echo 1bc7 1201 > /sys/bus/usb-serial/drivers/option1/new_id

In my terminal, then rebooted, but my serial interfaces did not come back up. I wasn't too sure I understood if it would work, but given what they wrote, it seemed promising. I wasn't exactly sure what my PID was.

You'll have to excuse me as my knowledge of the kernel at this level is not very deep, (but I'm learning as I go along). So with the echo command you provided, you found this in the kernel mailer that @bmork just referenced, correct?

Then once execute this command, do I use the command qmicli --device-open-mbim -p -d /dev/cdc-wdm0 --dms-swi-set-usb-composition=# to change the composition? And I won't have to update my OpenWrt snapshot to do this? (Sorry for all the questions, I'm very new to this, in terms of cellular modems, I'm 3 days in)

@bmork

Wow what timing! October 4th. I just got this modem almost at the right time! I actually bought this modem from sixfab (https://sixfab.com/product/raspberry-pi-4g-lte-modem-kit/) with their LTE HAT for raspberry pi, but wanted to do this on OpenWrt. I just liked the form factor of a HAT versus using a usb dongle, because well, it protrudes too much haha. Otherwise, If I had a board with a mini PCI slot, I'd certainly be using that. I'll get one of those in the future to play around with.

Glad to hear they are doing their job!

I look forward to when it gets into the stable build and then into OpenWrt!

Slightly off topic, but in terms of modems, would you recommend Sierra Wireless over Telit? From my research, I see that Sierra Wireless has quite the community around it (just like OpenWrt), which makes me gravitate to using their modems in the future.

Thank you so much for your help, you're really helping me out of a bind.

AndrewZ · October 15, 2021, 9:54pm

As I wrote earlier, that qmicli command has nothing to do with your case.

If you want to keep using your modem in its current mode, you will need to add the echo line mentioned into /etc/rc.local before exit 0.
If you only want to switch the modem into another working mode, run that echo command manually once, do not reboot, run a terminal like picocom and switch your modem to the mode you need.

dev_odyssey · October 16, 2021, 2:38am

Right, I do understand that. My only means of qmicli in this scenario was just to find a way to change the usb composition. Through my bouts of googling, I stumbled upon the qmicli command, referenced here, and also in the sierra wireless forum, that might be able to change my usb composition, since I only knew how to do it via AT commands. But yes, qmicli is definitely independent of the issue, and I hoped it was as a means to an end. My apologies if I implied that it was the part of the issue.

Nonetheless, I do really appreciate the attention you gave to the procedural detail, since I wasn't sure what would happen after I invoked that command. Once I did so, I checked dmesg like so:

root@OpenWrt:~# echo "1bc7 1204 ff" > /sys/bus/usb-serial/drivers/option1/new_id
root@OpenWrt:~# dmesg | grep ttyUSB
[  285.332831] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
[  285.346603] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
[  285.360441] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
[  285.374222] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
[  285.388017] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
[  285.401768] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5

And my usb interfaces came back up Only if I knew it was so simple! After that I invoked minicom to change my usb composition back to 0 that lets me get back to the usb serial interface easily. At least I know now how "not to get stuck again" just in case I do.

Also thanks for that tidbit on adding it to /etc/rc.local if I wanted to keep the same usb composition, thats a neat way of getting around it to persist the changes on boot.

Thank you so much for the help and explanation. You've saved me countless more hours that I already spent and would've spent more trying to figure out this issue, and at worst just buying a new modem. I sincerely appreciate it, as I now understand usb interface and drivers in linux just a bit better

Hope you don't mind if I have I have just one more question. What does the ff in echo "1bc7 1204 ff" > /sys/bus/usb-serial/drivers/option1/new_id signify?

I do get that 1bc7 is the idVendor, and 1204 is the idProduct, but can't seem to find that the ff means.

Thanks in advance!

bmork · October 16, 2021, 8:25am

I believe they're both very good choices, based on the publicly available documentation and customer support I can observe in open forums. I don't want to recommend one of them over the other.

AndrewZ · October 16, 2021, 8:33am

ff is USB bInterfaceClass, see Cls=ff(vend.) in your post.

Cat6 Sierra is always better than Cat4 Telit.

bmork · October 16, 2021, 8:40am

QMI is only a transport channel similar to AT commands. It allows communication between a number of modem subsystems and the host. Most of the subsystems and requests are common to all Qualcomm devices (of the same generation at least), but vendor specific and device specitic subsystems and requests are also possible.

USB function layout management is a very device specific functionality, regardless of whether it is controlled by AT commands or QMI, or something else. The qmicli solution discussed here is using a vendor specific QMI request only available on a very limited number of Sierra Wireless devices. It is not a generic solution.

I don't know if Telit have implemented something similar using QMI. But I don't see a really good reason they should have. Selecting a specific USB composition isn't the sort of change you would normally do. It's more like a one time setup. Using AT commands for that is fine. The important part is that the procedure and options are well documented. And AFAICT, Telit are among the best there.

EDIT: A good reason for Sierra Wireless adding this QMI feature is of course that they allow disabling the AT command function. I don't think Telit allows that in any composition, so AT commands will always work for them. Modulo driver issues like you stumbled across. But those are easy to fix, at least in Linux. And the method is even documented by Telit as you pointed out.

dev_odyssey · October 16, 2021, 2:32pm

Thats fair and understandable. From I have seen great documentation from Telit that helped me get this far, along with a decent knowledge base. It seems like there's a great community around sierra wireless that are big open source fans. Though, with Telit committing to the kernel to maintain support for their products, I can claim they're good in open source support as well. Looks like they're both great choices

@AndrewZ

Ahh I see now, thanks for pointing that out. I'll have to spend more time researching what these classes do (if anything else other than just an identifier).

Thats true as well, CAT 6 will definitely provide better performance. Something I think I'll look into for the future when trying out different modems for other OpenWrt cellular deployments. My initial use case for this is to create a failover / multi WAN setup on a home router for internet backup. I can certainly say when working from home the past few years, I've had numerous times of internet outages where a cellular backup would've provided seamless failover without even noticing the primary WAN connection failed. Plus I can see many others benefit from this as well, and hope to share my results once I get something stable up and running.

@bmork

Thanks for the very detailed and informative explanation. I didn't realize at first that this qmicli command was vendor and device specific. Getting the same error response when using that command didn't help to clear that up for me. I have a better understanding now, and was unaware of vendor specific and device specific subsystems and requests as it relates to transport channels like QMI and AT.

For deployment of these modems, I can see why a command like this wouldn't be a something necessary, since it seems like deployments are a "one and done" kind of event as you noted. For the tinkerer like me, my use case is the opposite for learning purposes . Those pdf documents Telit has on all their AT commands has been great for me thus far when tinkering with this modem so I can troubleshoot and connect to cellular networks, since this process for me hasn't been the most straightforward, as I'm sure you can see. I applaud them for that.

That is an interesting use case for Sierra Wireless, so that command makes sense for them. I'm glad that Telit doesn't allow disabling of AT command function in any composition, as otherwise I might've been completely stuck, other than possibly re-flashing the firmware (if doing so didn't require AT commands, otherwise I really wouldn't know what to do). So just that I understand, the issue I ran into was a "feature not enabled in Linux" scenario from Telit? And that they just got to enabling it with that commit on October 4th? Certainly glad this was an easy fix, especially in Linux (I've become a *nix guy over the years), and happy their documentation was just about comprehensive enough for me to resolve the issue.

Thanks again for the information, and good conversation too