Re. the patches: all-000-disable-sync-from-dhcp-time.patch >I don't know what good this patch does. Is it necessary?
We use NTP on our clients. Some of our userland is vulnerable to jumps and does not use CLOCK_MONOTONIC_RAW. 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 interaction with ConnMan is done via a Python GUI interface using DBus signals and this is executed by the OSMC user 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? Not sure of the potential benefit of doing so. We only use this option for NFS installations, where we have to ignore etho (-I eth0 on ConnMan), but still desire it for other technologies such as Bluetooth. ConnMan isn't able to provide an accurate /etc/resolv.conf in this situation, so we manually populate from /proc/net. all-004-disable-ipv6-by-default.patch > This will break ConnMan in my home network. Is it necessary? I wish not, but unfortunately it is. We see odd DNS resolution issues on some user's networks, so it is easier for us to make users enable it via the network setup GUI and disable it for new services by default. >I'd say this is due to an old WEXT driver. If there is any possibility >of using a nl80211 driver, please do so. This issue was replicated using an rtl8192cu chipset using an nl80211 driver. Here is my tree, with some patches to get it to build for 3.18: https://github.com/samnazarko/rtl8192cu-osmc. I am inclined to believe you that the driver is at fault as this seems to be a commonly reported issue, independent of ConnMan. Sam ________________________________________ From: connman <[email protected]> on behalf of Patrik Flykt <[email protected]> Sent: 30 June 2015 09:50 To: [email protected] Subject: Re: Restarting ConnMan too quickly breaks WiFi 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 _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
