This is Bret K6BAT's note on how he recovered a remote node that wound up with NOCALL after an update. The password was no longer valid, so he worked to determine what it was:
After Bob upgraded a Mikrotik LHG5 at our Tomato Springs site, it went into the first-boot state. So, I needed a local system on 192.168.1.0/24 to reach it. I added a vlan to our switch and a tagged interface on our Raspberry Pi at the site on that network. I had no easy access to a graphical browser on the Pi, so I used curl to submit the information needed to set the name and password on the node.
curl -X PUT http://192.168.1.1/a/status \
-H "Content-Type: application/json" \
-d '{"name": "N6IPD-Tomato-to-K6BAT", "passwd": "securepass123"}'
Whoops, I used the json content type, when x-www-form-urlencoded was expected. The node came back up as NOCALL with an unknown password. So, even though the node was on the mesh, I had no way of logging in and giving it proper settings.
I was able to reproduce the issue at home on another Mikrotik node in firstboot, but this time I had an open ssh session on the node while I submitted the form with json. I ran a 'while' loop, looking for any commands containing 'passwd', hoping I would catch a passwd-related command with arguments that would give me a clue as to what the password was being set to with the bad json input.
while : ; do
ps w | grep passwd
done
Then I ran the curl command, and I saw this:
7240 root 1260 S {setpasswd} /usr/bin/lua /usr/local/bin/setpasswd null
7243 root 1352 S sh -c { echo 'null'; sleep 1; echo 'null'; } | passwd -a md5
7244 root 1352 S sh -c { echo 'null'; sleep 1; echo 'null'; } | passwd -a md5
7245 root 1348 S passwd -a md5
Since it had no value for a passwd, it used a literal "null" string.
For future prosperity, this is the correct syntax for the curl command was:
curl -X PUT http://192.168.1.1/a/status \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "name=<NODENAME>" \
--data-urlencode "passwd=<PASSWORD>"
Bret K6BAT
After Bob upgraded a Mikrotik LHG5 at our Tomato Springs site, it went into the first-boot state. So, I needed a local system on 192.168.1.0/24 to reach it. I added a vlan to our switch and a tagged interface on our Raspberry Pi at the site on that network. I had no easy access to a graphical browser on the Pi, so I used curl to submit the information needed to set the name and password on the node.
curl -X PUT http://192.168.1.1/a/status \
-H "Content-Type: application/json" \
-d '{"name": "N6IPD-Tomato-to-K6BAT", "passwd": "securepass123"}'
Whoops, I used the json content type, when x-www-form-urlencoded was expected. The node came back up as NOCALL with an unknown password. So, even though the node was on the mesh, I had no way of logging in and giving it proper settings.
I was able to reproduce the issue at home on another Mikrotik node in firstboot, but this time I had an open ssh session on the node while I submitted the form with json. I ran a 'while' loop, looking for any commands containing 'passwd', hoping I would catch a passwd-related command with arguments that would give me a clue as to what the password was being set to with the bad json input.
while : ; do
ps w | grep passwd
done
Then I ran the curl command, and I saw this:
7240 root 1260 S {setpasswd} /usr/bin/lua /usr/local/bin/setpasswd null
7243 root 1352 S sh -c { echo 'null'; sleep 1; echo 'null'; } | passwd -a md5
7244 root 1352 S sh -c { echo 'null'; sleep 1; echo 'null'; } | passwd -a md5
7245 root 1348 S passwd -a md5
Since it had no value for a passwd, it used a literal "null" string.
For future prosperity, this is the correct syntax for the curl command was:
curl -X PUT http://192.168.1.1/a/status \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "name=<NODENAME>" \
--data-urlencode "passwd=<PASSWORD>"
Bret K6BAT