Lease obtained, but Not going further

On an EC25 module connected to an ubuntu-based PC, I have been able to connect through Mobile broadband (PPP) to the LTE network and Internet. Now I am trying to connect through the CM tool, but I have stuck.
Here is the log of Quectel-CM tool

sudo ./quectel-CM -i wwp0s20u4i4 -4

[03-01_15:25:56:661] Quectel_QConnectManager_Linux_V1.5.5
[03-01_15:25:56:662] Find /sys/bus/usb/devices/3-4 idVendor=0x2c7c idProduct=0x125
[03-01_15:25:56:662] Auto find qmichannel = /dev/cdc-wdm0
[03-01_15:25:56:662] Auto find usbnet_adapter = wwp0s20u4i4
[03-01_15:25:56:662] Modem works in QMI mode
[03-01_15:25:56:673] cdc_wdm_fd = 7
[03-01_15:25:56:770] Get clientWDS = 20
[03-01_15:25:56:802] Get clientDMS = 2
[03-01_15:25:56:834] Get clientNAS = 4
[03-01_15:25:56:866] Get clientUIM = 1
[03-01_15:25:56:898] Get clientWDA = 1
[03-01_15:25:56:930] requestBaseBandVersion EC25EFAR06A07M4G
[03-01_15:25:57:058] requestGetSIMStatus SIMStatus: SIM_READY
[03-01_15:25:57:091] requestGetProfile[1] mtnirancell///0
[03-01_15:25:57:122] requestRegistrationState2 MCC: 432, MNC: 35, PS: Attached, DataCap: LTE
[03-01_15:25:57:154] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
[03-01_15:25:57:154] ifconfig wwp0s20u4i4 down
[03-01_15:25:57:158] ifconfig wwp0s20u4i4 0.0.0.0
[03-01_15:25:57:218] requestSetupDataCall WdsConnectionIPv4Handle: 0x8726e350
[03-01_15:25:57:346] ifconfig wwp0s20u4i4 up
[03-01_15:25:57:350] udhcpc -f -n -q -t 100 -i wwp0s20u4i4
udhcpc: started, v1.27.2
udhcpc: sending discover
udhcpc: sending select for 10.193.187.227
udhcpc: lease of 10.193.187.227 obtained, lease time 7200
^C[03-01_15:25:59:146] requestDeactivateDefaultPDP WdsConnectionIPv4Handle
[03-01_15:25:59:170] ifconfig wwp0s20u4i4 down
[03-01_15:25:59:174] ifconfig wwp0s20u4i4 0.0.0.0
[03-01_15:25:59:363] QmiWwanThread exit
[03-01_15:25:59:363] qmi_main exit

I have checked that QCFG returns 0, and CGPADDR returns a valid IP Address.

Dear Sir,
Thanks for your inquiry in Quectel forum.
About your issue, could you help to do more test to check the results ?

  1. whether the SIM card is normal now ? Could you use AT command to check whether it can register on network normally ?
    2)If you dial up again when it have such issue, whether it can dial up successful ?
    3)How about to change another SIM card or module to have a try ?
    4)How about just use ./quectel-CM to dial up , do not add the following parameters ?

Thank you for fast reply.
Before I run quectel-CM, I can connect through ppp, but afterwise, I cannot dial up again and it would fail. (Strangely it even disconnects the wired connection too. It should be turned off and on to get connected!, but the ppp never comes back).
The sim card seems to have no problem and is registered (CREG and CEREG both return 0, 1, both when connected through ppp, before running quectel-CM, and after that)
running quectel-CM without parameters does not change anything.

I should mention that my linux driver (ubuntu 18.4; Kernel source 4.15.0) is somewhat different from the document WCDMA&LTE_Linux_USB_Driver_User_Guide_V1.8 (it has a dyncfg part). I feel the problem might be there in, as I had to do heuristics for the dhcp to pass the discover phase.

Dear Sir,
You can check the following document and refer to the sample code of kernel source 4.15.0 version. Thanks!
Hopefully it is useful to you. Thanks!
How to install driver and test AT&network card dial on Ubuntu PC.pdf (192.1 KB)

https://cnquectel-my.sharepoint.com/:u:/g/personal/asean-fae_quectel_com/ESYhrroWU5VNnGnbJdKeT94BNWwNs3H2RbJr8XLYKyrZ5A?e=LOXgUm

The PDF is not in sync with this zip file, is it?

The PDF is the user guide, and the zip file is the source sample code. Thanks!

Thanks

I have passed forward somehow. Now route table seems to have problems:
sudo ./quectel-CM

[03-02_13:37:55:677] Quectel_QConnectManager_Linux_V1.5.5
[03-02_13:37:55:678] Find /sys/bus/usb/devices/3-4 idVendor=0x2c7c idProduct=0x125
[03-02_13:37:55:678] Auto find qmichannel = /dev/cdc-wdm0
[03-02_13:37:55:678] Auto find usbnet_adapter = wwp0s20u4i4
[03-02_13:37:55:678] Modem works in QMI mode
[03-02_13:37:55:688] cdc_wdm_fd = 7
[03-02_13:37:56:688] QmiThreadSendQMITimeout pthread_cond_timeout_np timeout
[03-02_13:37:57:782] Get clientWDS = 20
[03-02_13:37:57:814] Get clientDMS = 1
[03-02_13:37:57:846] Get clientNAS = 4
[03-02_13:37:57:878] Get clientUIM = 1
[03-02_13:37:57:910] Get clientWDA = 1
[03-02_13:37:57:942] requestBaseBandVersion EC25EFAR06A07M4G
[03-02_13:37:58:070] requestGetSIMStatus SIMStatus: SIM_READY
[03-02_13:37:58:102] requestGetProfile[1] mtnirancell///0
[03-02_13:37:58:134] requestRegistrationState2 MCC: 432, MNC: 35, PS: Attached, DataCap: LTE
[03-02_13:37:58:166] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
[03-02_13:37:58:167] ifconfig wwp0s20u4i4 down
[03-02_13:37:58:171] ifconfig wwp0s20u4i4 0.0.0.0
[03-02_13:37:58:230] requestSetupDataCall WdsConnectionIPv4Handle: 0x87206d70
[03-02_13:37:58:358] ifconfig wwp0s20u4i4 up
[03-02_13:37:58:360] busybox udhcpc -f -n -q -t 5 -i wwp0s20u4i4
udhcpc: started, v1.27.2
udhcpc: sending discover
udhcpc: sending select for 10.196.141.154
udhcpc: lease of 10.196.141.154 obtained, lease time 7200
[03-02_13:37:58:496] /etc/udhcpc/default.script: Resetting default routes
SIOCDELRT: No such process
[03-02_13:37:58:500] /etc/udhcpc/default.script: Adding DNS 10.255.255.254
[03-02_13:37:58:500] /etc/udhcpc/default.script: Adding DNS 8.8.8.8

It seems that it have dial up successful, right?
You can use command ifconfig to double check it. Thanks!

By dialup you mean broadband connection through PPP? Yes, as I told from the start.
In this latest step, this is the ifconfig result:

wwp0s20u4i4: flags=4291<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.177.110.192 netmask 255.255.255.128 broadcast 10.177.110.255
inet6 fe80::7054:67ff:fee6:4f4e prefixlen 64 scopeid 0x20
ether 72:54:67:e6:4f:4e txqueuelen 1000 (Ethernet)
RX packets 8 bytes 1110 (1.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 39 bytes 4365 (4.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I have seen other people on the internet having such problems with udhcp, so it may be just a software problem. If I found out, I’ll report here too.

The last problem was regarding resolvconf. I had to add 8.8.8.8 to /etc/resolv.conf (see ping google not working

Now everything seems to work. Thanks

What should I do for quectel-CM to run under the hood?

Dear Sir,
Thanks for your updating. Now it seems that the root reason is the resolvconf file, right ?
Normally, it should have no such issue. As you know that it is DNS client configuration file, it may software problem. If it have any issue, we just can modify it manually. Thanks!

Can I also get these files please? I am also using Eg25g