Closed lczub closed 9 years ago
Workaround to start remote_cli with AUTH_PROC without using _robot_remotecli, accepting unconventional local ip
_global example_auth_proc << _proc (hostname, hostaddr)
## a customised remote_cli auth_proc
_if hostaddr = "127.0.0.1" _orif # default local host ip
hostaddr.matches?("*.0.0.0.0.0.1") _orif # unconventional local ip under sw5
hostaddr.matches?("111.222.333.*") # special authorised none local ip
_then
# trust localhost or local network
_return _true
_else
# trust nobody
_return _false
_endif
_endproc
$
remote_cli.new(14099, example_auth_proc)
$
IP determination under sw5 seams to work a little bit different as under sw4. Example local remote cli communication under sw4
Example local remote cli communication under sw5 (same machine, same windows session)
Why sw5 detects a different local ip than sw4 is not clear. One reason for unconventional IP might be, that the machine has no connection to the normal domain network (but it has a valid IP in a local network).
Problem is, the normal testing can not start, cause sw5 images does not accept these local telnet connection . As workaround, the script _robot_remotecli can be used in combination with an environment variable _ROBOTHOSTADDR set to "*.0.0.0.1". This will initialize the remote_cli with a special AUTH_PROC for validate the connection.
But the idea of _ROBOTHOSTADDR is, to define valid not local addresses. So it would be better, when _robot_remotecli accept as local adress also the unconventional IP "*.0.0.0.0.0.0.1"