AVL not sending even if it says host is up

Networking Solutions
1

Hi! Again I’ve a problem with AVL. The last time, the host wouldn’t connect to the host (see AVL host not connecting anymore - #14 by NerdRelaxo ) now it doesn’t send any data to the AVL server, even it is connected. my Settings are unchanged since last time (see screenshots in the other thread).

The router has the following stats:

image
image2606×300 19 KB

Time since last record sent stays “-” and successful count and failed count stay 0. Multiple reboots, power down/up and even a firmware update to RutOS 07.18.3 didn’t help.

I also tried altering settings like static navigation and others while driving to check if there are any changes, but that all didn’t help.

Kind regards

Hendrik

3

Hi,

I read through the thread and to help narrow this down, here’s a short list of follow-up questions that should clarify where the issue is coming from:

  • Can you confirm the AVL rule is enabled and that the collect , save , and send thresholds (distance, period, min records) are low enough to actually trigger sending?
  • Is the device actively collecting GPS data (valid fix, movement detected)? Does “time since last record sent” ever change while driving?
  • From the router CLI, can you ping/telnet to the AVL server and port , and does it stay reachable over time?
  • When movement occurs, do router logs show any AVL send attempts, errors, or retries ?
  • If you run a tcpdump , do you see outbound traffic toward the AVL server when data should be sent?
  • Does the server log show any incoming connections or rejected packets from this device?
  • Have you tested both TCP and UDP , and does the server expect the same protocol/codec the router is configured to send?
  • Were any settings reset or altered after firmware upgrades or reboots?
  • Are there multiple AVL rules configured that could conflict?
  • If you temporarily lower all thresholds (short send period, small distance), does any data get sent?

Answers to these should help me to tell whether this is a configuration, data-collection, connectivity, or server-side issue.

Best regards,
V.

4

Hi Vilius,

Yes, the rule is enabled. Also I didn’t change anything, it just stopped working from one day to another.

Yes, it collects data as the values increase. Also on the Map I get the correct location.

Yes, it is reachable, also per nc on the correct port.

Do I need to enable traffic log for this? In the eventlog I only find the configuration changes when I tried to fix it by changing settings.

Can’t do that while driving at the moment.

Yes I see the following logs:

Jan 22 08:10:23 2026-01-22 06:10:23 INFO: [T1e21e619: gotop < censored IPv6 (tried IPv4 also) from my router> 000f383630333032303531343131373137

Jan 22 08:10:23 2026-01-22 06:10:23 INFO: [T1e21e619] disconnected

Jan 22 08:10:23 2026-01-22 06:10:23 WARN: [T1e21e619] error -

Jan 22 08:10:23 at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:354)

Jan 22 08:10:23 at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:354)

Jan 22 08:10:23 at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:356)

Jan 22 08:10:23 at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:93)

Jan 22 08:10:23 at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1429)

Jan 22 08:10:23 at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)

Jan 22 08:10:23 at io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:196)

Jan 22 08:10:23 at io.netty.channel.SingleThreadIoEventLoop.runIo(SingleThreadIoEventLoop.java:225)

Jan 22 08:10:23 at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:168)

Jan 22 08:10:23 at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.handle(AbstractNioChannel.java:445)

Jan 22 08:10:23 at io.netty.channel.nio.NioIoHandler$DefaultNioRegistration.handle(NioIoHandler.java:388)

Jan 22 08:10:23 at io.netty.channel.nio.NioIoHandler.processSelectedKey(NioIoHandler.java:596)

Jan 22 08:10:23 at io.netty.channel.nio.NioIoHandler.processSelectedKeys(NioIoHandler.java:512)

Jan 22 08:10:23 at io.netty.channel.nio.NioIoHandler.processSelectedKeysOptimized(NioIoHandler.java:571)

Jan 22 08:10:23 at io.netty.channel.nio.NioIoHandler.run(NioIoHandler.java:484)

Jan 22 08:10:23 at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)

Jan 22 08:10:23 at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)

Jan 22 08:10:23 at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)

Jan 22 08:10:23 at io.netty.handler.codec.DelimiterBasedFrameDecoder.decode(DelimiterBasedFrameDecoder.java:215)

Jan 22 08:10:23 at io.netty.handler.codec.DelimiterBasedFrameDecoder.decode(DelimiterBasedFrameDecoder.java:285)

Jan 22 08:10:23 at io.netty.handler.codec.DelimiterBasedFrameDecoder.fail(DelimiterBasedFrameDecoder.java:299)

Jan 22 08:10:23 at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)

Jan 22 08:10:23 at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1193)

Jan 22 08:10:23 at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)

Jan 22 08:10:23 at java.base/java.lang.Thread.run(Thread.java:1583)

Jan 22 08:10:23 at org.traccar.WrapperInboundHandler.channelRead(WrapperInboundHandler.java:56)

Jan 22 08:10:23 at org.traccar.handler.network.NetworkMessageHandler.channelRead(NetworkMessageHandler.java:36)

Jan 22 08:10:23 at org.traccar.handler.network.StandardLoggingHandler.channelRead(StandardLoggingHandler.java:62)

Jan 22 08:10:23 io.netty.handler.codec.TooLongFrameException: frame length exceeds 1024: 1037 - discarded

I asked Perplexity to analyze this for me and this came up:

The root cause in the log is that Traccar discards incoming packets due to “TooLongFrameException” – this means that the GPS data is not passed on to position processing and you cannot see any current points in the interface.

So was there any change regarding the AVL packets in RutOS in the last versions?

Yes I tried to enable UDP also, didn’t make a difference.

Before it stopped working not on the router side.

I think the problem is on the server side of things. But maybe you’ve any idea.

Greets
Hendrik

5

Hello,

For troubleshooting purposes, we will require more sensitive information from your end, such as the troubleshoot file, which may contain passwords, public IP addresses, serial numbers, and such. To avoid leaking this information, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 17027.

Thank you,

V.

6

To help narrow things down, have you tried attaching to the Traccar Demo Servers, using the correct port number?

7

Sorry, forgot to update here. I solved the problem. It seems there was a change in traccar way back in November when it stopped working, that it doesn’t work on port 5050 anymore (where it worked nearly a year) and now only works on port 5027. You can close the topic.

1 Like
8

Greetings,

Thank you for an update,

I am glad that you were able to resolve the issue. In case you have any additional questions, please don’t hesitate to let me know.

Best wishes,
V.