Re: NM not connecting with KDE4.10.2
On Sunday 12 May 2013 06:05:45 Cliff McDiarmid wrote: - Original Message - From: Lamarque V. Souza Sent: 05/11/13 04:53 PM To: networkmanager-list@gnome.org Subject: Re: NM not connecting with KDE4.10.2 On Saturday 11 May 2013 06:16:05 Cliff McDiarmid wrote: Hi I have just installed NM-0.9.8.0 and wpa-supplicant-2.0 under KDE 4.10.2. D-bus is working fine, but after the intial: May 9 22:52:04 cliffhanger NetworkManager[1895]: info NetworkManager (version 0.9.8.0) is starting... May 9 22:52:04 cliffhanger NetworkManager[1895]: info Read config file /etc/NetworkManager/NetworkManager.conf May 9 22:52:04 cliffhanger NetworkManager[1895]: info WEXT support is enabled May 9 22:52:05 cliffhanger dbus[1872]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) May 9 22:52:05 cliffhanger polkitd[1930]: Started polkitd version 0.107 May 9 22:52:05 cliffhanger dbus[1872]: [system] Successfully activated service 'org.freedesktop.PolicyKit1' May 9 22:52:05 cliffhanger NetworkManager[1895]: info Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. May 9 22:52:05 cliffhanger NetworkManager[1895]: info monitoring kernel firmware directory '/lib/firmware'. May 9 22:52:05 cliffhanger NetworkManager[1895]: info rfkill0: found WiFi radio killswitch (at /sys/devices/pci:00/:00:1c.0/:02:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi) May 9 22:52:05 cliffhanger NetworkManager[1895]: info WiFi hardware radio set enabled May 9 22:52:05 cliffhanger dbus[1872]: [system] Activating service name='org.bluez' (using servicehelper) May 9 22:52:05 cliffhanger dbus[1872]: [system] Activated service 'org.bluez' failed: Cannot launch daemon, file not found or permissions invalid May 9 22:52:05 cliffhanger NetworkManager[1895]: info WiFi enabled by radio killswitch; enabled by state file May 9 22:52:05 cliffhanger NetworkManager[1895]: info WWAN enabled by radio killswitch; enabled by state file May 9 22:52:05 cliffhanger NetworkManager[1895]: info WiMAX enabled by radio killswitch; enabled by state file May 9 22:52:05 cliffhanger NetworkManager[1895]: info Networking is enabled by state file May 9 22:52:05 cliffhanger NetworkManager[1895]: info (wlan0): using nl80211 for WiFi device control May 9 22:52:05 cliffhanger NetworkManager[1895]: info (wlan0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 5) May 9 22:52:05 cliffhanger NetworkManager[1895]: info (wlan0): exported as /org/freedesktop/NetworkManager/Devices/0 May 9 22:52:05 cliffhanger NetworkManager[1895]: info (wlan0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] May 9 22:52:05 cliffhanger NetworkManager[1895]: info (wlan0): bringing up device. May 9 22:52:06 cliffhanger NetworkManager[1895]: info (wlan0): preparing device. May 9 22:52:06 cliffhanger NetworkManager[1895]: info (wlan0): deactivating device (reason 'managed') [2] May 9 22:52:06 cliffhanger dbus[1872]: [system] Activating service name='fi.w1.wpa_supplicant1' (using servicehelper) May 9 22:52:06 cliffhanger NetworkManager[1895]: warn failed to allocate link cache: (-10) Operation not supported May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): carrier is OFF May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): new Ethernet device (driver: 'sky2' ifindex: 3) May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): exported as /org/freedesktop/NetworkManager/Devices/1 May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): bringing up device. May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): preparing device. May 9 22:52:06 cliffhanger NetworkManager[1895]: info (eth0): deactivating device (reason 'managed') [2] May 9 22:52:06 cliffhanger NetworkManager[1895]: info Added default wired connection 'Wired connection 1' for /sys/devices/pci:00/:00:1c.2/:04:00.0/net/eth0 May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/dummy0: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/sit0: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/dummy0: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn /sys/devices/virtual/net/sit0: couldn't determine device driver; ignoring... May 9 22:52:06 cliffhanger NetworkManager[1895]: warn
Re: NM not connecting with KDE4.10.2
exited with unknown return code 255 May 9 22:52:06 cliffhanger NetworkManager[1895]: error [1368136326.306764] [nm-supplicant-interface.c:997] interface_add_cb(): (wlan0): error adding interface: Launch helper exited with unknown return code 255 May 9 22:52:06 cliffhanger NetworkManager[1895]: dbus_g_proxy_cancel_call: assertion `pending != NULL' failed May 9 22:52:06 cliffhanger NetworkManager[1895]: info (wlan0): supplicant interface state: starting - down May 9 22:52:06 cliffhanger NetworkManager[1895]: warn Trying to remove a non-existant call id. May 9 22:52:06 cliffhanger dbus[1872]: [system] Activating service name='fi.w1.wpa_supplicant1' (using servicehelper) Maybe the Excec= line in /etc/dbus-1/system.d/wpa_supplicant.conf is incorrect. Where did you install wpa_supplicant (the prefix you used)? Under KDE the applet is saying that NM is not running and should be started. Starting it manually has no effect. That message appear if the KDE applet (Plasma NM) is not able to contact NetworkManager, that usually happens when NM is not running but polkit or dbus problems can prevent Plasma NM from contacting NM. Is NM really running? What does the command 'ps u -C NetworkManager' return? Can someone point me in the right direction here. Help appreciated. Did you compile both (or either) NM and wpa_supplicant yourself? -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem automatically unmounting VPN shares
Em Saturday 28 July 2012, Robby Workman escreveu: On Sat, 28 Jul 2012 12:50:13 +0100 Peter Rockett p.rock...@sheffield.ac.uk wrote: Hi I am trying to automatically mount and unmount a share at my office. I have a script in /etc/NetworkManager/dispatch.d which runs along the lines: #!/bin/bash case $2 in vpn-up) exec mount blah-blah-blah ;; vpn-down) exec umount blah-blah-blah ;; esac which mounts the share in my home directory (on Ubuntu 11.10 + Network Manager v. 0.9.1.90). I swear this all worked fine when I set it up in 2010. But some time in the intervening period it has broken. (I am infrequent user of VPN since I got DropBox!) I have also upgraded from Natty to Oneiric in the meantime... Now, VPN connects fine, the remote share is mounted OK. I can see/access all the remote files. But when I disconnect from VPN, the running of the umount seems to go very wrong. After disconnect, if I open a terminal and type ls to list the contents of my home directory (the mount point), the ls command hangs. (Nautilus also hangs - either it won't start or, if it was running already, it hangs.) Everything else in the OS seems to work OK. It seems for all the world as if the mount point is getting screwed and the only recovery is to restart (in which the shutdown takes much longer than usual). The weird thing is that, if I delete the dispatcher script above, connect to VPN, mount the drive manually in a terminal, then umount it manually, and disconnect from VPN, everything is fine and as it should be. So it seems like the dispatcher daemon is making a mess of running the unmount... but not the mount. Any ideas where to go with this? What is happening is that NetworkManager is taking down the connection before running the dispatch script. That is a known problem. See mount(8), particularly the -l and -f options: -f Force unmount (in case of an unreachable NFS system). -l Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. Those options can prevent other programs from hanging. But keep in mind that nfs clients maintain a local cache that may not have been sync'ed to the server by the time the connection is taken down. Files can be corrupted because of that though I have never seen that happening. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: file location of VPN config
Em Saturday 28 July 2012, Michael Irons escreveu: Thanks again for the quick reply, Lamarque. Basically, I'm trying to get round the problem you highlighted here https://bugs.kde.org/show_bug.cgi?id=295468. Since there's no way of doing it through nm-applet or the plasmoid, I'm trying to edit the connection file manually, then start it through nmcli. For the user to update the file in /etc/NetworkManager/system-connections/, I have to chmod it. That works, but nmcli doesn't pickup the changes when it dsplays the connection dialog. After a network-manager restart, the connection disappears. It seems this happens when the file permissions change. Is there a better method of changing the 'Xauth username' through a script? Some months ago I created a patch to change VPN's settings from Plasma NM's secret agent. It does not work properly because when the secret agent is called the connection is already in progress and NetworkManager still uses the old username and group even though the new username and group were correctly saved, to the connection fails. On a second connect attempt the new username and group correctly appear in the password dialog. So basically that depends on NetworkManager, if NetworkManager allowed secret agents to change the settings of an ongoing connect attempt (like it allows for the secrets of that connection) we can implement the proper support in NetworkManager's clients (Plasma NM, nm-applet, etc). I think the same problem will happen with any script you try to create (it will only work on the second connect attempt, the first attempt will always use the old username). Cheers Mike On 28 July 2012 03:25, Lamarque V. Souza lamar...@kde.org wrote: Em Friday 27 July 2012, Michael Irons escreveu: Can anyone tell me where network manager stores the username, for saved VPN/vpnc connections? ~/.kde/share/apps/networkmanagement/secrets/ - contains a guid file with the group password and user password, but I need to be able to amend the stored username from a script. The username is stored in /etc/NetworkManager/system-connections/connection name OBS: ~/.kde/share/apps/networkmanagement/secrets/ is used only when you set Plasma NM to store secrets in plain text, which is not the default configuration. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: file location of VPN config
Em Friday 27 July 2012, Michael Irons escreveu: Can anyone tell me where network manager stores the username, for saved VPN/vpnc connections? ~/.kde/share/apps/networkmanagement/secrets/ - contains a guid file with the group password and user password, but I need to be able to amend the stored username from a script. The username is stored in /etc/NetworkManager/system- connections/connection name OBS: ~/.kde/share/apps/networkmanagement/secrets/ is used only when you set Plasma NM to store secrets in plain text, which is not the default configuration. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The NetworkManager does not run dispatch script
Em Wednesday 25 July 2012, Chengyu Fan escreveu: Hi~ Hi, I use NetworkManager on Ubuntu. After I install a new DHCP client, the NetworkManager does not run the script 01ifupdown in /etc/NetworkManager/dispatcher.d/ when the network is up. What should I do to let NM run this script? Thanks, Does the script has execution permissions (chmod 755)? -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting openVPN options
Em Monday 27 February 2012, Volker Kuhlmann escreveu: On Sun 26 Feb 2012 05:38:58 NZDT +1300, Lamarque V. Souza wrote: Which openvpn version do you use? openvpn-2.2.1-18.1.2.x86_64 I use 2.2.0 here. openSUSE 12.1 With Gentoo. I am not aware of this problem (I am the responsible for Plasma NM, the KDE applet for NetworkManager). I have just check it here and my wifi connection stays in the plasmoid and the kcm (Manage Connections) lists after I disconnect it. For debugging all of this I intentionally disconnect the wifi connection by clicking on the panel applet icon, which shows a connection summary with connection list on the left and the configured NM connections and fond APs on the right. Click on the white X with the red round background in the top right corner of each connection drops the connection, and removes the wifi connections (all of them) from the right side. It happens every single time. Immediately after that, an iwlist wlan0 scan shows the closest AP (mine) immediately, but the AP list on the right is not populated again for quite some time afterwards. As the list is empty, one can't click on it to start the connection again. It's often faster to turn off enable wireless and turn it on again immediately. This look like kded4 or NetworkManager crashed when you disconnected the wifi connection. By the fact that the AP list is not populated for some time I guess it was NetworkManager. kded4 restarts itself when it crashes, so if it was kded4 the list should have been re-populated some seconds later. Can you send me NetworkManager's log and ~/.xsession-errors file? Wifi driver is broadcom wl (apologies, not one I'd have chosen). I used to have my problems with broadcom drivers. Fortunately my broadcom card is now supported by native driver. Sure there is a security issue to deal with, but given that NM asks for a root password each time there's a change to the connection settings I don't see any security *problem* here. The problem is implemeting in NM all the checks to make sure the options are safe. NM cannot just pass them to openvpn daemon. Sorry, NM asks for the *root* password here. Safety checks no longer exist. Why do they no longer exist? Running as root does not mean the program should take any parameter without checking it. It's ironic that the insistence on checks leads to a less-secure program that is incapable of putting in the one security option I insist I have in there. openvpn warns loudly if it's missing. Keyword MITM. Which option is that? If it is always required it should not even be an option. auto-connect for VPN is not implemented in NM as far as I know. There are some scripts from users in this mailing list to do just that. I have never tested them though. The autoconnect tickbox is still there for VPN. Even if it didn't work, I'd be happy to be able to manually click on the connection name to get it started. That works as long as you have another non-VPN connection already started. I can delete routes. I'm all ears. What's the trick? For my scenario above where I just do not want the VPN to set the default route you should do the following (all in the IPv4 tab in the connection editor): . in Basic settings mark Method as Automatic (VPN) addresses only. This option makes NM sets up only network address, netmask and IP address, and no routes. . in Routes check Use only for resources on this connection My VPN sets the local network 10.0.0.0/24 but I also need to access a different internal network (192.168.0.0/24), so I add a new route for it. That works for me, the problem is that I need to do two things and most people believe that just checking Use only for resources on this connection is enough to set up a VPN connection that does not set the default route. * NM starts openvpn with an openvpn option that causes the vpn to stop dead halfway through the startup. Impossible to fix with NM. Which option is that? To be honest I'm reluctant to say, because it gains nothing. It's pointless to deal with one particular option while ignoring the other 3. If the option should not be used how do you think someone could remove it from NM without knowing each one it is? I've cranked up kvpnc, which is pretty annoyingly buggy, but differs from NM in one crucial point: it gets the job done. The alternative is to manually create an openvpn config file (done that by now) and a 1-line script for convenience. Needs a root login (as does kvpnc), but it's lightning fast to the alternatives. Ok then, good that the other alternatives work. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list
Re: Setting openVPN options
be added with NM, but they can't be deleted. I can delete routes. Running nm-openvpn-service --persist --debug will run openvpn with --verb 10 which will also show the verb3/verb4 output. Is that nto working for you? Sorry I was wrong twice. Yes it does work, and the debug output is from openvpn (perhaps I didn't see it first because my openvpn wrapper script wrote arguments and output to file). It does however not show the arguments to openvpn, and that's pretty poor. For troubleshooting first thing I want to know is how external programs are called. I don't mind editing /etc/NetworkManager/system-connections/VPN_whatever (as root!) but doing so serves no useful purpose. It still doesn't pass options to openvpn, all it does is for nm to barf before even starting openvpn. pfsense (a professional firewall with BUI) has a text box for arbitrary options too. And I haven't used it yet, there is a useful range of options in the standard option part that just make it work. You say a text box isn't good for users? But a useless piece of software is more user-friendly? Useless being the adjective for a kettle that doesn't boil water. Chasing the options which someone might need is a losing proposition. I doubt you can know in advance. What happens if openvpn changes? 12 months of you're stuffed with NM? Bottom line is NM openvpn can't be made to work. I like it for wifi though. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Force default gateway for a specific connection?
Em Friday 20 January 2012, Pantelis Koukousoulas escreveu: On Fri, Jan 20, 2012 at 11:13 AM, Thomas Bechtold thomasbecht...@jpberlin.de wrote: That's not working in my case because both conenctions should grap the default route, but the modem connection should have a higher priority. My humble opinion is that it should be like this by default, i.e., ppp connections should have higher priority for getting the default route with the rationale being that LAN connections can be used for many things while ppp connections are more internet-specific in general. Is there any real advantage for LAN to have higher priority than PPP? PPP is used by mobile broadband, which is more expensive (in money sense) than the other connection types, which usually are free of charge. Besides, LAN is usually faster. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trying to use the DBus API with QtDBus - does the example work?
Em Wednesday 21 December 2011, devine-ml...@ddevnet.net escreveu: On Wed, 21 Dec 2011 10:21:45 -0200, Lamarque V. Souza wrote: You should use the Settings path to get the settings for a connection: I figured that out minutes before I saw your reply :S DBUS Service: org.freedesktop.NetworkManager DBUS Object Path: /org/freedesktop/NetworkManager DBUS Interface: org.freedesktop.NetworkManager This little snippet made me think. Depending which Object you're working with you have different Interfaces available to manipulate the object. I found the Settings object, eventually. Initially I was trying to work with a Devices object. Now that I know this, I went over the example again and did see getConnection was indeed returning a settings path. You should try QtNetworkManager instead of creating your program from scratch: https://projects.kde.org/projects/kdereview/libnm-qt QtNetworkManager make those details transparent. Unfortunately there is not small example of how to use it. I use it in Plasma NetworkManagement, but Plasma NM is a big program. If you want to try take a look at manager.h and connection.h, those probably contain the methods you are looking for. This is great news. The bad news is that I am very new to Qt and C++ so it may be too tricky for me to get started without examples. The functionality I need is the basic set: getting interfaces, IP addresses, default gateway, setting an IP addresses... Not much past that. Do you think you could put together a small example that lists interfaces and sets an IP address on an interface? I added one example of how to list interfaces and retrieve the IP configuration (for static and dhcp). Git pull the repository and look at the examples directory. I still need to create the example for setting a IP address, which is not that simple since with NM you have to create a connection with the IP configuration first. The GObject and Python APIs look so simple :( Well, QtNetworkManager is a working in progress and as so it is not finished yet. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to force NetworkManager to don't add default router (with ifnet plugin on and dhcp)?
Em Monday 19 December 2011, Орлов Сергей Александрович escreveu: When I start network with /etc/init.d/net.wlan0 start it don't add default route. When I start network with /etc/init.d/NetworkManager start with ifnet plugin it add default router How to force NetworkManager to don't add default router (with ifnet plugin on and dhcp)? NetworkManager-0.8.4.0 /etc/conf.d/net -- enable_ipv6_0x444C494E4B5F574952454C455353=false auto_0x444C494E4B5F574952454C455353=true config_0x444C494E4B5F574952454C455353=( dhcp ) dhcp_0x444C494E4B5F574952454C455353=nogateway -- When using the keyfile plugin you need to add something like the lines below to connection file: [ipv4] ignore-auto-routes=true I do not know how to do that with the ifnet plugin. I also never use ifnet since it causes more troubles than good for me. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trying to use the DBus API with QtDBus - does the example work?
___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager 0.9.2.0 issues (possibly user issues :) )
Em Sunday 04 December 2011, Fabio Coatti escreveu: Hi all, I've recently upgraded from nm 0.8.4 to 0.9.2 and I'm experiencing several issues, that I haven't been able to sort out looking around so I'asking for mìsome help/hints here environment: gentoo, kde 4.7.3, networkmanagement 0.8.95 issues that I'm experiencing: - wpa_supplicant.conf file saved with 644 permissions and with password in cleartext. Ideally no passwords or anything else should be saved in that file, but permissions 644 are a big problem. That's strange, Plasma NM (networkmanagement-0.8.95 in Gentoo) saves secrets in kwallet by default to workaround this problem. Secrets should not go to wpa_supplicant.conf unless you check System connection in the edit dialog. - as described here, https://bugs.gentoo.org/show_bug.cgi?id=392409, nm uses his own connection names: in the same situation 0.8.x allowed to enter any name for the connection. Ifnet causes some problems in my Gentoo, so I always disable it. - probably a setup problem, even I can't find where to look: nm-applet is always started: I'm using kde applet so this is a problem for me. Check if file /etc/xdg/autostart/nm-applet.desktop exists, if it exists then remove it. Any hint about how to search? I've some other issues, but having hints for the ones above, maybe I will be able to solve also the others by myself :) Thanks for any answer. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Qt bindings to ModemManager and Networkmanager
Hi Dan Williams, As we discussed during last Desktop Summit we from KDE/Solid are developing Qt bindings to MM and NM, they are almost ready: https://projects.kde.org/projects/kdereview/libmm-qt https://projects.kde.org/projects/kdereview/libnm-qt There are some features missing compared to libnm-glib and some things not tested (wimax, lte). For the most common connection types (wired, wifi, gsm, bluetooth, vpn) the libraries work fine. I asked in kde-core-devel mailing list to move the libraries to kdereview for other KDE developers review the source code. One issue that has come up is the libraries names (libmm-qt.so.0.5.0 and libnm-qt-0.9.0). libmm- qt is very similar to libmm, which has nothing to do with ModemManager. The final goal is to move libmm-qt and libnm-qt to ModemManager and NetworkManager's repositories (like we suggested during Desktop Summit). I want to know if there is any problem if I rename the libraries libQtModemManager.so.0.5.0 and libQtNetworkManager.so.0.9.0. I also would like to know how to proceed to move the bindings to MM and NM's repositories. I would like to have write access to the repositories to fix eventual problems. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Running dispatch scripts before sleeping
Hi, I have received this bug in bugs.kde.org and I think it belongs to NM, not Plasma NM: https://bugs.kde.org/show_bug.cgi?id=286433 What I think is happening is that PowerDevil (KDE's power management widget) triggers the sleep event in UPower, NetworkManager listens for that event and goes to sleep before triggering the dispatch scripts in /etc/NetworkManager/dispatcher.d. That causes some troubles when someone needs to execute something before the connections are deactivated. That problem can happen with any program that triggers UPower's sleep event, so it is not Powerdevil specific. Does NM have any way to execute scripts BEFORE deactivating a connection? As far as I know NM executes the dispatch scripts only after the connection has been deactivated, right? -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting KDE3 NetworkManager to 0.9
Em Monday 10 October 2011, Dan Williams escreveu: On Sat, 2011-10-08 at 14:15 -0400, Robert Xu wrote: Hi all, Given the fact that I am relatively new at this stuff, forgive me if I am asking very noobish questions... I am trying to figure out how to implement the Register/Unregister functions and the SecretAgent interfaces. http://projects.gnome.org/NetworkManager/developers/api/09/ref-migrating.ht ml has more information on the architecture changes in 0.9. One big one is that the session applets (knetworkmanager, nm-applet, etc) no longer store whole connections; they only store secrets. Thus they become secret agents instead of full settings storage services. They no longer need to advertise a D-Bus service. You can also look at how we implemented it in Plasma NM (KDE 4.x): git clone git://anongit.kde.org/networkmanagement (branch nm09) This is our agent backends/NetworkManager/nmdbussecretagent.cpp. - Where would I implement Register/Unregister? When the program starts up/closes down? Yes, whenever the thing that's going to respond to secrets requests (ie, the secret agent) starts up and shuts down. We added a watcher for NetworkManager service, everytime NM appears on DBus the watcher triggers the agent registration. - (what c++ call do I make to do that? ;) Probably the Qt D-Bus bindings, which I think is what the old KDE stuff used. In Qt 4.x you create a QDBusInterface to NM's agent manager service and just call -connection().registerObject(NM_DBUS_PATH_SECRET_AGENT, d-agent, QDBusConnection::ExportAllSlots). d-agent is the pointer to our dbus adaptor object, which is a child of our agent and connects the agent to the system bus. - For SecretAgent interfaces, KNetworkManager has a storage file that handles this stuff. Should this all be depreciated for NM's new handling? Not necessarily; you'd still need to store secrets somewhere, and the storage files are probably as good as any. But you wont' need to store whole connections; just secrets. So at a minimum you'll need to store the secret itself, the key name of the secret (ie 'psk' or 'password' or whatever), and the UUID of the connection the secret is for. In Plasma NM we allows to save secrets in kwallet or in plain text (text files). Kwallet is the default storage. This file implements our storage service: libs/service/secretstorage.cpp. - (again, how do you call the functions in c++? relatively new to dbus calling in c++ ;) Usually with Qt/KDE you'd use the Qt D-Bus bindings to do anything D-Bus related. Unfortunately I don't know much about those, but others on this list (like Will Stephenson and Eckhart Woerner) know the Qt/KDE side of things. Well, I have never programmed with qt3's dbus bindings :-/ I cannot help with this part. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting KDE3 NetworkManager to 0.9
Em Monday 10 October 2011, Robert Xu escreveu: On Mon, Oct 10, 2011 at 20:02, Lamarque V. Souza lamar...@kde.org wrote: You can also look at how we implemented it in Plasma NM (KDE 4.x): git clone git://anongit.kde.org/networkmanagement (branch nm09) This is our agent backends/NetworkManager/nmdbussecretagent.cpp. Oh, thanks for this. I was looking for how KDE4 did it in hopes that I could maybe backport some stuff. We added a watcher for NetworkManager service, everytime NM appears on DBus the watcher triggers the agent registration. So, basically, it just idles in the panel waiting for NM? Yes. The agent's constructor sets up the watcher and afterwards calls the slot reponsable for registering the agent. If NM is running the registration succeeds and that is it. If NM is not running the registration fails, but whenever NM appears on the system bus the slot is called again and it registers the agent. This scheme also works when NM restarts. If you call the registration slot only on knetworkmanager start the agent will stop working when NM restarts. In Qt 4.x you create a QDBusInterface to NM's agent manager service and just call -connection().registerObject(NM_DBUS_PATH_SECRET_AGENT, d-agent, QDBusConnection::ExportAllSlots). d-agent is the pointer to our dbus adaptor object, which is a child of our agent and connects the agent to the system bus. *notes* Well, I have never programmed with qt3's dbus bindings :-/ I cannot help with this part. That's fine, I think I have a much better idea now. Thanks so much! You are welcome. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
