[TL-MR6400 v5] LTE "disconnect" after six hours

Hi.
I need to open a new topic about this router/modem because I didn't find a good solution.
Even if this isn't my first OpenWRT router, I'm new with this distro.
I write everything so, maybe, it can be useful also for other users with the same hardware.

My need is a modem with 4G to use it predominantly only with LTE connection.
After some research here in Italy, I found this Tp-Link TL-MR6400 v5 that I bought after I found the page about this here on the OpenWRT's site and forum.

Received it, I didn't try it with the stock firmware and flash directly with the right image:
with WAN connection it works fabulously, with LTE no.

First problem: LTE module didn't work.
After installed the uqmi package and stuff about this (https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle),
the SIM didn't connect with provider's network.

So I patched the file "/lib/netifd/proto/qmi.sh" as indicate here -> Enabling TL-MR6400 v5 LTE
The SIM connect to the network but there wasn't Internet.
I use command as
uqmi -d /dev/cdc-wdm0 --get-signal-info

to verify that the SIM has joined to the provider's network.

I found the image of fachos user (https://mega.nz/folder/tj5yTTgb#FzUuQNF4XaPqB--pnzxFIA) and it works but, sorry, I prefer the official images,
so I went back on the official image, with uqmi package and patch but still no Internet.

After two days, I gave up and use the uqmi package modified by mrhaav user (https://github.com/mrhaav/openwrt/tree/master/21.02.2 - TL-MR6400 v4 - LTE modem for WAN connection - #13 by Dotlee)
and it just works (and I would like to know the reason, but I didn't have time).

I found also a script for LTE led signal that is very useful (TP-Link TL-MR6400 v5.2 LTE configuration - #6 by suchagoodguy)
so, I closed everything and put "in production" this router/modem.

It seemed to work but
second problem: connect but no Internet after six hours.
After six hours with SIM connect and Internet working,
again the problem as indicate in the first problem section:
the SIM is joined to the LTE Network of the provider but no Internet.

It's always after six hours, I timed it.

I didn't find any informations about this in the log and I still have this problem.

I found a video on YouTube (https://www.youtube.com/watch?v=9vxJEZrR1Fk) where it showed the same problem but,
unfortunately it isn't in English, so I don't understand anything.
At the end of the video, there is a script to "auto-reconnect" the LTE module when the Internet is down....
it is just a ping to Google DNS and when there is an error, use the S&A algorithm: turn down/off and turn up/on LTE interface (in Italian: "Spegni&Accendi").

It's a crappy solution IMHO but I tried: unfortunately, in my case, the provider give an error when the SIM tries to connect again:
Error: Unknown error (DATA_FORMAT_FAILURE)

I need a quick solution because the router/modem it isn't near me (more then ~100Km) and I didn't a VPN (unfortunately the provider, Very Mobile, use a CG-NAT, so I have to install a server here and configure the router to connect automatically to the server),
so I use this command when the ping gives error:
reboot now

Shame on me but it works but I don't like it.

Any suggestion?

I'll try with another SIM Very Mobile with a smartphone in hotspot if there are some problem after six hours,
to exclude a provider "problem" (or block) but I think it's a some fault in the package for the LTE module.

I use also "adblock" and "https-dns-proxy" modules but I use them also in another router and I don't have this problem.

Thanks.
Have a nice day.

Ps.: the script on the video on YouTube, I wrote down:

#https://www.youtube.com/watch?v=9vxJEZrR1Fk
#!/bin/sh

iface="WANLTE"			#which interface to bring up/down
host='8.8.8.8'		#what to ping

ping -c 2 -W 15 "$host" > /dev/null
if [ $? -eq 0 ]; then
	echo ok
	exit 0
else
	ifdown "$iface" $$ ifup "$iface"
fi

Hi

It is not uncommon that the service provider reset the connection after a certain time.
The problem is that uqmi can not handle it in a god way.

I will see if I reproduce the issue and find a more tidy way to do it then just restart the interface.

I think your YouTube script is wrong in the "else" part.
ifup "$iface" should be enough.

BTW. If you have some time left, you can find my source code at https://github.com/mrhaav/openwrt-packages :wink:

1 Like

Hi

I found SIM card where the service provider release the connection every 6th hour. So I created a new version of uqmi that includes a daemon for checking network connectivity every 30sec.
If the connection is released from the network side the daemon will activate the connection again and re-initiate the interface. The daemon will also send the rssi value to /usr/bin/uqmi_led.sh for trigger LEDs.
The new version is available at: https://github.com/mrhaav/openwrt/tree/master/21.02.2

1 Like

Hi mrhaav,
I had the answer in the draft waiting to try your suggestions (but I'm 100Km away from the device :slight_smile: ).

So thank you so much for your effort for the research and the new daemon.

Just a question: does the script for the leds require a cron job?
It's cleaner than the other one I linked.

Have a nice day.

No, you shall not run the uqmi_led.sh as a cron job.

Maybe a possibility to reset the interface, or device, via SMS could be useful, or?
I think it´s possible to add an SMS function in the daemon.

Ok, the script is managed by daemon... better in this way.

SMS can be useful but also dangerous if someone finds it.
To be safe to use it, it should also add some protection system, such as an allowed list number or a "password" in the message.

Just IMHO.

Thanks.

Yes, the script is managed by the daemon.

I agree we need to have some security regarding SMS.
It is easy to filter on the sender of the SMS. So SMS from your mobile is only allowed.

If it is easy, it should be very useful manage the HW also with SMS.
Thanks.

Hi

I made a new version with an SMS receiver. It will store the SMS in folder /var/sms and the daemon will send the file name to /usr/bin/uqmi_sms.sh.
In the SMS file the first row is the phone number of the sender and the following rows are the text message.
So you can easy check who has send the message and you can add roles in the text message for you operations.

Good Morning/Evening.
I saw it, very simple to change for own needs.

Just a hint: maybe it can be better to delete the SMS also if the number is unauthorized after log the number in the error message.
Someone can try and make a "DDoS" of SMS and the memory could be saturated.
A really remote case but "security "is never enough :slight_smile: .

Thanks.

And, sorry for the other message, are you sure it is "logget" and not "logger"?
I check the command and:
https://openwrt.org/docs/guide-user/base-system/log.essentials

Thanks.

Hi

The uqmi_led.sh and uqmi_sms.sh are not included in the ipk file. So you have to create them your self.

Yes, I agree it could be a good idea to delete unauthorized SMSs, if you are not curious. :wink:
The daemon will print to the system log when an SMS is received, for all received SMSs.
Thu Apr 28 21:54:47 2022 user.notice uqmi_d: SMS recieved from +46123456

Yes, it shall be "logger", it was a typo.

Ahahah, you're right: I didn't think to see the body of the message.
Ok, so I have to create the scripts, clear.

I'll "update" it and try it.

Thanks.
Regards.

Hi.
I just updated the package with the newone (https://github.com/mrhaav/openwrt/blob/master/21.02.2/uqmi_2022-04-22-0.5_mipsel_24kc.ipk) and now I'm trying it.

I'm thinking: can the SMS of the provider (example: renew the tariff plan) cause some problem?
I don't think so but I have some doubts.

I'll update if the network connection is stable or not.

Have a nice afternoon.

Hi
I don´t see that the SMS from your provider will cause any issue. You can just delete the SMS when you receive it.
You had received it any way, now it´s just visible.

Yes, right and I add something: it's useful to check the SMS of the provider.
I'm thinking of doing a script (or edit your script, sorry if you don't like it) to send me the provider's SMS via email to know when something has changed.

Anyway, seven hours after updating the package it seems to work without problem.
Before change it, I tried also to delete "my" script to reboot it and give only a
ifup "$iface"

when it stopped to "surf the net"
and yes, it worked better than the reboot (but I deleted it after the upgrade package, so...).

The script for led give me this error:

image.png

On Git I read that the script it's an example for MR200v4, so maybe it doesn't work for this model.

I edit it in this way:


#!/bin/sh

rssi=$1

LED1=$(readlink -f /sys/class/leds/white:signal1)
LED2=$(readlink -f /sys/class/leds/white:signal2)
LED3=$(readlink -f /sys/class/leds/white:signal3)

if [ "${rssi}" -eq -200 ]
then
echo 0 > $LED1/brightness
echo 0 > $LED2/brightness
echo 0 > $LED3/brightness
elif [ "${rssi}" -le -90 ]
then
echo 255 > $LED1/brightness
echo 0 > $LED2/brightness
echo 0 > $LED3/brightness
elif [ "${rssi}" -le -70 ]
then
echo 255 > $LED1/brightness
echo 255 > $LED2/brightness
echo 0 > $LED3/brightness
else
echo 255 > $LED1/brightness
echo 255 > $LED2/brightness
echo 255 > $LED3/brightness
fi

It works.
Any advice, suggestions or something to change?

If you want, you can add it to the READMEon GIT for this model.

Thanks.
Have a good evening.

There will be a notice in the syslog if the daemon has re-connected the modem.
You can use logread -e uqmi_d to see disconnections, re-connections and received SMSs.

It´s up to you and change the uqmi_sms.sh script. :slight_smile:
That´s the reason I didn´t include uqmi_led.sh and uqmi_sms.sh. You need to modify them to fit your system and purpuse.

Your uqmi_led.sh looks good. I will add it to my github.

Hi again @mrhaav .
I'm writing here for the reason that maybe can be useful for someone.

I flash again the firmware on the TP-Link TL-MR6400 to have a fresh installation of this;
I also update your uqmi package because I see on the official TP-Link TL-MR6400 wiki page that there is another version * uqmi_2022-05-16-0.5_mipsel_24kc.ipk* (mine was 2022-04-22).

Everything works but I have again the problem of disconnection after six hours.....
So, I checked your Git page and I noticed that the link on wiki page is old because there is another version, the uqmi_2022-05-16-0.6_mipsel_24kc.ipk (0.6 instead of 0.5).

I just update to this version, so I cannot if this works fine or not but, before check on your Git page, I compared the "uqmi_d.sh" scripts and, maybe I'm committing an error, but I think there is a missed variable: I don't see the variable "default_profile" that is called when start the network again (both IPv4 and IPv6).
In the version 2022-04-22-0.5 the variabile is set to false.
I checked if a global variable but not, it just empty.

So, I don't now if the last version (0.6) works fine or not (at least not yet.... if not, I'll add the variable in the script) but I wanted to notice you that maybe it's better update the wiki page with the new version.

Thanks.
Regards.

Sorry @mrhaav,
I confused "default_profile_used" with "default_profile".

Anyway, I hope the last version works fine as the 2022-04-22-0.5 .
Thanks.

Last think @mrhaav, I update the "uqmi_sms.sh" script, because I want:

  • confirmation that the SMS that I sent is correctly arrived
  • forward all SMS' provider to my number
#!/bin/sh

interface=$(uci show network | grep qmi | awk -F . '{print $2}')
device=$(uci get network.${interface}.device)

receivedSMS=$1
Anumber=$(sed -n '1p' $receivedSMS)
if [ $Anumber = '+2348294238943243289' ]
then
        first_row=$(sed -n '2p' $receivedSMS)
        uqmi -s -d $device --send-message "Ok $first_row" --send-message-target $Anumber 2>/dev/null
        rm $receivedSMS
        $first_row
else
        logger -t SMS Unauthorized Anumber
        uqmi -s -d $device --send-message "$receivedSMS" --send-message-target $Anumber 2>/dev/null
fi

Thanks.
Regards.

Ps.: I know that it's so "beautiful" defining the variables ("interface" and "device") again, but I don't want to change the "uqmi_d.sh" script so I can update the package without problem.