Mikrotik and Starlink on a ship. Problems and solutions

Greetings! I continue the topic of using Starlink in ship conditions in conjunction with Mikrotik. And in this article I will describe the problems that arise during the operation of Mikrotik on a ship, as well as solutions to these problems.

As it turned out, using MikroTik on a ship is a "real pleasure". It seems like you set everything up and forgot about it, but no. Periodically, something does happen. In my case, not having enough experience with it, some problems began to appear that I did not foresee in advance.

Setting up Mikrotik. If you need information on how to set up Mikrotik for Starlink, then read the article: "Starlink REV4 + Mikrotik. Monitoring Internet traffic on a ship using Mikrotik".

In this article, I will not only describe the problems and solutions, but will also try to add fresh knowledge as I gain experience with Mikrotik.

1. Mikrotik RADIUS server does not respond

So, the first significant problem that happened was that the RADIUS server "fell". When trying to connect to the Internet, namely logging in under your profile, it gives the messages "RADIUS server is not responding" or "Web browser did not send challenge response (try again, enable JavaScript). In addition, it is impossible to access it from a browser by IP address (it gives an incorrect login or password).

Mikrotik's RADIUS server is not responding

And here I made a mistake, rebooted Mikrotik to try to restore the radius server. By doing this I erased the old logs. Instead, I should have first looked at the logs for errors. It turned out that Mikrotik ran out of internal memory "Out of disk space!" free-hdd-space: 500.0KiB, while the entire memory is about 16MB (total-hdd-space: 16.0MiB). And accordingly, because of this, the radius server "fell".

Checking the contents of the file system for large files (command in the terminal):

/file print detail

You can also simply go to the Mikrotik file system (Files section) and visually search for large files.

File logsqldb in the flash/user-manager directory

When searching for the cause of insufficient internal memory, a file logsqldb was found in the flash/user-manager directory with a size of 2645.0 KiB (about 2.7 MB). Below I suggest you familiarize yourself with the options for solving this problem.

What is the logsqldb file responsible for?

The logsqldb file in the flash/user-manager directory accumulates logging data for User Manager, including the history of sessions, authorizations, and other events. If the system is not configured to limit the volume of logs or to clean them regularly, the file can quickly increase in size, especially on devices with a large number of users or frequent authorizations.

Why did the logsqldb file become so large?

• A large number of users and authorizations: If a lot of users go through User Manager, and information about sessions and logs is written each time, this quickly fills up the available space.
• Long storage time for logs: By default, the system may not clean old logs, so they accumulate over time.
• Limited device memory: The device has only 16 MB of internal memory, which makes it vulnerable to overflow due to such large files.
• No automatic cleaning: MikroTik does not clean logs automatically. You need to manually clean them or configure a script.

Why did this cause the RADIUS server to crash?

When the device's internal storage is full, RouterOS stops working properly. Some processes (such as RADIUS, which uses User Manager for authentication) require free space for temporary files or write operations.

The "Out of disk space!" message indicates a critical condition in which many system functions may be disrupted.

How to set up automatic log cleaning?

To prevent this situation, you can set up automatic log cleaning using a script and a scheduler. Here's an example:

1. Create a script to clean up the logs:

/system script set clear_user_manager_logs source="

:local logFile [/file find name=\"flash/user-manager/logsqldb\"];

:if ([:len \$logFile] > 0) do={

    /file remove \$logFile;

    :log info \"User Manager logs cleared to free up disk space.\";

} else={

    :log warning \"logsqldb file not found, no action taken.\";

}"

Script check

Script check:

/system script print

If there is an I flag next to your script, it is invalid. Check its correctness.

2. Run the script manually:

/system script run clear_user_manager_logs

When the script is activated, the logsqldb file may be deleted, this is normal. Then it will be recreated when logging users. If it is not created, then you need to restart Mikrotik.

3. Check the logs:

/log print where message~"logs"

If the script was executed successfully, the message will appear:

info: User Manager logs cleared to free up disk space.

4. Set up the scheduler for regular execution:

Add a task that will run the script, for example, once a week:

/system scheduler add name="weekly_log_cleanup" interval=1w on-event=clear_user_manager_logs

5. Test the scheduler:

/system scheduler print

Example of the result:

name="weekly_log_cleanup" start-date=nov/28/2024 start-time=00:00:00 interval=1w on-event=clear_user_manager_logs

6. Change the interval if needed: If you need to run the script more often (e.g. daily), change the interval:

/system scheduler set weekly_log_cleanup interval=1d

I used this script, ran it manually and the RADIUS server started working again. I also set up the scheduler to automatically clean up every 7 days.

Below I suggest reading additional recommendations for monitoring logs and optimizing the database. Use all this with caution if you know exactly what you are doing.

Additional measures to control logs:

Limit the logging level

Configure the minimum required logging level for User Manager:

/tool ​​user-manager logging set level=critical

This will reduce the number of events recorded.

Regular database optimization

To reduce the size of the database, it is recommended to periodically clean up old sessions and optimize:

/tool ​​user-manager database clear-session

/tool ​​user-manager database clear-log

Disk space monitoring

Configure monitoring so that the system warns if free space becomes too small:

Create a script:

/system script add name="check_disk_space" source="

:if ([/system resource get free-hdd-space] < 1000) do={

:log warning \"Low disk space on device!\";

}"

Configure execution every 10 minutes:

/system scheduler add name="disk_monitor" interval=10m on-event=check_disk_space

These measures will help prevent disk overflow in the future, while maintaining the functionality of the RADIUS server and the entire system.

Make sure your system has no task conflicts and that scripts do not delete important files by checking them before launching.

As a result, we can conclude that it is necessary to periodically monitor the size of the Mikrotik file system and prevent it from overflowing. You can use scripts or manually monitor the file size. By the way, Mikrotik was launched about two months ago before the problem occurred.

2. Overloading Wi-Fi extenders and the Starlink router

I noticed that one Wi-Fi extender, which is connected to the Tp-Link router on Mikrotik, periodically crashes. It has to be rebooted about once a week. This mainly happens due to network overload through the main Starlink router.

That is, a device that is connected to the Starlink router directly (without traffic limitation) and, for example, Speed ​​Test can be done on it, thus "putting down" the extender. I think there is only one way out - do not do this (do not overload the network) while the ship is in transit on limited traffic.

By the way, if you are interested in the process of installing and configuring Starlink on a ship, I recommend reading the article "Starlink on a ship. Experience of operating the global Internet on a ship".

That's all for now. As problems with Mikrotik arise, the article will be updated. If you have problems with Mikrotik or have something to share from personal experience, then write in the comments to the article. I would be very grateful.

I hope the article was useful for you. Thank you for your attention!