Please on beta6, or any new version, start another topic.
I’m expecting, from this topic, the experience of users, and eventually problems encountered and how solve that.
All related only to latest beta, and not other version, container or wifiwave2 package (that have more than one topic already present)
This topic has been made perfectly useless and difficult to consult,
because users, instead of exposing the problems encountered on the beta,
do nothing but uselessly comment,
give useless suggestions in this context,
philosophize among themselves as if it were a chat,
and asking for new things here, instead of opening or using existing dedicated topics.
Please change back the internal description of .npk file from generic-for-all-platform “system” to specific "routeros-" as before,
on this way on Netinstall is possible distinguish the files on list AND on The Dude is possible again to do updates,
because The Dude search (rigtly) “routeros-” inside internal description and not only “system”
Not sure if this is specific to the RB1100AHx4 or not, but when enabling the container functionality in device-mode, power cycling doesn’t successfully enable it. Using the reset button does, but this isn’t going to work well for remotely deployed devices.
Anyone managed to find a better way to use the data provided by netwatch (status, since etc) I currently only had successful results with something like this:
:local currenthost $host;
:local comment [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=comment];
:local status [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=status];
:local since [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=since];
:log info "netwatch: $currenthost ($comment) is $status since $since";
Not the best way to do it, if you have multiple monitored hosts with the same IP it will obviously fail to work properly.
I’ve tried to use $host directly in the get commands but it only works for one host, once you start adding the same script for other hosts it fails to work for every host.
The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.
But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
Remember doing “/system reboot” is not the same as hard power cycling the device. Doing a software reboot this way would not work, but power cycling should work.
What I was a bit disappointed about was that enabling the feature using the reset button on the RB4011 actually did reboot the router. It was my impression that RESET simply is a software button used to control config erasure and in this case was used for this device-mode thing, but it seems it is actually a CPU reset as well. Or its handling is coded in such a way that pressing the button does a hard reboot. I expected the router to just remain running when using the button to enable the device mode.
That hard reset may not be so desirable, especially because the button (contrary to other devices) is easy to press and does not require fiddling with a pin.
Have you tried it wit a foreach where $i is containing the .id? This way you can read multiple values in one go, sequential. Not having to do a new find for each value.
Bye
Update, try this if will display the information. About Epoch, there are scipts to convert that, it would be nicer if MT would create [:toepoch and [:todate for us.
{
:foreach i in=[/tool/netwatch find] do={
:set $host [/tool/netwatch get $i host ]
:set $comment [/tool/netwatch get $i comment]
:set $status [/tool/netwatch get $i status]
:set $since [/tool/netwatch get $i since ]
:put "Netwatch: host $host ($comment) is $status since $since";
}
}
I didn’t go that far.
I was expecting that using $host $status and $since in the scripts for the current host will work, apparently it doesn’t, $host returns the host, $since returns the time in unix time and unusable, and $status shows nothing.
Using the .id probably works but I haven’t found a way to get the .id for the current host that the current on-up or on-down script runs.
It seems to me that when changing device mode, command itself actually installs some kind of command file which executes at boot time … but gets removed either after time out or when executing reboot/shutdown command. So “surprise” reboot is necessary and either reset (via button) or power cycle should do. However, my own experience is as well that power cycle doesn’t do it, could be due to some flash controller/drive write cache which flushes with reset button but doesn’t before power is cut (tried on arm device and mipsbe device, fails in both cases).
Maybe you need to wait a little longer before doing the powercycle? It could be that the flash is flushed every 30 seconds or so.
I did not yet test what happens when I push the button on the 4011 without having done the device-mode setting. It really would not be so good when it does a hard CPU reset as that button may well be accidentally hit.
Could be. When I tried it, the delay between device mode set command and power cut was around 30 seconds if not more as devices were not in the same room as management chair. But even if it’s a matter of delay, it should either be improved (so that no additional delay is needed) or clearly documented.
That’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.
There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.
It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be able
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.
[quote=“, post:171, topic:158543”]
But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
[/quote]
There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.
Others have reported it as well. It looks like a bug that should be fixed.
