The most common problems when operating a celluar link are usually down to network registration getting into a "confused" state or problems with getting or maintining a funtioning network connection.
To help here we have created a simple perl script to detail some of the key points to take note of regarding network registration :
The most common checkpoints prior to "dial out" that should be tested are that the SIM is talking OK to the modem (i.e. it's not PIN locked or blocked) , the system has good signal strength (anywhere from around 5 to 22+ is considered OK) and the network is detected and registered.
If the modem detects low signal strength (below 10/31), the antenna should be re-orientated to capture best signal or fitted with a Yagi directional arial (pointing at the nearest base station) in areas where signal coverage is poor. Below 10 and you'll more likely to have problems with getting LTE and the system may back off to 3G/EDGE/GPRS modes.
Occasionally modems can get stuck in the "Not registered, (not) searching" mode, or report really odd signal strength values, here a soft reset can be issued to the modem via AT commands (depending on modem type) :
This usually is enough to reboot the modem firmware and restart the network registration process, failing that the device can be toggled in/out of airplane mode or given a hardware reset, using either 'Wireless Disable' (GPIO39) or 'Modem Reset' (GPIO23) Lines (see GPIO docs section for details).
When doing a PPP dial out the system will give you exit codes showing what went wrong in the process (man pppd - exit status) These are useful for debugging the situation, the most common issues are apn/password details incorrect/spelt wrong, inadequate signal, cellular basestation congestion.
Once a network connection is made is is is worth checking periodically that the internet network connection is still valid (especially so if the modem is using the standard consumer apn details) as network providers have a tendancy to "mute" your connection, as opposed to just chopping your network connection entirely, if you are deamed to be hogging your base station slot for long periods (with relatively low data volumes) in preference to other users. Here your connection may appear valid, but your data transfters to remote server(s) will fail.
A method I have used in the past for checking this is via a curl http request (ideally to a page on your target server, which you have control over) to check the last modified time stamp of the webpage (to reduce the byte transfer count) :
curl -I -s --connect-timeout 5 --max-time 10 http://www.msftncsi.com/ncsi.txt | grep "HTTP/1.1 200 OK"
Using the sucess/fail error code (of the grep command on the end) is a pretty good indication on the viability of the comms connection. We have found that using curl to simulate a web request more reliable than using ping as network providers often break ping functionality, usually to mitigate DDoS attacks.
Again if that network check fails 3 times in a row then you should consider the internet connection bad (regardless of whether the network interface is active) and bring down/up the connection to restablish connectivity.
A common "gotcha" is getting the APN details wrong, sometimes the error messages received can be a bit cryptic, see below example of what results of an incorrect APN name :
qmi-network start problem with Raspbian 9, reports below error on starting network error: "couldn't start network: QMI protocol error (64): '(null)'.
There looks like a minor problem with the scripting in libqmi-utils package version 1.16.2 that prevents dialout via the qmi command line utilities, see below link for information and solution : Bug Report with Fix
Here are some useful links containing more information :