Teltonika UDP commands
It seems like simply invalid format, but you should include the actual hex from your log.
My bad. Here's a complete exchange:
2025-03-24 18:44:46 INFO: [Ud41a5727: teltonika > 10.141.81.1] 000000000000000f0c010500000007676574696f0d0a0100003349
2025-03-24 18:44:47 INFO: [Ud41a5727: teltonika < 10.141.81.1] 00000000000000230c01060000001b4449313a30204449323a302041494e313a32363020444f313a3020010000842c
2025-03-24 18:44:47 WARN: Unknown device - ^L^A^F^@^@^@^[DI1:0 DI2:0 AIN1:260 DO1:0 ^A (10.141.81.1)This doesn't look like valid Teltonika UDP data.
I use Teltonika devices so I have some context.
First up, don't use UDP. Mobile networks can and do tear down active connections all the time based on mobile network load, so unless your VPN is able to constantly force the connection to be kept alive without any kind of teardown by a L4 gateway (CGNAT or otherwise in the path), you will end up with Devices in the "Unknown" state. UDP is tempting, so as to reduce data consumption, but it is a false economy due to the many status failures you will end up with.
When using UDP, commands are still sent to devices in this state, even if there is no UDP socket open for use. If you use TCP, any active teardowns by intermediate gateways (CGNAT or otherwise) result in a TCP teardown either using TCP RST packets or a graceful FIN/ACK process. This will mark the devices as Offline (red in Traccar) so that commands sent to them are at least queued. Traccar 6.7 (soon to be released) includes a "No queue" option so you can also ensure that commands you do NOT want to be queued are never queued, and just fail. I don't know what v6.7 does with failed commands though regarding "Command Result"; best to check the source code to see how it behaves.
Regarding your data stream from the device back to the server, it looks like your message is in Codec 12, which is, uh, backwards. Codec 12 is used for sending commands to Teltonika devices from Traccar, and Codec 8 (usually Codec 8 Extended these days) is used when sending data from the tracker back to the server.
What's missing in your data coming from the remote device is its Device ID, which is what Traccar is trying to determine here. It's searching the hex string, assuming it is Codec 8, for the Device ID and the location in the message where Device ID would exist appears to have status data in it.
Please show us screenshots of your GPRS Settings menu from Teltonika Configurator. That will help a lot to see what's going on here.
Thanks both for the replies. This format is what I get when I send any commands to the device. I understand the limitations of UDP but have been using this tracker successfully in this configuration for almost 3 years and feel this functionality should work - I've only come across it because I rarely need to send commands and had previously just used SMS to do so.
GPRS settings:
System settings:
Everything there looks correct, so I'm confused why it's not working.
Could be some kind of weird state tracking issue where Traccar doesn't know it's a reply to a command maybe, and assumes it is just a new AVL record?
Honestly the best way to test that is to set it to TCP and test if it works then. If it does, it's some kind of state tracking issue. And when I say "state tracking" I'm being a big generic. If the source UDP port changes for example that would break state.
I'm not certain about this yet - your log entries suggest that Traccar knows it's the same conversation. At the very least please make sure you are using the latest version of Traccar. I note Anton deals with many support requests with multiple posts, only to find out the person is using a six year old version!
Already running the latest version of Traccar (in Docker if that matters). Oddly when I set it to TCP I don't see any response to the commands at all - not in the logs and not in the events view.
That's....odd.
I don't know much about 1NCE but I do know that certain operators have stupidly aggressive CGNAT connection teardowns, or just trash CGNAT gateways configurations. Teltonika sell TruPhone (1Global) cards and their CGNAT has been really consistent.
The fact that it's operating over a Layer-3 VPN (and yeah, I get that it's not an encryption VPN but more of a Virtual Private WAN) also makes me highly suspicious of the Layer-3 routing or state tracking devices involved.
Is there any chance you can connect over the public Internet and test?
So it seems to have exactly the same behaviour when using the public internet, but I’m going to try again later with a simpler networking setup.
Currently I’ve got an OpenVPN container (connected to 1NCE) bridged to my Traccar one.
Hi,
I'm using a Teltonika tracker with UDP transit and a SIM card with VPN to my Traccar server. When I send commands from Traccar (such as getver), I see the following in the logs:
2025-03-24 18:29:02 WARN: Unknown device - ^L^A^F^@^@^@<98>Ver:03.29.00_18 GPS:AXN_5.10 Hw:FMB920 Mod:13 IMEI:354018xxxxxxxxx Init:2025-3-11 21:11 Uptime:1082637 MAC:001E42xxxxxx SPC:1(0) AXL:1 OBD:0 BL:1.7 BT:4^A (10.141.81.1)I understand that UDP being connectionless the server is unable to correlate the response to a device. It also looks like not all responses include the IMEI. Codec 12 is the protocol being used for commands.
I wondered if this same problem had been solved for other types of tracker? If there is any appetite for it, I'm happy to contribute an (optional) fallback device matcher that uses the last IP address to match to a device.
Dan