Hi,
On Mon, 2015-06-29 at 14:55 +0000, Sam Nazarko wrote:
> We appear to have found a bug in ConnMan but would like some
> verification before submitting it on JIRA. This is our environment:
>
>
> Debian Jessie with ConnMan (1.2.9), built with patches from here:
I'm assuming you mean 1.29 here.
> https://github.com/samnazarko/osmc/tree/master/package/connman-osmc/patches
> with systemd.
The patches are interesting, but not the source of the problem[1].
> If we restart ConnMan with (systemctl restart connman), which we do
> when upgrading the ConnMan package, WiFi is not guaranteed to work.
> We sometimes get:
>
> Jun 24 20:53:21 rpi2 connmand[849]: wlan0 runs an unsupported 802.11 driver
This line is printed if a WEXT wifi driver is found. Notice that WEXT
has not seen any new features for the last N years and such a driver
should no longer be used if a more reliable and supported nl80211 WiFi
driver is needed.
> Jun 24 20:53:21 rpi2 connmand[849]: Adding interface wlan0 [ wifi ]
> Jun 24 20:53:21 rpi2 wpa_supplicant[356]: ioctl[SIOCSIWAP]: Operation not
> permitted
>
> When WiFi is not working:
>
> connmanctl> scan wifi
> Error /net/connman/technology/wifi: Not supported
>
> This is sporadic and unpredictable. It would appear that Not supported
> is printed if service->immutable is true. It seems that running
> ifconfig wlan0 down before restarting the service resolves this issue.
service->immutable is only used if you have a .config file
in /var/lib/connman, which not what is reported here. As the above
prints out that a WEXT driver is being used, it is most likely that the
driver/wpa_supplicant combo is not resetting its state/driver/hw fast
enough.
Ifconfig wlan0 tells the driver to close properly, it seems
wpa_supplicant is not able to do that or signals something strange that
ConnMan does not understand. As this is a WEXT problem, please use a
more modern nl80211 driver for this chipset. If the problem persists,
it's much more likely to be an issue with ConnMan.
> Restarting ConnMan twice also seems to resolve this issue
ConnMan takes down all interfaces on startup that it is going to use to
get rid of previously existing routes and IP configuration to start from
a clean state. Restarting ConnMan twice indicates some kind of
driver/wpa_supplicant sluggishness in disabling the WiFi driver.
> sudo systemctl stop connman; sleep 5; sudo systemctl start connman
Using a 'sleep 5' indicates there is some issue in disabling the WiFi
driver.
> I think that ConnMan may not be tearing down the interfaces in a
> timely manner. systemd sends SIGTERM when it exits, is ConnMan
> handling this?
ConnMan starts to shut down when receiving a SIGTERM and this can be
detected by the string "Terminating" appearing in the logs.
I'd say this is due to an old WEXT driver. If there is any possibility
of using a nl80211 driver, please do so.
Cheers,
Patrik
[1] About the patches.
all-000-disable-sync-from-dhcp-time.patch
I don't know what good this patch does. Is it necessary?
all-001-online-connectivity-via-dolon.patch
If the server used has good connectivity this will work.
all-002-osmc-dbus-connman-interaction.patch
IIRC isn't the send_interface="net.connman.* directive for user osmc
just enabling the osmc user to send these signals? In that case
everything running as osmc can pretend to be ConnMan and fish out
credentials from the UI, send counter information and notifications
at will. I'm not sure these capabilities are needed by anyone else
except ConnMan.
all-003-add-an-option-to-prevent-etc-resolv-conf.patch
Could this patch be turned around so that ConnMan can write another
resolv.conf file instead of the default one?
all-004-disable-ipv6-by-default.patch
This will break ConnMan in my home network. Is it necessary?
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
