Re: PATCH/Feature request
On 01/26/2012 01:27 AM, Dan Williams wrote: On Thu, 2012-01-26 at 00:00 +0100, Oncaphillis wrote: On 01/25/2012 09:19 PM, Dan Williams wrote: > On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: >> Hi, >> >> Please find attached a patch against the current git >> which re-enables DHCP/DNS Name transmission including >> domain suffix as an option. >> >> I have a rather dim DSL router with DHCP function >> which doesn't accept any domain specific options >> but allows for the transmission of a full hostname >> via the "send host-name" command. I use the domain name >> to distinguish between my VPN connection and the rest >> of the world. So I used to add the full hostname >> for NetworkManager. Now it chops off the >> domain suffix before transmission. >> >> The attached patch adds a property "dhcp-with-domain" >> to NetworkManager which disables this behaviour when true. >> >> In addition the ifcfg-rh plugin enables this feature >> if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding >> ifcfg-xxx file. > > Just to clarify, you used to set your persistent system hostname to say > "mycomputer.foobar.org" and NM used to send that entire hostname to the > router, correct? Yes -- I was pretty sure that sending a FQDN breaks some rules but it used to work on my router and allows me to give all my home machine my own private domain. > I know we changed it a while ago to only send the > hostname excluding the domain portion. However, I think we should only > strip the hostname when we're using the system hostname. If the user > manually specifies a name in dhclient-.conf or in the connection > settings, then I think we should send exactly what the user entered. Does 'should' mean that it is current behaviour ? That doesn't seem to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg- file doesn't change anything at all. The domain gets chopped of. nm-dhcp-dhclient-util.c doesn't seem to care where the hostname came from and if it has been provided with a valid hostname it filters out any "send host-name" statements in the /etc/dhclient-.conf file. By "should" I meant that it doesn't do that, but we should fix it to do so. Sorry for the ambiguous terminology. > That needs a bit of work though; we need to adjust the NMDhcpClient > class to take two hostnames to the client_start() function, one for the > system hostname and one for the hostname from the > NMSettingIP4Config/NMSettingIP6Config. Then internally > nm-dhcp-dhclient.c would know whether to strip the system hostname (if > the hostname from settings is missing) or to use the configured hostname > verbatim. The original bug for stripping the hostname is rh#694758. And then you still have to decide if you allow the send host-name command to take place with the FQDN or to build your own sequence of fqdn commands (which my router doesn't seem to understand). The end goal here is to update your DDNS entries, right? AFAIK that's what the FQDN option is typically used for. Is that what you'd use the hostname option for as well? It kinda sucks that dhclient doesn't pick which one to use; ie if it had a policy like "if the hostname given ends in a . then it's fully-qualified and we send FQDN" then we wouldn't need to choose between FQDN and hostname. Second, there's the whacky options for FQDN like encoded and server-update which of course we have no idea what to do with and aren't going to expose in any UI. ... and if dhclient would automatically choose the 'right' method it would be totally useless in cases where the dhcp server doesn't understand the FQDN command. In my case it just would have been enough if the nm-dhcp-manager wouldn't overwrite the "send host-name" option from the /etc/dhclient-.conf file. The strategy that one might specify a FQDN in the NetworkManagers configuration and trigger the transfer this way sounds good. Then may be we need an additional option like "SEND_AS_PLAIN_HOSTNAME" where the nm-dhcp-manager can decide if it tells dhclient to use the "send fqdn.fqdn" or the "send host-name" command. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On Thu, 2012-01-26 at 00:00 +0100, Oncaphillis wrote: > On 01/25/2012 09:19 PM, Dan Williams wrote: > > On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: > >> Hi, > >> > >> Please find attached a patch against the current git > >> which re-enables DHCP/DNS Name transmission including > >> domain suffix as an option. > >> > >> I have a rather dim DSL router with DHCP function > >> which doesn't accept any domain specific options > >> but allows for the transmission of a full hostname > >> via the "send host-name" command. I use the domain name > >> to distinguish between my VPN connection and the rest > >> of the world. So I used to add the full hostname > >> for NetworkManager. Now it chops off the > >> domain suffix before transmission. > >> > >>The attached patch adds a property "dhcp-with-domain" > >> to NetworkManager which disables this behaviour when true. > >> > >>In addition the ifcfg-rh plugin enables this feature > >> if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding > >> ifcfg-xxx file. > > > > Just to clarify, you used to set your persistent system hostname to say > > "mycomputer.foobar.org" and NM used to send that entire hostname to the > > router, correct? > >Yes -- I was pretty sure that sending a FQDN breaks some rules but > it used to work on my router and allows me to give all my home > machine my own private domain. > > > I know we changed it a while ago to only send the > > hostname excluding the domain portion. However, I think we should only > > strip the hostname when we're using the system hostname. If the user > > manually specifies a name in dhclient-.conf or in the connection > > settings, then I think we should send exactly what the user entered. > > Does 'should' mean that it is current behaviour ? That doesn't seem > to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg- file > doesn't change anything at all. The domain gets chopped of. > nm-dhcp-dhclient-util.c doesn't seem to care where the hostname came > from and if it has been provided with a valid hostname it filters > out any "send host-name" statements in the /etc/dhclient-.conf > file. By "should" I meant that it doesn't do that, but we should fix it to do so. Sorry for the ambiguous terminology. > > That needs a bit of work though; we need to adjust the NMDhcpClient > > class to take two hostnames to the client_start() function, one for the > > system hostname and one for the hostname from the > > NMSettingIP4Config/NMSettingIP6Config. Then internally > > nm-dhcp-dhclient.c would know whether to strip the system hostname (if > > the hostname from settings is missing) or to use the configured hostname > > verbatim. The original bug for stripping the hostname is rh#694758. > And then you still have to decide if you allow the send host-name > command to take place with the FQDN or to build your own sequence > of fqdn commands (which my router doesn't seem to understand). The end goal here is to update your DDNS entries, right? AFAIK that's what the FQDN option is typically used for. Is that what you'd use the hostname option for as well? It kinda sucks that dhclient doesn't pick which one to use; ie if it had a policy like "if the hostname given ends in a . then it's fully-qualified and we send FQDN" then we wouldn't need to choose between FQDN and hostname. Second, there's the whacky options for FQDN like encoded and server-update which of course we have no idea what to do with and aren't going to expose in any UI. Dan > thanks or the reply > > Sebastian > > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can't enter password to make changes
On Thu, 2012-01-05 at 08:47 -0500, Shawn J. Goff wrote: > I've had this same issue for months now. I filed a bug here: > https://bugzilla.gnome.org/show_bug.cgi?id=667356 . Sorry about that; fixed now in git master. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gnome 3, Network-Manager & ifupdown
On Fri, 2011-12-23 at 00:09 +0100, David BERCOT wrote: > Hello, > > I'm a Debian (sid) user under Gnome 3.2. > > Because I have many places to configure, I use guessnet > in /etc/network/interfaces. Then, I'd like Network-Manager not to think > I'm not connected, so, I've added : > [ifupdown] > managed=true > in /etc/NetworkManager/NetworkManager.conf > > Now, I have two questions : > 1. how can I ask Network-Manager to automatically use the connection > choosen in /etc/network/interfaces ? I'd like not to have to click on > the "Ifupdown (myconnection)"... > 2. when my wired cable is not connected, how can I do a "basic" > configuration ? Maybe it is in /etc/network/interfaces, but I've tried : > iface eth_disconnected inet manual > test missing-cable > and it does not work... I think the answer here is that this is attempting to encode logic into configuration files, which doesn't usually play that well. Yeah, it works if you want to manually manage all this stuff, but in general you want your network configurations separate from the logic like guessnet that's supposed to figure out which one to use. The 'script' parts of /e/n/i don't get executed because there's really no interface there or any way to move information back and forth between the script and what's calling it. The shorter answer is that we'd like something like this in NetworkManager and we've had discussions about it before but haven't had more movement on the issue. Essentially it would be the same thing: a know MAC address and possibly a known IP address to ping and match the response's MAC to the known MAC. Then NM itself would automatically do what guessnet does. NM's ifupdown support is simply for reading the configuration in that file. It doesn't (nor can it) do much of anything with the logic (ie, scripts, tests, etc) because there's really no API there. By which I mean, what is the "test" directive supposed to do? Is that specific to guessnet? If we had native support for guessing wired connections in NM then perhaps we could transparently read the guessnet parameters and use them though. So on to solutions... there may be some way to automate this in the mean time by using the NM D-Bus API or the dispatcher hooks, but I'm not 100% sure they'll replace the functionality that guessnet has. In the end I think we just need to implement it for real in NM (just like we need to implement captive portal login and other stuff that's similar but which guessnet doesn't do) to make this stuff work smoothly. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On 01/25/2012 09:19 PM, Dan Williams wrote: > On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: >> Hi, >> >> Please find attached a patch against the current git >> which re-enables DHCP/DNS Name transmission including >> domain suffix as an option. >> >> I have a rather dim DSL router with DHCP function >> which doesn't accept any domain specific options >> but allows for the transmission of a full hostname >> via the "send host-name" command. I use the domain name >> to distinguish between my VPN connection and the rest >> of the world. So I used to add the full hostname >> for NetworkManager. Now it chops off the >> domain suffix before transmission. >> >>The attached patch adds a property "dhcp-with-domain" >> to NetworkManager which disables this behaviour when true. >> >>In addition the ifcfg-rh plugin enables this feature >> if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding >> ifcfg-xxx file. > > Just to clarify, you used to set your persistent system hostname to say > "mycomputer.foobar.org" and NM used to send that entire hostname to the > router, correct? Yes -- I was pretty sure that sending a FQDN breaks some rules but it used to work on my router and allows me to give all my home machine my own private domain. > I know we changed it a while ago to only send the > hostname excluding the domain portion. However, I think we should only > strip the hostname when we're using the system hostname. If the user > manually specifies a name in dhclient-.conf or in the connection > settings, then I think we should send exactly what the user entered. Does 'should' mean that it is current behaviour ? That doesn't seem to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg- file doesn't change anything at all. The domain gets chopped of. nm-dhcp-dhclient-util.c doesn't seem to care where the hostname came from and if it has been provided with a valid hostname it filters out any "send host-name" statements in the /etc/dhclient-.conf file. > That needs a bit of work though; we need to adjust the NMDhcpClient > class to take two hostnames to the client_start() function, one for the > system hostname and one for the hostname from the > NMSettingIP4Config/NMSettingIP6Config. Then internally > nm-dhcp-dhclient.c would know whether to strip the system hostname (if > the hostname from settings is missing) or to use the configured hostname > verbatim. The original bug for stripping the hostname is rh#694758. And then you still have to decide if you allow the send host-name command to take place with the FQDN or to build your own sequence of fqdn commands (which my router doesn't seem to understand). thanks or the reply Sebastian ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: help please
On Thu, 2012-01-05 at 15:25 +0200, Dr. Amr Osman wrote: > hello > I need to make a small script in bash or python to use dbus to send > receive SMS through Network Manager .. please I need just two example > one for sending and one for receiving i can't find any on google > any help will be apreciated doesn't matter bash or python Sorry for the late response; there is the mm-send-sms.py script here: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/test which should show how to do it. Note that some of the options (smsc, validity) only work with the PDU mode support that I added last week. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Phase 2 in EAP-TLS
On Fri, 2012-01-06 at 10:39 +0800, Gary Ching-Pang Lin wrote: > 2012/1/6 Dan Williams : > > On Thu, 2011-12-29 at 11:27 +0800, Gary Ching-Pang Lin wrote: > >> Hi all, > >> > >> I read the source code of network-manager-applet recently and > >> have some questions about the eap-method-tls.c. > >> > >> In eap-method-tls.c, there are several checks for the variable > >> "phase2" which isn't used in ttls or peap, and the variable is > >> initialized in eap_method_tls_new() and is never changed afterward. > >> However, I found that eap_method_tls_new() is called only in > >> wireless-security.c, and "phase2" is set to FALSE explicitly. > >> In other words, the phase2 functions in eap-method-tls.c were > >> never used. > >> > >> Here are my questions. > >> 1) Why "phase2" is declared but never used? For any further plan > >> or just a legacy of some old code? > > > > It's actually used. The EAPMethod things are lightweight objects but > > don't use GObject, just plain C structures. So what's going on there is > > that phase2 gets passed into eap_method_tls_new() and then that is > > passed to the call to eap_method_init(). The object returned from that > > call is actually the EAPMethodTLS, or "self". Anywhere in that file you > > see EAPMethod/parent that means the EAPMethodTLS->parent, so the phase2 > > passed in here actually shows up as parent->phase2 throughout the file. > > > Thanks for the explanation. What's confusing me is that eap_method_tls_new() > only appears in wireless-security.c besides eap-method-tls.*: > > em_tls = eap_method_tls_new (sec, connection, FALSE, secrets_only); > > The statement assigns FALSE to phase2 explicitly. So even there are checks for > phase2 in eap-method-tls.c, the variable is always FALSE, and the phase2 > checks > become kind of meaningless. It looks like TLS phase2 was coded for but never actually enabled/finished because at the time I think there may have been questions about whether it was really a valid configuration. But I think the phase2 support will never get called, as you suggest. We could enable it though, I'd be happy to take patches to do so since I've had a few questions about it. Dan > > It could be clearer if these were actually GObjects I suppose, since > > that's a standard understandable mechanism, instead of the pseudo-object > > stuff that I wrote here long ago. > > > >> 2) In what condition EAP-TLS will be used as "Phase 2"? > >> I googled related documents but only found the Phase 2 auth > >> methods for PEAP and TTLS. > > > > TTLS-TLS is a valid method: TTLS for the outer tunnel, and TLS for the > > inner tunnel. I've also heard that PEAP-TLS is used though that's a > > pretty pointless setup. Basically, TLS is a valid inner tunnel (ie, > > "phase2" method). > > > Ah, then that makes sense, though TTLS-TLS/PEAP-TLS seems too > complicated for a normal user :-p > > Gary Lin ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Huawei E220 can't connect on Ubuntu 11.10
On Mon, 2012-01-09 at 11:27 +0100, Aleksander Morgado wrote: > Hey Dan, > > >> > >> On Ubuntu 11.10 there is problem with connection via modem Huawei E220. > >> > >> On Ubuntu 11.10 the NetworkManager is in version 0.9.1.90-0ubuntu5.1 > >> On Ubunto 11.04 there is version 0.8.4~git.20110319t175609.d14809b-0ubuntu3 > >> > >> The issue for Ubuntu was submitted: > >> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/868034 > >> > >> I suspect that this problem could be related to NetworkManager. > >> One of the most interesting comment is available at: > >> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/868034/comments/86 > >> > >> Could you please take a look at this bug? > > > > Looks like https://bugzilla.gnome.org/show_bug.cgi?id=662113 to me. > > > > What would be helpful would be to test this with the latest > > NetworkManager, from git head. You'll need libnl3 3.2.3 for that, > > which is not yet in Ubuntu (or to patch the configure.ac file to avoid > > blocking the build for that). There's preliminary packages for libnl3 > > 3.2.3 in the daily builds PPA for NetworkManager for Ubuntu: > > http://launchpad.net/~network-manager/+archive/trunk. You may want to > > test this, which also includes a very recent snapshot from git (from > > the 10th of December). The problem is, these packages are largely > > untested, so no garantees that anything is fixed, or that it doesn't > > break your system. This is further complicated by the fact that > > reverting from libnl3 3.2.3 might not be all that easy, but it's > > definitely possible. > > > > I'm updating the Ubuntu bug report now to add a procedure for testing. > > > > This issue seems to have been tracked up to commit dc89c0. With that > patch on, the modems get rebooted when they start to get commands in the > secondary port. From what I saw in the logs, we do enable unsolicited > messages in the secondary port during modem enable with AT^CURC=1, and > then we also send commands to it (AT+CREG/CGREG=2, to enable unsolicited > registration messages), which is the time when the hang & reboot happens. I did try and reproduce this with my E220 (a Telia branded one with latest E220 firmware) and could not. But the change in question I think was for a modem that turned out not to require it, so we could revert that. We do want unsolicited notifications on the secondary port though, because otherwise we don't get anything useful when the primary port is being used for PPP. One possibility here is that the Windows drivers tag usbif 0 as the "modem" port (ie, to be used for PPP) and the secondary port as the "pcui" port. I think it's actually the "pcui" port that the Windows stuff uses normally, and only turns on usbif 0 when it needs PPP (since usbif 0 has the interrupt endpoint but we don't need that for plain AT commands). I'd done a patch a long time ago to better separate the primary port from the port used for PPP, since right now we assume the primary port should be used for both command&status and PPP, but that may not be the case all the time. Perhaps it's time to dust that patch off so people could at least test this theory out on E220s that see the problem. Also, what firmware version are the problematic modems running? Mine is on 11.117.07.00.07. My E226, which is basically an E220 with Americas 3G bands (850/1900), hasn't had issues so far. Dan > I would suggest to revert that commit until a better solution is found > and ideally make a new stable release. > > Also, did we try to completely avoid sending any command to the > secondary port once unsolicited messages were enabled on it? I can try > to hack such behaviour and then ask bug reporters to test it. > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: How to generate "Auto eth0" from command line ?
On Tue, 2012-01-17 at 14:58 +, ning ji wrote: > Hi Mathieu, > > Thanks for the "uuidgen". > > Regarding no "Auto eth0" initially, > my task is to make it work in embedded board, so there's no GUI. > > step 1: I tried from scratch, no "Auto eth0", it's in DHCP mode, it > works. > Then from GUI i set it to static ip. It generates "auto eth0". I keep > this file in another place call it "mycfg.static". > Then move back to DHCP from GUI, then remove > the /etc/NetworkManager/Auto eth0. > > step 2: After reboot, the system is in a fresh new state, no "Auto > eth0". > copy "mycfg.static" to /etc/NetworkManager/Auto eth0. > > step 3: from "network configurations" i saw 2 interfaces, somehow it > takes a default somewhere again. > > > So my question is, can i switch from dhcp to static without GUI, as > this is our requirement ? There are some Python examples in NetworkManager git if you want to use the D-Bus control interface. Alternatively, it's certainly possible to simply generate connection files and move them around as you see fit. When you move a connection file out of /etc/NetworkManager/system-connections NM should tear down the connection, and dropping a new file in there should make NM connect it as long as autoconnect=true in that file in the [connection] section. For the dbus interface, you'd grab the connection settings (I'd just store the UUID and request the connection via its UUID), make the changes to the settings, call the connection's Update method with the new settings, and (optionally) tell NM to activate the connection again to apply the new settings you just wrote. http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C/glib If can describe in a bit more detail what you'd like to do I can point you more closely in the right direction. Dan > > Thanks very much ! > > > > > > > Date: Mon, 16 Jan 2012 23:28:58 +0100 > > Subject: Re: How to generate "Auto eth0" from command line ? > > From: mathieu...@gmail.com > > To: nin...@hotmail.com > > > > On Sat, Jan 14, 2012 at 11:16 PM, ning ji > wrote: > > > Hi i'm new to NetworkManager. > > > > > > In ubuntu 10.4, if i remember this correctly, by default, > > > there's NO "Auto Eth0" under /etc/NetworkManager/... > > > > > > If in the menu i edit eth0 to use static ip, there'll be a "Auto > Eth0“ file. > > > > > > 1. My question is how to generate this file from command line ? > > > > > > 2. How to generate uuid for eth0, heard there's a "blkid" command, > > > but /dev/eth0 is not available in linux ? > > > > There already should be one -- but it won't show in > > /etc/NetworkManager, because it's automatically created by NM when > > used. In other words, make sure nm-applet is running, then plug in a > > cable and things should just work. > > > > In 10.04, you might be able to use cnetworkmanager (from the > > cnetworkmanager package) to do this. > > > > As for your question about UUIDs, try 'uuidgen -r'. > > > > Mathieu Trudel-Lapierre > > Freenode: cyphermox, Jabber: mathieu...@gmail.com > > 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange behaviour on wireless connection
On Fri, 2012-01-20 at 12:38 +0100, Arend van Spriel wrote: > In my wireless test setup I use nmcli. I get a number of warnings. I am > wondering why a "Get" is done for 'Vpn' property. This is a wireless > connection so it is probably expected to fail. Any hints are welcome. > > Gr. AvS > > --- > $ nmcli con up id smoke-net > > ** (process:22937): WARNING **: fetch_connections_done: error fetching > user connections: (2) The name > org.freedesktop.NetworkManagerUserSettings was not provided by any > .service files. This is normal if you're not running nm-applet or the KDE workspace network management stuff. > ** (process:22937): WARNING **: Error in getting active connection 'Vpn' > property: (19) Method "Get" with signature "ss" on interface > "org.freedesktop.DBus.Properties" doesn't exist I think this is fixed about a year ago (in NM 0.8.4 and later); it's really the client libs asking whether this ActiveConnection is a VPN or not, and the Vpn property is what indicates that. Can you run the following command when you see this, replacing the object path with the one from the error? dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/ActiveConnection/X org.freedesktop.DBus.Properties.GetAll string:"org.freedesktop.NetworkManager.Connection.Active" ie, replace the X with '9' here and tell me what you find. Dan > > ** (process:22937): WARNING **: _nm_object_array_demarshal: couldn't > create object for /org/freedesktop/NetworkManager/ActiveConnection/9 > > ** (process:22937): WARNING **: Error in getting active connection 'Vpn' > property: (19) Method "Get" with signature "ss" on interface > "org.freedesktop.DBus.Properties" doesn't exist > > > ** (process:22937): WARNING **: _nm_object_array_demarshal: couldn't > create object for /org/freedesktop/NetworkManager/ActiveConnection/9 > > ** (process:22937): WARNING **: Error in getting active connection 'Vpn' > property: (19) Method "Get" with signature "ss" on interface > "org.freedesktop.DBus.Properties" doesn't exist > > > ** (process:22937): WARNING **: _nm_object_array_demarshal: couldn't > create object for /org/freedesktop/NetworkManager/ActiveConnection/9 > Error: Obtaining active connection for > '/org/freedesktop/NetworkManager/ActiveConnection/9' failed. > > -- > $ nmcli con > smoke-net 82f56905-c5c3-4302-90c5-5b8851e0f797 802-11-wireless system never > > -- > udev events > > KERNEL[1327059014.034431] add /module/brcmfmac (module) > UDEV [1327059014.034751] add /module/brcmfmac (module) > KERNEL[1327059014.696434] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/firmware/mmc0:0001:2 > (firmware) > KERNEL[1327059014.698181] remove > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/firmware/mmc0:0001:2 > (firmware) > UDEV [1327059014.698292] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/firmware/mmc0:0001:2 > (firmware) > KERNEL[1327059014.698375] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0 > (ieee80211) > UDEV [1327059014.698890] remove > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/firmware/mmc0:0001:2 > (firmware) > KERNEL[1327059014.699039] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0/rfkill13 > (rfkill) > UDEV [1327059014.699085] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0 > (ieee80211) > KERNEL[1327059014.699178] change > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0/rfkill13 > (rfkill) > KERNEL[1327059014.699395] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/net/wlan0 > (net) > KERNEL[1327059014.699564] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/net/wlan0/queues/rx-0 > (queues) > KERNEL[1327059014.699700] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/net/wlan0/queues/tx-0 > (queues) > UDEV [1327059014.700011] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0/rfkill13 > (rfkill) > UDEV [1327059014.700760] change > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/ieee80211/phy0/rfkill13 > (rfkill) > KERNEL[1327059014.701852] add /bus/sdio/drivers/brcmfmac (drivers) > UDEV [1327059014.702297] add /bus/sdio/drivers/brcmfmac (drivers) > KERNEL[1327059014.709310] move > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/net/wlan1 > (net) > UDEV [1327059014.770649] add > /devices/pci:00/:00:1c.2/:04:00.1/mmc_host/mmc0/mmc0:000
Re: how to get 3g modem back in managed state
On Fri, 2011-12-30 at 11:46 +0100, Eduard Hasenleithner wrote: > 2011/12/30 José Queiroz : > > Try to SIGTERM modem-manager. > > > > sudo killall -TERM modem-manager > > This does not work for me. Is there no way to tell network-manager to > manage a particular device again while keeping nm (and mm) running? We need a bit more information here. Does the device actually disappear from the USB bus (ie, it crashes)? When this happens check with lsusb to see if it's still there or not. If it is still there, we'll need some more detailed logs from ModemManager. I did notice that disconnecting the device failed, so it would be good to figure out why that happened. ie this line specifically from the logs: Dec 29 18:17:28 eeepc modem-manager[519]: Modem /org/freedesktop/ModemManager/Modems/0: state changed (disconnecting -> connected) indicates that MM was not able to tell the modem to terminate the packet connection successfully, and thus it has no choice but to assume you're still connected. A detailed MM debug log would indicate which command is failing there. See: http://live.gnome.org/NetworkManager/Debugging for how to get that log. > btw, is there a utility which allows to show all devices managed by > network manager, and their state (over dbus)? nm-tool or "nmcli dev" Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 6/7] time: Poll for timezone
On Fri, 2012-01-20 at 15:21 -0500, Thomas Tuttle wrote:
> Signed-off-by: Thomas Tuttle
> ---
> src/mm-modem-base.c | 88
> +++
> src/mm-modem-base.h |3 ++
> src/mm-modem-time.c | 15 +
> src/mm-modem-time.h |8 +
> 4 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/src/mm-modem-base.c b/src/mm-modem-base.c
> index e50e13f..dd1420e 100644
> --- a/src/mm-modem-base.c
> +++ b/src/mm-modem-base.c
> @@ -80,6 +80,9 @@ typedef struct {
> GHashTable *ports;
>
> GHashTable *tz_data;
> +gboolean tz_poll_running;
Do we really need tz_poll_running? As long as tz_poll_source is cleared
to zero when the poll is stopped, you could just check for
(tz_poll_source > 0) to find out if the poll is running instead. Also,
could we rename that to tz_poll_id instead? _source (at least to me)
implies that it's a GSource which is slightly lower-level mechanism for
adding timeout/idle handlers (ie with g_timeout_source_new()) that's
overkill for this application.
Dan
> +guint tz_poll_source;
> +guint tz_poll_count;
> } MMModemBasePrivate;
>
>
> @@ -503,6 +506,80 @@ value_destroy (gpointer data)
> g_slice_free (GValue, v);
> }
>
> +static void
> +timezone_poll_done (MMModem *modem, GError *error, gpointer user_data)
> +{
> +/* do nothing; modem will call mm_modem_base_set_network_timezone if
> + it has timezone data, and then we will stop nagging it. */
> +}
> +
> +static gboolean
> +timezone_poll_callback (gpointer data)
> +{
> +MMModemBase *self = (MMModemBase *) data;
> +MMModemBasePrivate *priv = MM_MODEM_BASE_GET_PRIVATE (self);
> +gboolean result;
> +
> +if (priv->tz_poll_count == 0)
> +goto stop_polling;
> +
> +priv->tz_poll_count--;
> +result = mm_modem_time_poll_network_timezone (MM_MODEM_TIME (self),
> + timezone_poll_done,
> + NULL);
> +if (!result)
> +goto stop_polling;
> +
> +return TRUE;
> +
> +stop_polling:
> +mm_modem_base_set_network_timezone (self, NULL, NULL, NULL);
> +return FALSE;
> +}
> +
> +#define TIMEZONE_POLL_INTERVAL_SEC 5
> +#define TIMEZONE_POLL_RETRIES 6
> +
> +void
> +mm_modem_base_set_network_timezone_polling (MMModemBase *self,
> +gboolean should_poll)
> +{
> +MMModemBasePrivate *priv;
> +
> +g_return_if_fail (self != NULL);
> +g_return_if_fail (MM_IS_MODEM_BASE (self));
> +
> +priv = MM_MODEM_BASE_GET_PRIVATE (self);
> +
> +if (should_poll == priv->tz_poll_running)
> +return;
> +
> +if (should_poll) {
> +priv->tz_poll_count = TIMEZONE_POLL_RETRIES;
> +priv->tz_poll_source = g_timeout_add_seconds
> (TIMEZONE_POLL_INTERVAL_SEC,
> + timezone_poll_callback,
> + self);
> +} else
> +g_source_remove (priv->tz_poll_source);
> +
> +priv->tz_poll_running = should_poll;
> +}
> +
> +static void
> +modem_state_changed (MMModemBase *self, GParamSpec *pspec, gpointer
> user_data)
> +{
> +MMModemState state;
> +gboolean registered;
> +
> +state = mm_modem_get_state (MM_MODEM (self));
> +registered = (state >= MM_MODEM_STATE_REGISTERED);
> +
> +mm_modem_base_set_network_timezone_polling (self, registered);
> +
> +if (!registered)
> +mm_modem_base_set_network_timezone (self, NULL, NULL, NULL);
> +}
> +
> void
> mm_modem_base_set_network_timezone (MMModemBase *self, gint *offset,
> gint *dst_offset, gint *leap_seconds)
> @@ -530,6 +607,8 @@ mm_modem_base_set_network_timezone (MMModemBase *self,
> gint *offset,
> g_hash_table_remove (priv->tz_data, "leap_seconds");
>
> g_object_notify (G_OBJECT (self), MM_MODEM_TIME_NETWORK_TIMEZONE);
> +
> +mm_modem_base_set_network_timezone_polling (self, FALSE);
> }
>
> /*/
> @@ -782,6 +861,7 @@ mm_modem_base_init (MMModemBase *self)
>
> priv->ports = g_hash_table_new_full (g_str_hash, g_str_equal, g_free,
> g_object_unref);
> priv->tz_data = g_hash_table_new_full (g_str_hash, g_str_equal, NULL,
> value_destroy);
> +priv->tz_poll_running = FALSE;
>
> mm_properties_changed_signal_register_property (G_OBJECT (self),
> MM_MODEM_ENABLED,
> @@ -815,6 +895,11 @@ mm_modem_base_init (MMModemBase *self)
>
> MM_MODEM_TIME_NETWORK_TIMEZONE,
> NULL,
>
> MM_DBUS_INTERFACE_MODEM_TIME);
> +
> +g_signal_connect (self,
> + "notify::" MM_MODEM_STATE,
> +
Re: NetworkManager 0.8.6 doesn't reply to ActivateConnection
On Mon, 2012-01-23 at 15:27 -0600, Dan Williams wrote: > On Thu, 2012-01-19 at 19:35 +, David Röthlisberger wrote: > > We are using NetworkManager 0.8.6 on a device without the official NM > > applet, > > so we do all communication with NM over DBus ourselves. If there is no > > entry in > > the system-connections directory *and* no "no-auto-default" entry in > > NetworkManager.conf, then NetworkManager doesn't reply to the method call > > org.freedesktop.NetworkManager.ActivateConnection. > > > > NM *does* receive the method call and does apply the configuration, but > > simply > > doesn't reply; the caller eventually gets a DBus timeout. > > > > After this first call (which times out), NM has created its configuration > > file > > in system-connections, and the next call works correctly. > > > > I can consistently reproduce this behaviour by: > > * killing NM, > > * removing any "no-auto-default" entry in NetworkManager.conf, > > * removing everything in the system-connections directory; then > > * starting NM > > * and sending NM a series of method calls culminating in > > ActivateConnection. > > I can reproduce this with a small python program. Clearly a bug, fixing > it now. The issue here is that, because it was simpler, the "default wired connection" actually changes it's object path when it's updated. Basically, it gets written out by the first plugin that can save connections, and then the plugin creates a completely new connection object for it because the plugin had no knowledge of the default wired connection before. Thus it gets a new object path. Then, when you call ActivateConnection with the old object path, NM waits around for the connection to show up, but it never does because it's actually gone. But it's a bug that NM doesn't time that out and return an error. But that would actually be unhelpful anyway. So the real solution here is to explore how the default wired connection can retain it's old object path when it gets reported by the settings plugin that wrote it to disk. Unfortunately that's not simple because we've tried to keep the objects fairly well encapsulated from each other internally. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disconnect a WiFi accespoint using cNetworkManager Python library
On Fri, 2012-01-20 at 12:52 +0100, Olivier Deckmyn wrote:
> Hi,
>
>
> I’m building an Python application that has to connect and disconnect
> from Wifi on linux box. It's my very first experience with d-bus and
> gobject.
>
>
> I’m using NetworkManager layer, through the nice networkmanager lib
> found in cnetworkmanager
> (http://vidner.net/martin/software/cnetworkmanager/ thanx to Martin
> Vidner), in my daemon (named stationd).
I think the issue here is that you're trying to register two User
Settings services. There should be only one and it should be global to
your python program. ie in /home/biopredictive/station/lib/network.py
at line 88 is the problem; that object should only be created once (it
should really be a global object) but it looks like the call to connect
creates one each time. Since the object didn't get destroyed when the
first connect completed (and it shouldn't really be) you get the
dbus-python error.
Dan
>
> This daemon runs a gobject.MainLoop. Once a timeout_add_seconds awake
> (triggers by an action of user in GUI), I have to disconnect current
> running Wifi and connect to a new one:
>
>
> from dbus.mainloop.glib import DBusGMainLoop
> DBusGMainLoop(set_as_default=True)
>
>
> from networkmanager import NetworkManager
> import networkmanager.applet.settings as settings
> from networkmanager.applet import USER_SERVICE
> from networkmanager.applet.service import
> NetworkManagerUserSettings, NetworkManagerSettings
> import time
> import memcache
>
>
> import gobject
> loop = gobject.MainLoop()
>
>
> nm = NetworkManager()
>
>
> dummy_handler = lambda *args: None
>
>
> cache = memcache.Client(['127.0.0.1:11211',] )
>
>
>
>
> def get_device(dev_spec, hint):
> candidates = []
> devs = NetworkManager().GetDevices()
> for dev in devs:
> if dev._settings_type() == hint:
> candidates.append(dev)
> if len(candidates) == 1:
> return candidates[0]
> for dev in devs:
> if dev["Interface"] == dev_spec:
> return dev
> print "Device '%s' not found" % dev_spec
> return None
>
>
> def kill_allconnections():
> connections=nm['ActiveConnections']
> for c in connections:
> print c.object_path
> nm.DeactivateConnection(c.object_path)
>
>
> class Wifi(object):
>
> def connect(self, ssid, security="open", password=None):
> "Connects to given Wifi network"
> c=None # connection settings
> us = NetworkManagerUserSettings([])
> if security=="open":
> c = settings.WiFi(ssid)
> elif security=="wep":
> c = settings.Wep(ssid, password)
> elif security=="wpa":
> c = settings.WpaPsk(ssid, password)
> else:
> raise AttributeError("invalid security model '%s'"%
> security)
> svc = USER_SERVICE
> svc_conn = us.addCon(c.conmap)
> hint = svc_conn.settings["connection"]["type"]
> dev = get_device("", hint)
> appath = "/"
> nm.ActivateConnection(svc, svc_conn, dev, appath,
> reply_handler=dummy_handler, error_handler=dummy_handler)
>
>
>
>
> def change_network_settings():
> key="station:network:change"
> change=cache.get(key)
> if change is not None:
> print "DISCONNECT"
> kill_allconnections()
> print "CHANGE SETTINGS"
> wifi=cache.get(key+':wifi')
> if wifi is not None:
> ssid=cache.get(key+':wifi:ssid')
> security=cache.get(key+':wifi:security')
> password=cache.get(key+':wifi:password')
> print "SWITCHING TO %s"%ssid
> Wifi().connect(ssid, security, password)
> cache.delete(key)
> return True
>
>
> def mainloop():
>gobject.timeout_add_seconds(1, change_network_settings)
>try:
> loop.run()
>except KeyboardInterrupt:
> loop.quit()
>
>
> if __name__=="__main__":
> mainloop()
>
>
> This runs perfectly for a first connection (read : the box is not
> connected, daemon is ran and box connects flawlessly to Wifi). Issue
> is when I try to connect to another Wifi : kill_allconnections() is
> ran silently, and connect method raises an exception on
> nm.ActivateConnection:
>
>
> Traceback (most recent call last):
> File "stationd.py", line 40, in change_network_settings
> Wifi().connect(ssid, security, password)
> File "/home/biopredictive/station/lib/network.py", line 88, in
> connect
> us = NetworkManagerUserSettings([])
> File
> "/home/biopredictive/station/lib/networkmanager/applet/service/__init__.py",
> line 71, in __init__
> sup
Re: Problem whit applet network manager 0.8.1
On Sat, 2012-01-21 at 19:13 -0500, fbergeron wrote: > I have applet network manager 0.8.1 whit my new Dell Vostro 1440 > notebook whit UBUNTU 10.10 install on my notebook. The problem is that I > cant have a connection faster than 1Mb/s and whit older notebook I have > 68Mb/s generally. What can I do for that ? I am a reel beginner's whit > Linux, so be very "step by step" if I have to do something on a > terminal. Is this with the WiFi or the wired connection? There are two possibilities really; (1) 0.8.1 cannot handle reading the bitrate on higher speed wifi connections (ie, 802.11N bitrates) due to kernel limitations, but this is fixed in NM 0.9 development builds. Second is that the wifi driver has a bug where it either cannot transmit at the higher bitrates, or it does not report them correctly. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SMS Functions
On Wed, 2012-01-25 at 21:20 +0200, Dr. Amr Osman wrote: > when sms send/receive will be available to network manager > till now only partial sms send is functional > and only support some modems ??? I committed code last week to use PDU mode on modems that don't support text mode, and I expect to flip all PDU-capable modems to use this code in the future. The SMS functionality wont' be available to *NetworkManager*, but is in ModemManager like the rest of the 3G functionality. I'd appreciate testing of the SMS sending code that's now in ModemManager 0.5.x and git master if you can. One thing that's not done yet is multi-part messages, something we'll work on. Current the code will return an error if it can't pack the message into a single SMS. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: > Hi, > > Please find attached a patch against the current git > which re-enables DHCP/DNS Name transmission including > domain suffix as an option. > > I have a rather dim DSL router with DHCP function > which doesn't accept any domain specific options > but allows for the transmission of a full hostname > via the "send host-name" command. I use the domain name > to distinguish between my VPN connection and the rest > of the world. So I used to add the full hostname > for NetworkManager. Now it chops off the > domain suffix before transmission. > > The attached patch adds a property "dhcp-with-domain" > to NetworkManager which disables this behaviour when true. > > In addition the ifcfg-rh plugin enables this feature > if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding > ifcfg-xxx file. Just to clarify, you used to set your persistent system hostname to say "mycomputer.foobar.org" and NM used to send that entire hostname to the router, correct? I know we changed it a while ago to only send the hostname excluding the domain portion. However, I think we should only strip the hostname when we're using the system hostname. If the user manually specifies a name in dhclient-.conf or in the connection settings, then I think we should send exactly what the user entered. That needs a bit of work though; we need to adjust the NMDhcpClient class to take two hostnames to the client_start() function, one for the system hostname and one for the hostname from the NMSettingIP4Config/NMSettingIP6Config. Then internally nm-dhcp-dhclient.c would know whether to strip the system hostname (if the hostname from settings is missing) or to use the configured hostname verbatim. The original bug for stripping the hostname is rh#694758. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
SMS Functions
when sms send/receive will be available to network manager till now only partial sms send is functional and only support some modems ??? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using different hostnames on different interfaces (with dhclient)
On Tue, 2012-01-24 at 11:25 +0200, Stefan Puiu wrote:
> Hi and thanks for the reply.
>
> On Mon, Jan 23, 2012 at 10:48 PM, Dan Williams wrote:
> >> I'm using Ubuntu 11.04 at work and I have 2 NICs, each connected to a
> >> separate subnet. Only one of the subnets is accessible when I VPN to
> >> work, so I thought it would be cool to be able to use different
> >> hostnames for each interface. I tried the following in
> >> /etc/dhcp/dhclient.conf:
> >>
> >> interface "eth4" {
> >>send host-name "host2";
> >> }
> >>
> >> interface "eth5" {
> >>send host-name "host1";
> >> }
> >
> > At the moment NM allows the dhclient hostname to be specified in two
> > ways:
> >
> > 1) via the NM connection configuration
> > 2) via an interface-specific dhclient config file
> > like /etc/dhcp/dhclient-.conf
> >
> > So we could add support for the combined dhclient I suppose, making sure
> > to only use stuff for the right interface. It's just not implemented at
> > this time. If you split the config out into separate per-interface
> > config files in the same location, it should work.
>
> I tried the following:
> $ cat /etc/dhcp/dhclient-eth4.conf
>
> send host-name "host2";
>
> $ cat /etc/dhcp/dhclient-eth5.conf
> send host-name "host1";
>
> However, I still get the IP from eth4 mapped to host1.
>
> In /var/run/nm-dhclient-eth4.conf I see:
>
> send host-name "host1"; # added by NetworkManager
>
> While nm-dhclient-eth5.conf doesn't have any "send host-name" directive.
>
> What would option 1 involve?
So it looks like NM will use the system hostname if the connection
doesn't provide one (ie, option #1), overriding the send-hostname from
the config file. Which kinda sucks, I wasn't expecting that, but due
some internal architecture we can't distinguish between the system
hostname and the one from the connection config when DHCP is being
started. That's fixable though and we should do it; the goal is for
options in the dhclient config files to override the system hostname
(but not configuration hostname as specified below).
For option 1, if your connection is specified using keyfiles (ie, it's
in /etc/NetworkManager/system-connections you can add
"dhcp-send-hostname=" key to the [ipv4] block and that
should work.
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: please this issue
On Tue, 2012-01-24 at 15:59 +0530, Ashutosh Kumar wrote: > http://www.linuxquestions.org/questions/showthread.php?p=4581166#post4581166 I'm pretty sure this is a core kernel issue and nothing to do with wifi or NetworkManager, so your best bet is the kernel ACPI mailing list: http://vger.kernel.org/vger-lists.html#linux-acpi Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: add missing device state reasons
On Wed, 2012-01-11 at 22:26 +0100, Thomas Bechtold wrote: > Some NMDeviceStateReason 's are not available in > introspection/nm-device.xml Pushed to git master, thanks! Dan > Tom > > > --- > introspection/nm-device.xml | 20 > 1 files changed, 20 insertions(+), 0 deletions(-) > > diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml > index 5fdda96..2f3aa8f 100644 > --- a/introspection/nm-device.xml > +++ b/introspection/nm-device.xml > @@ -476,6 +476,26 @@ >The Bluetooth connection timed out or failed. > > > + > + > + GSM Modem's SIM Card not inserted. > + > + > + > + > + GSM Modem's SIM Pin required. > + > + > + > + > + GSM Modem's SIM Puk required. > + > + > + > + > + GSM Modem's SIM wrong > + > + > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/2] bonding: Export path of master device property over DBUS
On Wed, 2012-01-11 at 10:45 +0100, Thomas Graf wrote:
> Adds a new "master" property to NMActiveConnection containing the path
> of the master NMDevice if the connection has a master.
Both these pushed to git master, thanks.
Dan
> Signed-off-by: Thomas Graf
> ---
> introspection/nm-active-connection.xml |3 ++
> libnm-glib/libnm-glib.ver|1 +
> libnm-glib/nm-active-connection.c| 47
> ++
> libnm-glib/nm-active-connection.h|2 +
> src/nm-activation-request.c |7 -
> src/nm-active-connection.c | 10 ++-
> src/nm-active-connection.h |4 ++-
> src/nm-device.c | 14 +
> src/nm-device.h |1 +
> src/vpn-manager/nm-vpn-connection-base.c |6 +++-
> 10 files changed, 91 insertions(+), 4 deletions(-)
>
> diff --git a/introspection/nm-active-connection.xml
> b/introspection/nm-active-connection.xml
> index a150b2c..710e0e1 100644
> --- a/introspection/nm-active-connection.xml
> +++ b/introspection/nm-active-connection.xml
> @@ -37,6 +37,9 @@
>
>Whether this active connection is also a VPN
> connection.
>
> +
> + The path to the master device if the connection is a
> slave.
> +
>
>
>
> diff --git a/libnm-glib/libnm-glib.ver b/libnm-glib/libnm-glib.ver
> index 9c2baf6..77bcd05 100644
> --- a/libnm-glib/libnm-glib.ver
> +++ b/libnm-glib/libnm-glib.ver
> @@ -23,6 +23,7 @@ global:
> nm_active_connection_get_default6;
> nm_active_connection_get_default;
> nm_active_connection_get_devices;
> + nm_active_connection_get_master;
> nm_active_connection_get_specific_object;
> nm_active_connection_get_state;
> nm_active_connection_get_type;
> diff --git a/libnm-glib/nm-active-connection.c
> b/libnm-glib/nm-active-connection.c
> index 7dc1c2d..ddde4cc 100644
> --- a/libnm-glib/nm-active-connection.c
> +++ b/libnm-glib/nm-active-connection.c
> @@ -50,6 +50,7 @@ typedef struct {
> NMActiveConnectionState state;
> gboolean is_default;
> gboolean is_default6;
> + char *master;
> } NMActiveConnectionPrivate;
>
> enum {
> @@ -61,6 +62,7 @@ enum {
> PROP_STATE,
> PROP_DEFAULT,
> PROP_DEFAULT6,
> + PROP_MASTER,
>
> LAST_PROP
> };
> @@ -72,6 +74,7 @@ enum {
> #define DBUS_PROP_STATE "State"
> #define DBUS_PROP_DEFAULT "Default"
> #define DBUS_PROP_DEFAULT6 "Default6"
> +#define DBUS_PROP_MASTER "Master"
>
> /**
> * nm_active_connection_new:
> @@ -290,6 +293,33 @@ nm_active_connection_get_default6 (NMActiveConnection
> *connection)
> return priv->is_default6;
> }
>
> +/**
> + * nm_active_connection_get_master:
> + * @connection: a #NMActiveConnection
> + *
> + * Gets the path to the master #NMDevice of the connection.
> + *
> + * Returns: the path of the master #NMDevice of the #NMActiveConnection.
> + * This is the internal string used by the connection, and must not be
> modified.
> + **/
> +const char *
> +nm_active_connection_get_master (NMActiveConnection *connection)
> +{
> + NMActiveConnectionPrivate *priv;
> +
> + g_return_val_if_fail (NM_IS_ACTIVE_CONNECTION (connection), NULL);
> +
> + priv = NM_ACTIVE_CONNECTION_GET_PRIVATE (connection);
> + if (!priv->master) {
> + priv->master = _nm_object_get_string_property (NM_OBJECT
> (connection),
> +
> NM_DBUS_INTERFACE_ACTIVE_CONNECTION,
> +DBUS_PROP_MASTER,
> +NULL);
> + }
> +
> + return priv->master;
> +}
> +
> static void
> nm_active_connection_init (NMActiveConnection *ap)
> {
> @@ -324,6 +354,7 @@ finalize (GObject *object)
> g_free (priv->connection);
> g_free (priv->uuid);
> g_free (priv->specific_object);
> + g_free (priv->master);
>
> G_OBJECT_CLASS (nm_active_connection_parent_class)->finalize (object);
> }
> @@ -355,6 +386,9 @@ get_property (GObject *object,
> case PROP_DEFAULT6:
> g_value_set_boolean (value, nm_active_connection_get_default6
> (self));
> break;
> + case PROP_MASTER:
> + g_value_set_string (value, nm_active_connection_get_master
> (self));
> + break;
> default:
> G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
> break;
> @@ -514,4 +548,17 @@ nm_active_connection_class_init (NMActiveConnectionClass
> *ap_class)
> "Is the default IPv6
> active connection",
> FALSE,
> G_PARAM_READABLE));
> +
> + /**
> + * NMActiveConnection:master:
> + *
> + * The
Re: Disconnect WiFi using cNetworkManager Python library
On Mon, 2012-01-23 at 15:48 +0100, Olivier Deckmyn wrote: > Hi, > > > I’m building an Python application that has to connect and disconnect > from Wifi on linux box. It's my very first experience with d-bus and > gobject. > > > I’m using NetworkManager layer, through the nice networkmanager lib > found in cnetworkmanager > (http://vidner.net/martin/software/cnetworkmanager/ thanx to Martin > Vidner), in my daemon (named stationd). Don't know if something has changed, but last time I was looking at the cnetworkmanager code it was using the old NM API (version 0.7 I think). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
