I have been working with an EC25 Module to facilitate a 4G uplink for a portable device, and I have noted some odd behaviour whenever a connection is implemented over PPP.
Has anyone else run into an issue where the required Carrier APN Changes between power cycles? At the present time I am seeing mine change between two possible APN values whenever the device is power cycled, and have yet to figure out the cause of this issue. For reference the SIM being used is a Vodafone card, and the toggle is between ‘Internet’ and ‘wap.vodafone’.
If anyone is aware of what is going on here, and knows of a possible solution it would be greatly appreciated.
Dear Iain，
Thanks for your inquiry in Quectel forum.
For your issue, as you know that the APN is match with the network type, the reason why it will change, because the network type may change. You can try to check it with command AT+QICSGP and AT+COPS? . Thanks!
Having run that command I still run into the same error message with each call of the AT+QICSGP AT command.
The return from the AT+QICSGP=1 command was ‘+QICSGP: 1,“internet”,"","",0’ for reference.
Furthermore, here is the log from an attempted connection using sudo pon on the device that is currently mounting the EC25 module in case this sheds some light on the issue. Note that the issue only appears whenever the device is fully powered down and then rebooted. Software reboots do not affect the device’s functionality.
abort on (BUSY)
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (ERROR)
abort on (NO ANSWER)
timeout set to 30 seconds
send (AT^M)
expect (OK)
^M
OK
-- got it
send (ATE0^M)
expect (OK)
^M
^M
OK
-- got it
send (ATI;+CSQ;+COPS?;+CGREG?;&D2^M)
expect (OK)
^M
^M
Quectel^M
EC25^M
Revision: EC25EFAR06A08M4G^M
^M
+CSQ: 19,99^M
^M
+COPS: 0,0,"vodafone UK",7^M
^M
+CGREG: 0,1^M
^M
OK
-- got it
send (AT+CGDCONT=1,"IP","internet",,0,0^M)
expect (OK)
^M
^M
OK
-- got it
send (ATD*99#^M)
expect (CONNECT)
^M
^M
CONNECT
-- got it
Script chat -s -v -f /etc/chatscripts/chat-connect -T internet finished (pid 996), status = 0x0
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc06a19cc> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap MD5> <magic 0x3618d21d> <pcomp> <accomp>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth chap MD5> <magic 0x3618d21d> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xc06a19cc> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xc06a19cc]
rcvd [LCP DiscReq id=0x3 magic=0x3618d21d]
rcvd [CHAP Challenge id=0x1 <ecef4e848bc17681b2304ecea62da843>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <539a85443cfea41610d6ad827a2236aa>, name = "raspberrypi"]
rcvd [LCP EchoRep id=0x0 magic=0x3618d21d c0 6a 19 cc]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [LCP EchoReq id=0x1 magic=0xc06a19cc]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x2 "No network protocols running"]
Please follow up the suggestion to check the changes. That means that before you powered down the device to check it and check again after rebooted. Thanks!
Apologies for the sporadic activity on this issue, it has been a long term project being worked on in the background while several other projects have held priority so there hasn’t been much time to work on it as of late. I’ve got the time to work on it a bit more now as the priority tasks have finished, so I have worked through the comments on this forum again, and still seem to be running into the same issue.
With regards to AT+QICSGP=1 and AT+COPS?;
Before Hard Reset.
+QICSGP: 1,“internet”,"","",0
+COPS: 0,0,“vodafone UK”,7
After Hard Reset there is no change.
Changing the APN at this point to the other option restores the functionality, but this requires manually editing a file on the Pi to enact the change,
Are there any other sources for this issue that you can think of? The issue does not occur when it is a soft reset or reboot, so could it be tied to the previous connection not being released correctly? Is there a command that could be used to flush any existing connections in order to confirm if that might be the case?
Just pinging this to see if anyone has any further insights on the topic mentioned above. Further testing has been carried out using the SIM, and no further insights into why it fails in the attempt to reconnect after a hard reset has occurred have been seen in the logs.
An attempt to connect using the only other SIM Card I have failed, but I suspect that this may be linked to it being a Phone SIM rather than a Data SIM, or possibly issues in configuring the PAP authentication it would require (though that did seem to have passed).
Issue is still present with APN changing on each hard reset.
APN must be changed after each connection, though this can happen either prior to or after the hard reset has occurred. Prior to the hard reset any number of connections and disconnections can be made using the ‘current’ APN.
Issue persists after new connection has been made. Changing the APN back after this does not allow for a new connection until after the APN has been changed and the device undergoes another hard reset.
No deviation is seen in any of the tested outputs recorded in Minicom Terminal.
Do any of these offer additional information on what may or may not be causing this issue to occur?
Have any of the additional details provided an insight into where the issue might lie with the current configuration?
As things stand this is the only sticking point with the current setup, as we wish to have the connection running over serial PPP rather than needing to use a USB connection and driver in order to connect to the hat utilising this module before finalising a production version of the overall stack.
Overall we are happy with the performance of the device, however needing to use a cable adds additional points of failure we are unhappy to leave in a finalised production version.
