Chateau LTE18 "modem's control interface have reset"

RouterOS General
1

With my recently bought Chateau LTE18, I keep getting modem errors whenever the weather outside is anything less than sunny. (Though certain things make me suspect some kind of interference from construction nearby, rather than the weather.) (Edit 2: Now that I have actual graphs, I’m increasingly suspecting interference… 12 resets in just an hour, and then perfectly stable the rest of the day.)

lte,packet,raw lte1 mbim: wdm >>> recv #0
lte,packet,raw lte1 mbim: 04000080 10000000 00000000 05000000
lte,info       lte1 mbim: error: protocol error: not opened
lte,error      lte1 mbim: modem's control interface have reset (13)
lte,account    lte1 session: 119s 3659657/822817 bytes 5293/4334 packets
lte,debug      lte1 mbim: state 18=>0
lte,debug      lte1 mbim: <<< close

Sometimes it resets just once, sometimes twice in a row; today it has counted 13 resets in just a few hours. In good weather it stays stable for days. It usually recovers in a few seconds, although there have been one or two occasions where it got stuck on “no response for: AT E0 V1” and I had to power-cycle it, but those have been rare.

(That is, with 7.15.x it reconnects fine; but with 7.16beta7 it almost always makes the whole router crash and reboot.)

As far as I can manage to understand the numbers, the link quality isn’t great but isn’t terrible either (I get 50-60 Mbps, more than the ISP-provided Huawei modem could do):

      primary-band: B20@10Mhz
            earfcn: 6300
        phy-cellid: 383
           ca-band: B1@20Mhz earfcn: 300 phy-cellid: 295
                    B3@20Mhz earfcn: 1348 phy-cellid: 282
     dl-modulation: qpsk
               cqi: 9
                ri: 1
               mcs: 0
              rssi: -73dBm
              rsrp: -101dBm
              rsrq: -11dB
              sinr: 10dB

(Sometimes it connects to a tower with RSSI -73, sometimes to another with -83.)

The modem firmware is latest:

> /interface/lte/firmware-upgrade lte1
  installed: EG18EAPAR01A13M4G_01.002.01.002
     latest: EG18EAPAR01A13M4G_01.002.01.002
2

So it lasted a month without any issues. Then we had a power outage so the modem rebooted, and seemed to be working… until it started resetting every five minutes. Reboot didn’t help, power-cycle didn’t help, upgrading to 7.15.3 and then to 7.16rc4 didn’t help, several more reboots and power-cycling helped a little, but it’s still back to its original behavior of resetting multiple times in an hour.

Looking at debug logs, though, one thing that consistently shows up is “pcc” “LTE BAND 28”. I only have logs for the last few hours (plus a few small pieces from last month), but it seems that every single crash in the last few hours happened when band 28 was primary – in fact it seems to crash immediately as soon as the modem tries to use band 28 – so I’ve now set “bands=1,3,7,20” to see if that helps.

lte1: sent AT+QENG="servingcell"
lte1: rcvd +QENG: "servingcell","NOCONN","LTE","FDD",246,01,xxxxxxxx,383,9360,28,3,3,21A2,-106,-14,-72,9,7,210,-
lte1: sent AT+QCAINFO
lte1: rcvd +QCAINFO: "pcc",9360,50,"LTE BAND 28",1,383,-106,-15,-73,10
lte1: rcvd +QCAINFO: "scc",1348,100,"LTE BAND 3",1,282,-119,-16,-80,1

Edit: Five hours later, no crashes with band 28 disabled… and I also found out that my ISP lists band 28 as “5G Non-Standalone”, not as 4G. I’m guessing the 4G-only modem doesn’t like that.

3

Well, it’s been running for 5 days with LTE band 28 disabled and so far absolutely no problems.

(Also took the opportunity to disable band 8 as it just made the connection slower whenever the modem switched to “Primary: B8@5MHz”.)

I still wonder why a 4G-only modem even tries to connect to a 5G network, or why it crashes instead of going “nope, this doesn’t look like a 4G signal” – I hope this will get a firmware fix at some point.

4

The band28 of your provider may be used for both 4G and 5G.
And maybe the modem has problems with this, but this is something that mikrotik should investigate.