Question

Hi,

I am trying to change the LAN ip address in an RUT 240 with 7.02.07 firmware via SMS so that I can access a device mistakenly given a static IP by a client and then mounted several meters off the ground...sigh.

I'm trying this on my test bench and not having any success. After sending the command the interface IP looks to be updated (i.e. uci show network looks right), but it stops functioning completely, even after a reboot.

The commands I'm sending are:

<password> uci set network.lan.ipaddr='192.168.54.1'

<password> uci commit network

<password> uci commit dhcp

<password> reload_config

Any help or advice you can give me is much appreciated.

Tony

Answer 1

Hello,

Thank you for your question,

<password> uci set network.lan.ipaddr='192.168.54.1'

<password> uci commit network

and lastly

<password> reboot

should be enough to change the router's IP, as after making changes using uci to some service, you need to reset it, in this case, that would be "/etc/init.d/network restart", however, this command is not possible using SMS, that's why you need to use reboot because it restarts all services.

If you have any questions regarding this, feel free to ask.

Sincerely, Justas.

Comments

Thanks heaps for the advice, Justas!

I just tried this on my test bench RUT240, firmware 7.02.07 (same as client, although I also tested 7.02.04 which is our standard build), connected to my laptop via ethernet.

I start by sending "<password> restore" to make sure I'm working with a clean config (and the default password). All looks normal.

Then, as you suggest (per the attached screen shots):

<password> uci set network.lan.ipaddr='192.168.54.1'

<password> uci commit network

<password> reboot

You can see in the pictures, below that the commands are as you suggested (and they match my original commands). You can also see the result. No IP address via DHCP, no ping or ssh to the router with static IP set. It's like the commands kill the interface until it's restored.

BTW it works fine if I use the same commands via SSH (but I can't do that in this instance, obviously).

I should also add that I set a static ip of 192.168.1.10 to see if I could hit the original router address of 192.168.1.1, without success.

Thanks for your thoughts!

Tony

---

In the second screenshot of Mac, I see that it has an IP of 169.254.160.14 which means that at the moment it has a self-assigned IP, you'd need to wait a few more minutes until the router has fully rebooted and the DHCP service has started, then the PC should receive an IP from new LAN range.

However, if the problem still persists, you'd need to physically connect to its LAN.

---

Thanks, Justas. I realised it's a self-assigned IP, and DHCP never gives out an address. I can't connect even by setting a static IP -- changing the IP via the SMS UCI API seems to break the interface. FYI I am physically connected to the LAN on the unit I'm testing.

I think this might be a bug, and I'll attempt to log it with Teltonika. Do you know how to do that?

Cheers,

Tony

Answer 2

SMS UCI API only sends what to change in device configs, after that, new settings need to be committed to UCI. After this, regarding what type of category/service that configuration belongs to, it needs to be restarted with new settings. However, restarting specific services with SMS, currently, is not possible. That is why you need to reboot the device after each UCI configuration change and commit.

Firstly, I would like to ask you if you're using the RMS service. If you are, then we could remotely connect to the device and check if settings are responding to UCI changes. However, if this option is unavailable, you can try other solutions below:

1. DHCP service is not working correctly therefore, a device reboot is required to restart the server. However, there is a possibility that some configurations may have interfered with DHCP, then you should do a full device factory reset.
2. With a faulty port or cable, then the connection is not possible at all. Or connect via WiFi after reset, using a provided password on the back of the device.

Sincerely, Justas.

Comments

Thanks, Justas.

I agree with everything you've said. No, we are unfortunately not using the RMS service, I agree that would be optimal, but the owners of the business I am doing this work for won't pay for it.

I had the (pretty obvious in hindsight) idea to SSH into my test bench router and check the configuration (‘uci show network’) before and after making the change via SMS, but before committing the change, and have found the culprit. 

The factory default config looks like: network.lan.ipaddr='192.168.1.1’. 

After sending and receiving the following, the config looks like: network.lan.ipaddr=''\''192.168.54.1'\''' — broken (this is quote-backslash-quote-quote-value-quote-backslash-quote-quote-quote).

I then had the idea to resend the command without the quotes. After sending and receiving the following, the config looks like: network.lan.ipaddr='192.168.54.1’ — success!

I then sent a commit via SMS, restarted the router via SMS, and all is fine with the new IP and subnet.

Looking at the router, I can see that the value is always enclosed in single quotes when viewed using ‘uci show’ or from the config file:

Snip from SSH:

Snip from the config file:

Looking looking at Teltonika’s UCI command reference here https://wiki.teltonika-networks.com/view/UCI_command_usage, I see that values are never enclosed in single quotes in the examples:

Reading the UCI syntax here https://openwrt.org/docs/guide-user/base-system/uci, I can see that the value should always be enclosed in quotes (single or double):

Have I misunderstood the syntax? Perhaps there is an issue with the value being enclosed in quotes because of SMS providers here in Australia (I’ve tested this using both Vodafone AU and Telstra sim’s with the same result, but I can’t see the messages in ‘read messages’), or there is an issue with the Teltonika SMS API including escape characters when processing SMS’s?

Cheers,

Tony

Answer 3

Hello Tony,

To begin with, I would like to sincerely apologize for not informing you about the importance of escape characters when executing uci commands via SMS Utilities.

In comparison, using single quotes in the cli(SSH) doesn't impact the configuration value, however, when sending the command via SMS - it does break, and, therefore you should always send using "uci set <config>=<value>".

When looking at configuration files or UCI values, they will be enclosed in single quotes, however, the quotes shouldn't be used when executing the commands via SMS.

You definitely understood the syntax correctly, and once again, I am sorry for not pointing this out. To prevent this from happening I have updated our Wiki article as well with a disclaimer.

Sincerely, Justas.