EC25-AF w/ Verizon call_end_reason_verbose is 241

IoT Modules LTE Standard Module
1

I’m running an EC25-AF with Verizon SIM.

I get the following error continuously (it retries every 60 seconds).
call_end_reason is 1
call_end_reason_type is 2
call_end_reason_verbose is 241

I couldn’t find any docs on verbose call_end reasons. What’s 241 mean?

Here’s more output:
[03-22_20:38:14:911] Auto find qmichannel = /dev/cdc-wdm0
[03-22_20:38:14:911] Auto find usbnet_adapter = wwan0
[03-22_20:38:14:911] netcard driver = qmi_wwan, driver version = 22-Aug-2005
[03-22_20:38:14:911] Modem works in QMI mode
[03-22_20:38:14:917] cdc_wdm_fd = 7
[03-22_20:38:14:989] Get clientWDS = 17
[03-22_20:38:15:029] Get clientDMS = 2
[03-22_20:38:15:052] Get clientNAS = 3
[03-22_20:38:15:085] Get clientUIM = 2
[03-22_20:38:15:116] Get clientWDA = 1
[03-22_20:38:15:149] requestBaseBandVersion EC25AFFAR07A08M4G
[03-22_20:38:15:277] requestGetSIMStatus SIMStatus: SIM_READY
[03-22_20:38:15:278] requestSetProfile[1] vzwinternet///0
[03-22_20:38:15:340] requestGetProfile[1] vzwinternet///0
[03-22_20:38:15:372] requestRegistrationState2 MCC: 311, MNC: 480, PS: Attached, DataCap: LTE
[03-22_20:38:15:405] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
[03-22_20:38:15:405] ifconfig wwan0 down
[03-22_20:38:15:415] ifconfig wwan0 0.0.0.0
[03-22_20:38:15:436] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
[03-22_20:38:15:437] call_end_reason is 1
[03-22_20:38:15:437] call_end_reason_type is 2
[03-22_20:38:15:437] call_end_reason_verbose is 241
[03-22_20:38:15:437] try to requestSetupDataCall 5 second later
[03-22_20:38:20:461] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
[03-22_20:38:20:461] call_end_reason is 1
[03-22_20:38:20:461] call_end_reason_type is 2
[03-22_20:38:20:461] call_end_reason_verbose is 241
[03-22_20:38:20:461] try to requestSetupDataCall 10 second later
[03-22_20:38:30:478] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
[03-22_20:38:30:478] call_end_reason is 1
[03-22_20:38:30:478] call_end_reason_type is 2
[03-22_20:38:30:478] call_end_reason_verbose is 241
[03-22_20:38:30:478] try to requestSetupDataCall 20 second later
[03-22_20:38:50:543] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
[03-22_20:38:50:543] call_end_reason is 1
[03-22_20:38:50:543] call_end_reason_type is 2
[03-22_20:38:50:543] call_end_reason_verbose is 241
[03-22_20:38:50:543] try to requestSetupDataCall 40 second later

2

Hello Stephen_Smith, thanks for your question
You can try to kill the dialing process, and then restart the AP to perform the dialing operation, thank you.

3

Hey Duncan, I’ve tried restarting this many times. I’ve tried letting it run for an hour. No luck. Any other ideas?

4

Call end reason 1 == “generic unspecified”
Call end reason type 2 == “internal”
Call end reason verbose == “interface in use, config match”

Those values are also defined in libqmi, see https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/blob/master/src/libqmi-glib/qmi-enums-wds.h

absolutely no idea why that happens though :slight_smile: don’t think I’ve personally seen that error when using libqmi+ModemManager

5

Hello, Stephen_Smith
you can try uninstall modemmanager, modemmanager is a module management software, because it will also read and write our modules, which will interfere with our testing, so it needs to be uninstalled.

apt remove modemmanager

If the problem persists, you can grab the exception log email to support@quectel.com, we will provide more help, thank you.

6

Hello,

I am having the exact same issue with my RM520N-GL modem.

call_end_reason is 1
call_end_reason_type is 2
call_end_reason_verbose is 241

Were you ever able to resolve the issue on your end?

I found a “hack” that always solves my issue - if I launch quectel-CM using the APN “vzwapp”, close that, then re-launch, I do not have this issue. But I don’t want to use this hack long-term.

7

Unfortunately, no. At the time, we were running about 10 Verizon lines and they would intermittently experience this issue - best correlation was bad signal. We’ve switched away from Verizon and now run >100 ATT lines with no issues. T-Mobile is also good, but we don’t use them as often.

8

I finally solved my issue. I thought it was related to signal, but the issue would happen so intermittently and when I did have a working connection, bandwidth was high.

The solution:
Execute these AT commands, then reboot:

AT+QMBNCFG=“AutoSel”,0
AT+QMBNCFG=“Deactivate”
AT+CFUN=1,1

If the first AT+QMBNCFG=“AutoSel”,0 command gives an error, run AT+QMBNCFG=“list” first.

Make sure to escape the double quotes if you are using a script or service to send the AT commands.