Warning — LTE interface stops working after upgrade to 7.23.6, 7.24.3

Announcements
1

Do not upgrade the following devices to the latest released versions 7.23.6, 7.24.3. Doing so will leave the LTE interface non-functional:

  • RBSXTLTE3-7
  • EC25-EU&KNe
  • EG25-G&KNe
  • EC25-EU&SXTsq
  • EG25-G&SXTsq

If you have already upgraded, restore LTE as follows:

  1. Downgrade RouterOS to version 7.23.5 or 7.24.2

  2. Update the modem firmware:
    /interface/lte/firmware-upgrade lte1 upgrade=yes

  3. Reboot the router.

If the router has no internet connection, download the modem firmware package manually, upload it to the router's Files list, and reboot to install it.

Firmware packages:
RBSXTLTE3-7 : https://box.mikrotik.com/seafhttp/f/677d8585b306489d8179/?op=view
EC25-EU&KNe, EC25-EU&SXTsq : https://box.mikrotik.com/seafhttp/f/aa44c75e455e41e7a34f/?op=view
EG25-G&KNe, EG25-G&SXTsq : https://box.mikrotik.com/seafhttp/f/065097528eda44759481/?op=view

2

Is the problem resolved by the LTE firmware update?
Is it possible to reinstall versions 7.23.6 / 7.24.3 later, or do I need to wait for versions 7.23.7 ​​/ 7.24.4?

Thanks.

3

Upgrade to v7.23.6 or v7.24.3 will permanently delete the firmware. Even if you install it back - it will be removed again. You must downgrade in order to install firmware back and remain on the same version while waiting for a new release which will "not delete LTE firmware by accident".

4

I am wondering, which changelog item in the release of 7.23.6 is the cause for this issue? I do not even see a * lte - xxx. Only a lot of stability improvements.

5

I didn't want to rub it in, but I was wondering the same thing myself...

6

There I fixed the changelog :wink:

7

I presume you meant:

8

Seriously, what will be the changelog line in 7.23.7?

  • lte - improve firmware removal stability
9

No I mean they add this to 7.23.6 so everyone known. I just loved the comment removes the firmware by accident :slight_smile:

Not that this is a factor that forgives this but now with AI and codereview I'm very happy I work in infrastructure as the pressure on companies that produce software must be massive.
MT is not the only vendor. Where I work we have major indidents due to RDP faliure that we got from this months paches from MS but to be fair they fixed over 950 CVE's in one patch.

10

It must be under

  • system - improve stability...
    ... by deleting LTE modem firmware...
11

I laughed out loud at that!
The people around me gave me a strange look.

You only get to experience sensations like that using MikroTik!

12

I’ve just upgraded to 7.24.4 on my LHGGM , and I’m terrified.

Option #System:RouterBOARD->upgrade inconsistent with #Interfaces.LTE_Firmware_Upgrade

After OS upgrade first reported firmware upgrade completed, second new firmware available.
To check and proceed , I had required to disable FIREWALL rule blocking of other outputs for filter chain.

Logs reported toons of failures outputs
2026-09-17T00:31:08.144+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK), x.x.x.x:39202->159.148.147.251:80, len 52

2026-09-17T00:31:08.145+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:08.394+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:08.854+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:09.264+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK), x.x.x.x:39202->159.148.147.251:80, len 52

2026-09-17T00:31:09.834+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:11.224+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK), x.x.x.x:39202->159.148.147.251:80, len 52

2026-09-17T00:31:11.764+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:15.264+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK), x.x.x.x:39202->159.148.147.251:80, len 52

2026-09-17T00:31:15.524+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:18.154+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,FIN,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:23.354+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,FIN,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

2026-09-17T00:31:23.574+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK), x.x.x.x:39202->159.148.147.251:80, len 52

2026-09-17T00:31:38.714+02:00 router-lte firewall,info OTHER output: in:(unknown 0) out:lte1, connection-state:established proto TCP (ACK,FIN,PSH), x.x.x.x:39202->159.148.147.251:80, len 220

Why firmware upgrade completed by HTTP if OS using HTTPS?

Firmware version EG18EAPAR01A13M4G_01.300.01.300 upgraded to EG18EAPAR01A14M4G_01.300.01.300.

Checking what's happen now.

This is the first time, and I have to say something has gone wrong with MT.
AI is having too much say in development, or there’s a lack of rigorous testing.

13

And where is that written?

Besides, it makes no difference:
the files are checked beforehand to see if the signatures match, they aren't installed blindly,
so why waste resources encrypting a connection that is already signed to begin with?
HTTP works perfectly fine.
And if you set outbound rules for the router that needs to connect to download updates,
what do you expect? That it won't create logs? (in the rule you created yourself, which isn't there by default)

14

I presume he is talking about this:

system/package/update/print  
            channel: long-term                   
               mode: **https**                       
  check-certificate: yes                         
         ip-version: auto                        
  installed-version: 7.23.7                      
     latest-version: 7.23.7                      
             status: System is already up to date

But yeah, checking signature should be safe enough,,,

15

Because one may not want to inform the whole Internet infrastructure between the device and download.mikrotik.com about the transferred data. While for MikroTik as a company that may be insignificant, there are user threat models in which that matters, so this is not a waste.

Speaking of all that, the IP address is considered personal data under the GDPR, so any other data that can be correlated with it must be protected "using available technology", i.e. associated traffic.

In short, the assumption that TLS is only for authenticity and integrity is simply incorrect.

16

There is no problem with this because the packages are all signed. Do you know that Linux distros such as Debian and Ubuntu still default to using HTTP mirrors? Even for fetching the package lists.

And do you really think that the IP addresses are hidden if you use HTTPS :rofl:?

17

I guess @utiker is afraid that somebody will see that he's downloading ROS for certain architecture. Because downloading from download.mikrotik.com could also mean he's fetching his daily dose of (insert your favourite on-line waste of time here).

I also guess that @utiker drives car which is masked because seeing he's driving Tesla cybertruck people might get some weird idea about him.

18

If you really read what you are quoting, you wouldn't need to laugh at what it doesn't say.

19

Actually I did also understand it the way @CGGXANNX did. You consider IP address as personal data which must be protected by all measures. But IP address can't be hidden. But if you meant it differently, you need to explain what you actually meant.

20

I wonder why.

You consider IP address as personal data which must be protected by all measures.

I didn't say that. I said the GDPR considers that IP address is personal data.

"‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); " - Article 4(1)

Also discussed here.

which must be protected by all measures.

Not my words. I said "available technology" - the wording used in GDPR. In the current context, TLS is available technology.

Recital (26):

"The principles of data protection should apply to any information concerning an identified or identifiable natural person. [...] To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. [...]"

The phrase "available technology" is mentioned in other parts of the GDPR too.

But IP address can't be hidden. But if you meant it differently, you need to explain what you actually meant.

What I said:

Speaking of all that, the IP address is considered personal data under the GDPR,

See above the explanation of what that means. I did not say "IP address can be hidden using HTTPS" (which of course is nonsense).

so any other data that can be correlated with it must be protected "using available technology", i.e. associated traffic.

Associated traffic means traffic related to the IP address (of the MikroTik device) - that can also be considered personal data in relation to the IP address, as it can be used to identify an individual.

Even if the IP address is not immediately available (e.g. one hides it using Tor, VPN, ...), an adversary can still analyze the traffic to identify a target, especially when it reveals usage of unpopular hardware and particular software version. Unencrypted traffic makes that much easier.