Re:Can't create new wireless network in NetworkManager Applet 0.8 - SOLVED
I guess NetworkManager has to be able to deal with dummies like me. Turns out that I need to fill in all the required fields with the minimum number of required characters before the "Create" or "Apply" buttons become active. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS Device - T Mobile Web And Walk
Hi, Am Freitag, 20. Mai 2011, 15:27:33 schrieb Aleksander Morgado: > On Fri, 2011-05-20 at 14:59 +0200, Harald Jung wrote: > > May 20 14:41:21 ThinClient modem-manager[3764]: > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT > > +CPMS="ME","ME","ME"' > I have removed the CPMS setting from the source code, I don't need any sms support and the AT command caused the modem device to hang. After submitting this command to the device, it isn't possible to communicate via the tty port anymore. After that i was running into the next problem, it seems that the device is blocked by modem-managers frequent status request. So pppd doesn't come up: May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): --> 'AT$QCPDPP=2,0' May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): <-- 'OK' May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): --> 'AT_OWANCALL=2,0,1' May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): <-- 'OK' May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): --> 'AT_OWANCALL=2,1,1' May 23 18:34:54 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): <-- 'OK' May 23 18:34:55 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): <-- '_OWANCALL: 2, 1' May 23 18:34:55 ThinClient modem-manager[2228]: [mm-port.c:181] mm_port_set_connected(): (ttyHS0): port now connected May 23 18:34:55 ThinClient modem-manager[2228]: [mm-modem.c:761] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected) May 23 18:34:55 ThinClient modem-manager[2228]: [mm-generic- gsm.c:4739] simple_state_machine(): (ttyHS0): simple connect state 6 May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) scheduled... May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) starting... May 23 18:34:55 ThinClient NetworkManager[2216]: (ttyHS0): device state change: prepare -> config (reason 'none') [40 50 0] May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) successful. May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) scheduled. May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) complete. May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) started... May 23 18:34:55 ThinClient NetworkManager[2216]: (ttyHS0): device state change: config -> ip-config (reason 'none') [50 70 0] May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) complete. May 23 18:34:55 ThinClient NetworkManager[2216]: retrieving IP4 configuration failed: (32) Sending command failed: device is connected May 23 18:34:55 ThinClient NetworkManager[2216]: (ttyHS0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] May 23 18:34:55 ThinClient NetworkManager[2216]: Activation (ttyHS0) failed. May 23 18:34:55 ThinClient NetworkManager[2216]: (ttyHS0): device state change: failed -> disconnected (reason 'none') [120 30 0] May 23 18:34:55 ThinClient NetworkManager[2216]: (ttyHS0): deactivating device (reason: 0). I see frequent requests in the modem log, on both tty Ports: May 23 18:35:21 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): --> 'AT_OWCTI?' May 23 18:35:21 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS0): <-- '_OWCTI: 1OK' May 23 18:35:37 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS1): <-- '_OSIGQ: 9,0' May 23 18:35:40 ThinClient modem-manager[2228]: [mm-at-serial- port.c:298] debug_log(): (ttyHS1): <-- '_OSIGQ: 8,0' best regards, Harald Jung ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Can't create new wireless network in NetworkManager Applet 0.8
Ubuntu 10.04 LTS When I left click the applet and select "Create New Wireless Network" the "Create" button is grayed out. If I right click the applet, select "Edit Connections", then the "Wireless" tab, then the "Add" button, the "Apply" button is grayed out. If I open a terminal and enter "nm-tool" I get [QUOTE NetworkManager Tool State: connected - Device: wlan0 Type: 802.11 WiFi Driver: iwl3945 State: disconnected Default: no HW Address: 00:18:DE:2D:74:88 Capabilities: Wireless Properties WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points Janet -O_Wireless_C990BB: Infra, 00:22:75:C9:90:BB, Freq 2437 MHz, Rate 54 Mb/s, Strength 34 - Device: eth0 [Wired connection 1] --- Type: Wired Driver: tulip State: connected Default: yes HW Address: 00:04:5A:A8:76:D5 Capabilities: Carrier Detect: yes Wired Properties Carrier: on IPv4 Settings: Address: 64.77.253.186 Prefix: 23 (255.255.254.0) Gateway: 64.77.252.1 DNS: 198.6.1.122 DNS: 198.6.1.3 /QUOTE] Any ideas would be greatly appreciated. Bill ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 1199:6832 Sierra Wireless, Inc. MC8780 not working with NetworkManager 0.8.3.998 / ModemManager 0.4
On Mon, May 23, 2011 at 8:58 AM, Gerd Bavendiek wrote: > The log from the second package Pantelis provided is in mm-nok.log. CFUN=1 > is being sent in line 159: > [...] Just for kicks (although I 'm not very confident) can you please also test the latest package in my ppa? (and attach logs like above) Also could you attach lsusb output? Theoretically Aleksander's patch should work I think. It is strange that it doesn't, although as I said I don't have any modemmanager experience to know for sure. Pantelis ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reconnect silently
Dan Williams writes: > On Tue, 2011-05-17 at 22:10 +0900, Misha Shnurapet wrote: >> Hi. >> >> I run torrents on my notebook. On an electricity outage NM starts asking for >> a new password, so when I'm not around and the light goes back on (powering >> up the WLAN router), it just stands stalled. Is there a way to tell NM not >> to ask for a new password ever? :) > > Not yet, but we do want to optimize this, and if you've ever connected > successfully to the network, and we know the password hasn't changed (we > can easily tell this with WPA-PSK but not as easily with other modes) > then we should just fail the connection silently and try later. Haven't > gotten around to that and nobody else has posted a patch for that > either,but it'll happen. I don't think you necessarily want to fail silently. It's possible that the password *did* change, so you want to give the user a chance to fix that. However I think the dialog should timeout if unattended and then you can assume the retry. > Dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Howto change port used for 3g modem?
Dan, I need to get the updated mm along with the most recent nm into my fedora 14 repositories used to build a custom spin. I have packaged the mm after applying the patches and this works OK. When I pulled the most recent nm from fedora 15, it doesn't install because of a lot of missing newer packages due to fedora 14 being too old. How do I obtain the most up-to-date nm that will still run on fedora 14? Thanks Perazim O email é um dos seus instrumentos de trabalho? http://www.portugalmail.net/profissional ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Getting NM to re-try DHCP
On Saturday 09 of April 2011 02:01:09 Mikhail Efremov wrote:
> On Wed, 06 Apr 2011 17:24:44 -0500 Dan Williams wrote:
> > On Tue, 2011-04-05 at 11:37 -0400, Derek Atkins wrote:
> > > Hey all,
> > >
> > > I have a strange issue. I lost power last night and one of my
> > > systems came up before my DHCP server did (which is surprising,
> > > because my DHCP server usually comes up pretty quick!) This
> > > "client" system was supposed to get itself on the network (it has
> > > an auto-logon system). However, NM didn't succeed because my DHCP
> > > server wasn't responding, yet.
> > >
> > > This is a hard-wired system (not wireless). Is there any way to
> > > get NM to periodically retry DHCP if at first it does not succeed?
> > >
> > > I realize that DHCP has its own retry mechanism, but if the whole
> > > process times out, can I set NM to retry every, say, 5 minutes?
> >
> > We'd need some code changes in NM; basically for wired connections if
> > the activation attempt fails a certain number of times (currently 3)
> > then the connection is marked "invalid". What probably should happen
> > is that internally, in nm-policy.c, a timeout handler should be
> > scheduled for the connection (using g_timeout_add_seconds()) that
> > triggers after 5 minutes or so and if the connection isn't currently
> > active (ie check the NMManager's active connection list) then the
> > invalid flag is cleared from the connection, which will let it be
> > automatically retried.
>
> Not on this issue exactly, but this is reminded me about my old patch
> which was written long time ago (it was just forgotten to submit, sorry).
> If cable was unplugged, then when it is replugged this may be another
> network, so NM should try to reconnect even if the connection was
> early marked as "invalid".
> This patch for the NM_0_8 branch, for master it should be remaked, but
> I have no time to do this right now, sorry. And there may be no
> necessary for a separate function to clear the tag.
Looks good. However, we may want to remove the 'invalid' flag for all
connections compatible with the device.
Patches both for NM_0_8 and master attached.
Jirka
From fd1fcb95bcd2edc565ff75d21ca7f36f6139018b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=
Date: Mon, 23 May 2011 12:23:28 +0200
Subject: [PATCH] core: clear 'invalid' tag when cable is replugged
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When re-plugging we may be in a different network. So remove invalid tag from
compatible connection so that they can be tried again.
Based on a patch from Mikhail Efremov.
Signed-off-by: Jiří Klimeš
---
src/nm-policy.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/src/nm-policy.c b/src/nm-policy.c
index da6ce94..78efef0 100644
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -848,6 +848,32 @@ get_device_connection (NMDevice *device)
}
static void
+clear_invalid_tag (NMManager *manager, NMDevice *device)
+{
+ GSList *connections, *iter;
+ NMDeviceInterface *dev_iface;
+ GError *error = NULL;
+
+ g_return_if_fail (NM_IS_MANAGER (manager));
+ g_return_if_fail (NM_IS_DEVICE (device));
+
+ dev_iface = NM_DEVICE_INTERFACE (device);
+
+ /* System connections first, then user connections */
+ connections = nm_manager_get_connections (manager, NM_CONNECTION_SCOPE_SYSTEM);
+ connections = g_slist_concat (connections, nm_manager_get_connections (manager, NM_CONNECTION_SCOPE_USER));
+
+ /* Clear INVALID_TAG for all connections compatible with the device */
+ for (iter = connections; iter; iter = g_slist_next (iter)) {
+ if (nm_device_interface_check_connection_compatible (dev_iface, iter->data, &error))
+ g_object_set_data (G_OBJECT (iter->data), INVALID_TAG, NULL);
+ g_object_unref (G_OBJECT (iter->data));
+ g_clear_error (&error);
+ }
+ g_slist_free (connections);
+}
+
+static void
device_state_changed (NMDevice *device,
NMDeviceState new_state,
NMDeviceState old_state,
@@ -882,9 +908,14 @@ device_state_changed (NMDevice *device,
update_routing_and_dns (policy, FALSE);
break;
+ case NM_DEVICE_STATE_DISCONNECTED:
+ /* Clear INVALID_TAG when carrier on. If cable was unplugged
+ * and plugged again, we should try to reconnect */
+ if (reason == NM_DEVICE_STATE_REASON_CARRIER && old_state == NM_DEVICE_STATE_UNAVAILABLE)
+ clear_invalid_tag (policy->manager, device);
+ /* fall through */
case NM_DEVICE_STATE_UNMANAGED:
case NM_DEVICE_STATE_UNAVAILABLE:
- case NM_DEVICE_STATE_DISCONNECTED:
update_routing_and_dns (policy, FALSE);
schedule_activate_check (policy, device, 0);
break;
--
1.7.4.4
From 15825c119e33b15f5782b6c47c6fff452db9d5a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=
Date: Mon, 23 May 2011 12:50:25 +0200
Subject: [PATCH] core: reset auto retries counter when cable is replugged
MIME-Version: 1.0
Content
networkmanager can not connect wired device automatically any more after using wrong 802.1X profile
I got two profiles,one is normal eth0 profile , one is 802.1X profile. If I connected to a 802.1X port which is using a different username/passwd, not corresponding to my 802.1X profile. so, normal eth0 profile failed first ,then after 3 tries for 802.1X failed, the two profile are both invalid. In this case,NetworkManager's profiles are invalid . Even though I unplug the wire ,and re-plug a new wire, NetworkManager still can not make a automatically connection. I suggests that when I unplug the wire, NetworkManager could clear the tries or invalid tag. So NetworkManager could always try to automatically connect. -- zhang dongmao ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
DHCP fall back to link-local? (IPv4)
Hi, there was a discussion[1] of this issue in 2009-04. I'm not sure what the outcome was, but I Dan expressed his opinion as follows: "I'm not opposed to it, I just think we do need to think through the consequences of doing something like that, because it breaks stuff including user expectations." Was there any further discussion I didn't find yet? Or should I just you dhcpcd-4 and patch NM to use it like suggested later on[2]? Is this still correct with NM 0.8.4/0.9? Thanks in advance! Background: I like to have this behaviour, because my (embedded) device should work out-of-the-box with both DHCP and link-local setups. The drawback is a relatively long timeout when waiting for non-present DHCP, but at least MS-Windows and Mac users are used to it, as their OSes work this way. Cheers [1] http://mail.gnome.org/archives/networkmanager-list/2009-April/msg00073.html [2] http://mail.gnome.org/archives/networkmanager-list/2009-April/msg00097.html ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
