LTE Connections

RouterOS General
1

I am bench-testing the MikroTik "D53G-5HacD2HnD&FG621-EA".
I wrote a script to monitor how many TCP connections I can establish via the LTE1 interface; I see a maximum of 220 simultaneous connections. Is anyone else experiencing something similar who might have a tip?
If I route the internet via my smartphone's Wi-Fi, I can establish an average of 2,600 connections, but when I install the SIM card in the MikroTik, the maximum is 227.
The script I run for this test sends out multiple SYN packets to establish TCP sessions, allowing me to test the session limit within the MikroTik's conntrack table.

2

Hi,

What is your router's configuration.
Connection tracking limits could be set and influence the numer of connections.
You can check there: Connection tracking - RouterOS - MikroTik Documentation

Maybe your phone blindly reports connections that are not really active?
MT has TCP SYN timeout set to 5 sec, so non confirmed connection could be cleared almost immediately.

3

Hello.
Before running the test, I adjusted the limits to an average of 59 seconds to prevent the connections from dropping. I observed this behavior—where no more than 227 sessions could be established—across all the devices and modems I tested. I am absolutely certain this isn't a RouterOS issue; however, since RouterOS allows for better traffic monitoring, I thought perhaps someone else had encountered this before.
It is a very strange behavior that occurred on every device I tested. Given that they all behaved similarly, I suspect it is directly related to how the device's modem processes packets. I say this because when tethering via a smartphone, the number of sessions achieved is significantly higher—likely due to the phone having greater processing power than these modems.
Regarding packet TTL: in addition to extending the connection duration in RouterOS, I set the TTL via a script—averaging 120 seconds—to ensure they could still be accounted for after all packets were sent.

4

Are you sure that your phone does share hotspot using the LTE connection, not WiFi to WiFi one?
The 227 limit could come from LTE operator.

5

yep, the limit really only applies when using a modem.

6

So, it seems that we have an answer.

7

I am interested how this script looks like.

8

My script test.

#!/bin/bash

# --- Ajuste de Limites do Sistema (Ubuntu) ---
sudo ulimit -u 65535 >/dev/null 2>&1
sudo ulimit -n 65535 >/dev/null 2>&1

# --- ConfiguraçÔes ---
REDES=($(grep -v "source:" sites.txt))
PORTA=443
CONNS=20500
TIMEOUT_SESSAO=60
DURACAO_MONITORAMENTO=20 

echo "--- TESTE DE ALTA PRESSÃO V3 (OPTIMIZED FOR UBUNTU) ---"

# Pré-geração da lista
ALVOS=()
total_sites=${#REDES[@]}
for ((i=0; i<CONNS; i++)); do
    ALVOS+=("${REDES[$((i % total_sites))]}")
done

# LatĂȘncia Inicial
PING_BASE=$(ping -c 3 8.8.8.8 | awk -F"/" 'END{print $5}')
echo "LatĂȘncia Inicial: ${PING_BASE}ms"

# --- Disparo com Controle de Burst ---
echo "Disparando $CONNS conexÔes..."
for i in $(seq 1 "$CONNS"); do
    TARGET=${ALVOS[$((i-1))]}
    
    # Simula navegação mantendo o socket aberto
    ( (sleep "$TIMEOUT_SESSAO" | nc -w "$TIMEOUT_SESSAO" "$TARGET" "$PORTA") > /dev/null 2>&1 & )
    
    # A cada 200 conexÔes, uma pausa de 0.05s para não estourar o fork do Ubuntu
    if (( i % 200 == 0 )); then
        sleep 0.05
    fi

    if (( i % 1000 == 0 )); then
        echo ">> Injetadas $i conexÔes..."
    fi
done

echo "----------------------------------------------------------"
echo "TEMPO | ESTABLISHED | SYN-SENT | PING (8.8.8.8)"
echo "----------------------------------------------------------"

for t in $(seq 1 "$DURACAO_MONITORAMENTO"); do
    ESTAB=$(ss -ant | grep -c "ESTAB")
    SYN_SENT=$(ss -ant | grep -c "SYN-SENT")
    PING_NOW=$(ping -c 1 -W 1 8.8.8.8 | grep 'time=' | awk -F'time=' '{print $2}' | cut -d' ' -f1)
    
    printf "%-5s | %-11s | %-8s | %-s\n" "${t}s" "$ESTAB" "$SYN_SENT" "${PING_NOW:-"TIMEOUT"}"
    sleep 1
done

echo "----------------------------------------------------------"
echo "VEREDITO: Se o PING estabilizou acima de 100ms ou deu TIMEOUT, o modem falhou."

# File sites.txt
www.google.com
www.youtube.com
www.facebook.com
www.instagram.com
www.chatgpt.com
x.com
www.reddit.com
www.whatsapp.com
www.bing.com
www.wikipedia.org
www.yahoo.com
www.amazon.com
www.tiktok.com
www.baidu.com
www.bet.br
www.linkedin.com
www.temu.com
www.netflix.com
www.live.com
www.dzen.com
www.pinterest.com
www.bilibili.com
www.xvideos.com
www.office.com
www.xhamster.com
www.twitch.tv
www.microsoft.com
www.weather.com
www.vk.com
www.fandom.com
www.samsung.com
www.sharepoint.com
www.roblox.com
www.globo.com
t.me
canva.com
duckduckgo.com
stripchat.com
booking.com
ebay.com
openai.com
aliexpress.com
www.gigawebtecnologia.com.br
teste.gigawebtecnologia.com.br
cliente.gigawebtecnologia.com.br
9

That is not really an apples-to-apples test. With the SIM in the MikroTik, you are testing the MikroTik LTE path, including firewall/NAT/conntrack. With the SIM in the phone, you are basically testing the phone as a hotspot, so that is a different datapath.

We use several different MikroTik LTE models as CPEs and have never seen any generic conntrack limit like this. Thousands of connections normally work without any issue.

My first thought was some broken IPv4 CGNAT behavior on the MNO side, but if you are using the same SIM in both tests, that is probably not the main factor.

My guess is that something is off with the test script, the config, or possibly both.

10

@Alessandro_Schneider - Regarding your script: it looks very much like an LLM-generated script, with several flaws that an experienced person would spot immediately:

  1. The main issue is that this script doesn't actually measure the MikroTik conntrack table. It measures TCP socket states on the Ubuntu client.

    So the ESTABLISHED/SYN-SENT numbers are client-side socket states, not RouterOS conntrack entries. To test MikroTik conntrack, you need to measure it on the router itself, for example with /ip/firewall/connection/print count-only while the test is running.

  2. Also, nc to port 443 without doing any TLS/HTTP handshake isn't a very reliable “real connection” test. It creates TCP sessions, but many remote servers may close idle or incomplete sessions quickly, so the result can be affected by the remote servers, local Linux limits, and script behavior, not just the MikroTik. Use curl instead of nc.

  3. ICMP ping also creates conntrack entries, but in RouterOS the default ICMP conntrack timeout is only 10 seconds. Ping latency is therefore not a good indicator of sustained conntrack capacity either.

  4. sudo ulimit -u 65535 and sudo ulimit -n 65535 in the beginning of the script probably don't do what you think here. Ulimit (a shell builtin function) effects the current shell process only (and its children) so running it through sudo like that will not raise the limits for the script itself.

11

@Alessandro_Schneider what happens when 220 limit is reached? New connections cannot be established or stalling? Personally for more reliable test I would use curl in script and validate server responses (no matter which HTTP code is responded) with parallel HTTP GET from some valid URLs list in loop with some configurable parallel connection pool count variable, can be root URLs to some sites. While performing such test also try to establish connections over different device on network, like trying to browse over mobile phone connected to same local network and observe behavior.

I had LTE maximum connections issue over my ISP when I was behind CGNAT, I think it was around 500, now I have for a while public IP over LTE and there is no such issues, tested with 10 of thousand connections with Apache JMeter to some REST service when I was performing load test for it. So I guess in my case it was bottleneck on ISP side because of CGNAT.

12

@optio, read my comment on the test script above and check the script itself. You will see all the flaws and why this is not a serious test.

13

AFAIK when curl performs HTTP GET it's not just performing TLS handshake, it is also fetching data from HTTP server and it should not be incomplete session. Definitely 1k curl parallel requests can create 1k connections.

14

Yeah, you are correct regarding curl, but I think you missed the point.

15

Well that's how I tested when I had similar issue and confirmed it. Also on other devices when script was running connections was stalling,

16

Well, yeah, that's what I would use as well, but the LLM-generated script uses nc. Still, that is not the main issue here. Read my highlighted comment on the script and you will probably understand why.

17

Ok, then we misunderstood each other, my suggestion was also to rewrite script...

18

The sole purpose of this script is to measure the number of established TCP connections, regardless of whether the connection is via mobile data or any other type. I believe the issue at hand is unrelated to RouterOS itself but may be linked to the modem being used with the MikroTik device.
I hope I’ve made my objective clear.

19

I apologize to my friend, but the script is a perfectly reliable test for the purpose for which it was developed; as I mentioned earlier, its purpose is to measure the number of established connections, whether they are passing through an LTE modem or fiber optics.

20

For now, I’m ruling out the possibility that the issue is related to CGNAT, since everything works as expected when tethering via a smartphone—establishing around 3,000 TCP connections. The problem only occurs when using a mobile data modem.
I think using cURL is a valid approach; my goal is simply to verify the number of connections I can establish by checking the TCP handshake.
The issue is that once the number of established connections approaches 200, everything else stops working—web pages fail to load. This only happens when using a modem; on "standard" connections, such as fiber optics, everything works perfectly.

Just a quick note: I am an internet service provider in my region.