On Thu, 22 Jun 2023, Matthias Petermann wrote:
...and from the server log...
```
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 196608
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
process_output: ssh_packet_write_poll: Connection from user user 192.168.2.50
port 60196: Host is down
```
...appears a bit like both parties blaming each other... client tells the
remote host has closed the connection, and the remote host complains about
the client beeing down.
So, the server tries to write data into the socket; write() fails with
errno = EHOSTDOWN which sshd(8) treats as a fatal error and it exits.
The client tries to read/write to a closed connection, and it too quits.
The part which doesn't make sense is the EHOSTDOWN error. Clearly the
other end isn't down. Can't say I understand what's happening here. You
need a Xen guru now, Matthias :)
On Thu, 22 Jun 2023, Brian Buhrow wrote:
hello. Actually, on the server side, where you get the "host is down"
message, that is a
system error from the network stack itself. I've seen it when the arp cache
times out and
can't be refreshed in a timely manner.
But, does ARP make any sense for Xen IFs? I thought MAC addresses were
ginned up for Xen IFs...
-RVP
