On Thu, Sep 19, 2019 at 01:47:45PM +0200, Nenad Peric wrote:
A theoretical way to test this against any other protocol is to have
a
firewall rule which can be triggered locally which just drops the traffic
and then re-enables the traffic in a while (short or long, can be
decided/tweaked).
This way, there is no need to think about which protocol is used, when we
kill the connectivity.
The only consideration could probably be that the dropped connections would
cover only the ports we need.
To reduce the size of the hammer :)
Good idea, you just need to keep in mind that the underlying protocols might
have their own keep-alive methods, which should be removed or at least minimised
when testing this.
*Nenad Perić*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Migration Engineering
nenad(a)redhat.com
<
http://redhat.com>
On Thu, Sep 19, 2019 at 1:34 PM Richard W.M. Jones <rjones(a)redhat.com>
wrote:
> This is a retry filter implementation as outlined here:
>
https://www.redhat.com/archives/libguestfs/2019-September/msg00167.html
>
> It is only lightly tested. One way to test it is to try an SSH copy
> (see the commit message for patch 2/2), and in the middle of the copy
> kill the per-connection sshd on the remote machine. You will see that
> the copy recovers after a few seconds. Add the nbdkit -v option to
> see some useful messages from the filter:
>
> ...
> nbdkit: ssh[1]: debug: ssh: pread count=2097152 offset=216006656
> nbdkit: ssh[1]: error: read failed: Socket error: Connection reset by
> peer (-1)
> nbdkit: ssh[1]: debug: retry 1: original errno = 5
> nbdkit: ssh[1]: debug: waiting 2 seconds before retrying
> nbdkit: ssh[1]: debug: ssh: reopen
> nbdkit: ssh[1]: debug: close
> nbdkit: ssh[1]: error: cannot close file: Socket error: Connection reset
> by peer
> nbdkit: ssh[1]: debug: ssh: open readonly=0
> nbdkit: ssh[1]: debug: opened libssh handle
> nbdkit: ssh[1]: debug: ssh: pread count=2097152 offset=216006656
> ...
>
> It really needs an actual test, which is tricky to implement. My
> thinking currently is that a custom (sh) plugin is the way to go, but
> it would also be nice to test curl/ssh/vddk with this filter -- if
> anyone has any suggestions on how to do that ...
>
> This patch will probably conflict with Eric's series here:
>
https://www.redhat.com/archives/libguestfs/2019-September/msg00180.html
> but that shouldn't be too hard to fix up.
>
> Rich.
>
>
>