Hi [ I'm cross-posting this reply for #806889 to the bugreport in #766746 and #715267, if you're interested in networkd integration, feel free to skip to the second ff. paragraph. ]
On 2016-03-16, Daniel Baumann wrote:
> Hi,
>
> any news on this?
I am currently seeing problems with a wpa_supplicant/ hostapd combination
using 4addr setups (potential regression compared to v2.3, link staying
connected, not transmitting any data on the hostapd side, but not
reconnecting - forcing a reconnect by restarting hostapd tends to help).
As of yet, I haven't been able to confirm if this is an issue with
src:wpa v2.5 or induced by unrelated changes (e.g. kernel version),
given that this is difficult to reproduce reliably (it might take
several days to happen, but can also happen within minutes, making
reliable bisecting hard).
Another open question, not preventing the upgrade to v2.5, but one that
needs to either be deferred/ backed out or decided is #715267/ #766746,
shipping a systemd unit for networkd integration. While this is
technically simple (and no, the upstream provided systemd unit as it
stands is not suitable[1]) and strictly opt-in, shipping this in an
upload implies committing to this way of starting wpasupplicant more or
less for "all eternity" as fixed ABI...
+ it works, I'm testing it for close to a year now - with mixed results
+ there seem to be advantages when it comes to suspend/ resume
+ it's strictly opt-in and needs explicit enabling from the admin
- systemd-networkd upstream hasn't committed to a policy regarding
wireless devices, its handling might change in the future
- systemd-networkd doesn't provide any tools like ifup/ ifdown so
far, making dynamic configuration changes (e.g. switch from wired-
to wireless networks) difficult.
- hotpluggable wireless cards (USB) are problematic in the sense
that systemd will wait (until timeout, 90s by default) if the
a configured device is unplugged.
- basically unsuitable for notebook scenarios, where one might
occasionally want to switch to wired ethernet (so far routing
metrics seem to be the only, quite hacky workaround).
While it's easy to defer this decision once more, I was hoping to
come to an conclusion regarding #766746 for the next (as in this)
upload.
Given that it's opt-in, explicitly documenting this as volatile
and potentially unsupported (in the future) might be a way out,
but I'd still hate to eventually break previously working network
configurations in the future.
Regards
Stefan Lippers-Hollmann
[1] breaks with legacy/ staging (non-cfg80211 wlan cards)
and DBus activation, I have fixes for both in the
packaging VCs.
pgpRSi1OG7uLc.pgp
Description: Digitale Signatur von OpenPGP
