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@xxxxxxxxxxxxxxx>:
> 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.
>
