On Fri, 2011-07-22 at 01:06 -0700, David Miller wrote:

From: Jiri Bohac <redacted>
Date: Tue, 19 Jul 2011 20:02:53 +0200

quoted

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