Re: help please!!!

2012-05-14 Thread Jirka Klimes
On Monday 07 of May 2012 19:45:13 Paulina Bórquez wrote:

Please, I need some help. I made a mistake and deleted the network manager 
from mi control panel on the top of mi Ubuntu 8...and I can't find anywhere it 
to replace it in the control panel.
...I'm not very smart in using my pc, but I am an Ubuntu fan !!!
Can somebody help me?
Thanks

You'd beter ask in an Ubuntu forum.
I'm not sure what you mean by control panel. But, if you mean that you removed 
an icon for network-manager-applet (nm-applet) from the system tray, then you 
can display that again by running nm-applet in a terminal:

* start a terminal window
* execute this command: nm-applet

Jirka


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Funny behavior for NM and the KDE plasmoid

2012-05-14 Thread Jirka Klimes
On Wednesday 25 of April 2012 20:38:49 Larry Finger wrote:
 I am running openSUSE 12.1 KDE using Rev 0.9.1.90-4.6.1-x86_64 ov
 NetworkManager, and version 0.9.1+0.9.0-1.6.1-x86_64 of the
 plasmoid-networkmanagement applet. For the most part, any problems that I
 see are the fault of the underlying wireless drivers; however, I do see one
 problem.
 
 In general, the applet shows whatever APs that show up in a
 manually-triggered scan. There is, however, one exception. If I have the
 Connect Automatically box checked for one of the APs, that AP rarely
 shows in the possible connections. The one major exception is when the
 driver is unloaded, and then reloaded, when the connection is started
 nearly instantly. I have not tested the nm-applet to see if it shows the
 same behavior.
 
 Are there any steps that I can take to help show where the problem happens?
 
 Thanks,
 
 Larry

I'm not complely sure what is your complaint about, whether KDE-nm GUI or NM 
core behaviour.

Nonetheless, if you run 'nmcli dev wifi list' you will see what APs NM knows 
about and that should also be available in GUIs.
KDE-nm, AFAIK, displays AP and configured connections mixed.
Connect Automatically has no influence on connection visibility. It only 
instructs NM that the connection can be auto-connected.

Jirka


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


NMIP4Config availability in NetworkManger.DeviceState.ACTIVATED

2012-05-14 Thread Radek Vykydal

Hi,

I am trying to get NMIP4Config object after device becomes
NetworkManager.DeviceState.ACTIVATED but it is not
available immediately. Do I have to poll for it or is there any
event/state I can use?

Thanks,

Radek
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Change the state of iface from disconnected to connected using nmcli

2012-05-14 Thread Jirka Klimes
On Thursday 22 of March 2012 11:10:56 Dan Williams wrote:
 On Sun, 2012-03-18 at 23:43 +0530, Abhijeet Rastogi wrote:
  Hi,
  
  
  This is my first post here. I have tried googling and looking at the
  manpage but no help.
  
  
  We can use
  
  
  $nmcli dev disconnect iface eth0
  
  
  to change the state of eth0 to disconnect. Is there a command to
  change it's state back to connected? I tried looking at the manpage 
  I can't seem to find  any option for that.
 
 At the moment, you need to tell NM to reconnect to something, eg 'nmcli
 con up uuid uuid'.  Disconnect places the device into manual mode
 which requires user action to return to automatic mode.  I suppose we
 can add an 'autoconnect' property to each device, which Disconnect()
 would set to false, but which could be changed via the D-Bus properties
 interface (authenticated of course) back to TRUE.  This property would
 follow the internal 'autoconnect_inhibit' device member variable and the
 NMPolicy would listen for changes to this variable and retrigger an auto
 connection check if it changes back to TRUE.  Patches accepted for that.
 
 Dan


Attached are patches adding 'Autoconnect' property to NMDevice for core NM
and libnm-glib as well.

Jirka
From 4f1ce8b39eb8c722bc57fc853c6b381b90b2294f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?= jkli...@redhat.com
Date: Mon, 14 May 2012 15:32:54 +0200
Subject: [PATCH 1/2] core: add Autoconnect property to NMDevice
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It is bound to autoconnect_inhibit private variable (has opposite meaning).
While 'Autoconnect' is TRUE (default value) the device can automatically
activate a connection. If it is changed to FALSE, the device will not
auto-activate until 'Autoconnect' is TRUE again.
Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property
and schedules auto activation when FALSE-TRUE transition is made.

Signed-off-by: Jiří Klimeš jkli...@redhat.com
---
 introspection/nm-device.xml |6 ++
 src/nm-device.c |   28 +++-
 src/nm-device.h |4 +++-
 src/nm-policy.c |   12 +++-
 4 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
index d12d477..4b155d5 100644
--- a/introspection/nm-device.xml
+++ b/introspection/nm-device.xml
@@ -91,6 +91,12 @@
 Whether or not this device is managed by NetworkManager.
   /tp:docstring
 /property
+property name=Autoconnect type=b access=readwrite
+  tp:docstring
+If TRUE, indicates the device can autoconnect.  If FALSE, a manual intervention is required before the device
+is allowed to autoconnect again, like activating a connection on the device or restarting Networkmanager.
+  /tp:docstring
+/property
 property name=FirmwareMissing type=b access=read
   tp:docstring
 If TRUE, indicates the device is likely missing firmware necessary for
diff --git a/src/nm-device.c b/src/nm-device.c
index 2f69be6..175d044 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -111,6 +111,7 @@ enum {
 	PROP_ACTIVE_CONNECTION,
 	PROP_DEVICE_TYPE,
 	PROP_MANAGED,
+	PROP_AUTOCONNECT,
 	PROP_FIRMWARE_MISSING,
 	PROP_TYPE_DESC,
 	PROP_RFKILL_TYPE,
@@ -3759,6 +3760,9 @@ set_property (GObject *object, guint prop_id,
 	case PROP_MANAGED:
 		priv-managed = g_value_get_boolean (value);
 		break;
+	case PROP_AUTOCONNECT:
+		priv-autoconnect_inhibit = !g_value_get_boolean (value);
+		break;
 	case PROP_FIRMWARE_MISSING:
 		priv-firmware_missing = g_value_get_boolean (value);
 		break;
@@ -3867,6 +3871,9 @@ get_property (GObject *object, guint prop_id,
 	case PROP_MANAGED:
 		g_value_set_boolean (value, priv-managed);
 		break;
+	case PROP_AUTOCONNECT:
+		g_value_set_boolean (value, !priv-autoconnect_inhibit);
+		break;
 	case PROP_FIRMWARE_MISSING:
 		g_value_set_boolean (value, priv-firmware_missing);
 		break;
@@ -4028,6 +4035,14 @@ nm_device_class_init (NMDeviceClass *klass)
 		   G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY));
 
 	g_object_class_install_property
+		(object_class, PROP_AUTOCONNECT,
+		 g_param_spec_boolean (NM_DEVICE_AUTOCONNECT,
+		   Autoconnect,
+		   Autoconnect,
+		   TRUE,
+		   G_PARAM_READWRITE));
+
+	g_object_class_install_property
 		(object_class, PROP_FIRMWARE_MISSING,
 		 g_param_spec_boolean (NM_DEVICE_FIRMWARE_MISSING,
 		   FirmwareMissing,
@@ -4655,7 +4670,6 @@ nm_device_set_dhcp_anycast_address (NMDevice *device, guint8 *addr)
 	}
 }
 
-
 void
 nm_device_clear_autoconnect_inhibit (NMDevice *device)
 {
@@ -4664,3 +4678,15 @@ nm_device_clear_autoconnect_inhibit (NMDevice *device)
 	priv-autoconnect_inhibit = FALSE;
 }
 
+gboolean
+nm_device_get_autoconnect (NMDevice *device)
+{
+	NMDevicePrivate *priv;
+