Age | Commit message (Collapse) | Author |
|
If ssh_connection:adjust_window/3 is not called after each time data
is received in the netconf client, the client will eventually stop
receiving data. This bug has been corrected.
|
|
* inet:host_name() -> inet:hostname()
* ct:hook_options() -> ct_netconfc:hook_options()
|
|
OTP-10570
ct_netconfc:close_session sometimes returned {error,closed} because
the ssh connection was closed (from the server side) before the
rpc-reply was received by the client. This is normal and can not be
helped. It has been corrected so the return will be 'ok' in this case.
Other error situations will still give {error,Reason}.
|
|
OTP-10510
When starting a named netconf connection directly after stopping one
with the same name, it sometimes failed with 'connection_exists'. This
has been corrected.
|
|
* lukas/common_test/deep_get_config/OTP-9626:
Add more cross reference links to ct docs
Remove config option from common_test args
Update user config to use nested tuple keys
|
|
|
|
ct:get_config and ct:require can now use nested tuples
to fetch data from user configuration. E.g.
ct:get_config({localhost,ip,v4}).
This introduces a backwards incompatability with how names
are associated with keys when using require/2. E.g.
ct:require(a_name,{localhost,ip}) will associate a_name with ip
instead of localhost.
|
|
Only {data,...} and {closed,...} was handled, which caused the test to
fail with with a function_clause crash in ct_netconfc when
{exit_status,...} was received. This has been corrected.
|
|
The netconf client supports basic netconf functionality over SSH. In
order to allow testing of both success and failure cases, it is
intentionally written to allow non-standard behavior.
In order for the netconf client to use the generic connection
mechanism in common_test, ct_gen_conn has been updated to be more
flexible:
Added options:
{reconnect,bool()}
{forward_messages,bool()}
{use_existing_connection,bool()}
Allow handle_msg to return
{reply,Reply,State} |
{noreply,State} |
{stop,Reply,State}
If forward_messages==true, the ct_gen_conn callback must also
implement:
handle_msgs(Msg,State) -> {noreply,State} | {stop,State}
|