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 :)


Nenad Perić

PRINCIPAL SOFTWARE ENGINEER

Red Hat - Migration Engineering

nenad@redhat.com



On Thu, Sep 19, 2019 at 1:34 PM Richard W.M. Jones <rjones@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.