Dear Teltonikans,
I’m migrating a project from Netmodule routers to Teltonika RUT241 devices.
Our SPC (Bernecker+Rainer) maintains a ping-pong TCP connection with the router. It uses this connection to send SMS messages and make phone calls, transmit its connection status, and also functions as a UPS-backed monitoring system for the SPC.
I’ve implemented all of this via a Lua script, which is executed by the “Event Juggler” on boot. Everything has been working well so far with firmware version RUT2M_R_00.07.14.3 (2025.05.26).
However, after updating the RUT241 to the latest firmware, RUT2M_R_00.07.15 (2025.06.06), the script is no longer executed with root privileges.
Why did this change occur, and how can I execute this script as root again?
I require root privileges for commands such as ubus call system board, gsmctl commands and to write files to /etc.
Could anyone please provide some guidance?
Your assistance is greatly appreciated.
Regards, Mario
Hello @steiner-automation,
Thank you for bringing this to our attention. I’ve forwarded this matter to our R&D team for further investigation.
Once we receive any updates or feedback from them regarding this behavior change and possible solutions, I’ll make sure to inform you promptly.
We appreciate your patience and cooperation in the meantime.
Best regards,
thx for the quick reply. this would be a breaking change if intended
Good afternoon,
I’ve received feedback from R&D. To address your questions:
- Why did this change occur, and how can I execute this script as root again?
Starting from firmware 7.15, as part of our ongoing security improvements, we’ve implemented an updated architecture where services and user scripts executed by system modules like the Event Juggler no longer run under the root user. Instead, they run under a dedicated service user context. This is an intentional change, and moving forward, it will no longer be possible to execute these scripts with root privileges for security reasons.
- How to handle privileged commands going forward:
- GSM actions (such as SMS and calls) can still be performed via
ubus calls, e.g., using ubus call gsm.modem0 send_sms or ubus call gsm.modem0 send_voice_call.
- Writing files is now permitted only within the service’s dedicated working directory, which for the Event Juggler is
/tmp/run/juggler/.
- System information similar to what you’d get from
ubus call system board can currently be accessed by reading:
/usr/lib/os-release/etc/board.jsonuname -r
These combined will give you most of the board and firmware information previously available via ubus call system board.
Thank you for your understanding.
Best regards,
Thx for the reply,
i do sort of understand introducing such measures (probably fear of script injection). but on the other hand, it is a very disruptive change probably for many. and how would you truly & fully restrict the system to not become an SMS / call / email spam server once it falls to a hack? you will leave your cherrished teltonika users with a not very usabel and flexible toolset. but who am i to say.
btw: such things made us leave Netmodule routers amongst other issues. having deployed 750+ devices and having to deal with such changes is a nightmare. unless you intend to target the class of home owner that buy on piece of equipment every decade from you. this will not make industry clients very happy.
but since my words probably wont change a single thing or decision, lets try to find a solution:
-
being restricted to /tmp/run/juggler/ means i have no permanent storage available anymore (/tmp resets at reboot!). or is there another option to store some text snippets of user info permanently?
-
having to read files now, instead of allowing ubus call system board is interesting …
-
what exactly are the privileges of that “juggler user”? equivilant to “admin”?
-
Will
gsmctl --sms --list all
be usable?
-
Limitations using “uci” to set and commit? (network apn username pw, simcard pin, operator). We use the Touch display based SPC to give the client and service personal a way to configure the router. Set APN, activate wireless if needed, activate VPN and so on
Please understand, that these changes introduced have some gravity. Maybe R&D could consider letting the user set the permission level of the lua script executed?
Hello,
Addressing your questions:
-
being restricted to /tmp/run/juggler/ means i have no permanent storage available anymore (/tmp resets at reboot!). or is there another option to store some text snippets of user info permanently?
At the moment, the only writable path for the application is within /tmp, specifically /tmp/run/juggler/. As you’ve noted, this directory is cleared on reboot, so unfortunately it doesn’t provide persistent storage.
-
having to read files now, instead of allowing ubus call system board is interesting …
The specific ubus call you mentioned (ubus call system board) is currently not permitted for access by the application due to privilege restrictions.
-
what exactly are the privileges of that “juggler user”? equivilant to “admin”?
Regarding privileges: our applications operate under different system users with varying permission levels. The juggler user is the owner of the event_juggler application and only has privileges necessary for its operation. Its permissions are more limited than those of an admin user.
-
Will gsmctl --sms --list all be usable?
No, ubus call for gsm.modem* should be used instead of gsmctl, as gsmctl is only a helper application that is not used by event_juggler and that’s why the juggler user cannot access it. However, a few ubus calls are used to get info about modem statuses, and sms and call actions are a part of it, that’s why they can be used in script as well, but unfortunately, the function for listing sms is not available at the moment for the user.
-
Limitations using “uci” to set and commit? (network apn username pw, simcard pin, operator)
There are some limitations when using uci set, but this user does have permission to apply UCI commands related to network configuration, SIM card PINs, APN settings, and operator selection.
I hope this clarifies it. Let me know if any additional questions come up.
Best regards,
Thank you Martynas,
you are doing a great job! And i know you are just the man in the middle 
Question: Will there be changes and adaptions made regarding this matter?
I checked uci commands and there is not much left that can be used. Wireless, sms listing all not useable anymore.
It would be nice if you could bring this to to attention of R&D. Maybe let user set the permission level of event_juggler user?
We just rolled out 5 test devices into the field. After successful tests we were about to purchase routers in higher numbers. Currently (it pains me) but i am seriously reconsidering using teltonika routers.
Regards, Mario
1 Like
Hello,
Thank you for your honest feedback 
.
Our R&D team has confirmed that a hotfix firmware addressing this situation is currently in preparation. With this update, you’ll be able to use your script as you did before the recent changes.
R&D has suggested holding off for a few days until the hotfix becomes available.
We genuinely appreciate your patience and understanding in the meantime.
Best regards,
1 Like
Hello again,
that is good news. i run the test routers on 14.3. so no stress timewise.
do u know if the permission level of the juggler user will stay on “root” level in the future?
Hello,
According to our R&D team, it’s likely that the permission level of the juggler user will not remain at root level in the long term. However, until a suitable alternative solution is implemented to securely handle the required operations, it will remain as it is.
Best regards,
Hello Martynas,
would like to ask one more question
uci set simcard.@sim[0].pincode=‘1111’
uci commit simcard
is the way to set sim PIN.
in order to set PUK code (we always let users enter that in our touch display too), what is the correct option code?
uci set simcard.@sim[0].pukcode=‘1111’
uci commit simcard
is there a list of all options for uci codes available somewhere ? plus its parameters or parameter lists?
does setting pin and puk require
/etc/init.d/network restart ?
Hello,
Thank you for your question.
At the moment, I’m unable to test this directly, but theoretically your example (uci set simcard.@sim[0].pukcode='1111' → uci commit simcard) should work.
Alternatively, there’s a ubus call available specifically for setting a PUK code along with a PIN, which should work immediately:
ubus call gsm.modem0 set_puk_code '{"puk":"string","pin":"string"}'
A list of possible UCI commands, structures, and options you can find in the wiki article here:
If you won’t find the required parameters, you are always welcome to ask about them here
After setting a new PIN or PUK via UCI, a restart (/etc/init.d/gsmd restart or /etc/init./network restart) should be enough to apply changes and reinitialize SIM operations.
Let me know if you’d like me to confirm this behavior on a test setup or assist with anything else.
Best regards,
Hello @steiner-automation,
I just wanted to follow up here and update you that the 7.15.1 hotfix was already released, and Lua Event Juggler’s script should now run with root privileges.
Let me know if the initial issue is now resolved. Thank you.
Best regards.