I have been struggling to setup this specific modem (which is required by new customers) to work with my openwrt router. I have been using for our previous customers RM500Q modem with support for multiple PDN before using the qmi_wwan_q driver and the quectel-cm tools (quectel-qmi-proxy and other additional scripts to set it up). While googling around, I found only one post (which was stating it as a hack - which is to use mbim mode). Now, I am even wondering if the driver supports qmi mode and if I can even use the quectel-cm tools to manage the connectivity? Thank you and looking forward. For sending the drivers: my email is: ekathva.advaita in gmail.
Thank you.
Most Quectel modems should work with standard QMI and MBIM Linux drivers.
If you need help with configuration, I suggest asking a question in OpenWrt forum.
I am using the same configuration as I had been using in the previous configuration with another modem. And the post I was referring to: you have commented it So, with the driver that I was provided previously, when I wrote the vendor product id in the new_id, I was getting the ttyUSB[0,1,2], but the /dev/cdc-wdm0 not being created. When I got the driver from the vendor who was supplying us with the modem, I managed to get the /dev/cdc-wdm0 device but not the ttyUSB*, which I fixed by adding hotplug to write that product vendor id. And for some reason, the quectel-CM was looking for wwan0 interface in the wrong directory, I fixed that one in quectel-CM and it is not still working. That is the reason, I am wondering if there is new driver and quectel-CM tools which is tested together. Thank you for the reply.
I have tried the standard qmi_wwan driver as well - that did not work (just like with the qmi_wwan_q which is being used with RM500Q, which I tried also with this modem). So, they don’t even create the /dev/cdc-wdm0 device with this modem. About quectel-cm, I don’t know how it was even acquired (I always thought that it is quectel provided - for some reason, it manages the connection - like using the proxy and setting up multiple PDN). I have no idea if I can do with what I get out of openwrt though! Do you have any specific documentation or example of that? Would be happy and thanful.
Now it seems to work - although it is taking some time for quectel-qmi-proxy to come alive. But once that is up, I see it up and running. Thank you very much. Okay, after testing it a bit more, I see that it is not supporting the multiple PDN. Am I missing something? And I still need to do: echo “2c7c 0316” > /sys/bus/usb-serial/drivers/option1/new_id to get the ttyUSB* exposed, and setup 4 profiles like this:
chat -t5 '' AT OK < /dev/$tty > /dev/$tty
chat -t5 '' AT OK 'AT+CGDCONT=1,""' OK < /dev/$tty > /dev/$tty
chat -t5 '' AT OK 'AT+CGDCONT=2,""' OK < /dev/$tty > /dev/$tty
chat -t5 '' AT OK 'AT+CGDCONT=3,""' OK < /dev/$tty > /dev/$tty
chat -t5 '' AT OK 'AT+CGDCONT=4,""' OK < /dev/$tty > /dev/$tty
wwan0_1 is up and running, but the error given below belongs to wwan0_2.
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:133] Modem works in QMI mode
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:134] connect to quectel-qmi-proxy0 sockfd = 7
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:134] cdc_wdm_fd = 7
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:196] Get clientWDS = 9
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:231] Get clientDMS = 3
Mon Jun 3 05:40:06 2024 user.notice mwan3-hotplug[10004]: mwan3 hotplug on qmi not called because interface disabled
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:264] Get clientNAS = 4
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:299] Get clientUIM = 3
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:332] Get clientWDA = 2
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:366] requestBaseBandVersion RG255CGLABR01A02M4G
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:400] qmap_settings.rx_urb_size = 16384
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:400] qmap_settings.ul_data_aggregation_max_datagrams = 11
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:400] qmap_settings.ul_data_aggregation_max_size = 8192
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:400] qmap_settings.dl_minimum_padding = 0
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:536] requestGetSIMStatus SIMStatus: SIM_READY
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:571] requestRegistrationState2 MCC: 244, MNC: 5, PS: Attached, DataCap: LTE
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:604] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:604] ip addr flush dev wwan0_2
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:610] ip link set dev wwan0_2 down
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:638] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:638] call_end_reason is 1
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:638] call_end_reason_type is 2
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:638] call_end_reason_verbose is 236
Mon Jun 3 05:40:06 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:06:638] try to requestSetupDataCall 5 second later
Mon Jun 3 05:40:11 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:11:664] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Mon Jun 3 05:40:11 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:11:665] call_end_reason is 1
Mon Jun 3 05:40:11 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:11:665] call_end_reason_type is 2
Mon Jun 3 05:40:11 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:11:665] call_end_reason_verbose is 236
Mon Jun 3 05:40:11 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:11:665] try to requestSetupDataCall 10 second later
Mon Jun 3 05:40:21 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:21:687] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Mon Jun 3 05:40:21 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:21:687] call_end_reason is 1
Mon Jun 3 05:40:21 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:21:687] call_end_reason_type is 2
Mon Jun 3 05:40:21 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:21:687] call_end_reason_verbose is 236
Mon Jun 3 05:40:21 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:21:687] try to requestSetupDataCall 20 second later
Mon Jun 3 05:40:41 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:41:724] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Mon Jun 3 05:40:41 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:41:724] call_end_reason is 1
Mon Jun 3 05:40:41 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:41:725] call_end_reason_type is 2
Mon Jun 3 05:40:41 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:41:725] call_end_reason_verbose is 236
Mon Jun 3 05:40:41 2024 daemon.notice netifd: qmi (10019): [06-03_05:40:41:725] try to requestSetupDataCall 40 second later
Thank you. Now it seems to be solved after I passed the different apn name in my chat command. That was in the hotplug, so, I never see any error and was thinking it was setting up the four profiles (which was not true). Now, I say - my problem is solved
So, with the driver that I was provided previously, when I wrote the vendor product id in the new_id, I was getting the ttyUSB[0,1,2], but the /dev/cdc-wdm0 not being created. When I got the driver from the vendor who was supplying us with the modem, I managed to get the /dev/cdc-wdm0 device but not the ttyUSB*, which I fixed by adding hotplug to write that product vendor id. And for some reason, the quectel-CM was looking for wwan0 interface in the wrong directory, I fixed that one in quectel-CM and it is not still working. That is the reason, I am wondering if there is new driver and quectel-CM tools which is tested together. Thank you for the reply.