On Fri, Jun 23, 2023 at 03:52:21PM +0200, Matthias Petermann wrote:
> Hi,
>
> On 23.06.23 02:45, RVP wrote:
> > 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 :)
>
> I will still try the tips from yesterday (long time ping test) and collect
> some more data. And yes - I think only someone with a strong Xen background
> can really help me :-) I will followup as soon I completed my recent tests.
I'm not sure it's Xen-specific, there have been changes in the network stack
between -9 and -10 affecting the way ARP and duplicate addresses are managed.
>
> >
> > 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...
>
> At the moment, I manually set the MAC adresses for all DomUs in the Domain
> configuration file (at the network interface specification), example:
>
> ```
> name="srv-net"
> type="pv"
> kernel="/netbsd-XEN3_DOMU.gz"
> memory=512
> vcpus=2
> vif = ['mac=00:16:3E:00:00:01,bridge=bridge0,ip=192.168.2.51' ]
the ip= part is not used by NetBSD.
A fixed mac address shouldn't make a difference, it's the xl tool which
generates one if needed and the domU doesn't know if it's fixed or
auto-generated.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
