Thanks for reporting the issue Bernhard.
I see the difference, we will make it similar to ifupdown and submit a fix in
the next update as soon as we can.
ifupdown:
=======
ifup_hotplug () {
if [ -d /sys/class/net ]
then
ifaces=$(for iface in $(ifquery --list --allow=hotplug)
do
link=${iface##:*}
link=${link##.*}
if [ -e "/sys/class/net/$link" ]
then
# link detection does not work unless
we up the link
ip link set "$iface" up || true
if [ "$(cat
/sys/class/net/$link/operstate)" = up ]
then
echo "$iface"
fi
fi
done)
[snip]
}
ifupdown2:
========
ifup_hotplug () {
if [ -d /sys/class/net ]
then
ifaces=$(for iface in $(ifquery --list --allow=hotplug 2>/dev/null)
do
link=${iface##:*}
link=${link##.*}
if [ -e "/sys/class/net/$link" ] && [ "$(cat
/sys/class/net/$link/operstate)" = up ]
then
echo "$iface"
fi
done)
if [ -n "$ifaces" ]
then
ifup $ifaces "$@" || true
fi
fi
}
On Mon, 20 Feb 2017 17:20:10 +0100 Bernhard Schmidt <be...@debian.org> wrote:
> Package: src:ifupdown2
> Version: 1.0~git20170114-1
> Severity: important
>
> Dear Maintainer,
>
> it seems that ifupdown2 allow-hotplug keyword works significantly
> different from ifupdown allow-hotplug.
>
> In ifupdown, when a new network device appears, a udev trigger fires
> where ifquery checks whether there is an "allow-hotplug $INTERFACE"
> configuration stanza in /e/n/i. If yes, ifup is called accordingly,
> bringing the interface up.
>
> In ifupdown2, when networking.service is started
> (/usr/share/ifupdown2/sbin/start-networking start), it checks for all
> interfaces marked "allow-hotplug" (function ifup_hotplug). If the
> interface is there _and_ has a link (operstate = up) it will be
> configured.
>
> This means:
>
> 1.) ifupdown2 needs a link, ifupdown just needs the interface to be
> there. Since the interface is normally DOWN and is only set UP by
> ifupdown(2) it would never configure the link (sort of a dependency
> cycle)
>
> 2.) allow-hotplug does not get triggered by a udev event when the
> interface appears, but expects all interfaces to be available at
> startup.
>
> 3.) The documentation (man interfaces(5)) is wrong, saying that
>
> "Note that "allow-auto" and "auto" are synonyms."
>
> I think basing the configuration on an operational link (that cannot be
> there if ifupdown2 hasn't touched the interface yet, and might not be
> there on bootup due to external circumstances or timing issues) will
> cause hard to debug issues. Therefor I suggest a targeted fix for
> Stretch dropping the operstatus conditional. It still doesn't address
> note #2 above, but it would be better than nothing.
>
> Best Regards,
> Bernhard
>
>
