Re: Wireless - properties popup after a few failed retries
Yeah, thats pretty annoying thing when you are in a city looking for a hotspot. Instead of popping up settings it should probably just show notification which would pop up settings page. On Tuesday 02 August 2011 14:47:09 Maverick wrote: > For example, I've got my laptop connect to the wireless network, and then I > have to stop my radius server for maintenance for 1h,when NetworkManager > detects that the connection is dropped it tries to reconnect a few times > and then fails as obvious. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM no longer supports a dialup modem?
On Sun, 2011-07-31 at 09:34 +0200, craig wrote: > Hello, > > Under Debian Etch with Gnome, NetworkManager listed my 56Kb dialup modem and > was > able to connect and disconnect to/from the Internet using that modem. I'd assume that was NM 0.6.x? Dialup support was pretty hacked in and was removed a few years ago with NetworkManager 0.7.x. We're looking at adding it back into ModemManager though, which is what NM 0.7+ uses for controlling modems and 3G sticks. > Now, under Debian Squeeze with Gnome, NetworkManager does not seem to know > about > my dialup modem at all, and I don't see any way to enter/edit that sort of > connection using NM's connection editor. Right, because they aren't seen by ModemManager and not supported at this time :( Dan > I have scoured for documentation and advice and found nothing about > NetworkMAnager and dialup modems. > > Can anyone suggest the best way to be connect/disconnect to/from the Internet > from within Gnome? > > Thanks in advance. > ___ > 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
ANN: ModemManager 0.5 released
Hi, I'm pleased to finally announce the release of ModemManager 0.5. It includes a ton of bug fixes since the last version, new functionality, new modem support, and a whole lot more magical stuff. Instead I'll just link to the NEWS file which details much of it; thanks to everyone who contributed patches and helped test and debug. http://cgit.freedesktop.org/ModemManager/ModemManager/plain/NEWS?h=MM_05 MM 0.5 is the first release of the 0.5.x stable branch. It is compatible with (among other programs) NetworkManager 0.8.x and 0.9.x. You can download MM from here: http://download.gnome.org/sources/ModemManager/0.5/ Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The meaning of Enable in MM/NM world of mobile broadband?
Den 02. aug. 2011 17:58, skrev Andrew Bird (Sphere Systems): There is one thing I noticed though after doing a few tests with NM on Ubuntu Natty. If after first insertion of a device, the user dismisses the PIN entry dialog without authenticating. Then he subsequently uses the nm-applet to enable mobile broadband but it doesn't prompt again for PIN. Which means that to see registration/sig strength/networks etc, the user must first attempt a connection in order to get prompted for PIN and auth, or he must pull the stick and reinsert. Which may be expected behaviour I guess, but a little awkward. There is also another similar issue, it seems to ask for PIN after bootup even if the PIN is saved on the connection, and then it might ask again on the actual connection. I can maybe understand the technical reasons for that, but it is annoying for the user. -- Marius ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] modem: fix race with nm_modem_set_mm_enabled
Once we've sent a method call over DBus requesting that the modem be
disabled, we should assume that the modem is disabled unless we hear
otherwise. Otherwise, code that checks the modem state immediately
after it gets disabled might think that it's enabled when it almost
certainly is not.
---
src/modem-manager/nm-modem.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/modem-manager/nm-modem.c b/src/modem-manager/nm-modem.c
index 33f1078..1823e5e 100644
--- a/src/modem-manager/nm-modem.c
+++ b/src/modem-manager/nm-modem.c
@@ -86,6 +86,17 @@ enum {
static guint signals[LAST_SIGNAL] = { 0 };
+static void
+update_mm_enabled (NMModem *self, gboolean new_enabled)
+{
+ NMModemPrivate *priv = NM_MODEM_GET_PRIVATE (self);
+
+ if (priv->mm_enabled != new_enabled) {
+ priv->mm_enabled = new_enabled;
+ g_object_notify (G_OBJECT (self), NM_MODEM_ENABLED);
+ }
+}
+
gboolean
nm_modem_get_mm_enabled (NMModem *self)
{
@@ -822,8 +833,7 @@ get_mm_enabled_done (DBusGProxy *proxy, DBusGProxyCall
*call_id, gpointer user_d
}
if (G_VALUE_HOLDS_BOOLEAN (&value)) {
- NM_MODEM_GET_PRIVATE (self)->mm_enabled = g_value_get_boolean
(&value);
- g_object_notify (G_OBJECT (self), NM_MODEM_ENABLED);
+ update_mm_enabled (self, g_value_get_boolean (&value));
} else
nm_log_warn (LOGD_MB, "failed get modem enabled state:
unexpected reply type");
@@ -880,6 +890,9 @@ nm_modem_set_mm_enabled (NMModem *self, gboolean enabled)
self, NULL,
G_TYPE_BOOLEAN, enabled,
G_TYPE_INVALID);
+ /* If we are disabling the modem, stop saying that it's
enabled. */
+ if (!enabled)
+ update_mm_enabled (self, enabled);
}
}
@@ -898,8 +911,7 @@ modem_properties_changed (DBusGProxy *proxy,
value = g_hash_table_lookup (props, "Enabled");
if (value && G_VALUE_HOLDS_BOOLEAN (value)) {
- priv->mm_enabled = g_value_get_boolean (value);
- g_object_notify (G_OBJECT (self), NM_MODEM_ENABLED);
+ update_mm_enabled (self, g_value_get_boolean (value));
}
value = g_hash_table_lookup (props, "IpMethod");
--
1.7.4.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] policy: don't autoconnect disabled modems
Normally, a device disabled via nm_device_interface_set_enabled() will
shift into the UNAVAILABLE state. Modems, however, don't do that.
Rather, they pretend that they are in the DISCONNECTED state, presumably
to make it easier to re-enable them. To avoid accidentally re-enabling
and autoconnecting a disabled modem, we need to explicitly make
nm_device_interface_get_enabled() == true a prerequisite for
autoconnecting.
---
src/nm-policy.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/nm-policy.c b/src/nm-policy.c
index 20729fd..a42a0fa 100644
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -896,6 +896,9 @@ schedule_activate_check (NMPolicy *policy, NMDevice
*device, guint delay_seconds
if (state < NM_DEVICE_STATE_DISCONNECTED)
return;
+ if (!nm_device_interface_get_enabled (NM_DEVICE_INTERFACE (device)))
+ return;
+
if (!nm_device_autoconnect_allowed (device))
return;
@@ -1054,6 +1057,12 @@ nsps_changed (NMDeviceWimax *device, NMWimaxNsp *nsp,
gpointer user_data)
}
#endif
+static void
+modem_enabled_changed (NMDeviceModem *device, gpointer user_data)
+{
+ schedule_activate_check ((NMPolicy *) (user_data), NM_DEVICE (device),
0);
+}
+
typedef struct {
gulong id;
NMDevice *device;
@@ -1088,6 +1097,8 @@ device_added (NMManager *manager, NMDevice *device,
gpointer user_data)
_connect_device_signal (policy, device, "nsp-added",
nsps_changed);
_connect_device_signal (policy, device, "nsp-removed",
nsps_changed);
#endif
+ } else if (NM_IS_DEVICE_MODEM (device)) {
+ _connect_device_signal (policy, device,
NM_DEVICE_MODEM_ENABLE_CHANGED, modem_enabled_changed);
}
}
--
1.7.4.1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM connects to a mobile network even if "Mobile network" in tray icon's context menu is unchecked
On 08/01/2011 05:57 PM, Dan Williams wrote: > On Sun, 2011-07-31 at 14:41 -0400, Daniel Gnoutcheff wrote: >> So, when the user disables wifi, we transition the wifi devices to >> NM_DEVICE_STATE_UNAVAILABLE. This is what prevents nm-policy from >> trying to autoconnect them. It also means that ActivateConnection calls >> will fail (unnecessarily perhaps) for those devices, but for wifi we can >> live with that. >> >> But we can't live with that for modems. This means we've been leaving >> "disabled" modems at NM_DEVICE_STATE_DISCONNECTED, so nm-policy happily >> autoconnects them. > > Hmm, though if the modem is still "enabled" then I suppose it's fair > game for autoconnecting, if the connection is set for that. That's a > nuance I hadn't thought of but makes some amount of sense, given that > users must explicitly enable the modem in the first place. I assume that "if the modem is still enabled" is equivalent to "nm_device_interface_get_enabled(modem_device) returns true", correct? If so, this sounds sensible to me as well. > We've given > "disconnect" special meaning though, which is that if the user > explicitly chooses disconnect from the menu (which translates to NM's > Disconnect() call) then the device is not supposed to be reconnected > automatically until either the user does so, or the machine is put to > sleep. If we're not respecting that for WWAN then we should be. That works fine for WWAN, using autoconnect_inhibit in NMDevice. There are scenarios, however, where where autoconnect_inhibit is not set but we still don't want to autoconnect. That's were we have trouble. Scenario 1: - User creates wwan connection with autoconnect=true - User sets WwanEnabled == false - User plugs in modem Expected: NM detects the modem but doesn't enable or autoconnect it Actual result: NM detects the modem, enables it, and autoconnects it Scenario 2: - User creates wwan connection with autoconnect=true - User plugs in modem and activates connection on it - User sets WwanEnabled == false Expected: NM disconnects modem, disables it, and leaves it alone Actual result: NM disconnects modem and disables it. But after some semi-random delay, NM re-enables and autoconnects it. We have this problem because NMPolicy seems to expect a disabled device to enter state UNAVAILABE. This holds true for wifi, where we always enter UNAVAILABE when somebody calls set_enabled(wifi_device, FALSE). But WWAN devices are different. Even when a modem is disabled, NMDeviceModem still claims that it's in state DISCONNECTED, not UNAVAILABLE. As a result, NMPolicy thinks that it's enabled even when it isn't. I'm not sure I like that disabled modems stay in DISCONNECTED. It obscures the fact that they are disabled, and as this bug seems to demonstrate, that can be confusing. That's why I proposed a new STANDBY state. But in any case, I'll write a patch that has makes nm_device_interface_get_enabled() == TRUE an explicit prerequisite for autoconnect. That would fix this. > So basically, we need to harmonize the way things are treated. If a > device is not available (disabled, rfkill, whatever) then we shouldn't > autoconnect it. If the device is available, then we should autoconnect > it as long as a autoconnect connection is defined. If the user has > explicitly disconnected the device, then the device should stay > disconnected until the user performs some action (or the machine wakes > up from sleep). > > The way to stop the WWAN device (and wired, and wifi) from doing > anything automatic is to disable it or disconnect it explicitly, or set > your connections to autoconnect=no. We can't make this too complicated > otherwise the ruleset that people have to memorize becomes too complex > and you're left wondering about what it's actually supposed to be doing. > I feel like the paragraph above is the most reasonable course of action > for a device, feel free to argue if you disagree though. Nope, this matches my understanding of how things are supposed to work, as long as we are in agreement on what "disabling the modem" means. Have a good one, Daniel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The meaning of Enable in MM/NM world of mobile broadband?
On Monday 01 August 2011, Dan Williams wrote: > On Mon, 2011-08-01 at 09:26 +0100, Andrew Bird (Sphere Systems) wrote: > > Hi all, > > > > I'm trying to understand the meaning of 'Enable Mobile Broadband' from > > > > the NM applet menu. I have a few questions: > > > > Is the NM applet Enable item just a direct control of the WWAN devices's > > radio function? > > Not necessarily. Enable means "power up the modem and initialize it so > that it is able to be connected at some point in the future." Before > the modem is enabled, it may not be powered up, it may not be registered > with a network, it may not send/receive SMS, etc. Basically, before > anything can be done with the modem beyond detecting that the modem > exists and whether the modem needs a PIN, the modem must be enabled. OK thanks, I understand now > > a) if so, what happens at startup, is the modem's radio functionality > > > > checked and the Enable checkitem state set accordingly, or is the modem's > > radio forced into some default/remembered NM/MM derived state? > > ModemManager starts all modems in disabled state, and NetworkManager > should not be automatically enabling modems; that's left to the user > because at the moment, most people won't be using their modems full-time > and probably don't want them to suck down power when they aren't > actually being used. It's up to the connection manager (NM or something > else) to determine whether or not to enable the device, and right now NM > requires the user to explicitly make that decision. If you're using an > embedded platform, whatever tells MM to connect probably wants to enable > the modem when that thing starts. OK thanks, I understand now > > > b) if so, what happens if we have two modems (perhaps one is embedded > > and > > > > the other external) and their radios are in different states, or need to > > be? > > MM allows both modems to have different state. With NetworkManager > however, because there isn't a separate rfkill for each WWAN device, > there's a single composite state just like there is for WiFi. If any > modem is disabled, the checkbox (and NM's "WwanEnabled" state) will be > FALSE. If the user checks the box (or something sets WwanEnabled to > TRUE) NM will attempt to call MM's Enable() method for all devices. > > I'm somewhat unclear on use-cases where multiple modems would be > connected to a system under normal conditions where both wouldn't be > able to be enabled at the same time. Thoughts? Yeah it was a contrived example, and the only reason I can think of is power saving on the unused modem. > > > c) if so, does MM prefer to use +CFUN=0 or +CFUN=4 to Disable the > > modem? > > That's left to the modem plugin. CFUN=0 often has the unfortunate > side-effect of actually powering off the device so it's not used on many > devices. CFUN=4 is unfortunately unimplemented on a wide range of > devices, but if it is available we should be using it. Patches for that > would be accepted; we can check CFUN=? on startup and then store the > returned list of available modes and use that to determine whether to > set CFUN=4 on disable. > > > d) if not, what function does Enable on the applet perform? > > Not sure what you're asking here... You answered it in part (a) > > > e) if not, is there another way to turn off the radio, perhaps an > > Aircraft > > > > Mode? > > That is current calling Enable(FALSE) for the modem on the MM DBus > interface, which is supposed to place the modem into low-power mode. > RFKILL/Aircraft mode isn't what we want to do here, because that is > easily confused with the physical button that many laptops have, which > often just disconnects the device from the USB bus completely. Which > means MM can't see it anymore because it doesn't exist. So I think just > having the device disabled via the equivalent of CFUN=4 is sufficient, > and leave actual airplane mode/rfkill to the BIOS, if any. > > Dan There is one thing I noticed though after doing a few tests with NM on Ubuntu Natty. If after first insertion of a device, the user dismisses the PIN entry dialog without authenticating. Then he subsequently uses the nm-applet to enable mobile broadband but it doesn't prompt again for PIN. Which means that to see registration/sig strength/networks etc, the user must first attempt a connection in order to get prompted for PIN and auth, or he must pull the stick and reinsert. Which may be expected behaviour I guess, but a little awkward. Thanks for taking the trouble to explain it all Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Wireless - properties popup after a few failed retries
I think you didn't understand my question. For example, I've got my laptop connect to the wireless network, and then I have to stop my radius server for maintenance for 1h,when NetworkManager detects that the connection is dropped it tries to reconnect a few times and then fails as obvious. What I'm asking is if it's possible to instead of showing up the popup, make it keep trying to reconnect so that it when my radius server comes back up my laptop connects automatically to my wifi network. -Original Message- From: Maverick [mailto:maverick...@gmail.com] Sent: segunda-feira, 1 de Agosto de 2011 23:20 To: 'Dan Williams' Cc: 'networkmanager-list@gnome.org' Subject: RE: Wireless - properties popup after a few failed retries WPA2 Enterprise (PEAP + MSCHAPv2) -Original Message- From: Dan Williams [mailto:d...@redhat.com] Sent: segunda-feira, 1 de Agosto de 2011 22:58 To: Maverick Cc: networkmanager-list@gnome.org Subject: Re: Wireless - properties popup after a few failed retries On Mon, 2011-08-01 at 14:45 +0100, Maverick wrote: > Good afternoon, > > > > When i’m connect to a wireless network and for some reason the > connection is interrupted for a while NetworkManager tries to > reconnect a few times and then it shows up a popup with the connection > properties, after that the only way to reconnect is to press the OK > button on that popup. > > > > Is there any way to make it not show this popup in order to reconnect > automatically when the connection comes back again? Which kind of network, WPA or WEP? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Extending the mobile-broadband-provider-info database
Hi Dan, > > > > >>> As long as the attributes we add aren't required, it should be fine > > > > >>> to > > > > >>> add them. See the balance check stuff that was added a while ago; > > > > >>> that > > > > >>> was added in a compatible manner and existing tools simply ignore > > > > >>> the > > > > >>> new attributes. > > > > >>> > > > > >> About the existing information there. I see it is mobile network > > > > >> identifiers, but I haven't seen that Network manager exploit this to > > > > >> automatically select or propose the correct network settings. Is > > > > >> this > > > > >> not implemented yet? > > > > > It's done in the client applications like nm-applet and > > > > > nm-connection-editor and the KDE bits, which create the actual > > > > > configuration and display stuff like signal and network names. NM > > > > > simply passes the mobile broadband specific configuration along to > > > > > ModemManager, but isn't itself involved at all with the carrier/APN > > > > > selection. nm-applet also makes use of the database to pull out a > > > > > carrier name based on MCC/MNC/SID if the modem doesn't one. > > > > > > > > Okay, I just haven't seen it happen in nm-applet. I always have had to > > > > select country and then operator/subscription. > > > > > > nm-applet doesn't yet pull the operator MCC/MNC out of the sim (and in > > > fact, lots of devices don't allow this for some reason, nothing to do > > > with the SIM, but the device). But nm-applet *does* use the database > > > for the selection dialog you're talking about, and it uses the database > > > for dispalying the operator name in the menu if the device doesn't > > > provide one. It also uses it to show the CDMA operator name (based on > > > SID) if you're using a CDMA device. So quite a few things at the > > > moment. > > > > actually all devices allow you to read the MCC/MNC from the SIM card. > > The MCC is the first 3 bytes of your IMSI. And the MNC follows the MCC. > > The only tricky part is that the MNC can be 2 or 3 digits. And to know > > what it actually is, you need to read the MNC length from the SIM card. > > You do need proper EF reading for that. > > Yeah, but see below, it often doesn't work. Not to say we can't try to > get it if it's available, but it's unreliable at best and broken at > worst. > > > The only problem is that you need to tweak the EF reading for some > older > > devices since it seems that it has not been tested enough for the data > > dongles. Most likely that is a Qualcomm problem since we only saw issue > > with it on old dongles using Qualcomm chips and thus most likely their > > AT command implementation. > > Yeah, that's what I've found on a number of devices. But SIMs (or > devices) are also pretty weird here. My standard T-Mobile USIM (from > 2009) simply doesn't have >= 4 bytes in EF_AD and thus we can't read the > MNC size at all, and since T-Mobile is one of the largest companies with > a 3-digit MNC that seems pretty odd: > > (Option 452 TMO SIM): > AT+CRSM=176,28589,0,0,255 > +CRSM: 144,0,"00" some Option cards are funny. There file size reading is all broken. So you need to force it to the correct size. > AT+CRSM=176,28589,0,0,4\r < \r\r\n+CRSM: 144,0,"0002"\r\n\r\nOK\r\n > (Sierra 306 TMO SIM): > AT+CRSM=176,28589,0,0,4 > +CRSM: 103,0,"" > AT+CRSM=176,28589,0,0,3 > +CRSM: 144,0,"00" The Sierra card will give you the correct file size. > AT+CRSM=192,28589,0,0,255\r < \r\n+CRSM: 144,0,"62178202412183026FAD8A01058B036F060180020004880118"\r\n\r\nOK\r\n > AT+CRSM=176,28589,0,0,4\r < \r\n+CRSM: 144,0,"0003"\r\n\r\nOK\r\n > (Option 452 3UK SIM): > AT+CRSM=176,28589,0,0,255 > +CRSM: 144,0,"0002" The really important part is that you have to implement EF reading properly. You can not just go ahead and try to read the file. That might work, but in most cases you wanna read the directory structure and the permission information first. > All three use Qualcomm chipsets but the SIM is what makes the > difference. Both a TMO and a 3UK SIM refuse when requesting the SPN > too: > > AT+CRSM=176,28486,0,0,255 > +CRSM: 111,0 > > Or is that the device? The SPN does not have to be present. It is optional and then the reported value from AT+COPS is correct. Some firmwares mangle the SPN and NITZ updates into AT+COPS responses. I wish they wouldn't, but in general if SPN is present, then you should be using SPN. > > Using the database for displaying the operator name is also wrong. At > > least for GSM. You need to use the SPN value from the SIM card for this. > > In addition you need to let the firmware handle NITZ updates. Operator > > names can change on the fly and can be changed by the network. > > Yes, but I've seen some examples where that's also completely wrong. > For example, a ZTE MF627 from 3UK with a 3UK SIM lists T-Mobile US as > "Voicestream" which it hasn't been since 2003, though that might be the > firmware since sticking that SIM in anot
