Connman WiFi p2p API evaluation
Hi, Thomas asked me to look at the Connman P2P/Direct APIs to see if we can share some of the interfaces. I think that's a worthwhile goal, so here's a short writeup of where the APIs stand WRT to NetworkManager's current D-Bus API. doc/wifi-p2p-overview.txt doc/technology-api.txt doc/peer-api.txt The largest issue is that all the interfaces start with "net.connman". If we're going to coordinate on API we should grab some neutral suffix to org.freedeskop. instead. The second issue is that the APIs have some property-related things that aren't org.fdo.DBus.Properties conformant. I think that's a legacy Connman thing, but eg I don't think we want to support the legacy net.connman.Peer.GetProperties() style functions or signals. Summary (the following from wifi-p2p-overview.txt) === WiFi P2P is supported as follows: - if hardware and wpa_supplicant supports it, a "p2p" technology will appear in the technology list * this appears to refer to the Connman Manager object's GetTechnologies() method. It looks like "Technologies" are somewhat like NM's devices, but I'm not sure whether you'll get two Technology objects for two separate wifi interfaces? Patrik? Anyway, one issue is that even if p2p is supported on a specific wifi interface, that interface may have different capabilities that impact how p2p can be used. I don't think we can divorce it entirely from the wifi interface it will be using, which the Connman interfaces appear to do. Might be able to work something out here though (see way below). - "p2p" technology, as for "wifi" technology, supports a Scan() method. Such method will trigger a P2P find process. The results will be available through the Manager interface, comparable to services being available through this same interface after a Scan() on "wifi" technology. * Scan() for p2p discovery sounds fine to me, but we'll have to figure out whether this should be on the WiFi device itself, or whether a global method is OK. I can see arguments both ways, but I guess most client apps using P2P won't care about wifi at all really, just about P2P. - the result of a "p2p" Scan() consists into a list of "peer" objects * This we might be able to implement. It looks like these are top-level objects in Connman instead, with no relation to their parent WiFi interface through which they will be reached. But like I said above, perhaps most clients using P2P don't actually care how the peer is found? and thus just care about P2P and not the parent wifi interface. - it is then possible to access peer information, connecting and disconnecting it via the Peer API. * As above, the Peer API might be something we can mostly use as-is if we can get a namespace change. API Usage (also from wifi-p2p-overview.txt) = The UI willing to access to WiFi P2P technology should proceed this way: - Request Manager.GetTechnologies() and figure out from the result if "p2p" technology is provided. What comes next implies this successful case. * I'd rather have a separate org.fdo.XXX.WiFiP2P interface on the top-level object that has a Capabilities properties with flags like "none", "client", "group owner". That would be more generic and then NM wouldn't have to deal with technologies. This interface would also have the Scan() method to find peers. - Add a listener to signal Manager.PeersChanged(): this signal will provide the results of a "p2p" technology Scan(). * I'd rather have this be signal on org.fdo.XXX.WiFiP2P instead, and coupled with an "ao" type Peers property that is an array of object paths to peers. There would also be PropertiesChanged signals for Peers. - From the "p2p" technology object, request a Technology.Scan() method. This will run for a while a P2P find process. * I'd rather have this on org.fdo.XXX.WiFiP2P, and it would emit changes to the Peers property as above. - If P2P peers are found, it will be signaled through Manager.PeersChanged(). Objects are "Peer" objects. UI might use Manager.GetPeers() instead, if listening to a signal is not the preferred way. * as above, I'd rather have a different dbus interface for these. - Once selected the proper Peer object, request a Peer.Connect() method on it so it will connect to it. Peer.Disconnect() will disconnect. * this should be mostly fine. --- The biggest question in my mind is whether the P2P operations can be (or should be) completely divorced from the WiFi interface they will be using. Do clients care about the WiFi interface? Quite possibly they don't; imagine a scenario in which you connect to a camera with P2P, where the Photos app doesn't care about wifi, it just wants to find some remote cameras it can connect to. I think there are restrictions in the drivers sometimes with whether they can be a Group Owner or client at the same time as a WiFi STA though, so clearly there would have to arbitration in some cases to warn the user they'd have to disconnect from their AP to do some of the P2
Re: Network-Manager on Raspbian (QUESTION)
On Thu, 2015-01-08 at 14:25 -0600, Alejandro Covarrubias wrote: > Dear Network-manager Squad > > > Recently, im trying to connect to a wifi wireless from python and > network manager on Raspbian 7 Raspberry isnt work, didnt work, but i > have the network manager v 9.4.0 and 9.8.8 on my ubuntu, well i think > "maybe the version is to old" but no i think maybe not i dont know, > because in ubuntu works perfectly, when i tried to install network > manager from apt-get in raspbian "networkmanager is already the newest > version" whats wrong? and i tried to hand-install and i get a lot of > problems with MAKE i got the 1.15 version. Apparently there is no newer version of NetworkManager available for your distribution. So you either: - find somewhere a repository with backports and a NM version that suits you better - compile NM yourself (either from source or you recompile a debian package) - get happy with what you have > > > how i can connect to a wifi from python + network-manager on > raspbian? :( add-system-wifi-connection.py dont work for me Why didn't it work? Look into the examples directory of upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python Note you can either use the DBUS API directory, or you use glib library libnm that wraps the DBUS API (by using gobject introspection). See the examples. Note that the examples might use a newer API then what you have currently installed. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Network-Manager on Raspbian (QUESTION)
Dear Network-manager Squad Recently, im trying to connect to a wifi wireless from python and network manager on Raspbian 7 Raspberry isnt work, didnt work, but i have the network manager v 9.4.0 and 9.8.8 on my ubuntu, well i think "maybe the version is to old" but no i think maybe not i dont know, because in ubuntu works perfectly, when i tried to install network manager from apt-get in raspbian "networkmanager is already the newest version" whats wrong? and i tried to hand-install and i get a lot of problems with MAKE i got the 1.15 version. how i can connect to a wifi from python + network-manager on raspbian? :( add-system-wifi-connection.py dont work for me thank you and sorry for my bad english :P ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFE: networkmanager-openvpn tls-version-min setting (for TLSv1.2)
On Mon, 2014-12-29 at 11:52 +0800, Anthony Alba wrote: > Playing around with Fedora 21/nm-openvpn it turns out that the version > of openvpn 2.3.6 in F21 supports TLSv1.2 cipher suites, however for > backward compatibility reasons openvpn >= 2.3.4 "forces" TLSv1 for > the Control Channel. > > If I have a server running 2.3.6 --tls-version-min=1.0, I would like > to be able to set nm-openvpn clinet to use --tls-version-min=1.2 thus > availing myself of TLSv1.2. I don't believe it's supported yet, and if you are willing to work on a patch that's great! I've filed this bug to track it: https://bugzilla.gnome.org/show_bug.cgi?id=742604 so it doesn't get lost. For the UI side I think the option should probably be a dropdown box in the Security tab of the Advanced dialog, much like HMAC Auth one. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DNS not working on openvpn connection.....don't know why?
On Wed, 2015-01-07 at 11:37 -0600, Dan Williams wrote: > On Thu, 2014-12-25 at 19:57 +, Another Sillyname wrote: > > Happy Crimbles everyone..now time for your Christmas quiz!! > > > > I am connecting to a free vpn service freevpn.me using the > > NetworkManager openvpn functionality in Fed21 x86_64. > > > > However once I connect to he vpn I cannot resolve names anymore. > > > > As freevpn.me is totally free their website isn't full of helpful info > > and googling has got me nowhere. > > > > I've added a DNS server entry in the NM part to no effect... > > > > ping IPs when the vpn is up works fine so I'm pretty sure it's a resolver > > issue. > > > > As it's totallly free could anyone with 10 minutes spare try it and > > see if you get the same result. > > Now that everyone is back from the holidays... :) As Michael asked, do > you have resolvconf installed at all? Could you paste the non-working > resolv.conf file into an email reply? Ok, you've sent the resolv.conf and they are identical, which seems to indicate that the VPN plugin was not sending the right nameservers to NM from the VPN itself. You should see something like this in the NM logs: NetworkManager[20412]: VPN connection 'My VPN' (IP4 Config Get) reply received from old-style plugin. NetworkManager[20412]: VPN Gateway: a.b.c.d NetworkManager[20412]: IPv4 configuration: NetworkManager[20412]: Internal Address: 1.2.3.4 NetworkManager[20412]: Internal Prefix: 32 NetworkManager[20412]: Internal Point-to-Point Address: 1.2.3.5 NetworkManager[20412]: Internal DNS: e.f.g.h NetworkManager[20412]: Internal DNS: i.j.k.l NetworkManager[20412]: DNS Domain: 'mycorp.com' NetworkManager[20412]: No IPv6 configuration Does anything like that show up and if so, what nameservers does it give? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Wed, 2015-01-07 at 23:42 +0100, poma wrote: > On 07.01.2015 18:29, Dan Williams wrote: > > On Mon, 2015-01-05 at 19:14 +0100, Thomas Schneider wrote: > >> Hello! > >> > >> I have installed latest version of NetworkManager and nmcli > >> respectively + OpenVPN plugin or NetworkManager. > >> > >> user@pc1-asus:~$ apt-cache policy network-manager > >> network-manager: > >> Installiert: 0.9.10.0-5 > >> Installationskandidat: 0.9.10.0-5 > >> Versionstabelle: > >> *** 0.9.10.0-5 0 > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages > >> 100 /var/lib/dpkg/status > >> user@pc1-asus:~$ apt-cache policy network-manager-gnome > >> network-manager-gnome: > >> Installiert: 0.9.10.0-2 > >> Installationskandidat: 0.9.10.0-2 > >> Versionstabelle: > >> *** 0.9.10.0-2 0 > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages > >> 100 /var/lib/dpkg/status > >> user@pc1-asus:~$ apt-cache policy network-manager-openvpn > >> network-manager-openvpn: > >> Installiert: 0.9.10.0-1 > >> Installationskandidat: 0.9.10.0-1 > >> Versionstabelle: > >> *** 0.9.10.0-1 0 > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages > >> 100 /var/lib/dpkg/status > >> user@pc1-asus:~$ apt-cache policy network-manager-openvpn-gnome > >> network-manager-openvpn-gnome: > >> Installiert: 0.9.10.0-1 > >> Installationskandidat: 0.9.10.0-1 > >> Versionstabelle: > >> *** 0.9.10.0-1 0 > >> 500 http://ftp.debian.org/debian/ jessie/main i386 Packages > >> 100 /var/lib/dpkg/status > >> > >> All maintained connections are working. This includes OpenVPN > >> connection type, too. > >> However, in order to use either nm-applet or command-line client > >> nmcli, I need to be root. > >> The issue I'm facing is that with older release I could use either > >> nm-applet or nmcli without root authorization. > >> This becomes a critical issue in a multi-user desktop PC where most > >> user neither have root authorization nor can utilize sudo. > >> > >> Question: > >> How can I ensure that both, nm-applet and nmcli, can be used without > >> root authorization? > > > > It's certainly intended that they can all be used without root. When > > you try to run 'nmcli' as a normal user, what error do you get? What is > > the output of "nmcli gen perm" as a normal user? > > > > $ nmcli -v > nmcli tool, version 0.9.10.0-14.git20140704.fc21 > > $ nmcli general permissions > PERMISSION VALUE > org.freedesktop.NetworkManager.enable-disable-networkyes > org.freedesktop.NetworkManager.enable-disable-wifi yes > org.freedesktop.NetworkManager.enable-disable-wwan yes > org.freedesktop.NetworkManager.enable-disable-wimax yes > org.freedesktop.NetworkManager.sleep-wakeno > org.freedesktop.NetworkManager.network-control yes > org.freedesktop.NetworkManager.wifi.share.protected yes > org.freedesktop.NetworkManager.wifi.share.open yes > org.freedesktop.NetworkManager.settings.modify.systemyes > org.freedesktop.NetworkManager.settings.modify.own yes > org.freedesktop.NetworkManager.settings.modify.hostname auth > > Is this expected output? Yes, that is expected output for "permissive" installs. > What manages the sleep state? The sleep-wake permission is actually unused. It was previously used for the "private" Sleep() dbus method, the only user of which was pm-utils scripts. Unfortunately the pm-utils scripts didn't wait for a dbus reply, which meant NM couldn't determine the UID of the caller, which meant polkit permission couldn't be used. So instead, the Sleep() method is locked to root and the permission isn't used. When upower or systemd are active, NetworkManager listens internally for suspend/resume signals from those services instead of using permissions or a D-Bus method. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
