No Connection on PPP

Hi,

(Non-Linux expert here so please be gentle!)

I cannot seem to get a connection on PPP.

I have a Raspberry Pi 3G/4G & LTE Base HAT and have followed the instructions for a PPP installation on a Raspberry Pi 3B+ (Raspbian Buster, fully updated). The installation seemed to go fine except I wasn’t asked the question “Do you have updated kernel? [Y/n]”.

(Incidentally, I noticed that when I was underground in our basement, i.e. when there was no possibility of a signal, the blue status LED is mostly off but occasionally flashes, When I brought it above ground this LED was mostly on but with occasional blinks.)

Anyway, I don’t seem to be getting a connection. Should I be able to browse the Internet from the GUI? I have checked the SIM card and APN settings in another 4G modem and it is definitely working.

I don’t know if this helps but when I give the command…

pi@raspberrypi:~ $ sudo systemctl status reconnect.service

…this is what I see:

● reconnect.service - PPP Auto Connection
   Loaded: loaded (/etc/systemd/system/reconnect.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-06-14 13:16:44 BST; 5min ago
 Main PID: 437 (sh)
    Tasks: 2 (limit: 2200)
   Memory: 4.9M
   CGroup: /system.slice/reconnect.service
           ├─ 437 /bin/sh /usr/src/reconnect.sh
           └─1856 sleep 10

Jun 14 13:22:09 raspberrypi sudo[1836]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 14 13:22:09 raspberrypi sh[437]: /usr/sbin/pppd: In file /etc/ppp/peers/provider: unrecognized option '/dev/ttyS0'
Jun 14 13:22:09 raspberrypi pppd[1841]: In file /etc/ppp/peers/provider: unrecognized option '/dev/ttyS0'
Jun 14 13:22:09 raspberrypi sudo[1836]: pam_unix(sudo:session): session closed for user root
Jun 14 13:22:19 raspberrypi sh[437]: ping: SO_BINDTODEVICE: No such device
Jun 14 13:22:19 raspberrypi sh[437]: Connection down, reconnecting...
Jun 14 13:22:19 raspberrypi sudo[1847]:       pi : TTY=unknown ; PWD=/usr/src ; USER=root ; COMMAND=/usr/bin/pon
Jun 14 13:22:19 raspberrypi sudo[1847]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 14 13:22:19 raspberrypi sh[437]: /usr/sbin/pppd: In file /etc/ppp/peers/provider: unrecognized option '/dev/ttyS0'
Jun 14 13:22:19 raspberrypi sudo[1847]: pam_unix(sudo:session): session closed for user root

Hi @K1tty,
Do you have enabled the Serial port hardware and disabled login shell over serial?

Enable serial_hw and I2C interfaces by following instructions below:

  1. Run sudo raspi-config
  2. Select 5 Interfacing Options
  3. Enable P5 I2C
  4. For P6 Serial
    • Disable Login shell to be accessible over serial
    • Enable Serial port hardware
  5. Finish
  6. Reboot
  7. It’s done :white_check_mark:

Many thanks but I have carried out your instructions with no luck - still no connection. Is there perhaps a checklist I can go through to make sure everything is ok? It is strange because all the instructions seem quite simple and I have not seen any errors.

I’ve been attempting using the IoT hat as well,
run:
sudo systemctl stop reconnect.service
to stop the service, then use
sudo pon
to manually start PPP and you should get a more verbose log

Thanks very much for this, I have tried this and when I type:

sudo pon

I see:

/usr/sbin/pppd: The remote system (3gppp) is required to authenticate itself
/usr/sbin/pppd: but I couldn't find any suitable secret (password) for it to use
 to do so.

I don’t understand what password it’s talking about. I entered the correct APN password - is there another?

Does your ISP need authentication? If yes, you can get credentials from your ISP.

Reference to similar issue:

I use this same SIM in a variety of different modems, e.g. ProRoute H865WRT, in various SIM-based projects such as Arduino shields and I have never needed anything more than just APN, username and password.

The service provider is o2 in the UK and the (published) APN details work fine in other devices. Also, there is no PIN.

I’m afraid I am a bit lost. The link that you are directing me to opens with the words:

The /etc/ppp/pap-secrets file looks like…

…but the words this person shows do not appear in the file on my machine. Here is what that file says on mine:

# /etc/ppp/pap-secrets
#
# This is a pap-secrets file to be used with the AUTO_PPP function of
# mgetty. mgetty-0.99 is preconfigured to startup pppd with the login option
# which will cause pppd to consult /etc/passwd (and /etc/shadow in turn)
# after a user has passed this file. Don't be disturbed therefore by the fact
# that this file defines logins with any password for users. /etc/passwd
# (again, /etc/shadow, too) will catch passwd mismatches.
#
# This file should block ALL users that should not be able to do AUTO_PPP.
# AUTO_PPP bypasses the usual login program so it's necessary to list all
# system userids with regular passwords here.
#
# ATTENTION: The definitions here can allow users to login without a
# password if you don't use the login option of pppd! The mgetty Debian
# package already provides this option; make sure you don't change that.

# INBOUND connections

# Every regular user can use PPP and has to use passwords from /etc/passwd
*       hostname        ""      *

# UserIDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd!
guest   hostname        "*"     -
master  hostname        "*"     -
root    hostname        "*"     -
support hostname        "*"     -
stats   hostname        "*"     -

# OUTBOUND connections

# Here you should add your userid password to connect to your providers via
# PAP. The * means that the password is to be used for ANY host you connect
# to. Thus you do not have to worry about the foreign machine name. Just
# replace password with your password.
# If you have different providers with different passwords then you better
# remove the following line.

#       *       password

I have also looked at the ‘/etc/ppp/options’ file and that contains the following:

# /etc/ppp/options
#
# Originally created by Jim Knoble <jmknoble@mercury.interpath.net>
# Modified for Debian by alvar Bray <alvar@meiko.co.uk>
# Modified for PPP Server setup by Christoph Lameter <clameter@debian.org>
#
# To quickly see what options are active in this file, use this command:
#   egrep -v '#|^ *$' /etc/ppp/options

# Specify which DNS Servers the incoming Win95 or WinNT Connection should use
# Two Servers can be remotely configured
# ms-dns 192.168.1.1
# ms-dns 192.168.1.2

# Specify which WINS Servers the incoming connection Win95 or WinNT should use
# ms-wins 192.168.1.50
# ms-wins 192.168.1.51

# Run the executable or shell command specified after pppd has
# terminated the link.  This script could, for example, issue commands
# to the modem to cause it to hang up if hardware modem control signals
# were not available.
#disconnect "chat -- \d+++\d\c OK ath0 OK"

# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it.  0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
asyncmap 0

# Require the peer to authenticate itself before allowing network
# packets to be sent or received.
# Please do not disable this setting. It is expected to be standard in
# future releases of pppd. Use the call option (see manpage) to disable
# authentication for specific peers.
auth

# Use hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
crtscts

# Use software flow control (i.e. XON/XOFF) to control the flow of data
# on the serial port.
#xonxoff

# Specifies that certain characters should be escaped on transmission
# (regardless of whether the peer requests them to be escaped with its
# async control character map).  The characters to be escaped are
# specified as a list of hex numbers separated by commas.  Note that
# almost any character can be specified for the escape option, unlike
# the asyncmap option which only allows control characters to be
# specified.  The characters which may not be escaped are those with hex
# values 0x20 - 0x3f or 0x5e.
#escape 11,13,ff

# Don't use the modem control lines.
#local

# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
lock

# Don't show the passwords when logging the contents of PAP packets.
# This is the default.
hide-password

# When logging the contents of PAP packets, this option causes pppd to
# show the password string in the log message.
#show-password

# Use the modem control lines.  On Ultrix, this option implies hardware
# flow control, as for the crtscts option.  (This option is not fully
# implemented.)
modem

# Set the MRU [Maximum Receive Unit] value to <n> for negotiation.  pppd
# will ask the peer to send packets of no more than <n> bytes. The
# minimum MRU value is 128.  The default MRU value is 1500.  A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data).
#mru 542

# Set the interface netmask to <n>, a 32 bit netmask in "decimal dot"
# notation (e.g. 255.255.255.0).
#netmask 255.255.255.0

# Disables the default behaviour when no local IP address is specified,
# which is to determine (if possible) the local IP address from the
# hostname. With this option, the peer will have to supply the local IP
# address during IPCP negotiation (unless it specified explicitly on the
# command line or in an options file).
#noipdefault

# Enables the "passive" option in the LCP.  With this option, pppd will
# attempt to initiate a connection; if no reply is received from the
# peer, pppd will then just wait passively for a valid LCP packet from
# the peer (instead of exiting, as it does without this option).
#passive

# With this option, pppd will not transmit LCP packets to initiate a
# connection until a valid LCP packet is received from the peer (as for
# the "passive" option with old versions of pppd).
#silent

# Don't request or allow negotiation of any options for LCP and IPCP
# (use default values).
#-all

# Disable Address/Control compression negotiation (use default, i.e.
# address/control field disabled).
#-ac

# Disable asyncmap negotiation (use the default asyncmap, i.e. escape
# all control characters).
#-am

# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach

# Disable IP address negotiation (with this option, the remote IP
# address must be specified with an option on the command line or in
# an options file).
#-ip

# Disable IPCP negotiation and IP communication. This option should
# only be required if the peer is buggy and gets confused by requests
# from pppd for IPCP negotiation.
#noip

# Disable magic number negotiation.  With this option, pppd cannot
# detect a looped-back line.
#-mn

# Disable MRU [Maximum Receive Unit] negotiation (use default, i.e.
# 1500).
#-mru

# Disable protocol field compression negotiation (use default, i.e.
# protocol field compression disabled).
#-pc

# Require the peer to authenticate itself using PAP.
#+pap

# Don't agree to authenticate using PAP.
#-pap

# Require the peer to authenticate itself using CHAP [Cryptographic
# Handshake Authentication Protocol] authentication.
#+chap

# Don't agree to authenticate using CHAP.
#-chap

# Disable negotiation of Van Jacobson style IP header compression (use
# default, i.e. no compression).
#-vj

# Increase debugging level (same as -d).  If this option is given, pppd
# will log the contents of all control packets sent or received in a
# readable form.  The packets are logged through syslog with facility
# daemon and level debug. This information can be directed to a file by
# setting up /etc/syslog.conf appropriately (see syslog.conf(5)).  (If
# pppd is compiled with extra debugging enabled, it will log messages
# using facility local2 instead of daemon).
#debug

# Append the domain name <d> to the local host name for authentication
# purposes.  For example, if gethostname() returns the name porsche,
# but the fully qualified domain name is porsche.Quotron.COM, you would
# use the domain option to set the domain name to Quotron.COM.
#domain <d>

# Enable debugging code in the kernel-level PPP driver.  The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
#kdebug n

# Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface.
#mtu <n>

# Set the name of the local system for authentication purposes to <n>.
# This is a privileged option. With this option, pppd will use lines in the
# secrets files which have <n> as the second field when looking for a
# secret to use in authenticating the peer. In addition, unless overridden
# with the user option, <n> will be used as the name to send to the peer
# when authenticating the local system to the peer. (Note that pppd does
# not append the domain name to <n>.)
#name <n>

# Enforce the use of the hostname as the name of the local system for
# authentication purposes (overrides the name option).
#usehostname

# Set the assumed name of the remote system for authentication purposes
# to <n>.
#remotename <n>

# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.
#proxyarp

# Use the system password database for authenticating the peer using
# PAP. Note: mgetty already provides this option. If this is specified
# then dialin from users using a script under Linux to fire up ppp wont work.
# login

# If this option is given, pppd will send an LCP echo-request frame to the
# peer every n seconds. Normally the peer should respond to the echo-request
# by sending an echo-reply. This option can be used with the
# lcp-echo-failure option to detect that the peer is no longer connected.
lcp-echo-interval 30

# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection.  Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
lcp-echo-failure 4

# Set the LCP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#lcp-restart <n>

# Set the maximum number of LCP terminate-request transmissions to <n>
# (default 3).
#lcp-max-terminate <n>

# Set the maximum number of LCP configure-request transmissions to <n>
# (default 10).
#lcp-max-configure <n>

# Set the maximum number of LCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#lcp-max-failure <n>

# Set the IPCP restart interval (retransmission timeout) to <n>
# seconds (default 3).
#ipcp-restart <n>

# Set the maximum number of IPCP terminate-request transmissions to <n>
# (default 3).
#ipcp-max-terminate <n>

# Set the maximum number of IPCP configure-request transmissions to <n>
# (default 10).
#ipcp-max-configure <n>

# Set the maximum number of IPCP configure-NAKs returned before starting
# to send configure-Rejects instead to <n> (default 10).
#ipcp-max-failure <n>

# Set the PAP restart interval (retransmission timeout) to <n> seconds
# (default 3).
#pap-restart <n>

# Set the maximum number of PAP authenticate-request transmissions to
# <n> (default 10).
#pap-max-authreq <n>

# Set the maximum time that pppd will wait for the peer to authenticate
# itself with PAP to <n> seconds (0 means no limit).
#pap-timeout <n>

# Set the CHAP restart interval (retransmission timeout for
# challenges) to <n> seconds (default 3).
#chap-restart <n>

# Set the maximum number of CHAP challenge transmissions to <n>
# (default 10).
#chap-max-challenge

# If this option is given, pppd will rechallenge the peer every <n>
# seconds.
#chap-interval <n>

# With this option, pppd will accept the peer's idea of our local IP
# address, even if the local IP address was specified in an option.
#ipcp-accept-local

# With this option, pppd will accept the peer's idea of its (remote) IP
# address, even if the remote IP address was specified in an option.
#ipcp-accept-remote

# Disable the IPXCP and IPX protocols.
# To let pppd pass IPX packets comment this out --- you'll probably also
# want to install ipxripd, and have the Internal IPX Network option enabled
# in your kernel.  /usr/doc/HOWTO/IPX-HOWTO.gz contains more info.
noipx

# Exit once a connection has been made and terminated. This is the default,
# unless the `persist' or `demand' option has been specified.
#nopersist

# Do not exit after a connection is terminated; instead try to reopen
# the connection.
#persist

# Terminate after n consecutive failed connection attempts.
# A value of 0 means no limit. The default value is 10.
#maxfail <n>

# Initiate the link only on demand, i.e. when data traffic is present.
# With this option, the remote IP address must be specified by the user on
# the command line or in an options file.  Pppd will initially configure
# the interface and enable it for IP traffic without connecting to the peer.
# When traffic is available, pppd will connect to the peer and perform
# negotiation, authentication, etc.  When this is completed, pppd will
# commence passing data packets (i.e., IP packets) across the link.
#demand

# Specifies that pppd should disconnect if the link is idle for <n> seconds.
# The link is idle when no data packets (i.e. IP packets) are being sent or
# received.  Note: it is not advisable to use this option with the persist
# option without the demand option.  If the active-filter option is given,
# data packets which are rejected by the specified activity filter also
# count as the link being idle.
#idle <n>

# Specifies how many seconds to wait before re-initiating the link after
# it terminates.  This option only has any effect if the persist or demand
# option is used.  The holdoff period is not applied if the link was
# terminated because it was idle.
#holdoff <n>

# Wait for up n milliseconds after the connect script finishes for a valid
# PPP packet from the peer.  At the end of this time, or when a valid PPP
# packet is received from the peer, pppd will commence negotiation by
# sending its first LCP packet.  The default value is 1000 (1 second).
# This wait period only applies if the connect or pty option is used.
#connect-delay <n>

# Packet filtering: for more information, see pppd(8)
# Any packets matching the filter expression will be interpreted as link
# activity, and will cause a "demand" connection to be activated, and reset
# the idle connection timer. (idle option)
# The filter expression is akin to that of tcpdump(1)
#active-filter <filter-expression>

# ---<End of File>---

…but this is a pretty large file and to be honest I feel pretty lost with this.

Any ideas?

K1tty,
looking at this thread there’s a lot of information needed but maybe we can get you facing in the right direction quickly.
Assumptions: Healthy Power Supply / Running headless - ssh over wifi or ethernet.
Comment: You weren’t prompted for a kernel update because 4.19.118 meets requirement.
FIRST: as earlier suggested uninstall the auto-reconnect service. Full instructions here:

SECOND: remove ALL other USB peripherals, leaving only the 90° cable connected that came with the hat.

Reboot
Check port assignment for your hat -

dmesg -T | grep tty
You should see something like (example only) …
usb 1-1.1.3: GSM modem (1-port) converter now attached to ttyUSB0
usb 1-1.1.3: GSM modem (1-port) converter now attached to ttyUSB1
usb 1-1.1.3: GSM modem (1-port) converter now attached to ttyUSB2
usb 1-1.1.3: GSM modem (1-port) converter now attached to ttyUSB3
You’ll want to select the last assigned port to insert into the install script.
Re-run your install script - ‘install.sh’
step through each menu item BUT decline to install the auto-reconnect.service.
Check/Edit the configuration file: /etc/ppp/peers/provider
look for ‘#noauth’ and uncomment (remove ‘#’)

try to run ‘sudo pon’ and let the board know your results.

there are still the questions of:
matched & properly installed antennae?
what mPCIe module is installed?
is SIM compatible with module?

Good luck!

Hi Mark,

Thank you very much indeed for your help with this - I will try to be as complete as possible in my answers:

A) Hardware Questions:

Power Supply: Yes, I believe the power supply is healthy - it is the official Raspberry Pi version.

Antennas: I tried the antennas that came with the kit but I found that the ones that come with my ‘usual’ 4G modem I normally use were better. (This is probably because I haven’t stuck the supplied antennas onto a surface yet. I know with Taoglas ‘stick-on’ antennas their VSWR is best when they are applied to a surface). Also, I feel that the antennas are working properly because I quickly get an indication from the LED that the module can see the cell tower ok.

mPCIe Module: It is the Quectel one supplied with the 4G ‘kit’.

SIM Compatibilty: I can’t be sure of this because I’ve never had any problems with it before. I have used this same in lots of other projects, e.g. Arduino, RPi as well as other 4G modems.

B) I have been running the Pi headless except for a USB keyboard/mouse dongle that I left plugged in when I first set it up - I can run it with SSH over wired Ethernet so I will remove this for future testing.

C) I have uninstalled to auto-reconnect service:

login as: pi
pi@192.168.1.69's password:
Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jun 22 17:45:34 2020 from 192.168.1.64

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

pi@raspberrypi:~ $ sudo systemctl stop reconnect.service
pi@raspberrypi:~ $ sudo systemctl disable reconnect.service
Removed /etc/systemd/system/multi-user.target.wants/reconnect.service.
pi@raspberrypi:~ $ sudo rm /etc/ppp/peers/provider
pi@raspberrypi:~ $ sudo rm /etc/chatscripts/chat-connect
pi@raspberrypi:~ $ sudo rm /etc/chatscripts/chat-disconnect
pi@raspberrypi:~ $

D) When I check the port assignment I get:

pi@raspberrypi:~ $ dmesg -T | grep tty
[Mon Jun 22 17:20:34 2020] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=tty1 root=PARTUUID=ea7d04d6-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[Mon Jun 22 17:20:34 2020] console [tty1] enabled
[Mon Jun 22 17:20:34 2020] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[Mon Jun 22 17:20:34 2020] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31250000) is a 16550
[Mon Jun 22 17:20:41 2020] usb 1-1.1.2: GSM modem (1-port) converter now attached to ttyUSB0
[Mon Jun 22 17:20:41 2020] usb 1-1.1.2: GSM modem (1-port) converter now attached to ttyUSB1
[Mon Jun 22 17:20:41 2020] usb 1-1.1.2: GSM modem (1-port) converter now attached to ttyUSB2
[Mon Jun 22 17:20:41 2020] usb 1-1.1.2: GSM modem (1-port) converter now attached to ttyUSB3
pi@raspberrypi:~ $

E) Apologies but at this point I’m not sure what to do. You ask me “…to select the last assigned port to insert into the install script.” This will be ttyUSB3 I guess. Do you mean that you want me to edit the script and insert this text somewhere or should I simply run install.sh and type that text when it gets to this part…

echo "${YELLOW}What is your device communication PORT? (ttyS0/ttyUSB3/etc.)${SET}"
read devicename

If you could please answer that I will continue to follow your instructions.

Again, many thanks for your help.

Good morning,
progress!
yes, enter ttyUSB3 as the port. nothing more the parent path will be added by the script.
a word about port assignment -
on boot they are usually consecutive and grab 0-3, unless you have another peripheral that “boots faster” and thus recognized by the OS sooner. In some cases you can see the port assignment split too. This can be controlled with a SYMLINK rule (I can post tutorial later is anyone is interested).
With all that said, the first two ports are bound for serial comm to the GPS and the last two bound for serial to the LTE modem. You can use either assigned but if you want parallel task you can use both., i.e., I want to retrieve the Signal level, ICCID & IMEI and start a ppp session simultaneously and independent of each other I would use (in your case) ttyUSB2 to fetch my info and ttyUSB3 to establish a session. Also, getting the former information does NOT require an active carrier session.

Post back and let everyone know your status.

Thanks

Many thanks. I have carried out the instructions and for the first time have actually seen some errors. Here is what I did:

I ran…

sh install.sh

…and answered the following:

6 for 3G/4G Base HAT

APN = mobile.o2.co.uk

Password? = Y

Username = o2web

Password = password

Device communication port = ttyUSB3

Activate auto-reconnect = n

(Noted that I should run ‘sudo pon’ to connect and ‘sudo poff’ to disconnect)

Pressed ENTER to reboot

Then got the following:

Press ENTER key to reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.
pi@raspberrypi:~ $

(I will leave the device as it is as long as I can without rebooting, etc. in case that’s useful.)

Hi there,
that’s an error in the install script … in short it doesn’t have permission to reboot so it can’t push a reboot message to the terminal window “wall” or broadcast to any other sessions, stop a service, etc.
Just go ahead and reboot it yourself ‘sudo reboot’

    • I misread your early post thinking you did NOT need a username/pwd.
      did you install from the ‘pi’ user account?
      check the home directory for ‘provider’ file
      make sure the user & password values are there & correct.
      ‘noauth’ should read ‘#noauth’, if not change it.
      also check for ‘debug’ on a line by itself, remove ‘#’ if present.
      this should give you more verbose logs to screen when you run.

let us know how you make out.

Again, many thanks.

Yes, I installed from the ‘Pi’ account. I only have that one as far as I know (although I suspect there may also be a ‘root’ that I am ‘sudo’-ing into).

I verified that the ‘provider’ file is set correctly. It needed no changes.

I rebooted the Pi with

sudo reboot

I verified that the blue LED was in its ‘blinking off’ state. (It seems that the ‘blinking on’ state means that it can’t see a cell tower but that might be just me misinterpreting the status.)

As instructed by the installation script I tried ‘sudo pon’ and got this:

pi@raspberrypi:~ $ sudo pon
The file /etc/ppp/peers/provider does not exist. Please create it or use
a command line argument to use another file in the /etc/ppp/peers/ directory.

Should I perhaps copy the ‘provider’ file into the /etc/ppp/peers/ directory? (Seems like a bit of a hack.)

yes, by default user:pi is part of the ‘root’ group. ‘sudo’ elevates your permissions to run/edit etc., without actually being logged in as ‘root’ , a liitle bit of protection if you will.
the install script should have built out the directory trees /etc/… chatscripts & ppp. Your home directory has a copy of: chat-connect & disconnect & provider.
pon is a shell script in /usr/bin/ and by default will call /etc/ppp/peers/provider. - So yes, copy from your home to /peers/ like so: ‘sudo cp ~/provider /etc/ppp/peers/’

  • this is not normal behavior, something went wrong with the install or maybe the uninstall of reconnect, etc.
    because of this missing file check the existence of /etc/chatscripts and copy ‘chat-connect’ & ‘-disconnect’ files there if they don’t exist.
    Post back your status.
    thanks

Ok, thanks, here goes:

I checked ‘chatscripts’ with…

pi@raspberrypi:~ $ sudo ls /etc/chatscripts
gprs  pap  provider

I therefore copied the two files across as you suggested with:

sudo cp ~/chat-connect /etc/chatscripts
sudo cp ~/chat-disconnect /etc/chatscripts

Thinking that this should now be set up correct I tried:

pi@raspberrypi:~ $ sudo pon
/usr/sbin/pppd: The remote system (3gppp) is required to authenticate itself
/usr/sbin/pppd: but I couldn't find any suitable secret (password) for it to use to do so.
pi@raspberrypi:~ $

I’m not sure what secret (password) this is talking about.

so pon calls provider which also calls chat-connect.
‘3gppp’ is the generic name for the connection/carrier, also in ‘provider’
‘provider’ should also have …
user “o2web”
password “password”
#noauth

you can also post the contents of your provider file, there is nothing unique or private to your specific setup.

This is the ‘provider’ file as it is at the moment:

 /etc/ppp/peers/provider
/dev/ttyUSB3 115200
# The chat script, customize your APN in this file
connect 'chat -s -v -f /etc/chatscripts/chat-connect -T mobile.o2.co.uk'
# The close script
disconnect 'chat -s -v -f /etc/chatscripts/chat-disconnect'
# Hide password in debug messages
hide-password
# The phone is not required to authenticate
#noauth
user "o2web"
password "password"
# Debug info from pppd
debug
# If you want to use the HSDPA link as your gateway
defaultroute
# pppd must not propose any IP address to the peer
noipdefault
# No ppp compression
novj
novjccomp
noccp
ipcp-accept-local
ipcp-accept-remote
local
# For sanity, keep a lock on the serial line
lock
modem
dump
updetach
# Hardware flow control
nocrtscts
remotename 3gppp
ipparam 3gppp
ipcp-max-failure 30
# Ask the peer for up to 2 DNS server addresses
usepeerdns

When you say the file should also have the username and password - those two have always been in there. Do you mean they should be after the reference to 3gppp as well?

that’s all good.
I suspect you’ll have to edit the chap-secrets in /etc/ppp/.
the column heading in this file is:
#client server secret IP addresses
on the next line enter with a [tab]space between each. (the values won’t line up with the column headings but that’s okay)
3gppp raspberrypi password *
save the file & try ‘sudo pon’ again.
post your results and IF you want an explanation of the chap-secrets values I can explain.
thanks

for clarity the asterisk ‘*’ IS the value in the 4th column for sample above.
thanks