Replacing Windows Network Scripts
At work in our migration efforts we still had two field laptops running Windows 7 Pro. The field techs informed me they used the Windows laptops for one use case only — to access some old embedded devices.
We are slowly replacing and phasing out these old embedded devices but the process will take months.
The techs were using an old utility called
Reflection4 that uses some special Windows network scripts to connect to these devices. Some digging revealed the connections basically are wrappers around the
telnet command and the proprietary firmware syntax. The scripts are native to the app although they look like some kind of Visual Basic or .NET derivative.
SSH is not an option with these old devices. The firmware only supports telnet. The embedded devices support basic web browser HTTP access but not SSL/TLS.
After tinkering I decided this was partly a training issue and partly an access issue. With respect to training, the field techs have no problems using the migrated laptops but even then, they still use the Linux version of PuTTY for various connections. That is, memory muscle is a challenge to overcome.
With respect to actual access, I wrote a shell script to configure NetworkManager (NM) to connect to the subnet of each device before we could use the web browser interface. With that obstacle out of the way we could use a terminal window and the web browser interface to connect to a device on the same subnet. Using the telnet command worked as well.
Add some documentation in our knowledge base and with some training and encouragement, the techs accepted that Windows no longer was needed. Whether they stop using PuTTY remains to be seen, but I am not perturbed about that.
Yet Another NM Work-Around.