On Thu, 28 Jan 2021 07:03:51 +0000
Peng Fan <[email protected]> wrote:

> > Subject: Re: ivshmem-net issue
> > 
> > On Thu, 28 Jan 2021 01:28:32 +0000
> > Peng Fan <[email protected]> wrote:
> >   
> > > > Subject: Re: ivshmem-net issue
> > > >
> > > > On Wed, 27 Jan 2021 09:08:28 +0000
> > > > Peng Fan <[email protected]> wrote:
> > > >  
> > > > > Hi Jan,
> > > > >
> > > > > When booting inmate Linux, I have ivshmem-net configured. In
> > > > > root cell it shows as eth2.
> > > > >
> > > > > I monitor system network, and see eth2 is assigned a random
> > > > > address.  
> > > >
> > > > This is not "random", this is where some dhcp-clients end up
> > > > when they do not receive an answer to their requests. It is a
> > > > fallback when there is no proper DHCP server and machines still
> > > > want to gain an address to potentially communicate. (zeroconf
> > > > APIPA)
> > > >
> > > > So it is worth checking the DHCP server to see why it did not
> > > > hand out an IP. Maybe because of the random MAC that Jan talked
> > > > about.  
> > >
> > > What do you mean DHCP server here? The eth2 is created by
> > > ivshmem-net, it has no physical connection.  
> > 
> > Well if you do not have a DHCP server in the other cell, you
> > probably should not be running a DHCP client. And looking at the
> > address you are running one. You probably do the whole setup on the
> > kernel cmdline and that works until userspace goes and configures
> > that interface as well ... again. You have to tell userspace that
> > this one interface is off limits and already configured. How to do
> > that depends an what is doing that, probably nm or systemd.  
> 
> But seems we are not able to differentiate the ivshmem-net created
> eth2 and the physical interface eth1?

You can do that by name. And if that is not stable enough you can do it
i.e. by driver or vendor. Maybe with an udev rule. For starters just
disable nm or systemd-networkd entirely and bring up that physical
interface manually.

On the kernel cmdline you can specify an interface name for your nfs
ip, in case the kernel picks the wrong device.

Taken from an NXP ls1043 lab setup of mine
root=/dev/nfs ip=${ipaddr}:::${netmask}:${hostname}:eth0
nfsroot=${serverip}:/srv/nfs/boards/${hostname}yocto,v3,tcp

Notice the ":eth0" at the end of "ip=".
https://elixir.bootlin.com/linux/latest/source/Documentation/admin-guide/nfs/nfsroot.rst#L88

regards,
Henning

> Thanks,
> Peng.
> 
> > 
> > Henning
> >   
> > > Thanks,
> > > Peng.
> > >
> > > Or maybe that  
> > > > MAC was taken and the client did not have a valid lease for it.
> > > >
> > > > Henning
> > > >  
> > > > > [ADDR]4: eth2    inet 169.254.232.89/16 brd 169.254.255.255
> > > > > scope global eth2 valid_lft forever preferred_lft forever
> > > > > [ROUTE]local 169.254.232.89 dev eth2 table local proto kernel
> > > > > scope host src 169.254.232.89 [ROUTE]broadcast
> > > > > 169.254.255.255 dev eth2 table local proto kernel scope link
> > > > > src 169.254.232.89 [ROUTE]169.254.0.0/16 dev eth2 proto
> > > > > kernel scope link src 169.254.232.89 [ROUTE]broadcast
> > > > > 169.254.0.0 dev eth2 table local proto kernel scope link src
> > > > > 169.254.232.89 [ROUTE]default dev eth2 scope link
> > > > >
> > > > >
> > > > > And also in route table, it added two entries going through
> > > > > eth2, I not understand why it will add one entry that default
> > > > > use eth2 with gateway 0.0.0.0 #route Kernel IP routing table
> > > > > Destination     Gateway         Genmask         Flags Metric  
> > Ref  
> > > > > Use Iface default         0.0.0.0         0.0.0.0         U  
> > 0  
> > > > >  0        0 eth2 default         _gateway        0.0.0.0  
> > > > UG  
> > > > >  0      0        0 eth1 10.193.102.0    0.0.0.0  
> > > > 255.255.255.0  
> > > > >   U     0      0        0 eth1 169.254.0.0     0.0.0.0
> > > > > 255.255.0.0     U     0      0        0 eth2
> > > > >
> > > > > It added the eth2 route table and will break nfsroot if we
> > > > > using 10.193.108.x for nfsroot server, because it will match
> > > > > the 1st entry.
> > > > >
> > > > > This is not jailhouse hypervisor issue, I just not sure the
> > > > > eth2 behavior, it is systemd does that route change or we
> > > > > need look into ivshmem-net to avoid update route table when
> > > > > creating eth2?
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > >  
> > >  
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/20210128120507.7d719105%40md1za8fc.ad001.siemens.net.

Reply via email to