Modem no longer working

[elw3]

#! /bin/bash
date
while [[ -f "/dev/ttyACM1" ]]; do
 sleep 1
done
date

May work, without warranty.

 

[elw3]

Man i hate bash, i had to ask for how to make it work in a terminal instead a script...

date; while [[ -f "/dev/ttyACM1" ]]; do sleep 1; done;date

 

[levi]

Yeah, I don't know why example writers tend to put the do on the same line as the condition. If you put that before the sleep instead then the translation is just to replace every newline with a semicolon. Putting the do in the inner block also allows you to indent them without running out of width on 80 character displays more often.

Edit: Scanning through that debug log you posted, it does seen to find various devices in different /dev/ttyACM[n]s. It seems to determine that /dev/ttyACM2 is the GPS module, but it generally has trouble getting anything to respond to an AT command.

 

[elw3]

Wait, i just realized the ; behind the condition isnt actually part of the syntax.
NOW i get it, ive been using bash wrong all this years.

Yes the modem creates 4 ports, that part is fine. And we see that whatever happens happens during probing one of it.
It says its using only the cinterion plugin. On my log it mentions the actual device "pls8" instead.
I gather it either uses the wrong probe plugin, maybe because the device does not report itself correctly or the port was set to the wrong type at the modem.

Personally i never realized how much modem manger accesses the device until this thread.
On my desktop for example it dumps out my entire sms memory every boot. Why?
There is stuff going on that clearly should not be done as none of it is needed to start a network connection.
I may consider ripping that thing out and just use wvdial again.

 

[levi]

On most phones I've used since about 1995, any SMSes on the card are dumped out to main memory. The space on the SIM for SMSes is very limited, to to receive and keep more than a handful of them they need to be moved to main memory. It seems a little strange it is doing that when you only asked for a network connection, but maybe it's just preempting that you will want to do that once we handle SMSes better.

 

[elw3]

No it does this when its plugged in, as in: You plug the modem in and automatically sms are read and stored in modemmanager, not removed from the sim thus it happens every plugin with the same messages.
There is no actual usage by the user whatsoever, simply plugging the device in makes the messages read.
This is not only a security risk, having your messages in ram all the time, but i also wonder if this constant reading can cause damage to the sim. After all its doing this every reconnect. A few times per day.

 

[Silent-Hunter]

#! /bin/bash
date
while [[ -f "/dev/ttyACM1" ]]; do
sleep 1
done
date

May work, without warranty.

I'll give that a try, thanks!

 

[fritata]

Too tired to fully understand the thread, but I had the same issue I think. (Modem just gone from NetworkManager gui options and ModemManager). Please try "nmcli radio wwan on" in terminal, then just "nmcli radio wwan" to see if its enabled (takes some time). This fixed it for me.

Edit: I have found another scenario in which the modem is unusuable and I think I know how to reproduce/fix it. May post here later if I figure it out.

2nd Edit: I think I figured out 1 issue that may or may not be the cause. Turning the device off and immediately on (At least for my US 4G Pyra) causes several error messages in the kernel buffer/dmesg output that say:
ehci-omap 4a064c00.ehci: port 2 reset error -110
repeated several times followed by:
usb usb1-port2: Cannot enable. Maybe the USB cable is bad?
Googling the error number -110 reveals something wrong with usb device resume after a suspend, and recommended waiting 5 minutes before turning back on what device (server, laptop, etc) you have.

So basically the following is my ritual to bring back the modem:
1. nmcli radio wwan off
2. Turn the pyra off
3. *Listen to this to pass the time*
4. Turn the pyra on
5. nmcli radio wwan on
6. Wait 1 minute
It works.

Further googling reveals a miriad of omap ehci initialization issues so I share with you what I think is the most likely candidate because:
1. It mentions running "usb start" during uboot which the pyra uboot does
2. It mentions the fix causing a regression in OMAP 5
I am not a developer/programmer and have no idea what that commit/patch does so this post may be little more trustworthy than gas station bathroom graffiti.
OMAP EHCI issue link: https://marc.info/?l=linux-usb&m=134098423528415&w=2