adopting a new device to the RMS is pretty seamless when there is DHCP on the target network. I can enter Serial, MAC and Password into the RMS beforehand and when the site manager plugs in the device everything is fine.
But what is the process when there is no DHCP in place and I probably do not know before that there is no DHCP in place. I currently do the following process:
I arrange a call with the site manager and instruct them to plug a PC to the LAN of the Teltonika device.
I have them log in to WebUI using the password printed on the machine.
The machine then INSISTS on changing the password and will NOT accept the printed password as new password since it is too short.
I usually instruct the site manager to append a!1 to the password to make the router accept the password.
I then speak the site manager through the process of setting WAN interface to protocol static and to enter the correct IP Address, Mask, Gateway and DNS-Server
I would now need to change the password in the still inactive device record in the RMS. I don’t know where to do that, so I usually remove the device from the RMS and enter the data again.
This works most of the time, but in about every third of those cases, the device gets blocked temporarily (I guess because it has been trying to log in with the “wrong” password too often) or it hangs in the state
Authentication was success. Waiting for reconnection…
115
According to the docs, the device is supposed to try reconnecting every 2-5 minutes, but that log entry is only repeatedly written about every 10 minutes.
How would I recover from this short of having remote personnel to pull the power plug? I have had to resort to a factory reset of the device, making it necessary again to start over from the very beginning. This is tedious and annoying work.
When I am setting up devices for my company, I always ensure I am logging into the device and updating the password first before adding to RMS to avoid any weird authentication issues.
If you do that first and then add to RMS using the new password, that should save some headache.
My normal usecase is that a new router is delivered directly to the target site without passing by my desk (or sometimes even without passing by my country). That works fine if the remote site has DHCP, and if it doesn’t I need to find someone local and have the trouble listed above.
You can disable the initial password-change prompt, but this requires SSH access to the device. Once connected via SSH, adjust the following parameter in the /etc/config/vuci file:
option firstlogin '0'
Setting this value to 0 disables the first-login password change and keeps the default password active.
Please keep in mind that this modification must be applied before logging in through the WebUI for the first time, otherwise the prompt will already be triggered.
If you need any further assistance, feel free to let me know!
That doesn’t help because the login is needed to get the device online. I surely cannot bother the local people with sshing into the device. Another solution please
Apologies for the delay. RMS validates device passwords during the first connection attempt. Therefore, I recommend updating the devices’ passwords before connecting them to RMS.
If you are adding multiple devices via a CSV file, you can specify the updated passwords directly in the CSV. For example, if you are appending a!1 to the default passwords, include this in the CSV so that each device’s password matches what RMS expects. Once the devices are online and attempt to connect, the passwords in the CSV will allow them to successfully authenticate with RMS.
This is a workaround. That would of course mean that I need to know in advance whether a device will have DHCP in its network (in which case I MUST NOT add the a!1 suffix to the device password but leave it as printed on the device) or whether a device needs to have its WAN address configured manually.
And even that doesn’t rule out the possibility that site personnel tries to be smart and brings the device online manually before telling me what they did.
The erratic connection behavior of the devices in this latter case has cost me beyond three hours of my time for just two devices to figure out what has been going on, whether the device will try to connect again or whether we’d have to start over again. In one of the cases, two hours after the password settings in RMS were fixed, site personnel was already on their way to the router to do a factory reset and start over again when the device logged in to the RMS successfully literally in the last ten seconds before the factory reset could be initiated.
The adoption process is really smooth when there is DHCP on the site, and full of pitfalls and footguns when there isn’t. Please consider working on that.
