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!

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).

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.

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