MikroTik KNOT with Quectel BG77 - Repeated PPP Failures Before Connection

RouterOS Wireless Networking
1

Hello everyone,

I’m experiencing issues with my MikroTik KNOT IoT LoRa8 Kit when trying to establish a PPP connection using an mdex EASY SIM (KPN) M2M SIM card (no fixed IP). While the connection eventually succeeds and stays stable, it takes an unusually long time due to many failed attempts beforehand.

Device Details:

  • Model: MikroTik KNOT IoT LoRa8 Kit
  • Modem: Quectel BG77 (Firmware: BG77LAR02A04)
  • RouterOS Version: 7.19beta5 (same issue on stable)
  • Modem Firmware: Updated to latest

PPP Interface Settings:

  • APN: wlapn.com
  • Dial Command: ATD*99#
    → Recommended by both mdex and Quectel BG77 manual
  • User / Password: mdex@mdex.de / mdex
  • Authentication: PAP only
  • Modem Init String:
    AT+QSIMDET=1,1;AT+QGPSCFG=“priority”,1;AT+QCFG=“iotopmode”,0,1
    Note: I’m using AT+QCFG=“iotopmode”,0,1 to enable both eMTC (Cat-M1) and NB-IoT with priority on eMTC, as recommended by the modem’s documentation.

Problem Description:
The connection log shows repeated cycles of:

initializing…
dialing out…
authenticated
terminating…
disconnected
resetting link…

This repeats for several minutes until finally:

authenticated
could not determine remote address, using 10.112.xxx.xxx
connected

Note: The “could not determine remote address” message is not a failure - it just means the provider didn’t assign a remote IP, so MikroTik used a default private IP. The connection is stable from that point on.

What I’ve Tried:

  • Verified APN, dial string, and PPP settings per provider
  • Updated modem firmware
  • Tested different RouterOS versions
  • Rebooted device and reset configs
  • LTE Cat-M1 signal is strong (SINR ~19 dB)

What could be causing these repeated PPP failures before connection succeeds?

Thanks in advance for any advice!

2

Hello,

I’ve got the same thing going on. Sometimes the connection is established within 1 minute and sometimes it takes 30 minutes for something to happen. But most of the time, a physical reboot is required as the PPP stops communicating with the modem (communication has not started at all).

3

Thanks for your reply – it’s somewhat reassuring to know I’m not the only one facing this issue.

I also tried delaying the PPP interface start after boot or resetting the modem automatically during boot - unfortunately, neither approach worked for me.
So I enabled more detailed logging and noticed the following entry:


ppp-out1: rcvd LCP TermReq id=0x3
…
ppp-out1: terminating…

As I understand it, this means the connection is being terminated by the provider, likely because after successful authentication, it expects IPCP negotiation (IP configuration) to proceed - but this step is either too slow or faulty with the modem.

4

Update – I might have made a breakthrough!

After some tweaking, the connection is now established right after the KNOT boots up, almost every time without any failed attempts.

Here’s what I changed:

Updated Modem Init String:

AT+QSIMDET=1,1;AT+QGPSCFG="priority",1;AT+CGATT=1
  • AT+QSIMDET=1,1: Enables SIM detection – this is the default on the KNOT.
  • AT+QGPSCFG=“priority”,1: Sets GNSS priority – also default.
  • AT+CGATT=1: Forces the modem to attach to the LTE network immediately.

I also removed AT+QCFG=“iotopmode”,0,1, as it didn’t seem to make any difference. This configures LTE Cat-M1/NB-IoT operation, but apparently, the modem attaches correctly without explicitly setting this.

Dial Command:

ATD*99#

Still using this, as recommended by mdex and supported by the modem manual.

Why AT+CGATT=1 might have helped:
This command forces the modem to attach to the LTE network before PPP tries to dial out.

My theory is that previously, PPP started dialing before the modem had fully attached, which led to numerous failed attempts.
Now, with forced network attachment, the modem seems to be ready in time, and PPP succeeds on the first try.

I can’t say for certain that this is the root cause, but so far the results are consistent and reproducible.

Here’s my log after reboot now:

09:29:13 initializing…
09:29:13 resetting link…
09:29:14 initializing modem…
09:30:06 dialing out…
09:30:07 authenticated
09:30:07 could not determine remote address, using 10.112.112.123
09:30:07 connected

I hope this helps anyone else.

5

I’ve spent quite a bit of time on this now, but I can’t seem to get a reliable internet connection. Serious question: does anyone actually use this in production environments?

I actually recommend the KNOT to many of my clients. Now I’ve received feedback that most clients tend to use an external mobile router in front of it because the built-in modem isn’t reliable.

Ulle’s modem init string doesn’t improve things for me. On the contrary: it seems to prevent it from connecting at all.

My setup:

  • Model: MikroTik KNOT IoT LoRa8 Kit
  • Modem: Quectel BG77 (Firmware: BG77LAR02A04)
  • RouterOS Version: 7.20.8
6

We’ve got 15 KNOTs used as remote BLE readers that send the detected device information back to base over the LTE (Cat M1 here in the UK) network. We are seeing similar problems when the signal strength is not the best, which I’m looking into now after a weekend where we had very patchy responses. Will update the thread with any findings.

7

There is a newer firmware available in the testing channel:

version: BG77LAR02A04_A0.301.A0.301

/interface/ppp-client/firmware-upgrade ppp-out1 upgrade=ye update-channel=testing

Maybe it improves things for you..

1 Like
8

Do you know if there are any release notes with the modem firmware updates? I’ve done some searching but nothing obvious on the Mikrotik or Quectel sites.