[PATCH] Support for openvpn --auth option
Hello everybody,
this is my first post to this list, and it combines submitting a patch
for a new feature, and a request for help.
The attached patch is against NetworkManager-openvpn-0.7.0-16.svn4027
(Fedora 9) and adds support for the --auth option of openvpn. The
configuration import feature works, calling openvpn with the --auth
option works, creating and changing a VPN configuration using the
--auth option works, but one problem still exists: The GtkComboBox
for this option in the "advanced" popup does not show the current
state of this option. (But it works as expected when changing the
value.)
I've tried changing nm-openvpn-dialog.glade with glade-3 and vi many
times, and double- and triple-checked the code in auth-helpers.c,
which I've copied and modified from the handling of the cipher option.
But I'm stuck and didn't get any further for hours. So I'm asking
here for help.
Please, can some glade and gtk expert look at this and tell me
how this issue could be fixed?
I need this patch for compatibilty with the openvpn setup of an
Astaro firewall. The current state is enough to get a working
VPN connection, but I would rather have this feature completed
and included in the NetworkManager-0.7.0 release. ;-)
Thanks,
Robert
diff -u NetworkManager-openvpn-0.7.0/properties/auth-helpers.c.hmacauth
NetworkManager-openvpn-0.7.0/properties/auth-helpers.c
--- NetworkManager-openvpn-0.7.0/properties/auth-helpers.c.hmacauth
2008-08-29 15:30:50.0 +0200
+++ NetworkManager-openvpn-0.7.0/properties/auth-helpers.c 2008-11-02
23:47:27.0 +0100
@@ -585,6 +585,7 @@
NM_OPENVPN_KEY_TAP_DEV,
NM_OPENVPN_KEY_PROTO_TCP,
NM_OPENVPN_KEY_CIPHER,
+ NM_OPENVPN_KEY_AUTH,
NM_OPENVPN_KEY_TA_DIR,
NM_OPENVPN_KEY_TA,
NULL
@@ -734,6 +735,50 @@
g_strfreev (items);
}
+#define HMACAUTH_COL_NAME 0
+#define HMACAUTH_COL_DEFAULT 1
+
+static void
+populate_auth_combo (GtkComboBox *box, const char *hmacauth)
+{
+ GtkListStore *store;
+ GtkTreeIter iter;
+ gboolean user_added = FALSE;
+ gchar **item;
+ gchar *items[] = {
+ NM_OPENVPN_AUTH_NONE,
+ NM_OPENVPN_AUTH_MD5,
+ NM_OPENVPN_AUTH_SHA1,
+ NULL
+ };
+
+ store = gtk_list_store_new (2, G_TYPE_STRING, G_TYPE_INT);
+
+ /* Add default option which won't pass --auth to openvpn */
+ gtk_list_store_append (store, &iter);
+ gtk_list_store_set (store, &iter,
+ HMACAUTH_COL_NAME, _("Default"),
+ HMACAUTH_COL_DEFAULT, TRUE, -1);
+
+ /* Add options */
+ for (item = items; *item; item++) {
+ gtk_list_store_append (store, &iter);
+ gtk_list_store_set (store, &iter,
+ HMACAUTH_COL_NAME, *item,
+ HMACAUTH_COL_DEFAULT, FALSE, -1);
+ if (hmacauth && !strcmp (*item, hmacauth)) {
+ gtk_combo_box_set_active_iter (box, &iter);
+ user_added = TRUE;
+ }
+ }
+
+ if (!user_added)
+ gtk_combo_box_set_active (box, 0);
+
+ gtk_combo_box_set_model (box, GTK_TREE_MODEL (store));
+ g_object_unref (store);
+}
+
static void
tls_auth_toggled_cb (GtkWidget *widget, gpointer user_data)
{
@@ -840,6 +885,10 @@
value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_CIPHER);
populate_cipher_combo (GTK_COMBO_BOX (widget), value);
+ widget = glade_xml_get_widget (xml, "hmacauth_combo");
+ value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_AUTH);
+ populate_auth_combo (GTK_COMBO_BOX (widget), value);
+
widget = glade_xml_get_widget (xml, "tls_auth_checkbutton");
value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_TA);
if (value && strlen (value))
@@ -944,6 +993,20 @@
}
}
+ widget = glade_xml_get_widget (xml, "hmacauth_combo");
+ model = gtk_combo_box_get_model (GTK_COMBO_BOX (widget));
+ if (gtk_combo_box_get_active_iter (GTK_COMBO_BOX (widget),
&iter)) {
+ char *hmacauth = NULL;
+ gboolean is_default = TRUE;
+
+ gtk_tree_model_get (model, &iter,
+ HMACAUTH_COL_NAME, &hmacauth,
+ HMACAUTH_COL_DEFAULT, &is_default,
-1);
+ if (!is_default && hmacauth) {
+ g_hash_table_insert (hash, g_strdup
(NM_OPENVPN_KEY_AUTH), g_strdup (hmacauth));
+ }
+ }
+
widget = glade_xml_get_widget (xml, "tls_auth_checkbutton");
if (gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON
Re: VPN "Only for this address range" equivalent
On Tue, 2008-11-04 at 14:59 -0800, the_leech wrote: > > Dan Williams wrote: > > > > > > You can add custom routes in the IPv4 tab of the connection editor for > > the VPN connection. You can also check "ignore automatically provided > > routes" if you don't care what the server sends you. > > > > > Dan, > Would you please elaborate on how to do that? > I just need to set up my network so that most of the traffic will go through > a direct Internet connection while all the traffic for a small number of IP > addresses (starting with 172.17.x.x in my case) will go through VPN. > "Only for this address range" worked like a charm in the previous version of > NM and now I am stuck trying to achieve the same thing with NM0.7. > The UI of the Routes page is really confusing - what am I supposed to put as > Prefix and Metric? This is fair criticism; we do need better explanations and help text. You enter the same information there that you entered in the "Only for these addresses box". The Address range and prefix are required (just like they were before) but you can leave the Gateway and Metric boxes blank if you like. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager 0.7.0-rc1 released
Hi, I tagged and uploaded NM 0.7.0-rc1 on Sunday night. Yes, there are still bugs, and yes, we'll fix the bad ones, and yes, some people's pet bugs will only get fixed after the final release. I'll do an rc2 this coming weekend, and we'll wrap up the 0.7 development cycle by November 15th. This time for real :) http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.7/ http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.7/ Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 15:18 -0800, [EMAIL PROTECTED] wrote: > Dan Williams <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-11-04 at 14:25 -0800, [EMAIL PROTECTED] wrote: > > > Dan Williams <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: > > > > > On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > > > > > > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > > > > > > Hello, I am a new user to Linux and tried to find the proper > > > > > resources before seeking help. > > > > > > > > > > > > > > I am using NM 0.7.0-lp.0025.o.4 > > > > > > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > > > > > > > > > > > As far as I can tell, I successfully installed the modem driver > > > > > > > and it is listed as /dev/ttyUSB0 > > > > > > > > > > > > > > Unfortunately, when try to dial using wvdial, it says the device > > > > > > > is busy. So I can't verify that it is working. > > > > > > > > > > > > > > Secondarily, if I open the NM window, I am only able to add a > > > > > > > wired or WiFi connection. So I'm not sure why I can't add the 3G > > > > > > > device that the docs refer to. > > > > > > > > > > > > Is this with Ubuntu? Ubuntu has changed the mobile broadband > > > > > > connection > > > > > > creation sequence so you may need to file a launchpad bug. > > > > > > > > > > the NM version from above doesnt look ubuntu/deb stylish. Its > > > > > definitly not a version of the official archives ;). > > > > > > > > I guess I assumed that "lp" mean launchpad or something, but I'm wrong, > > > > it's always PPA :) My bad. > > > > > > > > And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% > > > > likely that your modem is not correctly tagged by HAL, and thus is not > > > > recognized by NM. > > > > > > > > Can you attach the output of 'lshal' (typed into a terminal) to a reply > > > > when the 881 is plugged in? > > > > > > > > Dan > > > > > > > > > > > Yes, it is Linpus Lite on an Aspire One. > > > > > > Not knowing the relevant bits of the output, I've copied it all below. > > > Apologize in advance for the long string. > > > > Ok, the issue is that your modem is not recognized by the copy of HAL > > that Linpus Lite ships. Can you attach your copy of: > > > > /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi > > > > and also the output of > > > > /sbin/lsusb > > > > when the card is plugged in? > > > > Thanks! > > Dan > > > > > Hello Dan, > I don't have a file named 10-modem.fdi, however I have two that seem similar. > They are included below. The 10-usb-gsm.fdi file seems to have been added > as a part of the bundled "mobile partner" update from Acer/Linpus. To the > best of my knowledge, there is no Huawei modem in this notebook. The output > from lsusb is below. > > [EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-modem.fdi > > > > > > > modem > GSM-07.07 > > > > > > 3G modem > 3G modem > > > > > > [EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-gsm.fdi > > > > > modem > GSM-07.07 > GSM-07.05 > > > Paste the following in right after this section above: modem GSM-07.07 GSM-07.05 Then reboot and NM should see the card. Dan > [EMAIL PROTECTED] 10freedesktop]$ lsusb > Bus 005 Device 001: ID : > Bus 004 Device 001: ID : > Bus 003 Device 005: ID 045e:00e1 Microsoft Corp. > Bus 003 Device 001: ID : > Bus 002 Device 010: ID 1199:6856 Sierra Wireless, Inc. > Bus 002 Device 001: ID : > Bus 001 Device 004: ID 064e:d101 Acer Crystal Eye Webcam > Bus 001 Device 001: ID : > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN "Only for this address range" equivalent
Dan Williams wrote: > > > You can add custom routes in the IPv4 tab of the connection editor for > the VPN connection. You can also check "ignore automatically provided > routes" if you don't care what the server sends you. > > Dan, Would you please elaborate on how to do that? I just need to set up my network so that most of the traffic will go through a direct Internet connection while all the traffic for a small number of IP addresses (starting with 172.17.x.x in my case) will go through VPN. "Only for this address range" worked like a charm in the previous version of NM and now I am stuck trying to achieve the same thing with NM0.7. The UI of the Routes page is really confusing - what am I supposed to put as Prefix and Metric? So far, no matter what I enter all the traffic goes to VPN. I would be grateful for any help. Cheers, Piotr -- View this message in context: http://www.nabble.com/VPN-%22Only-for-this-address-range%22-equivalent-tp20236932p20333154.html Sent from the Gnome - NetworkManager mailing list archive at Nabble.com. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
Dan Williams <[EMAIL PROTECTED]> wrote: > On Tue, 2008-11-04 at 14:25 -0800, [EMAIL PROTECTED] wrote: > > Dan Williams <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: > > > > On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > > > > > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > > > > > Hello, I am a new user to Linux and tried to find the proper > > > > resources before seeking help. > > > > > > > > > > > > I am using NM 0.7.0-lp.0025.o.4 > > > > > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > > > > > > > > > As far as I can tell, I successfully installed the modem driver and > > > > > > it is listed as /dev/ttyUSB0 > > > > > > > > > > > > Unfortunately, when try to dial using wvdial, it says the device is > > > > > > busy. So I can't verify that it is working. > > > > > > > > > > > > Secondarily, if I open the NM window, I am only able to add a wired > > > > > > or WiFi connection. So I'm not sure why I can't add the 3G device > > > > > > that the docs refer to. > > > > > > > > > > Is this with Ubuntu? Ubuntu has changed the mobile broadband > > > > > connection > > > > > creation sequence so you may need to file a launchpad bug. > > > > > > > > the NM version from above doesnt look ubuntu/deb stylish. Its > > > > definitly not a version of the official archives ;). > > > > > > I guess I assumed that "lp" mean launchpad or something, but I'm wrong, > > > it's always PPA :) My bad. > > > > > > And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% > > > likely that your modem is not correctly tagged by HAL, and thus is not > > > recognized by NM. > > > > > > Can you attach the output of 'lshal' (typed into a terminal) to a reply > > > when the 881 is plugged in? > > > > > > Dan > > > > > > > > Yes, it is Linpus Lite on an Aspire One. > > > > Not knowing the relevant bits of the output, I've copied it all below. > > Apologize in advance for the long string. > > Ok, the issue is that your modem is not recognized by the copy of HAL > that Linpus Lite ships. Can you attach your copy of: > > /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi > > and also the output of > > /sbin/lsusb > > when the card is plugged in? > > Thanks! > Dan > > Hello Dan, I don't have a file named 10-modem.fdi, however I have two that seem similar. They are included below. The 10-usb-gsm.fdi file seems to have been added as a part of the bundled "mobile partner" update from Acer/Linpus. To the best of my knowledge, there is no Huawei modem in this notebook. The output from lsusb is below. [EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-modem.fdi modem GSM-07.07 3G modem 3G modem [EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-gsm.fdi modem GSM-07.07 GSM-07.05 [EMAIL PROTECTED] 10freedesktop]$ lsusb Bus 005 Device 001: ID : Bus 004 Device 001: ID : Bus 003 Device 005: ID 045e:00e1 Microsoft Corp. Bus 003 Device 001: ID : Bus 002 Device 010: ID 1199:6856 Sierra Wireless, Inc. Bus 002 Device 001: ID : Bus 001 Device 004: ID 064e:d101 Acer Crystal Eye Webcam Bus 001 Device 001: ID : ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 14:25 -0800, [EMAIL PROTECTED] wrote: > Dan Williams <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: > > > On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > > > > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > > > > Hello, I am a new user to Linux and tried to find the proper > > > resources before seeking help. > > > > > > > > > > I am using NM 0.7.0-lp.0025.o.4 > > > > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > > > > > > > As far as I can tell, I successfully installed the modem driver and > > > > > it is listed as /dev/ttyUSB0 > > > > > > > > > > Unfortunately, when try to dial using wvdial, it says the device is > > > > > busy. So I can't verify that it is working. > > > > > > > > > > Secondarily, if I open the NM window, I am only able to add a wired > > > > > or WiFi connection. So I'm not sure why I can't add the 3G device > > > > > that the docs refer to. > > > > > > > > Is this with Ubuntu? Ubuntu has changed the mobile broadband connection > > > > creation sequence so you may need to file a launchpad bug. > > > > > > the NM version from above doesnt look ubuntu/deb stylish. Its > > > definitly not a version of the official archives ;). > > > > I guess I assumed that "lp" mean launchpad or something, but I'm wrong, > > it's always PPA :) My bad. > > > > And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% > > likely that your modem is not correctly tagged by HAL, and thus is not > > recognized by NM. > > > > Can you attach the output of 'lshal' (typed into a terminal) to a reply > > when the 881 is plugged in? > > > > Dan > > > > > Yes, it is Linpus Lite on an Aspire One. > > Not knowing the relevant bits of the output, I've copied it all below. > Apologize in advance for the long string. Ok, the issue is that your modem is not recognized by the copy of HAL that Linpus Lite ships. Can you attach your copy of: /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi and also the output of /sbin/lsusb when the card is plugged in? Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
Alexander Sack <[EMAIL PROTECTED]> wrote: > On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > > Hello, I am a new user to Linux and tried to find the proper resources > > > before seeking help. > > > > > > I am using NM 0.7.0-lp.0025.o.4 > > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > > > As far as I can tell, I successfully installed the modem driver and it is > > > listed as /dev/ttyUSB0 > > > > > > Unfortunately, when try to dial using wvdial, it says the device is busy. > > > So I can't verify that it is working. > > > > > > Secondarily, if I open the NM window, I am only able to add a wired or > > > WiFi connection. So I'm not sure why I can't add the 3G device that the > > > docs refer to. > > > > Is this with Ubuntu? Ubuntu has changed the mobile broadband connection > > creation sequence so you may need to file a launchpad bug. > > the NM version from above doesnt look ubuntu/deb stylish. Its > definitly not a version of the official archives ;). > > - Alexander > Correct. As Dan noted in a subsequent post, this is Linpus Lite as bundled on the Aspire One. uname -a Linux localhost 2.6.23.9lw #105 SMP PREEMPT Fri Jun 27 18:56:59 EDT 2008 i686 i686 i386 GNU/Linux --Ted ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: blank lines added to /etc/hosts [PATCH]
I think this will fix my issue... only append the newline if we're not parsing
the last line of the file.
--- src/NetworkManagerPolicy.c.orig 2008-11-03 09:33:08.0 -0500
+++ src/NetworkManagerPolicy.c 2008-11-04 17:02:39.0 -0500
@@ -306,7 +306,8 @@
if (add_line) {
g_string_append (new_contents, *line);
- g_string_append_c (new_contents, '\n');
+if (*(line+1)) /* if not the last line */
+ g_string_append_c (new_contents, '\n');
}
}
-Original Message-
From: [EMAIL PROTECTED] on behalf of Miner, Jonathan W (US SSA)
Sent: Tue 11/4/2008 4:54 PM
To: NetworkManager-list@gnome.org
Cc:
Subject:blank lines added to /etc/hosts
Hi -
Each time I unplug, or reconnect my network cable, a blank line gets added to
the end of /etc/hosts.
# wc -l /etc/hosts
4 /etc/hosts
(unplug my cable...)
# wc -l /etc/hosts
5 /etc/hosts
(plug cable back in...)
# wc -l /etc/hosts
6 /etc/hosts
Guessing that it is the g_string_append_c() call on line 309 of
src/NetworkManagerPolicy.c which could needlessly add '\n' characters?
___
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
blank lines added to /etc/hosts
Hi - Each time I unplug, or reconnect my network cable, a blank line gets added to the end of /etc/hosts. # wc -l /etc/hosts 4 /etc/hosts (unplug my cable...) # wc -l /etc/hosts 5 /etc/hosts (plug cable back in...) # wc -l /etc/hosts 6 /etc/hosts Guessing that it is the g_string_append_c() call on line 309 of src/NetworkManagerPolicy.c which could needlessly add '\n' characters? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
Hi Dan, So the first thing that draw me off is that we are stupidly mapping the HAL devices 1:1 to our devices. That is wrong. We should not do this. So for example my Option card has three TTYs and one network device. This all is one device. Currently it shows up as three devices. The number of TTY (control, data or whatever) is an implementation and should not be exposed via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with "modem.command_sets" property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. I don't see how that can be. It was the HSO card and it might need more tweaks than usual. Besides kernel patches ;) hso cards _do_ need more tweaks than usual. They have either one or two control ports, but the HAL magic here is somewhat lacking. We need to "tag" the various ports with "control" or "data" or "gps" or "control2" in addition to determining the command sets. What you're seeing is HAL not being able to tag the ports correctly, because the only way to know this is to check hso-specific sysfs files. We really need a generic way to do this in the kernel drivers. sounds like a good idea. Do you have any proposal for the generic way of tagging the "type" of a TTY. Or is just a todo item? It might be a good idea to natively integrate this into the TTY subsystem instead of having every driver to create sysfs files manually. What _should_ be happening here is that (once Kay creates the repo) that a udev prober checks out each serial port's supported command sets, and stores that info in the udev database. Then, either MM can read that information directly, or we create a small HAL callout that reads the udev database and adds the right modem.command_sets items for backwards compatibility. Then we kill 10-modem.fdi and everyone is happy. I am all for the udev way. Was just checking out Kay's work in libudev and that looks really promising. In short, 'hso' is special and HAL is missing some stuff. It's not really MM's fault. Fair enough. So I am going to see if we can fix HAL somehow to classify my HSO device correctly. I also have one of these new Novatel MC950D from Rogers in Canada that is not recognized by HAL as a GSM modem. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: > On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > > Hello, I am a new user to Linux and tried to find the proper > resources before seeking help. > > > > > > I am using NM 0.7.0-lp.0025.o.4 > > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > > > As far as I can tell, I successfully installed the modem driver and it is > > > listed as /dev/ttyUSB0 > > > > > > Unfortunately, when try to dial using wvdial, it says the device is busy. > > > So I can't verify that it is working. > > > > > > Secondarily, if I open the NM window, I am only able to add a wired or > > > WiFi connection. So I'm not sure why I can't add the 3G device that the > > > docs refer to. > > > > Is this with Ubuntu? Ubuntu has changed the mobile broadband connection > > creation sequence so you may need to file a launchpad bug. > > the NM version from above doesnt look ubuntu/deb stylish. Its > definitly not a version of the official archives ;). I guess I assumed that "lp" mean launchpad or something, but I'm wrong, it's always PPA :) My bad. And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% likely that your modem is not correctly tagged by HAL, and thus is not recognized by NM. Can you attach the output of 'lshal' (typed into a terminal) to a reply when the 881 is plugged in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: location of DHCP lease files
On Tue, 2008-11-04 at 13:52 -0500, Miner, Jonathan W (US SSA) wrote:
> I understand the need for multiple lease files, based on network.
>
> My concern was the two different directories being used. I was trying to
> solve a network problem, and couldn't understand why my lease files were
> several months old... Then I discovered that NM was putting lease files
> somewhere else.
>
> Persistence across boots would require some cooperation with the DHCP server,
> which, in my case, may give me a new IP each time I boot. (It's some 3rd
> party, Windows based DHCP/DNS "solution", which I don't manage)
I'm not opposed to switching back to where dhclient really puts them if
that works better for people. I think the original reason to put them
in /var/run _was_ to blow them away on reboot, but since there's a lot
of suspend/hibernate going on these days thats no longer valid.
Dan
> - Jon
>
>
> -Original Message-
> From: Dan Williams [mailto:[EMAIL PROTECTED]
> Sent: Tue 11/4/2008 1:41 PM
> To: Miner, Jonathan W (US SSA)
> Cc: networkmanager-list@gnome.org
> Subject: Re: location of DHCP lease files
>
> On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
> > Hi -
> >
> > I've noticed that the native Fedora "ifup-eth" script puts its lease files
> > into
> >
> > /var/lib/dhclient/dhclient-${DEVICE}.leases
> >
> > but, NetworkManager puts the lease files into
> >
> > /var/run/dhclient-${DEVICE}.lease
>
> Correct. NM uses different lease files because in the near future,
> we'll want to use separate lease files for _each connection_. Since
> many machines move around, it's pretty pointless to use the same lease
> file for your home AP as for your work AP.
>
> What happens right now is that you'll get a lease from work, dhclient
> will cache it, and then when you come home it'll try to renew that work
> lease at home, leading to DHCP lag. That's bad.
>
> So even if the lease files _did_ stay in the same place as dhclient puts
> them, you'd have a lot more lease files anyway. But, once we modify NM
> to handle leasefile-per-connection, we should probably move them back
> to /var/lib/dhclient just to they are persistent.
>
> I assume you're worried about persistence of the lease across boots?
>
> Dan
>
>
>
>
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: > On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > > Hello, I am a new user to Linux and tried to find the proper resources > > before seeking help. > > > > I am using NM 0.7.0-lp.0025.o.4 > > I am using a Sierra Wireless 881 WCDMA modem with ATT > > > > As far as I can tell, I successfully installed the modem driver and it is > > listed as /dev/ttyUSB0 > > > > Unfortunately, when try to dial using wvdial, it says the device is busy. > > So I can't verify that it is working. > > > > Secondarily, if I open the NM window, I am only able to add a wired or WiFi > > connection. So I'm not sure why I can't add the 3G device that the docs > > refer to. > > Is this with Ubuntu? Ubuntu has changed the mobile broadband connection > creation sequence so you may need to file a launchpad bug. the NM version from above doesnt look ubuntu/deb stylish. Its definitly not a version of the official archives ;). - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
I just submitted a patch for this card up stream? What distro are you running? You try Ubuntu Intrepid ? You will need hal entries for it to find it in your distro. I use the ATT Sierra Wireless now. Only thing with Ubuntu Intrepid (as temporary work around till network manager gets updated), you will need to remove the APN entry. After that it will just works. I use the PCMCIA version of this card with my Thinkpad T61 daily. Jerone On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > Hello, I am a new user to Linux and tried to find the proper resources > before seeking help. > > I am using NM 0.7.0-lp.0025.o.4 > I am using a Sierra Wireless 881 WCDMA modem with ATT > > As far as I can tell, I successfully installed the modem driver and it > is listed as /dev/ttyUSB0 > > Unfortunately, when try to dial using wvdial, it says the device is > busy. So I can't verify that it is working. > > Secondarily, if I open the NM window, I am only able to add a wired or WiFi > connection. So I'm not sure why I can't add the 3G device that the docs > refer to. > > I'm happy to read more, so if there is an existing FAQ that will help, please > point me in that direction. > > I am using this as my baseline: > > http://www.sierrawireless.com/faq/ShowFAQ.aspx?ID=1076 > > Thank you! > > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: location of DHCP lease files
I understand the need for multiple lease files, based on network.
My concern was the two different directories being used. I was trying to solve
a network problem, and couldn't understand why my lease files were several
months old... Then I discovered that NM was putting lease files somewhere else.
Persistence across boots would require some cooperation with the DHCP server,
which, in my case, may give me a new IP each time I boot. (It's some 3rd party,
Windows based DHCP/DNS "solution", which I don't manage)
- Jon
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Tue 11/4/2008 1:41 PM
To: Miner, Jonathan W (US SSA)
Cc: networkmanager-list@gnome.org
Subject:Re: location of DHCP lease files
On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
> Hi -
>
> I've noticed that the native Fedora "ifup-eth" script puts its lease files
> into
>
> /var/lib/dhclient/dhclient-${DEVICE}.leases
>
> but, NetworkManager puts the lease files into
>
> /var/run/dhclient-${DEVICE}.lease
Correct. NM uses different lease files because in the near future,
we'll want to use separate lease files for _each connection_. Since
many machines move around, it's pretty pointless to use the same lease
file for your home AP as for your work AP.
What happens right now is that you'll get a lease from work, dhclient
will cache it, and then when you come home it'll try to renew that work
lease at home, leading to DHCP lag. That's bad.
So even if the lease files _did_ stay in the same place as dhclient puts
them, you'd have a lot more lease files anyway. But, once we modify NM
to handle leasefile-per-connection, we should probably move them back
to /var/lib/dhclient just to they are persistent.
I assume you're worried about persistence of the lease across boots?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM and a AccessPoint
On Tue, 2008-11-04 at 17:24 +0100, Marco Franke wrote: > Good evening, > > I went with a notebook in the range of my AccessPoint and the NetworkManager > need 40s to create with it. Is it normal? Not usually, no, but it depends greatly on how strong the AP's signal is. > How can I get informations about the problem? How can I start the NM with > debug informations? If you could try to create a plain wpa_supplicant config file for your AP, and attempt a connection with that, that is the best way to debug whether it's an NM or a driver issue. If you need help creating that file or running the supplicant, let us know. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot list wireless networks
On Mon, 2008-11-03 at 18:42 -0600, fREW Schmidt wrote: > Ok, so I got networkmanager up and running and I can't see any > networks listed in the add new connection screen. > > I am using knetworkmanager as an interface, but I presume that it's a > lower level issue, so I'll post the output to nm-tool here: When this occurs, as root, does 'iwlist eth1 scan' show any output? Dan > FrewSchmidt2 [8158] % nm-tool > > NetworkManager Tool > > State: connected > > - Device: eth0 > > Type: Wired > Driver:8139too > State: unmanaged > Default: no > HW Address:00:00:00:00:00:00 > > Capabilities: > Supported: yes > Carrier Detect: yes > Speed: 100 Mb/s > > Wired Settings > > > - Device: eth1 > > Type: 802.11 WiFi > Driver:ipw2200 > State: unmanaged > Default: no > HW Address:00:00:00:00:00:00 > > Capabilities: > Supported: yes > > Wireless Settings > WEP Encryption: yes > WPA Encryption: yes > WPA2 Encryption: yes > > Wireless Access Points > > > Any ideas? > > -- > > -fREW > ___ > 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: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: > Hello, I am a new user to Linux and tried to find the proper resources before > seeking help. > > I am using NM 0.7.0-lp.0025.o.4 > I am using a Sierra Wireless 881 WCDMA modem with ATT > > As far as I can tell, I successfully installed the modem driver and it is > listed as /dev/ttyUSB0 > > Unfortunately, when try to dial using wvdial, it says the device is busy. So > I can't verify that it is working. > > Secondarily, if I open the NM window, I am only able to add a wired or WiFi > connection. So I'm not sure why I can't add the 3G device that the docs > refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. Does 'lshal | grep -i gsm' show anything, and if so, what? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, 2008-11-04 at 15:54 +0100, Pablo Martí wrote: > On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote: > >> Sure! I also think that the Firefox approach is not the right one, is > >> just that I'm not very fond on NM's dispatcher > >> architecture/capabilities. I kinda like the description/mockup given > >> here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a > >> dispatcher script[1]. > >> > >> [0] > >> http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/ > >> [1] > >> http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html > >> > > > > OK thanks for the links. I really think this can be done outside of NM > > applet to things started. > > > > Writing a wispr-applet that listens to D-Bus events from NM and which > > does the wispr probing and authentication business should be fairly > > easy. > > Thanks for the input Alexander, much appreciated. What do other > developers think of this approach? Tambet? Dan? Shouldn't be part of NM, but NM should expose all the necessary information to allow auto-login to be possible using external tools. If that includes requesting WSP information explicitly from the DHCP server, that's great, we should add that. The DHCP information is already exposed over D-Bus and thus any app that listens for NM events should be able to get it. You can tie specific logins pretty easily to each connection's UUID, thus if you know that your "Starbucks" connection just came up (as opposed to any other connection) you could certainly match that up with stored credentials and try to auto-login with those first before doing any probing or whatever. Basically, if the AP is at least WPA encrypted, and NM connected, there's a 95% chance that nobody is spoofing the connection, and that you really are connected to Starbucks, so you can save some time probing by just trying stored Starbucks auth info first, maybe. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: location of DHCP lease files
On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
> Hi -
>
> I've noticed that the native Fedora "ifup-eth" script puts its lease files
> into
>
> /var/lib/dhclient/dhclient-${DEVICE}.leases
>
> but, NetworkManager puts the lease files into
>
> /var/run/dhclient-${DEVICE}.lease
Correct. NM uses different lease files because in the near future,
we'll want to use separate lease files for _each connection_. Since
many machines move around, it's pretty pointless to use the same lease
file for your home AP as for your work AP.
What happens right now is that you'll get a lease from work, dhclient
will cache it, and then when you come home it'll try to renew that work
lease at home, leading to DHCP lag. That's bad.
So even if the lease files _did_ stay in the same place as dhclient puts
them, you'd have a lot more lease files anyway. But, once we modify NM
to handle leasefile-per-connection, we should probably move them back
to /var/lib/dhclient just to they are persistent.
I assume you're worried about persistence of the lease across boots?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Problems with NM seeing 3G modem
Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. I'm happy to read more, so if there is an existing FAQ that will help, please point me in that direction. I am using this as my baseline: http://www.sierrawireless.com/faq/ShowFAQ.aspx?ID=1076 Thank you! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, 2008-11-04 at 10:04 +0100, Marcel Holtmann wrote: > Hi Tambet, > > >> So the first thing that draw me off is that we are stupidly mapping > >> the HAL > >> devices 1:1 to our devices. That is wrong. We should not do this. > >> So for > >> example my Option card has three TTYs and one network device. This > >> all is > >> one device. Currently it shows up as three devices. The number of TTY > >> (control, data or whatever) is an implementation and should not be > >> exposed > >> via the API. So we have to be smart with this. > > > > With the generic implementation, MM maps a HAL device with > > "modem.command_sets" property as a single device. So if you got 3, it > > means your HAL .fdi file is incorrect. > > I don't see how that can be. It was the HSO card and it might need > more tweaks than usual. Besides kernel patches ;) hso cards _do_ need more tweaks than usual. They have either one or two control ports, but the HAL magic here is somewhat lacking. We need to "tag" the various ports with "control" or "data" or "gps" or "control2" in addition to determining the command sets. What you're seeing is HAL not being able to tag the ports correctly, because the only way to know this is to check hso-specific sysfs files. We really need a generic way to do this in the kernel drivers. What _should_ be happening here is that (once Kay creates the repo) that a udev prober checks out each serial port's supported command sets, and stores that info in the udev database. Then, either MM can read that information directly, or we create a small HAL callout that reads the udev database and adds the right modem.command_sets items for backwards compatibility. Then we kill 10-modem.fdi and everyone is happy. In short, 'hso' is special and HAL is missing some stuff. It's not really MM's fault. Dan > >> The second thing is that the Manager interface talks about devices, > >> while > >> the main interface to the hardware is called Modem. So that should be > >> consistent. Either we call them devices or modems. > > > > Agreed. I initially had modems everywhere, but then thought it would > > be more consistent in the big picture if it resembled > > org.freedesktop.DeviceKit.Disks > > (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So > > EnumerateModems was renamed to EnumerateDevices while the modem > > interfaces didn't change. Just the reason behind it. > > Then just rename the interface to Device and everything will be fine. > > >> The Modem interface has a Connect method call that takes a > >> parameter number. > >> This makes no sense whatsoever. Connect should not take any > >> arguments it > >> should connect with whatever has been configured or be smart and > >> auto-configure it. Especially since you don't know if you are using > >> a real > >> number or actually an APN or something else. > > > > Modem interface is for all modems. Landline, GSM, CDMA, ... It is up > > to the specific implementation to validate and use the number. All the > > modems I've ever seen (and the dial command 'D' in the spec) take a > > number, so it makes perfect sense to me. > > Actually it doesn't. You should have some kind of method to setup your > device. So for example call Device.Setup(dict). You can give it a key > "Number" or key "APN" and then it will do the right calls. > > Actually the magic ATD*99*# crap is just something ETSI invented > because every OS was using weird and broken dialer scripts at that > time. There are proper commands when attaching a GPRS/UMTS link. Also > the HSO based cards don't use numbers. > > If you do the Setup method call once, then you can call Connect/ > Disconnect multiple times without modifying your setup or giving it a > number all the time. It just no consistent to give the APN one way and > the number the other way. And also some device don't use numbers at > all. We should really hide this implementation detail. > > >> And then we have Enable with a parameter. Don't do that. Just add > >> Enable and > >> Disable methods. Otherwise the API looks weird. Also signals like > >> Connected, > >> Enabled etc. are missing. > > > > It doesn't look weird to me. In real life you don't have two switches > > to turn things on/off, and to me it would look weird if my modem has > > two physical buttons: one to turn it on, and another to turn it off. > > In short it's a personal opinion and doesn't make much sense to argue > > about. > > It is weird in conjunction with Connect/Disconnect and then Enable > takes a parameter where TRUE means "enable" and FALSE means "disble". > > > There is no need for Connected and Enabled signals because the method > > to Enable/Connect doesn't return before it's done. That does not mean > > MM is not async, it accepts other commands and is responsive while > > Enable/Connect/any other method is pending. > > The async here means if other applications wants to monitor the > status. For examp
location of DHCP lease files
Hi -
I've noticed that the native Fedora "ifup-eth" script puts its lease files into
/var/lib/dhclient/dhclient-${DEVICE}.leases
but, NetworkManager puts the lease files into
/var/run/dhclient-${DEVICE}.lease
It looks like this is coming from nm-dhcp-manager.h, which builds
NM_DHCP_MANAGER_RUN_DIR from LOCALSTATEDIR and the constant "/run". The
localstatedir is set to /var in the top level Makefile.
Is this inconsistency related to running an SVN version (r4254), when compared
to an official Fedora yum update?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Problems with NM and a AccessPoint
Good evening, I went with a notebook in the range of my AccessPoint and the NetworkManager need 40s to create with it. Is it normal? How can I get informations about the problem? How can I start the NM with debug informations? Thanks -- Mfg der bijektive Homomorphismus ist ein Isomorphismus Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 4:10 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 4:54 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
>> On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>>> OK thanks for the links. I really think this can be done outside of NM
>>> applet to things started.
>>>
>>> Writing a wispr-applet that listens to D-Bus events from NM and which
>>> does the wispr probing and authentication business should be fairly
>>> easy.
>>
>> Thanks for the input Alexander, much appreciated. What do other
>> developers think of this approach? Tambet? Dan?
>
> I agree it should be done outside of NM. That's the point of having a
> stable (yeah, yeah, we'll get to that eventually) public DBus API.
Alright, thanks! I was still doubting between a separate process and a
dispatcher script, but it seems that the consensus is a separate
process. Thanks all for the input!
>
> Tambet
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 4:54 PM, Pablo Martí <[EMAIL PROTECTED]> wrote: > On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: >> OK thanks for the links. I really think this can be done outside of NM >> applet to things started. >> >> Writing a wispr-applet that listens to D-Bus events from NM and which >> does the wispr probing and authentication business should be fairly >> easy. > > Thanks for the input Alexander, much appreciated. What do other > developers think of this approach? Tambet? Dan? I agree it should be done outside of NM. That's the point of having a stable (yeah, yeah, we'll get to that eventually) public DBus API. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote:
>> Sure! I also think that the Firefox approach is not the right one, is
>> just that I'm not very fond on NM's dispatcher
>> architecture/capabilities. I kinda like the description/mockup given
>> here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a
>> dispatcher script[1].
>>
>> [0]
>> http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/
>> [1]
>> http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html
>>
>
> OK thanks for the links. I really think this can be done outside of NM
> applet to things started.
>
> Writing a wispr-applet that listens to D-Bus events from NM and which
> does the wispr probing and authentication business should be fairly
> easy.
Thanks for the input Alexander, much appreciated. What do other
developers think of this approach? Tambet? Dan?
Regards,
>
> - Alexander
>
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:10 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 3:06 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
>> No, the very first time you interact with the hotspot, you'll be
>> redirected to the login page anyway. You'll have to accept the ToS and
>> *pay*. The use-case discussed here is after paying for the access, not
>> having to explicitly log in the hotspot every time you want to use
>> afterwards
>
> Then it's entirely doable as a Firefox extension without any NM
> integration (check if the page is the login one, submit data and
> reload) or easily doable using python, dbus and curl (wait for
> connection, check SSID, if matching call curl with necessary POST
> payload - could be read from the keyring).
It is doable sure, but it depends on the context. What if you have no
firefox on the system. What if you just want to irssi a bit? Coupling
the solution to firefox is a no-go IMHO and is already done[0].
[0] http://coova.org/wiki/index.php/CoovaFX
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote: > Sure! I also think that the Firefox approach is not the right one, is > just that I'm not very fond on NM's dispatcher > architecture/capabilities. I kinda like the description/mockup given > here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a > dispatcher script[1]. > > [0] > http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/ > [1] > http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html > OK thanks for the links. I really think this can be done outside of NM applet to things started. Writing a wispr-applet that listens to D-Bus events from NM and which does the wispr probing and authentication business should be fairly easy. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
El mar, 04-11-2008 a las 15:02 +0100, Patryk Zawadzki escribió: > On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: > >> The benefit is that the user is not redirected to the hotspot webpage, > >> but is logged in automatically. It might seem a silly difference, but > >> is a requested feature. Our customer requires WISPr/WSP capabilities > >> and I'm very interested in the outcome of this thread. > > I agree that it would be nice to be automatically logged in, but I > > don't clearly see how why we need firefox to do that authentication. > > > > Another idea would be to write a tray applet that recognizes when NM > > goes online and the probes whether it gets redirected to hotspot > > site. If thats the case the tray thing would authenticate and would > > allow users also to end that session later (from the tray). This could > > be done by nm applet itself, but as we dont really have a plugin > > infrastructure for that yet I would suggest to make that a standalone > > tray tool until we have more experience on what we really want > > here. Would that work? > > I think the important question is: isn't this a direct violation of > the ToS? By automatically doing something that was created to enforce > user interaction you are creating a tool that silently accepts all > licenses, terms and conditions without notifying the user. Uhmmm not really sure... It seems it tries to be a standard thing: "WISPr was the first step toward standardizing HotSpot authentication."[0] Moreover, this is not the first time this protocol is around this list[1], although the answer was the same as the beginning of this thread [0]http://en.wikipedia.org/wiki/WISPr [1]http://mail.gnome.org/archives/networkmanager-list/2007-September/msg0.html Kind regards, -- Daniel Baeyens ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote:
>> On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>> > On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
>> >> On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>> >> > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
>> >> >>
>> >> >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID
>> >> >> you need it for and you're done.
>> >> >
>> >> > Do we have per-user dispatcher scripts or are you suggesting to open
>> >> > the browser as root here :) ?
>> >>
>> >> Ok, you're right, but listening for a DBus signal from a user process
>> >> isn't all that hard either. Or do you prefer NM executing firefox
>> >> directly (as root) like the original mail suggested?
>> >>
>> >
>> > Dbus would work. However, I dont really understand the use-case this
>> > is supposed to cover. The browser usually redirects to the login site
>> > anyway? What benefit would the user by such a firefox extension?
>>
>> The benefit is that the user is not redirected to the hotspot webpage,
>> but is logged in automatically. It might seem a silly difference, but
>> is a requested feature. Our customer requires WISPr/WSP capabilities
>> and I'm very interested in the outcome of this thread.
>
> I agree that it would be nice to be automatically logged in, but I
> don't clearly see how why we need firefox to do that authentication.
>
> Another idea would be to write a tray applet that recognizes when NM
> goes online and the probes whether it gets redirected to hotspot
> site. If thats the case the tray thing would authenticate and would
> allow users also to end that session later (from the tray). This could
> be done by nm applet itself, but as we dont really have a plugin
> infrastructure for that yet I would suggest to make that a standalone
> tray tool until we have more experience on what we really want
> here. Would that work?
Sure! I also think that the Firefox approach is not the right one, is
just that I'm not very fond on NM's dispatcher
architecture/capabilities. I kinda like the description/mockup given
here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a
dispatcher script[1].
[0] http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/
[1]
http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html
>
>
> - Alexander
>
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:06 PM, Pablo Martí <[EMAIL PROTECTED]> wrote: > No, the very first time you interact with the hotspot, you'll be > redirected to the login page anyway. You'll have to accept the ToS and > *pay*. The use-case discussed here is after paying for the access, not > having to explicitly log in the hotspot every time you want to use > afterwards Then it's entirely doable as a Firefox extension without any NM integration (check if the page is the login one, submit data and reload) or easily doable using python, dbus and curl (wait for connection, check SSID, if matching call curl with necessary POST payload - could be read from the keyring). -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 03:02:04PM +0100, Patryk Zawadzki wrote: > On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: > >> The benefit is that the user is not redirected to the hotspot webpage, > >> but is logged in automatically. It might seem a silly difference, but > >> is a requested feature. Our customer requires WISPr/WSP capabilities > >> and I'm very interested in the outcome of this thread. > > I agree that it would be nice to be automatically logged in, but I > > don't clearly see how why we need firefox to do that authentication. > > > > Another idea would be to write a tray applet that recognizes when NM > > goes online and the probes whether it gets redirected to hotspot > > site. If thats the case the tray thing would authenticate and would > > allow users also to end that session later (from the tray). This could > > be done by nm applet itself, but as we dont really have a plugin > > infrastructure for that yet I would suggest to make that a standalone > > tray tool until we have more experience on what we really want > > here. Would that work? > > I think the important question is: isn't this a direct violation of > the ToS? By automatically doing something that was created to enforce > user interaction you are creating a tool that silently accepts all > licenses, terms and conditions without notifying the user. > >From what i understand the user would still have to provide some form of credentials. Thus the user would be presented at minimum an initial login dialog, where he probably could opt-in for auto login in the future. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:02 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>> On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote:
>>> The benefit is that the user is not redirected to the hotspot webpage,
>>> but is logged in automatically. It might seem a silly difference, but
>>> is a requested feature. Our customer requires WISPr/WSP capabilities
>>> and I'm very interested in the outcome of this thread.
>> I agree that it would be nice to be automatically logged in, but I
>> don't clearly see how why we need firefox to do that authentication.
>>
>> Another idea would be to write a tray applet that recognizes when NM
>> goes online and the probes whether it gets redirected to hotspot
>> site. If thats the case the tray thing would authenticate and would
>> allow users also to end that session later (from the tray). This could
>> be done by nm applet itself, but as we dont really have a plugin
>> infrastructure for that yet I would suggest to make that a standalone
>> tray tool until we have more experience on what we really want
>> here. Would that work?
>
> I think the important question is: isn't this a direct violation of
> the ToS? By automatically doing something that was created to enforce
> user interaction you are creating a tool that silently accepts all
> licenses, terms and conditions without notifying the user.
No, the very first time you interact with the hotspot, you'll be
redirected to the login page anyway. You'll have to accept the ToS and
*pay*. The use-case discussed here is after paying for the access, not
having to explicitly log in the hotspot every time you want to use
afterwards
Pablo
>
> --
> Patryk Zawadzki
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: >> The benefit is that the user is not redirected to the hotspot webpage, >> but is logged in automatically. It might seem a silly difference, but >> is a requested feature. Our customer requires WISPr/WSP capabilities >> and I'm very interested in the outcome of this thread. > I agree that it would be nice to be automatically logged in, but I > don't clearly see how why we need firefox to do that authentication. > > Another idea would be to write a tray applet that recognizes when NM > goes online and the probes whether it gets redirected to hotspot > site. If thats the case the tray thing would authenticate and would > allow users also to end that session later (from the tray). This could > be done by nm applet itself, but as we dont really have a plugin > infrastructure for that yet I would suggest to make that a standalone > tray tool until we have more experience on what we really want > here. Would that work? I think the important question is: isn't this a direct violation of the ToS? By automatically doing something that was created to enforce user interaction you are creating a tool that silently accepts all licenses, terms and conditions without notifying the user. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: > On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote: > >> On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > >> > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: > >> >> > >> >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID > >> >> you need it for and you're done. > >> > > >> > Do we have per-user dispatcher scripts or are you suggesting to open > >> > the browser as root here :) ? > >> > >> Ok, you're right, but listening for a DBus signal from a user process > >> isn't all that hard either. Or do you prefer NM executing firefox > >> directly (as root) like the original mail suggested? > >> > > > > Dbus would work. However, I dont really understand the use-case this > > is supposed to cover. The browser usually redirects to the login site > > anyway? What benefit would the user by such a firefox extension? > > The benefit is that the user is not redirected to the hotspot webpage, > but is logged in automatically. It might seem a silly difference, but > is a requested feature. Our customer requires WISPr/WSP capabilities > and I'm very interested in the outcome of this thread. I agree that it would be nice to be automatically logged in, but I don't clearly see how why we need firefox to do that authentication. Another idea would be to write a tray applet that recognizes when NM goes online and the probes whether it gets redirected to hotspot site. If thats the case the tray thing would authenticate and would allow users also to end that session later (from the tray). This could be done by nm applet itself, but as we dont really have a plugin infrastructure for that yet I would suggest to make that a standalone tray tool until we have more experience on what we really want here. Would that work? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:13 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>> On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
>>> On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>>> > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
>>> >>
>>> >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID
>>> >> you need it for and you're done.
>>> >
>>> > Do we have per-user dispatcher scripts or are you suggesting to open
>>> > the browser as root here :) ?
>>>
>>> Ok, you're right, but listening for a DBus signal from a user process
>>> isn't all that hard either. Or do you prefer NM executing firefox
>>> directly (as root) like the original mail suggested?
>>>
>>
>> Dbus would work. However, I dont really understand the use-case this
>> is supposed to cover. The browser usually redirects to the login site
>> anyway? What benefit would the user by such a firefox extension?
>
> The benefit is that the user is not redirected to the hotspot webpage,
> but is logged in automatically. It might seem a silly difference, but
> is a requested feature. Our customer requires WISPr/WSP capabilities
> and I'm very interested in the outcome of this thread.
s/WSP//g mental corruption here :)
>
> Pablo
>
>>
>>
>> - Alexander
>>
>> ___
>> NetworkManager-list mailing list
>> NetworkManager-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>>
>
>
>
> --
> Pablo Martí
> http://www.linkedin.com/in/pmarti || http://www.warp.es
> python -c "print '706d6172746940776172702e6573'.decode('hex')"
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
>> On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote:
>> > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
>> >>
>> >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID
>> >> you need it for and you're done.
>> >
>> > Do we have per-user dispatcher scripts or are you suggesting to open
>> > the browser as root here :) ?
>>
>> Ok, you're right, but listening for a DBus signal from a user process
>> isn't all that hard either. Or do you prefer NM executing firefox
>> directly (as root) like the original mail suggested?
>>
>
> Dbus would work. However, I dont really understand the use-case this
> is supposed to cover. The browser usually redirects to the login site
> anyway? What benefit would the user by such a firefox extension?
The benefit is that the user is not redirected to the hotspot webpage,
but is logged in automatically. It might seem a silly difference, but
is a requested feature. Our customer requires WISPr/WSP capabilities
and I'm very interested in the outcome of this thread.
Pablo
>
>
> - Alexander
>
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote: > On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: > >> > >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID > >> you need it for and you're done. > > > > Do we have per-user dispatcher scripts or are you suggesting to open > > the browser as root here :) ? > > Ok, you're right, but listening for a DBus signal from a user process > isn't all that hard either. Or do you prefer NM executing firefox > directly (as root) like the original mail suggested? > Dbus would work. However, I dont really understand the use-case this is supposed to cover. The browser usually redirects to the login site anyway? What benefit would the user by such a firefox extension? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: >> >> Add a dispatcher script that runs "xdg-open $url" for a specific SSID >> you need it for and you're done. > > Do we have per-user dispatcher scripts or are you suggesting to open > the browser as root here :) ? Ok, you're right, but listening for a DBus signal from a user process isn't all that hard either. Or do you prefer NM executing firefox directly (as root) like the original mail suggested? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: > > Add a dispatcher script that runs "xdg-open $url" for a specific SSID > you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 11:01 AM, Tomas Kovacik <[EMAIL PROTECTED]> wrote: > and this is HAL .fdi problem?: > > dmesg: > [82410.648181] usb 2-2: new full speed USB device using uhci_hcd and address > 2 > [82410.821948] usb 2-2: configuration #1 chosen from 1 choice > [82411.050542] cdc_acm 2-2:1.1: ttyACM0: USB ACM device > [82411.053368] cdc_acm 2-2:1.3: ttyACM1: USB ACM device > [82411.055246] usbcore: registered new interface driver cdc_acm > [82411.055256] cdc_acm: v0.26:USB Abstract Control Model driver for USB > modems and ISDN adapters > > SE w810i, usb cable No, you don't get HAL logging from dmesg. It's OK to have multiple serial devices per one physical modem, but it's a bug to have 'lshal | grep -i gsm | wc -l' print out higher number than one when you have a single modem. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
Hi Tambet, So the first thing that draw me off is that we are stupidly mapping the HAL devices 1:1 to our devices. That is wrong. We should not do this. So for example my Option card has three TTYs and one network device. This all is one device. Currently it shows up as three devices. The number of TTY (control, data or whatever) is an implementation and should not be exposed via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with "modem.command_sets" property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. I don't see how that can be. It was the HSO card and it might need more tweaks than usual. Besides kernel patches ;) The second thing is that the Manager interface talks about devices, while the main interface to the hardware is called Modem. So that should be consistent. Either we call them devices or modems. Agreed. I initially had modems everywhere, but then thought it would be more consistent in the big picture if it resembled org.freedesktop.DeviceKit.Disks (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So EnumerateModems was renamed to EnumerateDevices while the modem interfaces didn't change. Just the reason behind it. Then just rename the interface to Device and everything will be fine. The Modem interface has a Connect method call that takes a parameter number. This makes no sense whatsoever. Connect should not take any arguments it should connect with whatever has been configured or be smart and auto-configure it. Especially since you don't know if you are using a real number or actually an APN or something else. Modem interface is for all modems. Landline, GSM, CDMA, ... It is up to the specific implementation to validate and use the number. All the modems I've ever seen (and the dial command 'D' in the spec) take a number, so it makes perfect sense to me. Actually it doesn't. You should have some kind of method to setup your device. So for example call Device.Setup(dict). You can give it a key "Number" or key "APN" and then it will do the right calls. Actually the magic ATD*99*# crap is just something ETSI invented because every OS was using weird and broken dialer scripts at that time. There are proper commands when attaching a GPRS/UMTS link. Also the HSO based cards don't use numbers. If you do the Setup method call once, then you can call Connect/ Disconnect multiple times without modifying your setup or giving it a number all the time. It just no consistent to give the APN one way and the number the other way. And also some device don't use numbers at all. We should really hide this implementation detail. And then we have Enable with a parameter. Don't do that. Just add Enable and Disable methods. Otherwise the API looks weird. Also signals like Connected, Enabled etc. are missing. It doesn't look weird to me. In real life you don't have two switches to turn things on/off, and to me it would look weird if my modem has two physical buttons: one to turn it on, and another to turn it off. In short it's a personal opinion and doesn't make much sense to argue about. It is weird in conjunction with Connect/Disconnect and then Enable takes a parameter where TRUE means "enable" and FALSE means "disble". There is no need for Connected and Enabled signals because the method to Enable/Connect doesn't return before it's done. That does not mean MM is not async, it accepts other commands and is responsive while Enable/Connect/any other method is pending. The async here means if other applications wants to monitor the status. For example if you have an applet just indicating if it is connected or not (but never calling Connect by itself). For that we need the signals. So the split between Modem interface and Gsm.Card make no real sense to me. I would just convert everything into properties or create a GetProperties method to retrieve one dictionary with all the information. All the GetImei, GetImsi calls only create round-trips to D-Bus that can be avoided. If one technology doesn't have IMSI, then this property is just missing. Again, it's your opinion. In my opinion, when I need IMEI, I don't want the modem to issue 50 AT commands to get all the properties. We can cache the properties. Since when doing Enable we can issue the AT commands for the values that are not changing and then just cache them. And for setting things like the APN etc, you can use writable properties or a SetProperty method. So you could just set all properties and then call Connect. To make this fully async, a signal PropertyChanged would be needed, too. So Enable(bool) looks weird to you and then you suggest the whole API to consist of 2 methods (SetStuff() and GetStuff()). Again, your personal opinion I don't agree with. I don't care about the Enable and how it is done, but you have to see the whole picture here.
Re: ModemManager API review
Tambet Ingo wrote: > On Tue, Nov 4, 2008 at 3:54 AM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > >> So the first thing that draw me off is that we are stupidly mapping the HAL >> devices 1:1 to our devices. That is wrong. We should not do this. So for >> example my Option card has three TTYs and one network device. This all is >> one device. Currently it shows up as three devices. The number of TTY >> (control, data or whatever) is an implementation and should not be exposed >> via the API. So we have to be smart with this. >> > > With the generic implementation, MM maps a HAL device with > "modem.command_sets" property as a single device. So if you got 3, it > means your HAL .fdi file is incorrect. > > and this is HAL .fdi problem?: dmesg: [82410.648181] usb 2-2: new full speed USB device using uhci_hcd and address 2 [82410.821948] usb 2-2: configuration #1 chosen from 1 choice [82411.050542] cdc_acm 2-2:1.1: ttyACM0: USB ACM device [82411.053368] cdc_acm 2-2:1.3: ttyACM1: USB ACM device [82411.055246] usbcore: registered new interface driver cdc_acm [82411.055256] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters SE w810i, usb cable t. >> The second thing is that the Manager interface talks about devices, while >> the main interface to the hardware is called Modem. So that should be >> consistent. Either we call them devices or modems. >> > > Agreed. I initially had modems everywhere, but then thought it would > be more consistent in the big picture if it resembled > org.freedesktop.DeviceKit.Disks > (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So > EnumerateModems was renamed to EnumerateDevices while the modem > interfaces didn't change. Just the reason behind it. > > >> The Modem interface has a Connect method call that takes a parameter number. >> This makes no sense whatsoever. Connect should not take any arguments it >> should connect with whatever has been configured or be smart and >> auto-configure it. Especially since you don't know if you are using a real >> number or actually an APN or something else. >> > > Modem interface is for all modems. Landline, GSM, CDMA, ... It is up > to the specific implementation to validate and use the number. All the > modems I've ever seen (and the dial command 'D' in the spec) take a > number, so it makes perfect sense to me. > > >> And then we have Enable with a parameter. Don't do that. Just add Enable and >> Disable methods. Otherwise the API looks weird. Also signals like Connected, >> Enabled etc. are missing. >> > > It doesn't look weird to me. In real life you don't have two switches > to turn things on/off, and to me it would look weird if my modem has > two physical buttons: one to turn it on, and another to turn it off. > In short it's a personal opinion and doesn't make much sense to argue > about. > > There is no need for Connected and Enabled signals because the method > to Enable/Connect doesn't return before it's done. That does not mean > MM is not async, it accepts other commands and is responsive while > Enable/Connect/any other method is pending. > > >> So the split between Modem interface and Gsm.Card make no real sense to me. >> I would just convert everything into properties or create a GetProperties >> method to retrieve one dictionary with all the information. All the GetImei, >> GetImsi calls only create round-trips to D-Bus that can be avoided. If one >> technology doesn't have IMSI, then this property is just missing. >> > > Again, it's your opinion. In my opinion, when I need IMEI, I don't > want the modem to issue 50 AT commands to get all the properties. > > >> And for setting things like the APN etc, you can use writable properties or >> a SetProperty method. So you could just set all properties and then call >> Connect. To make this fully async, a signal PropertyChanged would be needed, >> too. >> > > So Enable(bool) looks weird to you and then you suggest the whole API > to consist of 2 methods (SetStuff() and GetStuff()). Again, your > personal opinion I don't agree with. > > >> And on that matter, please don't use enums since higher level languages >> don't really have the concept of includes from a C definition. So if you >> wanna give the band information you can just say "gsm900", "gsm1800" etc. >> Also for the mode having things like "connect", "connecting" etc. make it a >> lot easier to develop and debug. And when using dbus-monitor is shows up in >> clear text. >> > > Every UI needs to translate enums to localized strings and back so all > the possible values need to be defined anyway. It's easier to do it > with integers than strings. > > >> Some things like GetRegistrationInfo are just better separated into >> properties or key/value pairs in a dictionary. That keeps the API small and >> also flexible for future changes. >> > > This is something I finally agree on! :) > > >> So the network details o
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:41 AM, Slokunshialgo <[EMAIL PROTECTED]> wrote: > I know I posted something about this awhile ago, but thinking about it a > bit more, a couple of questions and ideas have arisen in my mind. For > those who may not have read this before, the idea is to have something > using NetworkManager to automatically log in to web-authenticated > networks (ie: hotspots in a cafe) when it connects to specific networks. > > I have three ideas on how to implement this, but they all revolve around > the idea of having a Firefox extension that would listen to dbus signals > being sent by nm, and when told to, would go to a specific webpage to > log in, using Firefox's password storage. > > 1) Have nm check to see if Firefox is open, if not, open it and send the > signal > 2) Make nm have nothing to do with the extension, but merely sending its > regular signals and FF picking them up > 3) Make nm send modified signals specifically for the autologin, letting > any program pick them up (such as network name, URL to visit, etc) > > Judging by before, I doubt #1 would be the best idea (forcing FF to be > installed is not good), #2 may or may not work, but I think #3 would be > best. To get around whether FF is open or not, a small program could be > written to start on login (separate from nm) that would listen for the > signals, start FF, and pass it along. > > As for the technical side of this, it's primarily, what sort of > information does nm send through dbus, and are multiple programs able to > pick up on it? > > Opinions, ideas, information? Add a dispatcher script that runs "xdg-open $url" for a specific SSID you need it for and you're done. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 3:54 AM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > So the first thing that draw me off is that we are stupidly mapping the HAL > devices 1:1 to our devices. That is wrong. We should not do this. So for > example my Option card has three TTYs and one network device. This all is > one device. Currently it shows up as three devices. The number of TTY > (control, data or whatever) is an implementation and should not be exposed > via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with "modem.command_sets" property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. > The second thing is that the Manager interface talks about devices, while > the main interface to the hardware is called Modem. So that should be > consistent. Either we call them devices or modems. Agreed. I initially had modems everywhere, but then thought it would be more consistent in the big picture if it resembled org.freedesktop.DeviceKit.Disks (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So EnumerateModems was renamed to EnumerateDevices while the modem interfaces didn't change. Just the reason behind it. > The Modem interface has a Connect method call that takes a parameter number. > This makes no sense whatsoever. Connect should not take any arguments it > should connect with whatever has been configured or be smart and > auto-configure it. Especially since you don't know if you are using a real > number or actually an APN or something else. Modem interface is for all modems. Landline, GSM, CDMA, ... It is up to the specific implementation to validate and use the number. All the modems I've ever seen (and the dial command 'D' in the spec) take a number, so it makes perfect sense to me. > And then we have Enable with a parameter. Don't do that. Just add Enable and > Disable methods. Otherwise the API looks weird. Also signals like Connected, > Enabled etc. are missing. It doesn't look weird to me. In real life you don't have two switches to turn things on/off, and to me it would look weird if my modem has two physical buttons: one to turn it on, and another to turn it off. In short it's a personal opinion and doesn't make much sense to argue about. There is no need for Connected and Enabled signals because the method to Enable/Connect doesn't return before it's done. That does not mean MM is not async, it accepts other commands and is responsive while Enable/Connect/any other method is pending. > So the split between Modem interface and Gsm.Card make no real sense to me. > I would just convert everything into properties or create a GetProperties > method to retrieve one dictionary with all the information. All the GetImei, > GetImsi calls only create round-trips to D-Bus that can be avoided. If one > technology doesn't have IMSI, then this property is just missing. Again, it's your opinion. In my opinion, when I need IMEI, I don't want the modem to issue 50 AT commands to get all the properties. > And for setting things like the APN etc, you can use writable properties or > a SetProperty method. So you could just set all properties and then call > Connect. To make this fully async, a signal PropertyChanged would be needed, > too. So Enable(bool) looks weird to you and then you suggest the whole API to consist of 2 methods (SetStuff() and GetStuff()). Again, your personal opinion I don't agree with. > And on that matter, please don't use enums since higher level languages > don't really have the concept of includes from a C definition. So if you > wanna give the band information you can just say "gsm900", "gsm1800" etc. > Also for the mode having things like "connect", "connecting" etc. make it a > lot easier to develop and debug. And when using dbus-monitor is shows up in > clear text. Every UI needs to translate enums to localized strings and back so all the possible values need to be defined anyway. It's easier to do it with integers than strings. > Some things like GetRegistrationInfo are just better separated into > properties or key/value pairs in a dictionary. That keeps the API small and > also flexible for future changes. This is something I finally agree on! :) > So the network details on GSM are not really that interesting at all. I > would leave them out for now. However I do think that representing every > network as object path would be a better approach here. Network details and the signal quality are the biggest reason I started ModemManager, the most often asked features in this list. Why would they need to be DBus objects with paths? What methods do you think a network would have? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
