Re: [PATCH] Re: IP4Config and routes
On Tuesday 08 of June 2010 23:08:01 Dan Williams wrote:
On Tue, 2010-06-08 at 13:43 +0200, Jirka Klimes wrote:
On Saturday 05 of June 2010 04:58:36 Dan Williams wrote:
On Wed, 2010-06-02 at 09:51 +0200, Simon Schampijer wrote:
On 12/18/2009 03:14 PM, Daniel Drake wrote:
On Thu, 2009-12-17 at 14:22 -0800, Dan Williams wrote:
What would you expect the routing table to look like in your case?
I suppose we could do a default route for link-local. Not sure
if that will confuse apps that expect a default route to mean an
internet connection though.
I would expect the subnet route, as NM is creating already:
dest=169.254.0.0
gateway=0.0.0.0
genmask=255.255.0.0
I would also like the routing table to either include a default
route:
dest=0.0.0
gateway=0.0.0.0
genmask=0.0.0.0
or a multicast one:
dest=224.0.0.0
gateway=0.0.0.0
genmask=240.0.0.0
The routing table that NM is setting up now is reasonable, in my
opinion, but there should be some way of customizing the behaviour
in the settings object.
Daniel
Hi,
what is the status on this one? Was there a conclusion on whether NM
should set a default route for link local?
Creating a multicast route by default on link-local IPv4 connections
seems reasonable. Want to do a patch for that? I'd say just add the
desired route in aipd_get_ip4_config() in src/nm-device.c to the
returned NMIP4Config object and then lets make sure the code that adds
routes works correctly there.
The patch adds a multicast route as suggested by Dan.
destination=224.0.0.0
netmask=240.0.0.0
Daniel, does it work for your case?
Patch looks good; lets push it into master, NM_0_8_1, and
NETWORKMANAGER_0_7 branches. And something else I found today, the
Fedora network scripts add a 169.254 route by default for IPv4
connections even if they aren't LL-only. Not sure why or if that's
something we want to or why it was added to the Fedora initscripts in
the first place, but might be worth finding out.
Committed to the three branches.
Regarding 169.254.0.0 route, I've searched a bit. It is part of initscripts
quite a long time now (from RedHat 9.0).
/etc/sysconfig/network-scripts/ifup-eth:
# Add Zeroconf route.
if [ -z ${NOZEROCONF} -a ${ISALIAS} = no -a ${REALDEVICE} != lo ];
then
ip route add 169.254.0.0/16 dev ${REALDEVICE} metric $((1000 + $(cat
/sys/class/net/${REALDEVICE}/ifindex))) scope link
fi
http://linux.dbw.org/notes/static-routes.txt - last section.
I think that it was added as a response to Windows Automatic Private IP
Addressing(APIPA) feature when implementing zeroconf.
However, I don't know if Windows adds the route for all connections like
initscripts does. I could try to find that.
I'm not sure if the route could cause problems, probably not. But having it
just for LL-only connection looks cleaner.
There was a bug for creating it even for loopback, now
corrected:https://bugzilla.redhat.com/show_bug.cgi?id=203591#c8
Switching off the zeroconf route:
http://kbase.redhat.com/faq/docs/DOC-8628
Jirka
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: [PATCH] add UnlockRetries property to the modem dbus interface
-Original Message-
From: networkmanager-list-boun...@gnome.org
[mailto:networkmanager-list-boun...@gnome.org] On Behalf Of
Torgny Johansson
Sent: Wednesday, June 02, 2010 12:49 PM
To: Dan Williams
Cc: networkmanager-list@gnome.org
Subject: RE: [PATCH] add UnlockRetries property to the modem
dbus interface
Hi!
Any other comments on this patch?
Regards
Torgny
-Original Message-
From: networkmanager-list-boun...@gnome.org
[mailto:networkmanager-list-boun...@gnome.org] On Behalf Of Torgny
Johansson
Sent: den 27 maj 2010 12:07
To: networkmanager-list@gnome.org
Subject: [PATCH] add UnlockRetries property to the modem dbus
interface
Hi!
This is a new patch that fixes the issues from your comments.
Now only a property containing the UnlockRetries for the currently
locked pin type is added and no extra dbus method.
I also removed the change in send_pin_done, but as mentioned in a
previously mail that will still have to be addressed somehow as the
UnlockRequired and UnlockRetries properties do not properly
update on
failed SendPin attempts.
Regards
Torgny
---
introspection/mm-modem.xml |7 +++
plugins/mm-modem-mbm.c | 93
+++-
src/mm-generic-gsm.c | 38 ++
src/mm-modem-base.c| 46 ++
src/mm-modem-base.h|6 +++
src/mm-modem-gsm-card.c| 28 +
src/mm-modem-gsm-card.h| 17
src/mm-modem.c |8
src/mm-modem.h |4 +-
9 files changed, 245 insertions(+), 2 deletions(-)
diff --git a/introspection/mm-modem.xml
b/introspection/mm-modem.xml
index da7635b..2810db0 100644
--- a/introspection/mm-modem.xml
+++ b/introspection/mm-modem.xml
@@ -125,6 +125,13 @@
/tp:docstring
/property
+ property name=UnlockRetries type=u access=read
+ tp:docstring
+The number of unlock retries for the unlock code
given by the property UnlockRequired, or 999 if
+ the device does not support reporting
unlock retries.
+ /tp:docstring
+/property
+
property name=IpMethod type=u access=read
tp:type=MM_MODEM_IP_METHOD
tp:docstring
The IP configuration method.
diff --git a/plugins/mm-modem-mbm.c b/plugins/mm-modem-mbm.c index
10be0be..8441d96 100644
--- a/plugins/mm-modem-mbm.c
+++ b/plugins/mm-modem-mbm.c
@@ -28,17 +28,20 @@
#include mm-modem-mbm.h
#include mm-modem-simple.h
+#include mm-modem-gsm-card.h
#include mm-errors.h
#include mm-callback-info.h
static void modem_init (MMModem *modem_class); static void
modem_gsm_network_init (MMModemGsmNetwork
*gsm_network_class); static
void modem_simple_init (MMModemSimple *class);
+static void modem_gsm_card_init (MMModemGsmCard *class);
G_DEFINE_TYPE_EXTENDED (MMModemMbm, mm_modem_mbm,
MM_TYPE_GENERIC_GSM, 0,
G_IMPLEMENT_INTERFACE (MM_TYPE_MODEM,
modem_init)
G_IMPLEMENT_INTERFACE
(MM_TYPE_MODEM_GSM_NETWORK, modem_gsm_network_init)
-G_IMPLEMENT_INTERFACE
(MM_TYPE_MODEM_SIMPLE, modem_simple_init))
+G_IMPLEMENT_INTERFACE
(MM_TYPE_MODEM_SIMPLE, modem_simple_init)
+G_IMPLEMENT_INTERFACE
(MM_TYPE_MODEM_GSM_CARD,
+ modem_gsm_card_init))
#define MM_MODEM_MBM_GET_PRIVATE(o)
(G_TYPE_INSTANCE_GET_PRIVATE ((o), MM_TYPE_MODEM_MBM,
MMModemMbmPrivate))
@@ -736,6 +739,88 @@ mbm_modem_authenticate (MMModemMbm *self,
/*
/
+static void
+send_epin_done (MMAtSerialPort *port,
+ GString *response,
+ GError *error,
+ gpointer user_data)
+{
+MMCallbackInfo *info = (MMCallbackInfo *) user_data;
+const char *pin_type;
+int attempts_left = 0;
+
+if (error) {
+info-error = g_error_copy (error);
+goto done;
+}
+
+pin_type = ((char *)mm_callback_info_get_data (info,
pin_type));
+
+if (strstr (pin_type, MM_MODEM_GSM_CARD_SIM_PIN))
+sscanf (response-str, *EPIN: %d, attempts_left);
+else if (strstr (pin_type, MM_MODEM_GSM_CARD_SIM_PUK))
+sscanf (response-str, *EPIN: %*d, %d, attempts_left);
+else if (strstr (pin_type, MM_MODEM_GSM_CARD_SIM_PIN2))
+sscanf (response-str, *EPIN: %*d, %*d, %d,
attempts_left);
+else if (strstr (pin_type, MM_MODEM_GSM_CARD_SIM_PUK2))
+sscanf (response-str, *EPIN: %*d, %*d, %*d, %d,
attempts_left);
+else {
+g_debug (%s unknown pin type: %s, __FUNCTION__,
pin_type);
+
+info-error = g_error_new_literal (MM_MODEM_ERROR,
MM_MODEM_ERROR_GENERAL, Unknown PIN type);
+}
+
+mm_callback_info_set_result (info,
Invitation to connect on LinkedIn
LinkedIn Sanjeev Sharma requested to add you as a connection on LinkedIn: -- Trey, I'd like to add you to my professional network on LinkedIn. - Sanjeev Accept invitation from Sanjeev Sharma http://www.linkedin.com/e/UhWALb2cmzSf_dT_CirVab2MoQS4NOgDnhS8UdbL8q6T/blk/I2112291098_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnPwVc34Vcz8Ncj99bPdnq6hctmphbPkVdzARdPgTcP4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Sanjeev Sharma http://www.linkedin.com/e/UhWALb2cmzSf_dT_CirVab2MoQS4NOgDnhS8UdbL8q6T/blk/I2112291098_2/39ve3AMcjAOcz4NcAALqnpPbOYWrSlI/svi/ -- (c) 2010, LinkedIn Corporation___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] Fast-user-switching plans
On Sun, 2010-06-06 at 00:30 +1200, Simon Geard wrote: On Fri, 2010-06-04 at 19:24 -0700, Dan Williams wrote: On Wed, 2010-06-02 at 23:44 +1200, Simon Geard wrote: On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote: The one benefit of user connections is that they follow you if you back up your homedir and switch machines :) I don't think that's enough of a benefit to keep them around though. Also if you periodically update your OS - e.g installing a new Ubuntu release every six months. Stuff in $HOME stays - stuff in /etc doesn't. Yup. Though we could mitigate that by providing usable backup/restore capability that dumps a bunch of keyfiles describing your connections into a tarball or something. Is a user going to appreciate that, though? I.e, will they realise that their network settings are something that needs manually backing up? Or will they learn this out after installing an update, and finding they've lost the VPN settings they assumed were stored safely in $HOME? I think it's unclear... some users would based on previous expectations. If we make import/export work well we mitigate that. But there are also users for which this just doesn't matter because they don't go through the trouble of rsyncing $HOME every time they switch machines. It's clear this is a downside of the decision though. The question is, is it enough of a downside that it outweighs the benefits? That's a nuanced question but I think at this point my impression is that the benefits are greater. Namely, simpler architecture is more flexible and allows easier creation of different UI for different situations, which clearly benefits all users (this is the big one). Second, this simplification reduces the number of code-paths making future maintenance easier. Third, it enables fast-user-switching and multi-seat configurations which is something that people have also been asking about for a long time. Fourth, it also enables better integrated network configuration editing and creation from just about anywhere on the system. Either way, it's important to understand all the tradeoffs in this sort of decision. Actually, here's a thought - the login/password details for each connection are currently stored in the user's keyring. If you were to turn user connections into system connections with ACL, how would that piece work? If system connections are removed or their permissions changed, are keys removed from the keyring? That part depends on the connection; if secrets were pushed with the connection when it was created, user secrets wouldn't be required. However, there are cases where they would be desirable even if the secrets were already stored for it. In that case, we need to ensure we get signaling right, but we need to do that anyway. If the connection ACL is changed in such a way that certain users are no longer able to use that connection, then one of two things happens... if the user agent that has secrets already stored for that connection is running, then it would remove the stored secrets. If it is not running, the secrets would stay in the keyring and could optionally be removed by the user agent when the agent starts up the next time. I think it's clear that even if there are no user connections as such, that we still need secrets on a per-user basis for some connections. And that's not actually that hard to do, and we've got most of the code written for that already. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant process although no WiFi adapter is present
On Sun, 2010-06-06 at 14:42 +0200, Paul Menzel wrote: Dear NeworkManager folks, I am running a desktop box with Debian Sid/unstable. The system has no WiFi adapter. Sometimes a UMTS device will be used. I was surprised seeing that `wpa_supplicant` is running in the background nevertheless. I guess NetworkManager started it, since the package also depends on `wpasupplicant`. root 1116 0.0 0.2 4748 1304 ?S13:35 0:00 /sbin/wpa_supplicant -u -s Is there a way to disable the loading of `wpa_supplicant`? You can remove /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service which will stop the supplicant from getting auto-spawned. In reality we should just start it up when it's needed, but we currently dont' do that. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
