netdev - Re: [PATCH] Make virtio_net support carrier detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1236858219.14863.18.camel@localhost.localdomain>
Date:	Thu, 12 Mar 2009 07:43:39 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Pantelis Koukousoulas <pktoss@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] Make virtio_net support carrier detection

On Thu, 2009-03-12 at 19:46 +1030, Rusty Russell wrote:
> On Thursday 12 March 2009 18:14:44 Pantelis Koukousoulas wrote:
> > On Thu, Mar 12, 2009 at 9:29 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> > > On Wednesday 11 March 2009 22:27:22 Pantelis Koukousoulas wrote:
> > >> For now the semantics are simple: There is always carrier.
> > >>
> > >> This allows a seamless experience with e.g., qemu/kvm
> > >> where NetworkManager just configures and sets up
> > >> everything automagically.
> > >
> > > So, NetworkManager ignores the device because it doesn't support
> > > carrier detection?
> > 
> > It doesn't ignore it, it just doesn't enable it by default, like it does for
> > those that do report carrier.
> > 
> > But the user experience is that on real hardware you just boot a livecd
> > and see your network "just working" (and the familiar icon with the 2
> > computers indicating that), while under e.g., KVM/virtio you get
> > non-working network / an icon with a red X and you have to
> > figure out to left click on it and select eth0 to get things to work.
> > 
> > Some newer versions of NetworkManager seem to assume that
> > if no carrier detection is supported then carrier is on by default
> > so it should work for those, but that assumption seems like
> > a worse hack than this patch :)
> 
> No, that's absolutely sane behavior, the previous was buggy.  If a network
> doesn't support carrier, you shouldn't look for it.
> 
> Since they've fixed this in Network Manager, I'm not tempted to lie about it
> in the driver (though the distributions might choose to).

The problem is that there's no "my carrier detection is accurate" flag
for drivers.  Drivers that don't support carrier detection (say, my
Belkin PCMCIA NE2k card) always report "carrier on", but of course don't
support carrier detection.  So when NetworkManager looks at the device
and sees "hey, there's a carrier!" it will activate it, because a
carrier means the cable is plugged in or the PHY *thinks* a cable is
plugged in.

So NetworkManager checks whether the device supports ethtool get_link or
MII register carrier status in lieu of a general kernel driver flag for
"I support carrier detection".

Carrier is not on/off, it needs to be tristate, like on/off/unknown.  If
it was unknown, NM could make an intelligent decision about this without
resorting to ethtool/MII checks.  But we don't have that.

Dan


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html