Re: How is the new networking world supposed to work?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-04-21 at 02:26 +0200, Dennis Jacobfeuerborn wrote:
> Dan Williams wrote:
> >> - Device: eth0 ----------------------------------------------------------------
> >>     Type:              Wired
> >>     Driver:            forcedeth
> >>     State:             connected
> >>     HW Address:        00:00:00:00:00:00
> >
> > I've seen this once and not been able to reproduce; there might be a
> > race between bringing up the card and getting a valid MAC address since
> > sometimes the MAC can't be read until firmware is loaded and booted, but
> > that's usually only an issue with wireless cards since wired devices
> > don't usually have firmware.
> 
> I actually managed to fix my problem by disabling the "network" service. I 
> guess the remaining question is why the interface ends up in a b0rked state 
> when it is first brought up by "network" and then taken over by NM. Should 
> "network" actually bring the interface up if the config file says 
> "NM_CONTROLLED=yes"?

No, it probably should not do anything if NM is running.

> I think it would be useful to define the semantics when both services are 
> started. Should there be two sets of interfaces determined by NM_CONTROLLED 
> and each service only caring for its "own" so that they don't collide or 
> should this work like an override mechanism where one service takes over 
> interfaces from the service that ran before?

If NM_CONTROLLED=yes and NM is running, only NM should manage the
device.  If NM is not running or if NM_CONTROLLED=no, then it's probably
fine for the network service to touch the device.

Dan

> >>     Capabilities:
> >>       Supported:       yes
> >>       Carrier Detect:  yes
> >>       Speed:           100 Mb/s
> >>
> >>     Wired Settings
> >>
> >>     IP Settings:
> >>       IP Address:      192.168.2.100
> >>       Subnet Mask:     255.255.255.0
> >>       Broadcast:       192.168.2.255
> >>       Gateway:         192.168.2.1
> >>       DNS:             195.50.140.178
> >>       DNS:             195.50.140.114
> >>       DNS:             192.168.2.1
> >>
> >>
> >> - Device: eth1 ----------------------------------------------------------------
> >>     Type:              Wired
> >>     Driver:            3c59x
> >>     State:             unavailable
> >>     HW Address:        00:50:04:49:E0:EC
> >
> > This is the interesting part; and also something I've seen once in
> > conjunction with the issues above.  The "unavailable" state for wired
> > devices usually means NM can't detect a carrier for that card.  In your
> > case though, NM seems to think it does support carrier detection, since
> > it responds correctly to either MII register accesses or ethtool
> > queries.
> 
> eth1 isn't connected so the "unavailable" state is correct. That interface 
> isn't used at all.
> 
> >>     Capabilities:
> >>       Supported:       yes
> >>       Carrier Detect:  yes
> >>       Speed:           10 Mb/s
> >>
> >>     Wired Settings
> >>
> >> (I've added "prepend domain-name-servers 195.50.140.178, 195.50.140.114;"
> >> to dhclient-eth0.conf so I get decent nameservers in resolv.conf)
> >
> > You can also set DNS1 and DNS2 into your ifcfg files.  That's  a bit
> > easier...
> 
> Indeed, thanks for the tip.
> 
> Regards,
>    Dennis
> 

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux