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

Message-Id: <20110722.010628.1678943945721626312.davem@davemloft.net>
Date:	Fri, 22 Jul 2011 01:06:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jbohac@...e.cz
Cc:	netdev@...r.kernel.org, herbert@...dor.hengli.com.au,
	shemminger@...tta.com
Subject: Re: IPv6: autoconfiguration and suspend/resume or link down/up

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.
:-)
--
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