On Tue, 2015-12-01 at 22:28 +0100, Guus Sliepen wrote: > Ok, finally reproduced it. The problem is that apparently, the Linux > kernel waits with assigning an IPv6 link-local address until the > interface sees a "carrier". For wireless interfaces, that means it > waits > until it has associated with the base station. DHCPv6 requires a > link-local address. Unfortunately, the ISC DHCP client immediately > bails > out if the interface doesn't have a link-local address. It would have > been nice if it would just go to the background and wait until one > appears. I'll work around it by having ifup wait for a link-local > address right before starting the DHCP client. Did you report that upstream (i.e. that it doesn't bail out)?
> The loopback interface is always a bit special, and doesn't follow
> the
> rules of other interfaces.
Sure it's not that I'd complain... what I kinda miss is a best-
practises/examples documentation on how people *should* lay out their
ifupdown configuration (i.e. /e/n/interfaces).
/u/s/d/ifupdown/examples/network-interfaces.gz seems to be rather
limited and perhaps in some places even outdated, for example it says:
- "The loopback interface isn't really required any longer"
That shouls perhaps rather be something like "it doesn't need to be set
up by ifupdown anymore [as it's already set up by xyz]".
- The way it shows how to configure multiple addresses per iface:
# iface eth0 inet static
# address 192.168.0.100/24
# gateway 192.168.0.1
# iface eth0:1 inet static
# address 192.168.0.200
# netmask 255.255.255.0
is as far less preferred over:
# iface eth0 inet static
# address 192.168.0.100/24
# gateway 192.168.0.1
# iface eth0 inet static
# address 192.168.0.200
# netmask 255.255.255.0
I.e. I think it should be pointed more out that the later is preferred
when you just want more addresses, while the former really gives you
addition virtual ifaces (which most people probably wouldn't need).
> In general, if you run "ifup foo", it will act as if it runs all
> "iface
> foo" stanzas in /etc/network/interfaces in sequence. So if will first
> try to bring up your inet stanza, which in turn will configure
> wpa-supplicant. Then it brings up the inet6 stanza, but you don't
> need
> to repeat the wpa-* options.
Ah.... good to know... so it does some kind of "merging".
I think that should be more clearly explained like you did it just here
in the manpage... AFAICS, there is no section which really describes
that thoroughly.
And perhaps additionally in the example interfaces file using one as I
did with wifi + v4/v6 + wpa-*.
Maybe even one with eth, like:
iface eth0 inet dhcp
iface eth0 inet6 dhcp
iface eth0 inet manual
up vpnc foo
And tell people:
First it will bring v4 and v6 DHCP up... afterwards it will do the
vpnc.
> That's a bad idea. But if you want, you can separate the wpa-
> supplicant
> stuff from the IPv4 and IPv6 configuration, like so:
>
> iface wlan0-bar inet manual
> wpa-ssid bar
> wpa-key-mgmt WPA-PSK
> wpa-psk foo
>
> iface wlan0-bar inet dhcp
> iface wlan0-bar inet6 dhcp
I see... again, it would be (at least for me) a bit unclear, from the
manpage, that "manual" actually gets run here ("interfaces for which no
configuration is done by default")...
And perhaps it would be cleaner (in terms of config file language) to
have a pseudo family for shared options so that one can e.g. specify
something like that:
iface wlan0-bar all
wpa-ssid bar
wpa-key-mgmt WPA-PSK
wpa-psk foo
iface wlan0-bar inet dhcp
iface wlan0-bar inet6 dhcp
iface wlan0-bar all
vpnc foo
With "all" being poor naming for "done for all families" or and it
should allow (if not already the case) to have such section several
times like above:
1) set up wpa
2) run v4 dhcp
3) run v6 dhcp
4) set up some tunnel, once v4 and/or v6 addresses are there.
> > => which leads to the question, what happens if I do that with
> > scripts:
> > iface eth0 inet dhcp
> > post-up vpnc something
> > pre-down vpnc-disconnect
> > iface eth0 inet6 dhcp
> > post-up vpnc something
> > pre-down vpnc-disconnect
>
> It would execute the scripts twice.
Sounds logical,... but also something, that would be IMHO good to have
clearly shown in the docs/examples.
Thanks again for your efforts and best wishes,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
