TRB140 receives and sends SMS but can't establish data connection

Teltonika Networks
1

I have a TRB140 providing connectivity to a PLC in a remote location. FW is probably 07.04.4 – I can’t log on to the GW to verify.

The TRB is equipped with a SIM without any limits on data usage.

The TRB connects to the mobile network, and responds to SMSs as pr. the default configuration of “SMS utilities”. However, it is not able to establish a data connection. This means that I do not have access to the WebUI or other configuration tools – only SMS.

It is setup to extract data from the attached PLC via Modbus and transmit this data via MQTT every 30 mins. This worked until the morning of 2023-09-28, at which time it went silent.

A few minutes after midnight on 2023-10-01, it transmitted everything that it had collected since 2023-09-28, stayed online for approximately 1.5 hours and then went offline again.

Requesting status via SMS yields “[…] Data Connectin State - Disconnected; Connection type - LTE; Signal Strength - -66; […]”. Sending “mobileon” or “vpnon rms_[…]” do not work. I have tried rebooting the TRB; after a few minutes it responds with a status message - I expect this confirms a successful reboot?

I have a different TRB140 in an identical configuration running in a similar location. This device works as expected: It publishes data and I can connect to the WebUI.

What could be the cause of this problem and how would I fix it?

3

Hello,

Do you have remote access to the device?

If so, could you please wait for the issue to occur again, then, when the connection is restored, access the device and navigate to System → Administration → Troubleshoot and ‘view’ system logs. Please, share the logs around the time when the disconnects occured. Additionally, please share a screenshot of a Status → Mobile → Network page. Before sharing logs and a screenshot, make sure you hide sensitive information, such as IMSI, ICCID, IMEI, Public IP addresses etc.

When you have the logs, navigate to Services → Auto Reboot → Ping reboot and configure a rule to restart the modem (or the whole device, but I suggest trying to restart the modem first) if the pings to 8.8.8.8 or 1.1.1.1 fail. You can find more information about ping reboot here. This should restart the connection (or whole device) if there are connectivity issues. You can also configure the device to reboot itself periodically if that helps.

Kind Regards,

4

I do not have remote access. The issue is apparently permanent.

I can send SMS to the device and it responds.

I have tried rebooting it by SMS; this has not solved the issue.

Earlier this morning, the device responded with “[…] Data Connection state - Connected; […]”. It did not connect to RMS or the configured VPN and it has since responded “Disconnected” on every status request send via SMS.

While I can’t access the administration interface, I /can/ use the UCI interface through SMS. This is the response to “uci show network”:

network.loopback=interface
network.loopback.proto=static
network.loopback.ipaddr=127.0.0.1
network.loopback.netmask=255.0.0.0
network.loopback.device=lo
network.globals=globals
network.globals.ula_prefix=fd36:d522:6de1::/48
network.lan=interface
network.lan.proto=static
network.lan.netmask=255.255.255.0
network.lan.ip6assign=60
network.lan.device=br-lan
network.lan.ipaddr=192.168.1.1
network.lan.metric=1
network.lan.delegate=1
network.lan.force_link=1
network.lan.stp=0
network.mob1s1a1=interface
network.mob1s1a1.proto=connm
network.mob1s1a1.modem=3-1
network.mob1s1a1.metric=2
network.mob1s1a1.sim=1
network.mob1s1a1.pdp=1
network.mob1s1a1.dhcpv6=0
network.mob1s1a1.auto_apn=1
network.mob1s1a1.force_apn=-1
network.mob1s1a1.device=rmnet0
network.mob1s1a1.auth=none
network.mob1s1a1.pref_apn=397
network.mob1s1a1.apn=internet
network.eth0=device
network.eth0.name=eth0
network.eth0.macaddr=00:1E:42:##:##:##
network.br_lan=device
network.br_lan.name=br-lan
network.br_lan.type=bridge
network.br_lan.ports=

5

Hello,

Might be a coincidence, but this is right when the new month started.

From the previous SMS status messages, it seems that the device is disconnected from the mobile network. Unfortunately, in this case it is hard to say what can be the issue, as logs cannot be viewed via UCI commands. Also, since the device was connected before, not sure if the issue is within configurations.

Was that the last time when the device was online? If it does not reconnect, then you can try to reset the device completely via SMS messages, but I am not sure if this will help. But since it uses auto-apn, it should come online in RMS if it will be able to connect. Troubleshoot file can also be downloaded from the RMS, but the device needs to be online in RMS.

Kind Regards,

6

Yes, I noticed that too. The last evidence of online activity was 01:23 that night; no apparent activity since then.

However, for reasons I haven’t yet understood, the TRB has been back online since app. 1130 today. My instinctive conclusion would be problems in the cellular service, except that I have another, identically configured device operating without connectivity issues not to far from this one.

Anyway, I’ve downloaded the troubleshoot tarball. Any suggestions as to where I should direct my attention when I go through it?

7

Hello,

You can check the system logs around the time when the disconnects occured to see if the connection is simply lost, or there is something else that caused connection loss. Does the device contain logs from the time when it was disconnected? If the logs are just from the time when the connection came back, it is likely that the device was off / rebooted.

How is the connection so far after it came online?

Unfortunately, due to public nature of this forum, it is not feasible to exchange information privately. Thus, you can remove any sensitive information thay may potentially be in the logs, such as public IP addresses, and share some of the relevant logs here.

Kind Regards,

8

Entries in system.log start at 2023-10-02T03:05 and last until 03:15, then nothing until 2023-10-04T11:26. This is replicated using logread in the shell.

Entries from 10-02 indicate repeated attempts to connect to LTE without ever actually getting network connectivity. For example:

Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] Connected to operator 'vodafone ES Flexfone'
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] -CFUN- Functionality: "Full"
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] -COPS- Mode: "Auto", operator: "vodafone ES Flexfone"
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] -CREG- Mode: "Enabled (with location information)", status: "Roaming", LAC: "21205", cell ID: "15777708", technology: "UTRAN"
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] -CGREG- Mode: "Enabled (with location information)", status: "Roaming", LAC: "21205", cell ID: "15777708", technology: "UTRAN"
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] -CEREG- Mode: "Enabled (with location information)", status: "Unknown", LAC: "", cell ID: "", technology: "Unknown"
Mon Oct  2 03:06:14 2023 daemon.info mobifd: [gsm.modem0] IP address on PDP context "1": "0.0.0.0"
[...]
Mon Oct  2 03:06:17 2023 daemon.info mobifd: [gsm.modem0] IP address on PDP context "1": "0.0.0.0"
Mon Oct  2 03:06:20 2023 daemon.info mobifd: [gsm.modem0] IP address on PDP context "1": "0.0.0.0"
[...]
Mon Oct  2 03:06:30 2023 daemon.info mobifd: [gsm.modem0] Modem is attached to PS
Mon Oct  2 03:06:30 2023 daemon.notice netifd: Interface 'mob1s1a1' is setting up now
Mon Oct  2 03:06:30 2023 daemon.notice netifd: mob1s1a1 (10192): Starting network mob1s1a1 using APN: wap
Mon Oct  2 03:06:30 2023 user.notice netifd: uqmi -d /dev/cdc-wdm0 --timeout 30000 --set-client-id wds,2 --release-client-id wds --modify-profile --profile-identifier 3gpp,1 --profile-name profile1 --roaming-disallowed-flag no    --auth-type none  --apn wap  --pdp-type ip
Mon Oct  2 03:06:30 2023 user.notice netifd: uqmi -d /dev/cdc-wdm0 --timeout 30000 --get-client-id wds
Mon Oct  2 03:06:30 2023 daemon.notice netifd: mob1s1a1 (10192): 2
Mon Oct  2 03:06:30 2023 daemon.notice netifd: mob1s1a1 (10192): cid4: 2
Mon Oct  2 03:06:30 2023 user.notice netifd: uqmi -d /dev/cdc-wdm0 --timeout 30000 --set-ip-family ipv4 --set-client-id wds,2
Mon Oct  2 03:06:30 2023 user.notice netifd: uqmi -d /dev/cdc-wdm0 --timeout 30000 --set-client-id wds,2 --start-network --apn wap --profile 1  --auth-type none --username  --password
Mon Oct  2 03:06:31 2023 daemon.notice netifd: mob1s1a1 (10192): pdh4: "Call failed"
Mon Oct  2 03:06:31 2023 daemon.notice netifd: mob1s1a1 (10192): Unable to connect IPv4
Mon Oct  2 03:06:31 2023 user.notice mobile.sh: Device not responding, resetting mobile network

These messages show up several times until log entries stop at 03:15.

Interwoven with this are messages from OpenVPN about being unable to connect to RMS due to the network being unreachable.

Since the device came back online on 10-04 it has been reliably online and publishing data on schedule.

The long period without log entries would certainly suggest that the device has been powered off, except that in this period it consistently replied to instructions through SMS, so it must have been powered on.

At this point, I might be inclined to blame the cellular network for the lack of connectivity, but I would like to understand the complete absence of log entries after 2023-10-02T03:15 and before 2023-10-04T11:26?

9

Hello,

If the logs in the begging are relatively old, and the device replied to SMS messages, it means that the device was working. The issue was probably with the mobile data connection. While I am not completely sure about the missing logs in this specific case (since I do not have the full file), but its is likely because the logs were deleted by the device itself. Since logs are stored in RAM, there is a limit to prevent the RAM from getting too full. You can see the buffer size in System → Administration → Troublshoot. When the logs fill up, the device starts to delete older/unnecessary logs. Thus, this might be the reason why some of the older logs are missing. You can try increasing the buffer size.

How is the device so far after coming back? Is the connection fine?

Kind Regards,

10

It has been online and publishing data on schedule since it came back online on 10-04.

11

Hello,

Try increasing the buffer size and let me know if the issue occurs again.

Kind Regards,

12

This topic was automatically closed after 15 days. New replies are no longer allowed.