* Problem with M2M PPP connection
@ 2021-02-10 9:17 Björn Kirchner
2021-02-10 17:22 ` James Carlson
2021-02-15 7:30 ` Björn Kirchner
0 siblings, 2 replies; 3+ messages in thread
From: Björn Kirchner @ 2021-02-10 9:17 UTC (permalink / raw)
To: linux-ppp
Dear list readers,
I am stuck with the following problem and I hope you can give me some
hints or advice. It looks to me like a configuration or routing error.
I have an Olimex NB-IoT-DevKit with a Quectel BC66 LTE-NB1 chip which
is connected to a RaspberryPI 3B+ via UART connection. I try to make a
connection via PPP protocol to the ISP, but that is only “half”
working. The LTE modem can dial to the ISP and gets a connection. Both
sides exchange LCP configuration messages and IPCP configuration
messages. I receive the private static IP address assigned to the SIM
card and I also retrieve an IP address for the remote side. The ppp0
interface comes up and is configured with the private static IP address
and the P-t-P’s address. My problem is, that I cannot reach anything
via that connection. I cannot ping the P-t-P, I cannot ping other
addresses. The ISP’s support confirmed that PPP was a viable option to
connect and they told me to try the SIM card in a smartphone and to
ping 8.8.8.8, so I put the SIM card in an old Android tablet with a SIM
card slot and it connected to the remote and I could ping 8.8.8.8
successfully. The only surprising thing I noticed was the fact that the
ifconfig command for the dial-up interface on the Android tablet didn’t
have a P-t-P remote peer.
Apparently the LTE modem is working and the SIM seems to work, too. So
I am afraid that I did something wrong with the PPPD configuration.
I used pppd version 2.4.7 and the latest version from git’s master
branch (5191399f5266bb595f03f5c4fee13153092e2baf). The problem is the
same with both versions.
Output from pppd (git version):
/root/sandbox/pppd/sbin/pppd call quectel-ppp
root@raspberrypi:/etc/ppp/peers# /root/sandbox/pppd/sbin/pppd call quectel-ppp
pppd options in effect:
debug # (from /etc/ppp/peers/quectel-ppp)
nodetach # (from /etc/ppp/peers/quectel-ppp)
ktune # (from /etc/ppp/peers/quectel-ppp)
dump # (from /etc/ppp/peers/quectel-ppp)
noauth # (from /etc/ppp/peers/quectel-ppp)
refuse-chap # (from /etc/ppp/peers/quectel-ppp)
refuse-mschap # (from /etc/ppp/peers/quectel-ppp)
refuse-mschap-v2 # (from /etc/ppp/peers/quectel-ppp)
refuse-eap # (from /etc/ppp/peers/quectel-ppp)
user * # (from /etc/ppp/peers/quectel-ppp)
password ?????? # (from /etc/ppp/peers/quectel-ppp)
remotename 3gppp # (from /etc/ppp/peers/quectel-ppp)
/dev/ttyS0 # (from /etc/ppp/peers/quectel-ppp)
115200 # (from /etc/ppp/peers/quectel-ppp)
lock # (from /etc/ppp/peers/quectel-ppp)
connect /root/sandbox/pppd/sbin/chat -E -s -v -f /etc/chatscripts/quectel-chat-connect # (from /etc/ppp/peers/quectel-ppp)
disconnect /root/sandbox/pppd/sbin/chat -E -s -v -f /etc/chatscripts/quectel-chat-disconnect # (from /etc/ppp/peers/quectel-ppp)
record /tmp/quectel.record # (from /etc/ppp/peers/quectel-ppp)
nocdtrcts # (from /etc/ppp/peers/quectel-ppp)
local # (from /etc/ppp/peers/quectel-ppp)
noaccomp # (from /etc/ppp/peers/quectel-ppp)
nopcomp # (from /etc/ppp/peers/quectel-ppp)
passive # (from /etc/ppp/peers/quectel-ppp)
hide-password # (from /etc/ppp/peers/quectel-ppp)
novj # (from /etc/ppp/peers/quectel-ppp)
novjccomp # (from /etc/ppp/peers/quectel-ppp)
ipcp-accept-local # (from /etc/ppp/peers/quectel-ppp)
ipcp-accept-remote # (from /etc/ppp/peers/quectel-ppp)
ipparam 3gppp # (from /etc/ppp/peers/quectel-ppp)
noipdefault # (from /etc/ppp/peers/quectel-ppp)
nodefaultroute # (from /etc/ppp/peers/quectel-ppp)
noremoteip # (from /etc/ppp/peers/quectel-ppp)
noipv6 # (from /etc/ppp/peers/quectel-ppp)
noccp # (from /etc/ppp/peers/quectel-ppp)
nobsdcomp # (from /etc/ppp/peers/quectel-ppp)
nopredictor1 # (from /etc/ppp/peers/quectel-ppp)
abort on (BUSY)
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (ERROR)
abort on (NO ANSWER)
timeout set to 120 seconds
send (AT^M)
expect (OK)
AT^M^M
OK
-- got it
send (ATE0^M)
expect (OK)
^M
ATE0^M^M
OK
-- got it
send (ATI^M)
expect (OK)
^M
^M
Quectel_Ltd^M
Quectel_BC66^M
Revision: BC66NBR01A10^M
^M
OK
-- got it
send (AT+CSQ^M)
expect (OK)
^M
^M
+CSQ: 8,0^M
^M
OK
-- got it
send (AT+CPIN?^M)
expect (OK)
^M
^M
+CPIN: READY^M
^M
OK
-- got it
send (AT+COPS?^M)
expect (OK)
^M
^M
+COPS: 0,2,"26201",9^M
^M
OK
-- got it
send (AT+CGREG?^M)
expect (OK)
^M
^M
+CGREG: 0,5^M
^M
OK
-- got it
send (ATZ^M)
expect (OK)
^M
^M
OK
-- got it
send (AT+CGDCONT=1,"IP","iot.1nce.net",,0,0^M)
expect (OK)
^M
AT+CGDCONT=1,"IP","iot.1nce.net",,0,0^M^M
OK
-- got it
send (ATDT*99#^M)
expect (CONNECT)
^M
ATDT*99#^M^M
CONNECT
-- got it
Script /root/sandbox/pppd/sbin/chat -E -s -v -f /etc/chatscripts/quectel-chat-connect finished (pid 671), status = 0x0
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd514deb5>]
rcvd [LCP ConfReq id=0x1 <mru 1600> <magic 0x85704a90> <asyncmap 0x0> <pcomp> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd514deb5>]
rcvd [LCP ConfReq id=0x2 <mru 1600> <magic 0x85704a90> <asyncmap 0x0>]
sent [LCP ConfAck id=0x2 <mru 1600> <magic 0x85704a90> <asyncmap 0x0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 10.43.124.1>]
sent [IPCP ConfReq id=0x2 <addr 10.43.124.1>]
rcvd [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x1 <addr 10.0.0.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.43.124.1>]
local IP address 10.43.124.1
remote IP address 10.0.0.1
Script /etc/ppp/ip-up started (pid 677)
Script /etc/ppp/ip-up finished (pid 677), status = 0x0
Terminating on signal 2
Connect time 14.3 minutes.
Sent 3152 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 710)
sent [LCP TermReq id=0x2 "User request"]
Script /etc/ppp/ip-down finished (pid 710), status = 0x0
sent [LCP TermReq id=0x3 "User request"]
Connection terminated.
abort on (ERROR)
abort on (NO DIALTONE)
\send (+++ATH^M)
Good bye
Script /root/sandbox/pppd/sbin/chat -E -s -v -f /etc/chatscripts/quectel-chat-disconnect finished (pid 731), status = 0x0
Serial link disconnected.
Modem hangup
Waiting for 1 child processes...
script pppd (charshunt), pid 670
Child process pppd (charshunt) (pid 670) terminated with signal 15
Peer file /etc/ppp/peers/quectel-ppp:
#/etc/ppp/peers/quectel-ppp
# Usage:root>pppd call quectel-ppp
# Hide password in debug messages
hide-password
# The phone is not required to authenticate
noauth
# The chat script
connect '/root/sandbox/pppd/sbin/chat -E -s -v
-f /etc/chatscripts/quectel-chat- connect'
# The close script
disconnect '/root/sandbox/pppd/sbin/chat -E -s -v
-f /etc/chatscripts/quectel-ch at-disconnect'
# Debug info from pppd
debug
# Serial Device to which the HSPDA phone is connected
# Modem path, like /dev/ttyUSB3,/dev/ttyACM0, it depends on your
module. # Exmaple given is with the modem mounted at /dev/ttyUSB3
/dev/ttyS0
# Serial port line speed
115200
# If you want to use the HSDPA link as your gateway
nodefaultroute
# pppd must not propose any IP address to the peer
noipdefault
# No ppp compression
novj
novjccomp
noccp
nobsdcomp
noaccomp
ktune
#nomppe
#nomppe-40
#nomppe-128
#nompshortseq
#nomultilink
nopcomp
nopredictor1
noremoteip
ipcp-accept-local
ipcp-accept-remote
refuse-chap
refuse-mschap
refuse-mschap-v2
refuse-eap
local
nocrtscts
nocdtrcts
# For sanity, keep a lock on the serial line
lock
dump
# Keep pppd attached to the terminal
# Comment this to get daemon mode pppd
nodetach
# Network access credenatials.
# Set LTE_USERNAME and LTE_PASSWORD before executing pppd -C call
# Check with service provider for required details
user *
password *
remotename 3gppp
ipparam 3gppp
record /tmp/quectel.record
passive
noipv6
File /etc/chatscripts/quectel-chat-connect
ABORT "BUSY"
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
TIMEOUT 120
"" AT
OK ATE0
OK ATI
OK AT+CSQ
OK AT+CPIN?
OK AT+COPS?
OK AT+CGREG?
OK ATZ
# Connection to the network
# Set LTE_APN variable before executing chat -E ...
# Check with service provider for required details
OK AT+CGDCONT=1,"IP","iot.1nce.net",,0,0
# Dial the number
OK ATDT*99#
CONNECT
File /etc/chatscripts/quectel-chat-disconnect:
ABORT "ERROR"
ABORT "NO DIALTONE"
SAY "\NSending break to the modem\n"
"" +++ATH
SAY "\nGood bye\n"
Some information about the linux system:
cat /proc/version
Linux version 5.10.11-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8
(Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu)
2.34) #1399 SMP Thu Jan 28 12:06:05 GMT 2021
cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
I manually removed the ethernet default route and added a new default
route to the ppp0 device: root@raspberrypi:~# route del default
root@raspberrypi:~# route add default ppp0
root@raspberrypi:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0
0 0 ppp0 10.0.0.1 0.0.0.0 255.255.255.255 UH
0 0 0 ppp0 192.168.2.0 0.0.0.0 255.255.255.0
U 202 0 0 eth0
Output from ifconfig ppp0:
root@raspberrypi:~# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.43.124.1 netmask 255.255.255.255 destination 10.0.0.1
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 3 bytes 30 (30.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 30 (30.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
If you need more information I am eager to provide those. Do you have any
suggestions how to be able to receive the hosts on the "other" side?
Best regards,
Björn
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem with M2M PPP connection
2021-02-10 9:17 Problem with M2M PPP connection Björn Kirchner
@ 2021-02-10 17:22 ` James Carlson
2021-02-15 7:30 ` Björn Kirchner
1 sibling, 0 replies; 3+ messages in thread
From: James Carlson @ 2021-02-10 17:22 UTC (permalink / raw)
To: linux-ppp
On 2021-02-10 04:17, Björn Kirchner wrote:
> Dear list readers,
>
> I am stuck with the following problem and I hope you can give me some
> hints or advice. It looks to me like a configuration or routing error.
A broad hint first: less configuration is always better. Not only have
the developers chosen the defaults very carefully to make them work in
the widest range of cases, but the protocol itself is designed to
negotiate the available options in order to settle on the correct link
parameters. A giant configuration file either says "this set-up is
really brittle" or possibly "wow, the peer I'm forced to talk to is
flaming garbage."
I'm not saying you're necessarily doing anything wrong here, but that
laundry list is at least suspicious, and I'd certainly wonder why it is
set up that way.
A summary analysis: other than three questionable options
("nodefaultroute", "noaccomp", "nopcomp") and what appears to be a
broken serial interface ("nocdtrcts", "local"), I don't see anything in
particular going wrong at the PPP level. The problems, whatever they
may be, are elsewhere.
> I have an Olimex NB-IoT-DevKit with a Quectel BC66 LTE-NB1 chip which
Ah, the legacy of GPRS. Fortunately, I haven't kept up with this
"NB-IoS" stuff, but if it's from the same folks who designed that
earlier gear, then there are some things to be aware of here:
- The actual authentication and IP address assignment is done through
some other protocol, not PPP, and is typically done during the LCP
negotiation, and completely behind your back.
- Any failures that occur during that hidden work are almost always
completely invisible. If it's a bad user name or password, the peer
usually assigns a bogus IP address and just fails to provide any
service. There are no error messages. No way to know, at least via
PPP messages.
> and the P-t-P’s address. My problem is, that I cannot reach anything
> via that connection. I cannot ping the P-t-P, I cannot ping other
> addresses. The ISP’s support confirmed that PPP was a viable option to
That's typically what's expected when the authentication phase fails or
when the client is otherwise "unauthorized."
I strongly suspect that the problem is with the "AT" commands in the
chat script. I have no way of verifying those.
On to some (overly detailed) notes about your PPP configuration:
> refuse-chap # (from /etc/ppp/peers/quectel-ppp)
> refuse-mschap # (from /etc/ppp/peers/quectel-ppp)
> refuse-mschap-v2 # (from /etc/ppp/peers/quectel-ppp)
> refuse-eap # (from /etc/ppp/peers/quectel-ppp)
These really aren't necessary. If you don't have username/passphrase
pairs configured into the /etc/ppp/*-secrets files for this peer, then
pppd will automatically refuse those protocols. And the peer isn't even
asking for authentication from us ... so these do nothing.
> user * # (from /etc/ppp/peers/quectel-ppp)
> password ?????? # (from /etc/ppp/peers/quectel-ppp)
These are apparently useless. The peer isn't asking for authentication
at all via PPP. (Though, to be fair, this could be because the chat
script is setting things up incorrectly. Maybe it would ask if the
"modem" were set up correctly ... ?)
> remotename 3gppp # (from /etc/ppp/peers/quectel-ppp)
If you're not doing authentication, then this may be useless.
> record /tmp/quectel.record # (from /etc/ppp/peers/quectel-ppp)
Not sure why you'd want that. It's really an internal debug option
intended for PPP developers. I suggest leaving it out as it can
certainly complicate things. It forces the pppd daemon to run on top of
a pty pair and write the "raw" AHDLC data to a file for later analysis.
> nocdtrcts # (from /etc/ppp/peers/quectel-ppp)
> local # (from /etc/ppp/peers/quectel-ppp)
Those two are a real shame. This serial device really has no modem
control lines at all? Even if you get this working, it's possible that
it won't work very well at all.
"nocdtrcts" means "no hardware flow control exists." This means that
CTS/RTS aren't used. And if one side or the other encounters an
overflow, then it'll just drop bytes silently, causing packets to be
dropped. With enough of that, the link will be utterly unusable.
If the device you're using really is that horrible, then I'd check to
see if it can do at least XON/XOFF ("xonxoff") software flow control.
Something is better than nothing at all.
"local" means "no modem on/off hook signaling." This means that DTR/DCD
aren't used. That means that if the other end hangs up for some reason,
then you'll get no notice at all. Bytes will just stop flowing
mysteriously.
If that's really the case, then I *strongly* recommend using the
"lcp-echo-failure" and "lcp-echo-interval" options. This allows PPP's
LCP layer to detect link failure. Otherwise, you're shooting packets
into the dark.
> noaccomp # (from /etc/ppp/peers/quectel-ppp)
> nopcomp # (from /etc/ppp/peers/quectel-ppp)
These two appear to be incorrect. The peer is asking for these two
common options, and you've configured it intentionally to refuse them.
I don't see why anyone would do that. Note that these are *NOT* related
to data compression in any way. The "compression" they're referring to
here is just omitting some constant bytes from the PPP header.
ACFC gets rid of the static HDLC "FF 03" at the start of every PPP
frame. PFC gets rid of the extra "00" byte for network protocols less
than 0100 -- this means that IP shows up as "21" instead of "00 21".
Having both options on (the default) means saving 3 bytes per packet.
Unless you know for sure that you're operating over an HDLC link using
multi-point addressing, or that the peer has horrible bugs in its basic
PPP implementation, turning ACFC off likely makes little sense.
See RFC 1661 sections 6.5 and 6.6 for details.
> novj # (from /etc/ppp/peers/quectel-ppp)
> novjccomp # (from /etc/ppp/peers/quectel-ppp)
The peer isn't offering VJ header compression, so these likely don't do
much. Note that "vjccomp" is dependent on "vj", so saying "novj" alone
is sufficient to turn off both.
> nodefaultroute # (from /etc/ppp/peers/quectel-ppp)
This is a little weird. Are you sure? I thought this was supposed to
be your connection to the Internet. If so, then you certainly want to
have pppd establish a default route for you. (Doing so manually is at
best error-prone.)
Just make sure you remove the system's default route (if any) before
starting pppd.
> noremoteip # (from /etc/ppp/peers/quectel-ppp)
This appears to be unnecessary, but may be harmless. The peer is
offering an IP address for itself, so the option doesn't come into play.
> noccp # (from /etc/ppp/peers/quectel-ppp)
> nobsdcomp # (from /etc/ppp/peers/quectel-ppp)
> nopredictor1 # (from /etc/ppp/peers/quectel-ppp)
"noccp" is sufficient. The rest of those protocols are dependent on CCP
negotiation. You can't get there if CCP is turned off.
> Output from ifconfig ppp0:
> root@raspberrypi:~# ifconfig ppp0
> ppp0: flagsC05<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
> inet 10.43.124.1 netmask 255.255.255.255 destination 10.0.0.1
> ppp txqueuelen 3 (Point-to-Point Protocol)
> RX packets 3 bytes 30 (30.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 3 bytes 30 (30.0 B)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Nothing looks wrong there.
> If you need more information I am eager to provide those. Do you have any
> suggestions how to be able to receive the hosts on the "other" side?
I don't know what that means.
However, wireshark is an excellent tool to use if you think that there's
a problem at the network level, rather than just the basic connection
itself.
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem with M2M PPP connection
2021-02-10 9:17 Problem with M2M PPP connection Björn Kirchner
2021-02-10 17:22 ` James Carlson
@ 2021-02-15 7:30 ` Björn Kirchner
1 sibling, 0 replies; 3+ messages in thread
From: Björn Kirchner @ 2021-02-15 7:30 UTC (permalink / raw)
To: linux-ppp
Hello James,
thank you for your tips. You were right, I could dramatically shorten
the configuration. It let to the same behaviour. I had another LTE IoT
modem available (this time a Quectel BG96 chip) and I tested the same,
shortened, configuration with this modem. This time it worked out of
the box and I can ping in both directions the relevant hosts over the
PPP connection.
So, maybe it is something specific with the BC66 chip or even the Olimex
device hosting the BC66 chip. Unfortunately Quectel's documentation on
PPP with the BC66 chip only describes the configuration on Windows
hosts. In this document they describe lots of specific configuration
changes (like switching off different authentication methods, etc.).
That's why my first configuration was so convoluted, because I tried
to adapt the Windows specific options to PPP options.
Again, thank you for your help and support, it really helped.
I consider switching modems now...
Regards
Björn
Am Wed, 10 Feb 2021 12:22:57 -0500
schrieb James Carlson <carlsonj@workingcode.com>:
> On 2021-02-10 04:17, Björn Kirchner wrote:
> > Dear list readers,
> >
> > I am stuck with the following problem and I hope you can give me
> > some hints or advice. It looks to me like a configuration or
> > routing error.
>
> A broad hint first: less configuration is always better. Not only
> have the developers chosen the defaults very carefully to make them
> work in the widest range of cases, but the protocol itself is
> designed to negotiate the available options in order to settle on the
> correct link parameters. A giant configuration file either says
> "this set-up is really brittle" or possibly "wow, the peer I'm forced
> to talk to is flaming garbage."
>
> I'm not saying you're necessarily doing anything wrong here, but that
> laundry list is at least suspicious, and I'd certainly wonder why it
> is set up that way.
>
> A summary analysis: other than three questionable options
> ("nodefaultroute", "noaccomp", "nopcomp") and what appears to be a
> broken serial interface ("nocdtrcts", "local"), I don't see anything
> in particular going wrong at the PPP level. The problems, whatever
> they may be, are elsewhere.
>
> > I have an Olimex NB-IoT-DevKit with a Quectel BC66 LTE-NB1 chip
> > which
>
> Ah, the legacy of GPRS. Fortunately, I haven't kept up with this
> "NB-IoS" stuff, but if it's from the same folks who designed that
> earlier gear, then there are some things to be aware of here:
>
> - The actual authentication and IP address assignment is done through
> some other protocol, not PPP, and is typically done during the LCP
> negotiation, and completely behind your back.
>
> - Any failures that occur during that hidden work are almost always
> completely invisible. If it's a bad user name or password, the peer
> usually assigns a bogus IP address and just fails to provide any
> service. There are no error messages. No way to know, at least via
> PPP messages.
>
> > and the P-t-P’s address. My problem is, that I cannot reach anything
> > via that connection. I cannot ping the P-t-P, I cannot ping other
> > addresses. The ISP’s support confirmed that PPP was a viable option
> > to
>
> That's typically what's expected when the authentication phase fails
> or when the client is otherwise "unauthorized."
>
> I strongly suspect that the problem is with the "AT" commands in the
> chat script. I have no way of verifying those.
>
> On to some (overly detailed) notes about your PPP configuration:
>
> > refuse-chap # (from /etc/ppp/peers/quectel-ppp)
> > refuse-mschap # (from /etc/ppp/peers/quectel-ppp)
> > refuse-mschap-v2 # (from /etc/ppp/peers/quectel-ppp)
> > refuse-eap # (from /etc/ppp/peers/quectel-ppp)
>
> These really aren't necessary. If you don't have username/passphrase
> pairs configured into the /etc/ppp/*-secrets files for this peer, then
> pppd will automatically refuse those protocols. And the peer isn't
> even asking for authentication from us ... so these do nothing.
>
> > user * # (from /etc/ppp/peers/quectel-ppp)
> > password ?????? # (from /etc/ppp/peers/quectel-ppp)
>
> These are apparently useless. The peer isn't asking for
> authentication at all via PPP. (Though, to be fair, this could be
> because the chat script is setting things up incorrectly. Maybe it
> would ask if the "modem" were set up correctly ... ?)
>
> > remotename 3gppp #
> > (from /etc/ppp/peers/quectel-ppp)
>
> If you're not doing authentication, then this may be useless.
>
> > record /tmp/quectel.record #
> > (from /etc/ppp/peers/quectel-ppp)
>
> Not sure why you'd want that. It's really an internal debug option
> intended for PPP developers. I suggest leaving it out as it can
> certainly complicate things. It forces the pppd daemon to run on top
> of a pty pair and write the "raw" AHDLC data to a file for later
> analysis.
>
> > nocdtrcts # (from /etc/ppp/peers/quectel-ppp)
> > local # (from /etc/ppp/peers/quectel-ppp)
>
> Those two are a real shame. This serial device really has no modem
> control lines at all? Even if you get this working, it's possible
> that it won't work very well at all.
>
> "nocdtrcts" means "no hardware flow control exists." This means that
> CTS/RTS aren't used. And if one side or the other encounters an
> overflow, then it'll just drop bytes silently, causing packets to be
> dropped. With enough of that, the link will be utterly unusable.
>
> If the device you're using really is that horrible, then I'd check to
> see if it can do at least XON/XOFF ("xonxoff") software flow control.
> Something is better than nothing at all.
>
> "local" means "no modem on/off hook signaling." This means that
> DTR/DCD aren't used. That means that if the other end hangs up for
> some reason, then you'll get no notice at all. Bytes will just stop
> flowing mysteriously.
>
> If that's really the case, then I *strongly* recommend using the
> "lcp-echo-failure" and "lcp-echo-interval" options. This allows PPP's
> LCP layer to detect link failure. Otherwise, you're shooting packets
> into the dark.
>
> > noaccomp # (from /etc/ppp/peers/quectel-ppp)
> > nopcomp # (from /etc/ppp/peers/quectel-ppp)
>
> These two appear to be incorrect. The peer is asking for these two
> common options, and you've configured it intentionally to refuse them.
> I don't see why anyone would do that. Note that these are *NOT*
> related to data compression in any way. The "compression" they're
> referring to here is just omitting some constant bytes from the PPP
> header.
>
> ACFC gets rid of the static HDLC "FF 03" at the start of every PPP
> frame. PFC gets rid of the extra "00" byte for network protocols less
> than 0100 -- this means that IP shows up as "21" instead of "00 21".
> Having both options on (the default) means saving 3 bytes per packet.
>
> Unless you know for sure that you're operating over an HDLC link using
> multi-point addressing, or that the peer has horrible bugs in its
> basic PPP implementation, turning ACFC off likely makes little sense.
>
> See RFC 1661 sections 6.5 and 6.6 for details.
>
> > novj # (from /etc/ppp/peers/quectel-ppp)
> > novjccomp # (from /etc/ppp/peers/quectel-ppp)
>
> The peer isn't offering VJ header compression, so these likely don't
> do much. Note that "vjccomp" is dependent on "vj", so saying "novj"
> alone is sufficient to turn off both.
>
> > nodefaultroute # (from /etc/ppp/peers/quectel-ppp)
>
> This is a little weird. Are you sure? I thought this was supposed to
> be your connection to the Internet. If so, then you certainly want to
> have pppd establish a default route for you. (Doing so manually is at
> best error-prone.)
>
> Just make sure you remove the system's default route (if any) before
> starting pppd.
>
> > noremoteip # (from /etc/ppp/peers/quectel-ppp)
>
> This appears to be unnecessary, but may be harmless. The peer is
> offering an IP address for itself, so the option doesn't come into
> play.
>
> > noccp # (from /etc/ppp/peers/quectel-ppp)
> > nobsdcomp # (from /etc/ppp/peers/quectel-ppp)
> > nopredictor1 # (from /etc/ppp/peers/quectel-ppp)
>
> "noccp" is sufficient. The rest of those protocols are dependent on
> CCP negotiation. You can't get there if CCP is turned off.
>
> > Output from ifconfig ppp0:
> > root@raspberrypi:~# ifconfig ppp0
> > ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
> > inet 10.43.124.1 netmask 255.255.255.255 destination
> > 10.0.0.1 ppp txqueuelen 3 (Point-to-Point Protocol)
> > RX packets 3 bytes 30 (30.0 B)
> > RX errors 0 dropped 0 overruns 0 frame 0
> > TX packets 3 bytes 30 (30.0 B)
> > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> Nothing looks wrong there.
>
> > If you need more information I am eager to provide those. Do you
> > have any suggestions how to be able to receive the hosts on the
> > "other" side?
>
> I don't know what that means.
>
> However, wireshark is an excellent tool to use if you think that
> there's a problem at the network level, rather than just the basic
> connection itself.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-02-15 7:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-10 9:17 Problem with M2M PPP connection Björn Kirchner
2021-02-10 17:22 ` James Carlson
2021-02-15 7:30 ` Björn Kirchner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).