netdev - Re: IPv6: autoconfiguration and suspend/resume or link down/up

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] [day] [month] [year] [list]

Date:	Wed, 27 Jul 2011 14:48:46 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	jbohac@...e.cz, netdev@...r.kernel.org,
	herbert@...dor.hengli.com.au, shemminger@...tta.com
Subject: Re: IPv6: autoconfiguration and suspend/resume or link down/up

On Fri, 2011-07-22 at 01:06 -0700, David Miller wrote:
> From: Jiri Bohac <jbohac@...e.cz>
> Date: Tue, 19 Jul 2011 20:02:53 +0200
> 
> > When the cable is unplugged and plugged in again, we already get
> > notified through linkwatch -> netdev_state_change ->
> >   -> call_netdevice_notifiers(NETDEV_CHANGE, ...)
> > However, if the device has already been autoconfigured,
> > addrconf_notify() only handles this event by printing a
> > message.
> > 
> > So my idea was to:
> > - handle link up/down in addrconf_notify() similarly to
> >   NETDEV_UP/NETDEV_DOWN
> > 
> > - on suspend, faking a link down event; on resume, faking a link up event
> >   (or better, having a special event type for suspend/resume)
> > 
> > This would cause autoconfiguration to be restarted on resume as
> > well as cable plug/unplug, solving both the above problems.
> > 
> > Or do we want to completely rely on userspace tools
> > (networkmanager/ifplug) and expect them to do NETDEV_DOWN on
> > unplug/suspend and NETDEV_UP on plug/resume?
> > 
> > Any thoughts?
> 
> This is an oft-reocurring discussion, what to do on link up/down
> events wrt. all sorts of autoconfiguration.
> 
> My gut instinct is that on any link state change (physical link down,
> suspend) we should be prepared to renegotiate everything and anything
> since as you state we could be on a different physical network.
> 
> Suspend is even more important because while we were suspended we
> could be on the same network but the routers present and available
> might have changed completely.
> 
> In userspace I've noticed that we've grown an ecosystem of stupid
> tools and facilities, none (or very few) of which monitor link status
> in order to do handle things intelligently.  DHCP servers are a great
> example.  DHCP servers spit out broadcast discover packets before we
> even have a link up.
> 
> Filling this void is NetworkManager, which does listen on a netlink
> socket for device state changes, hotplug, etc.  And in response it
> explicitly tells various facilities to reprobe the network.
> 
> This is why I'm reluctant to give NetworkManager a hard time, because
> whilst it's a huge beast, it is at least trying to do the right thing.
> :-)

Oh, it's not that huge :)  What's huge is the networking problem space,
and thus when you build something that tries to be aware of much of
what's going on (which in the modern world you do really need) it's
going to need to talk to all sorts of different subsystems...  Such is
life :(  It's sufficiently module though that if you have no need to
modems, or PPP, or WiFi, or 802.1x, or WiMAX, you don't need to run
those parts.  Of course now we're adding bridging, VLAN, bonding, etc
support, so the amoeba gets larger.  If only people stopped adding
features to the kernel networking stack :)

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