Re: [PATCH] hal probe modem caps ondemand
2008/5/6 Alex Kanavin [EMAIL PROTECTED]:
2008/5/4 Vitja Makarov [EMAIL PROTECTED]:
Probe CDC-ACM modems, found in most cell phones on the fly, using
AT+GCAP modem command.
I tested it with 1 Nokia GSM phone, and 2 CDMA.
In practice most if not all phones seem to use protocol 1 (generic
v.25) in their usb interface descriptions and require probing, but it
wouldn't hurt to list the other protocols as well. Otherwise, the
patch seems fine to me (if the coding style is ok - someone else
should review that). A much simpler patch for just tagging interface
class 2/subclass 2 devices as modems has just been committed, so you
should redo your patch against that.
--
Alexander
I'm wondering what for are CDMA, 3G, GSM subclasses.
Here is new version of patch.
It simply calls prober for V.250 CDC-ACM modems.
Also I don't understand why we don't check interface.class and only
test interface.subclass?
and some prober fixes, I'm not sure it should lay in
hald/linux/probing as it's actually callout,
but can be used as prober too.
vitja.
diff --git a/fdi/information/10freedesktop/10-modem.fdi b/fdi/information/10freedesktop/10-modem.fdi
index b5b6200..57490fd 100644
--- a/fdi/information/10freedesktop/10-modem.fdi
+++ b/fdi/information/10freedesktop/10-modem.fdi
@@ -282,6 +282,7 @@
match key=@info.parent:usb.interface.subclass int=0x02
append key=info.capabilities type=strlistmodem/append
append key=modem.command_sets type=strlistV.250/append
+ append key=info.callouts.add type=strlisthald-probe-modem/append
/match
/match
diff --git a/hald/linux/probing/Makefile.am b/hald/linux/probing/Makefile.am
index 274b870..9e0c7ec 100644
--- a/hald/linux/probing/Makefile.am
+++ b/hald/linux/probing/Makefile.am
@@ -20,7 +20,8 @@ libexec_PROGRAMS = \
hald-probe-serial \
hald-probe-ieee1394-unit \
hald-probe-net-bluetooth \
- hald-probe-video4linux
+ hald-probe-video4linux \
+ hald-probe-modem
endif
hald_probe_smbios_SOURCES = probe-smbios.c ../../logger.c
@@ -39,6 +40,9 @@ hald_probe_hiddev_LDADD = $(top_builddir)/libhal/libhal.la
hald_probe_serial_SOURCES = probe-serial.c ../../logger.c
hald_probe_serial_LDADD = $(top_builddir)/libhal/libhal.la
+hald_probe_modem_SOURCES = probe-modem.c ../../logger.c
+hald_probe_modem_LDADD = $(top_builddir)/libhal/libhal.la
+
hald_probe_storage_SOURCES = probe-storage.c linux_dvd_rw_utils.c linux_dvd_rw_utils.h ../../logger.c
hald_probe_storage_LDADD = $(top_builddir)/libhal/libhal.la $(top_builddir)/partutil/libpartutil.la @GLIB_LIBS@ @VOLUME_ID_LIBS@
diff --git a/hald/linux/probing/probe-modem.c b/hald/linux/probing/probe-modem.c
new file mode 100644
index 000..43300e4
--- /dev/null
+++ b/hald/linux/probing/probe-modem.c
@@ -0,0 +1,167 @@
+/* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 8; tab-width: 8 -*- */
+
+#ifdef HAVE_CONFIG_H
+# include config.h
+#endif
+
+#include termios.h
+#include unistd.h
+#include fcntl.h
+#include errno.h
+
+#include stdio.h
+#include string.h
+#include stdlib.h
+
+#include libhal/libhal.h
+#include ../../logger.h
+
+#define MODEM_CAP_GSM 0x0001 /* GSM commands */
+#define MODEM_CAP_IS707_A 0x0002 /* CDMA circuit switched data commands */
+#define MODEM_CAP_DS 0x0004 /* data compression */
+#define MODEM_CAP_ES 0x0008 /* error control */
+#define MODEM_CAP_FCLASS 0x0010 /* Fax commands */
+#define MODEM_CAP_MS 0x0020 /* Modulation control commands */
+#define MODEM_CAP_W 0x0040 /* Wireless commands */
+
+struct modem_caps {
+ char *name;
+ int bits;
+};
+
+static struct modem_caps modem_caps[] = {
+ {+CGSM, MODEM_CAP_GSM},
+ /* TODO: are they the same? */
+ {+CIS707-A, MODEM_CAP_IS707_A},
+ {+CIS707, MODEM_CAP_IS707_A},
+ {+CIS707P, MODEM_CAP_IS707_A},
+ {NULL}
+} ;
+
+#define AT_CAPS_PROBE AT+GCAP\r\n
+
+static int modem_probe_caps(int fd)
+{
+ char buf[200];
+ char *ptr, *field = NULL;
+ int err, ret = 0;
+
+ err = write(fd, AT_CAPS_PROBE, sizeof(AT_CAPS_PROBE) - 1);
+
+ if (err != sizeof(AT_CAPS_PROBE) - 1)
+ return -1;
+
+ /* 100ms is enough for modem to send all the data */
+ usleep(10);
+
+ err = read(fd, buf, sizeof(buf) - 1);
+ if (err = 0)
+ return -1;
+ buf[err] = 0;
+
+ /* check okay reply */
+ ptr = strstr(buf, \r\nOK\r\n);
+ if (!ptr)
+ return -1;
+ *ptr = 0;
+
+ /* find +GCAP: string */
+ ptr = strstr(buf, \r\n+GCAP:);
+
+ if (ptr == NULL)
+ return -1;
+ ptr += 8;
+
+ /* and parse it */
+ do {
+ err = *ptr == '\0' || *ptr == '\r' || *ptr == '\n';
+ if (*ptr == ' ' || *ptr == ',' || err) {
+ *ptr = 0;
+ if (field) {
+struct modem_caps *cap = modem_caps;
+
+while (cap-name) {
+ if (!strcmp(cap-name, field))
+ ret |= cap-bits;
+ cap++;
+}
+ }
+ field = NULL;
+ } else if (NULL == field) {
+ field = ptr;
+ }
+ ptr++;
+ } while (!err);
+
+ return ret;
+}
+
+int main(int argc, char *argv[])
+{
+ struct termios
Re: [PATCH] hal probe modem caps ondemand
2008/5/6 Alex Kanavin [EMAIL PROTECTED]: 2008/5/6 Vitja Makarov [EMAIL PROTECTED]: I'm wondering what for are CDMA, 3G, GSM subclasses. Which subclasses? Where? I mean protocols defined at linux/usb/cdc.h: #define USB_CDC_ACM_PROTO_AT_V25TER 1 #define USB_CDC_ACM_PROTO_AT_PCCA1012 #define USB_CDC_ACM_PROTO_AT_PCCA101_WAKE 3 #define USB_CDC_ACM_PROTO_AT_GSM4 #define USB_CDC_ACM_PROTO_AT_3G 5 #define USB_CDC_ACM_PROTO_AT_CDMA 6 #define USB_CDC_ACM_PROTO_VENDOR0xff Here is new version of patch. It simply calls prober for V.250 CDC-ACM modems. Also I don't understand why we don't check interface.class and only test interface.subclass? Why do you think so? It clearly checks both: match key=@info.parent:usb.interface.class int=0x02 match key=@info.parent:usb.interface.subclass int=0x02 Sorry, I'm wrong here. Sometimes it's hard to read xml. vitja. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interface hotplugging and priorities
Le lundi 5 mai 2008, Dan Williams a écrit : Yeah, 0.6 won't work so well for you here. 0.7 has the option to tie connections to a specific MAC address, and then you could set autoconnect=FALSE for that MAC-locked connection, which would cause NM to only bring it up when you click it manually. That would indeed solve my problem, if not that of the newcomer who doesn't know what it is all about. With the usb0 cellular connection, is the computer expected to use DHCP to acquire an IP address? That's right. At least that's the way to use the usb0 interface. My phone is also recognized as a modem for which I can set up a ppp script. But the latter method is uselessly complicated when I already have a network interface with dhcp. Dan Aldric DEGORRE ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM applet: NetworkManagerUserSettings service not found
Compiled last network-manager-applet from: URL: https://svn.gnome.org/svn/network-manager-applet/trunk Repository: https://svn.gnome.org/svn/network-manager-applet UUID del Repository: 9c6bbc85-7128-0410-879a-9bbc9e4270e9 Revisione: 713 Starting nm-applet --sm-disable I have: ** (nm-applet:21205): WARNING **: WARN applet_dbus_manager_start_service(): C ould not acquire the NetworkManagerUserSettings service. Message: 'Connection :1.15 is not allowed to own the service org.freedeskto p.NetworkManagerUserSettings due to security policies in the configuration file ' (nm-applet:21205): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJ ECT (object)' failed I serach around network manager server to find the dbus service org.freedeskto p.NetworkManagerUserSettings but I couldn't find any. Ther is only org.freedesktop.NetworkManagerSystemSettings.service, did I miss something? Regards Marco ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is NetworkManager ready for servers with may interfaces?
On Mon, 5 May 2008, Dan Williams wrote: To edit the connection files directly, use the values documented here: http://live.gnome.org/NetworkManagerConfigurationSpecification Question: there's an Edit Connections dialog available in nm-applet; is this the same thing? There seems to be some persistent information stored (but still, Wired Networks and Wireless Networks are grayed out despite a week's worth of trying ...) -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is NetworkManager ready for servers with may interfaces?
On Mon, 5 May 2008, Dan Williams wrote: http://live.gnome.org/NetworkManagerConfigurationSpecification I'm still not quite sure how these end up in text files, what the filenames should be, nor what format. Can someone send me a tar file of their /etc/NetworkManager/system_config/ directory, please? -Kenny -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] nm-applet: build fix for srcdir != builddir
Hi,
nm-applet currently fails make distcheck.
Reason is, that nm-marshal.h is generated in builddir, not srcdir.
I fixed the Makefile.amS accordingly.
Another problem is, that po/POTFILES.in is not up-to-date.
Patch is attached.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Index: src/gconf-helpers/Makefile.am
===
--- src/gconf-helpers/Makefile.am (Revision 713)
+++ src/gconf-helpers/Makefile.am (Arbeitskopie)
@@ -13,7 +13,7 @@
libgconf_helpers_la_CPPFLAGS = \
$(NMA_CFLAGS) \
-I${top_srcdir}/src \
- -I${top_srcdir}/src/marshallers \
+ -I${top_builddir}/src/marshallers \
-I${top_srcdir}/src/utils
libgconf_helpers_la_LIBADD = \
Index: src/Makefile.am
===
--- src/Makefile.am (Revision 713)
+++ src/Makefile.am (Arbeitskopie)
@@ -17,7 +17,7 @@
-DNMALOCALEDIR=\$(datadir)/locale\ \
$(DBUS_CFLAGS) \
$(DISABLE_DEPRECATED) \
- -I${top_srcdir}/src/marshallers \
+ -I${top_builddir}/src/marshallers \
-I${top_srcdir}/src/utils \
-I${top_srcdir}/src/gconf-helpers \
-I${top_srcdir}/src/wireless-security \
Index: po/POTFILES.in
===
--- po/POTFILES.in (Revision 713)
+++ po/POTFILES.in (Arbeitskopie)
@@ -2,7 +2,6 @@
# List of source files containing translatable strings.
# Please keep this file sorted alphabetically.
src/applet-dbus-manager.c
-src/applet-dbus-settings.c
src/applet-device-cdma.c
src/applet-device-gsm.c
src/applet-device-wired.c
signature.asc
Description: OpenPGP digital signature
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] build fix: keyfile plugins uses dbus-glib but doesn't link against it.
Just a minor issue. reader.c uses dbus-glib, so the plugin should be linked against dbus-glib. Patch attached. Cheers Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? Index: system-settings/plugins/keyfile/Makefile.am === --- system-settings/plugins/keyfile/Makefile.am (Revision 3633) +++ system-settings/plugins/keyfile/Makefile.am (Arbeitskopie) @@ -23,6 +23,7 @@ libnm_settings_plugin_keyfile_la_LIBADD = \ $(GLIB_LIBS) \ $(GMODULE_LIBS) \ + $(DBUS_LIBS) \ $(GIO_LIBS) \ $(top_builddir)/libnm-util/libnm-util.la signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interface hotplugging and priorities
Le lundi 5 mai 2008, Dan Williams a écrit : Yeah, 0.6 won't work so well for you here. 0.7 has the option to tie connections to a specific MAC address, and then you could set autoconnect=FALSE for that MAC-locked connection, which would cause NM to only bring it up when you click it manually. That would indeed solve my problem, if not that of the newcomer who doesn't know what it is all about. With the usb0 cellular connection, is the computer expected to use DHCP to acquire an IP address? That's right. At least that's the way to use the usb0 interface. My phone is also recognized as a modem for which I can set up a ppp script. But the latter method is uselessly complicated when I already have a network interface with dhcp. Dan -- Aldric DEGORRE ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
2008/5/6 Vitja Makarov [EMAIL PROTECTED]: I'm wondering what for are CDMA, 3G, GSM subclasses. Which subclasses? Where? Here is new version of patch. It simply calls prober for V.250 CDC-ACM modems. Also I don't understand why we don't check interface.class and only test interface.subclass? Why do you think so? It clearly checks both: match key=@info.parent:usb.interface.class int=0x02 match key=@info.parent:usb.interface.subclass int=0x02 -- Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
2008/5/6 Vitja Makarov [EMAIL PROTECTED]: I mean protocols defined at linux/usb/cdc.h: #define USB_CDC_ACM_PROTO_AT_V25TER 1 #define USB_CDC_ACM_PROTO_AT_PCCA1012 #define USB_CDC_ACM_PROTO_AT_PCCA101_WAKE 3 #define USB_CDC_ACM_PROTO_AT_GSM4 #define USB_CDC_ACM_PROTO_AT_3G 5 #define USB_CDC_ACM_PROTO_AT_CDMA 6 #define USB_CDC_ACM_PROTO_VENDOR0xff In theory an ACM device should specify them in the interface description, but in practice we found that mobile phones always specify 1 (v.25) and so a probe is needed, which is exactly what you wrote - thanks. More information: http://bugs.freedesktop.org/show_bug.cgi?id=15346 Feel free to attach your patches to that bug. -- Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-editor: Can't make existing configuration a system setting
Hi, I'm running latest SVN (NM r3633, nm-applet r713). nm-system-settings is configured to use the keyfile plugin. When I run the connection-editor from within nm-applet, it presents me a list of configured wlan networks (Auto foo, Auto bar, ...). I wanted to make one of those configurations a system setting, so I pressed Edit and checked the System setting checkbox. Unfortunately, this doesn't make nm-system-settings write a config file in /etc/NetworkManager/system_config. If I instead use Add, and check the System setting right from the start, nm-system-settings correctly creates a config file (which works properly). So it seems as if nm-applet doesn't convert an existing (user)configuration into a system setting configuration. Is this a known issue? Cheers, Michael P.S: I was also wondering, if nm-system-settings supports to run multiple plugins (e.g. keyfile *and* ifcfg). If so, which one is used to write the configuration or is the config written to both? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Sun, 2008-05-04 at 11:34 +0400, Vitja Makarov wrote: Probe CDC-ACM modems, found in most cell phones on the fly, using AT+GCAP modem command. I tested it with 1 Nokia GSM phone, and 2 CDMA. Great! Thanks for writing this. So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM applet: NetworkManagerUserSettings service not found
On Tue, 2008-05-06 at 11:44 +0200, Marco wrote: Compiled last network-manager-applet from: URL: https://svn.gnome.org/svn/network-manager-applet/trunk Repository: https://svn.gnome.org/svn/network-manager-applet UUID del Repository: 9c6bbc85-7128-0410-879a-9bbc9e4270e9 Revisione: 713 Starting nm-applet --sm-disable I have: ** (nm-applet:21205): WARNING **: WARN applet_dbus_manager_start_service(): C ould not acquire the NetworkManagerUserSettings service. Message: 'Connection :1.15 is not allowed to own the service org.freedeskto p.NetworkManagerUserSettings due to security policies in the configuration file ' (nm-applet:21205): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJ ECT (object)' failed I serach around network manager server to find the dbus service org.freedeskto p.NetworkManagerUserSettings but I couldn't find any. Ther is only org.freedesktop.NetworkManagerSystemSettings.service, did I miss something? Are you on a debian-derived distro? If so, you need to change the /etc/dbus-1/system.d/nm-applet.conf file to use group=netdev instead of at_console or something along those lines, since debian uses a different method of authenticating who can and cannot control services on the bus. Then your user must be in the netdev group. The patch in this link shows you how to do this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426467 Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Tue, 2008-05-06 at 09:55 -0400, Dan Williams wrote: On Sun, 2008-05-04 at 11:34 +0400, Vitja Makarov wrote: Probe CDC-ACM modems, found in most cell phones on the fly, using AT+GCAP modem command. I tested it with 1 Nokia GSM phone, and 2 CDMA. Great! Thanks for writing this. So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. Or we should mark all the devices that don't use those drivers as V25 modems and install the callout for V25 modems, and devices with a specific driver. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is NetworkManager ready for servers with may interfaces?
On Tue, 2008-05-06 at 05:41 -0700, Kenneth Crudup wrote: On Mon, 5 May 2008, Dan Williams wrote: To edit the connection files directly, use the values documented here: http://live.gnome.org/NetworkManagerConfigurationSpecification Question: there's an Edit Connections dialog available in nm-applet; is this the same thing? There seems to be some persistent information stored (but still, Wired Networks and Wireless Networks are grayed out despite a week's worth of trying ...) Yeah, Edit Connections launches the connection editor, a GUI tool which lets you create, edit, and delete network stored connections. These connections need to be stored somewhere of course, and that can either be in your user-specific GConf or the system settings. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager - Auto
On Fri, 2008-05-02 at 13:52 -0400, Matthew Saltzman wrote: On Fri, 2008-05-02 at 10:52 -0400, Dan Williams wrote: On Thu, 2008-05-01 at 18:10 -0400, Rick Bilonick wrote: I'm using NetworkManager-0.7.0-0.6.7.svn3370.fc8 and I've noticed that sometimes a network access point is listed with a drop down menu () showing Auto. I've only noticed this within the last week or so. For my home network, it shows Auto nw-name seven times. What is going on? (It connects fine and I've seen this happen with some other access points when I was traveling.) Previous versions of NM 0.7 didn't match networks correctly when you selected them from the menu, leaving duplicates in GConf. Also, there is Edit Connections but every option but Delete is ghosted. I've built recent NM versions in Koji, but they'll be incompatible with the F-8 VPN plugins. If you don't need the VPN plugins, Will VPN plugins be working by F9 release? Oh, everything in F9 works. I meant F8; it's only trick to update the F8 versions to match the F9 versions. dan I'd grab: http://koji.fedoraproject.org/koji/buildinfo?buildID=47744 and give that a shot. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm api to get essid, freq, qual ...
On Fri, 2008-05-02 at 15:43 -0400, tyuoustwo three wrote: On Fri, May 2, 2008 at 12:10 PM, Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2008-05-02 at 04:03 -0400, tyuoustwo three wrote: Hi, I have already looked at http://lists.shmoo.com/pipermail/hostap/2007-December/016761.html message. I would like to know, if api's in nm-device-802-11-wireless.c in NetworkManager/src or nm-device-802-11-wireless.c in NetworkManager/libnm-glib can be used to get essid, frequency and quality. They are accessible both from libnm-glib and from D-Bus, since libnm-glib is really just a client-side wrapper around the D-Bus interface that NM exposes. You can also query wpa_supplicant for this information directly. Are you looking for information about which AP the machine is _currently_ associated with, or information about some random known AP that the machine is _not_ currently associated with? I am looking for information about AP that the machine can scan (just as in iwlist ath0 scan). Ok... I am trying to overlay network information (essid, freq ...) on a live video stream. Using system(iwlist ath0 scan | grep ESSID net_info.txt) and then This is going to just kill you, because you're scanning for networks, which can take more than 10 seconds on cards that support both the A and B/G frequency bands, using a passive scan (which is the default). You really, really don't want to trigger a scan every frame. Yes, I will have to try to introduce delay between each scan. So instead of using system(iwlist scan...) you should probably be calling the ioctls directly. Basically do what iwlist does, but do it in your program without calling out to iwlist and blocking. That way you can keep everything asynchronous. So first I'll need to know if you want info about the current associated AP or a known but not currently associated AP. That makes a big difference in the approach you should take. I am looking for an output similar to iwlist ath0 scan, but I need only certain information like essid, freq, qual. Also, we do not need every possible AP that the card can scan. But, only the top 3 or 4 AP (this can be less or more), based on the quality or signal. Be aware that not every AP shows up in every scan, so to get a good picture of what's really around you'll want to build up a list of the last 2 or 3 scans and age the scan results accordingly. That's just the way wireless works; it's not completely reliable. Drivers are also implemented differently (some use passive scans, some use active scans) and that also affects the results. Dan reading the file each millisecond or less takes a lot of time. (For each single video frame using system command to get network parameters and then overlaying text makes the live video really slow). So, looking for an api that directly provides the required wireless network parameters. Thanks, Ash ___ 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: Is NetworkManager ready for servers with may interfaces?
On Tue, May 6, 2008 at 3:43 PM, Kenneth Crudup [EMAIL PROTECTED] wrote: I'm still not quite sure how these end up in text files, what the filenames should be, nor what format. Can someone send me a tar file of their /etc/NetworkManager/system_config/ directory, please? The file names aren't important, but the the configuration files built by the keyfile plugin use connection names for file names. Since these files might contain passwords, they have to be owned by root and have 0600 permissions. Attached are two example files, one for ethernet, one for wireless with WPA-PSK security. It should be possible to create/modify/delete keyfile plugin files using the latest SVN nm-applet: when you open a connection properties page in connection-editor, there's a new checkbox System setttings. Checking it will push it to the system settings daemon. The version in SVN is not doing any authentication so everyone can do it, but I have patches to add PolicyKit support for it. Tambet Auto Ethernet Description: Binary data Auto it Description: Binary data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-editor: Can't make existing configuration a system setting
On Tue, May 6, 2008 at 4:50 PM, Michael Biebl [EMAIL PROTECTED] wrote: When I run the connection-editor from within nm-applet, it presents me a list of configured wlan networks (Auto foo, Auto bar, ...). I wanted to make one of those configurations a system setting, so I pressed Edit and checked the System setting checkbox. Unfortunately, this doesn't make nm-system-settings write a config file in /etc/NetworkManager/system_config. If I instead use Add, and check the System setting right from the start, nm-system-settings correctly creates a config file (which works properly). So it seems as if nm-applet doesn't convert an existing (user)configuration into a system setting configuration. Is this a known issue? It's known to me :) I sort of left it like that until the whole thing is secured with PolicyKit. Dan needs to approve my PK patches first, so you can blame him as well. :) Anyway, I'm glad it works properly with the add button for you, this is the first success story I hear. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-editor: Can't make existing configuration a system setting
On Tue, 2008-05-06 at 17:36 +0300, Tambet Ingo wrote: On Tue, May 6, 2008 at 4:50 PM, Michael Biebl [EMAIL PROTECTED] wrote: When I run the connection-editor from within nm-applet, it presents me a list of configured wlan networks (Auto foo, Auto bar, ...). I wanted to make one of those configurations a system setting, so I pressed Edit and checked the System setting checkbox. Unfortunately, this doesn't make nm-system-settings write a config file in /etc/NetworkManager/system_config. If I instead use Add, and check the System setting right from the start, nm-system-settings correctly creates a config file (which works properly). So it seems as if nm-applet doesn't convert an existing (user)configuration into a system setting configuration. Is this a known issue? It's known to me :) I sort of left it like that until the whole thing is secured with PolicyKit. Dan needs to approve my PK patches first, so you can blame him as well. :) I'm blocking on davidz reviewing them which he said he was going to do yesterday but apparently needs more encouragement :) dan Anyway, I'm glad it works properly with the add button for you, this is the first success story I hear. Tambet ___ 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: Crash of KNetworkMangager 0.2.2 attempting LEAP on iwl3945
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helmut Schaa wrote: Hi, Am Mi 30 Apr 2008 18:46:30 CEST schrieb Ryan Novosielski [EMAIL PROTECTED]: I figured I'd mention this one because I can reliably reproduce it. What information the backtrace really contains though, I'm not sure. Let me know if I can help somehow. That should be mentioned on the kde-networkmanager list, right? I guess I saw something similar already. Could you please try the following: - Close KNetworkManager - Move ~/.kde/share/config/knetworkmanagerrc anywhere else - Start KNetworkManager Can you still reproduce the issue? Don't forget to move the knetworkmanagerrc back as it contains all your configured networks :) Regards, Helmut That does seem to solve the problem. Now what do I do? :) - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIIHKJmb+gadEcsb4RAmfBAKCrE0KlPgSxfegSaEf6c8cSL728mgCeKxdt 6jr4qmdnVUoLC/bIdj+pRWs= =L29Y -END PGP SIGNATURE- begin:vcard fn:Ryan Novosielski n:Novosielski;Ryan org:UMDNJ;IST/AST adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103 email;internet:[EMAIL PROTECTED] title:Systems Programmer II tel;work:(973) 972-0922 tel;fax:(973) 972-7412 tel;pager:(866) 20-UMDNJ x-mozilla-html:FALSE version:2.1 end:vcard ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fails on inactivity timeout
On Sun, 2008-05-04 at 13:39 -0400, Neal Becker wrote: May 4 13:35:45 nbecker1 openvpn[12533]: Initialization Sequence Completed OK, it's up ... May 4 13:37:39 nbecker1 nm-openvpn[21349]: [nbecker] Inactivity timeout (--ping-restart), restarting May 4 13:37:39 nbecker1 nm-openvpn[21349]: SIGUSR1[soft,ping-restart] received, process restarting May 4 13:37:41 nbecker1 nm-openvpn[21349]: Re-using SSL/TLS context May 4 13:37:41 nbecker1 nm-openvpn[21349]: LZO compression initialized May 4 13:37:41 nbecker1 nm-openvpn[21349]: UDPv4 link local: [undef] May 4 13:37:41 nbecker1 nm-openvpn[21349]: UDPv4 link remote: 71.168.34.70:5002 May 4 13:37:41 nbecker1 nm-openvpn[21349]: [nbecker] Peer Connection Initiated with 71.168.34.70:5002 May 4 13:37:42 nbecker1 nm-openvpn[21349]: Preserving previous TUN/TAP instance: tun1 May 4 13:37:42 nbecker1 nm-openvpn[21349]: /usr/bin/nm-openvpn-service-openvpn-helper tun1 1500 1542 10.4.0.50 10.4.0.49 restart May 4 13:37:42 nbecker1 nm-openvpn[21349]: script failed: shell command exited with error status: 1 May 4 13:37:42 nbecker1 nm-openvpn[21349]: Exiting That seems wrong; can you paste that output into a bug in gnome bugzilla if it's not already there? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-applet: build fix for srcdir != builddir
On Tue, 2008-05-06 at 14:52 +0200, Michael Biebl wrote: Hi, nm-applet currently fails make distcheck. Reason is, that nm-marshal.h is generated in builddir, not srcdir. I fixed the Makefile.amS accordingly. Another problem is, that po/POTFILES.in is not up-to-date. Patch is attached. Committed, thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build fix: keyfile plugins uses dbus-glib but doesn't link against it.
On Tue, 2008-05-06 at 15:22 +0200, Michael Biebl wrote: Just a minor issue. reader.c uses dbus-glib, so the plugin should be linked against dbus-glib. Patch attached. Committed, thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager and rf_kill
Hi list, When disabling wireless network using nm-applet, NM does not seem to disable the device (by means of /sys/class/net/wlan0/device/rf_kill). This is true both of the 0.6.6 version that Ubuntu Hardy ships and a quite recent svn build that I've compiled myself. The svn build is on a machine with the ipw2200 driver and the 0.6.6 version is on a machine which uses the iwlwifi driver on 4965 chipset. Is this a bug that I should report, or is it a not yet implemented feature? Regards, K. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Crash of KNetworkMangager 0.2.2 attempting LEAP on iwl3945
Am Di 06 Mai 2008 17:00:25 CEST schrieb Ryan Novosielski [EMAIL PROTECTED]: Helmut Schaa wrote: Could you please try the following: - Close KNetworkManager - Move ~/.kde/share/config/knetworkmanagerrc anywhere else - Start KNetworkManager That does seem to solve the problem. Now what do I do? :) Just edit the knetworkmanagerrc and remove the part which contains the culprit-network. Afterwards you should be able to configure your network again without any problems. The crash seems to be triggered under some circumstances when the configuration in knetworkmanagerrc does not match the real configuration of your AP. Not sure how to fix that quickly. Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
Hi Dan, Probe CDC-ACM modems, found in most cell phones on the fly, using AT+GCAP modem command. I tested it with 1 Nokia GSM phone, and 2 CDMA. Great! Thanks for writing this. So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and rf_kill
On Tue, 2008-05-06 at 18:08 +0200, Khashayar Naderehvandi wrote: Hi list, When disabling wireless network using nm-applet, NM does not seem to disable the device (by means of /sys/class/net/wlan0/device/rf_kill). This is true both of the 0.6.6 version that Ubuntu Hardy ships and a quite recent svn build that I've compiled myself. The svn build is on a machine with the ipw2200 driver and the 0.6.6 version is on a machine which uses the iwlwifi driver on 4965 chipset. Is this a bug that I should report, or is it a not yet implemented feature? NetworkManager marks the device as down, ie !IFF_UP. Devices that are marked down should enter the lowest possible power saving mode, unfortunately that's not consistent behavior across drivers. That's how power-save works for wired devices and should work for wireless ones. However, it turns out that there are some parts (iwlwifi for example) that cannot detect rfkill unless firmware is loaded, which they do only when the device is up. To fix that, NM is going to switch to simply turning off the TX power of the device. Unfortunately, we need better support from HAL here, since HAL is not quite verbose enough to tell NM that the radio is hardware-rfkilled or software-rfkilled, which means NM can't know whether or not you can re-enable the radio via software or whether the user actually flipped a switch. Once that is fixed, I'll flip NM over to turning off TX power and then it will probably Just Work for you. dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Tue, 2008-05-06 at 19:10 +0200, Marcel Holtmann wrote: Hi Dan, Probe CDC-ACM modems, found in most cell phones on the fly, using AT+GCAP modem command. I tested it with 1 Nokia GSM phone, and 2 CDMA. Great! Thanks for writing this. So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Hmm, does that mean the device will only respond to AT+CPIN until you give it the PIN? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-tool and nm-applet problems in recent svn
Hi, I had this problem with nm-tool for some time now and it doesn't work in the latest svn of libnm, networkmanager and nm-applet yet: $ nm-tool NetworkManager Tool State: connected (process:14913): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `NMDevice' ** (process:14913): CRITICAL **: nm_device_get_state: assertion `NM_IS_DEVICE (device)' failed ** (process:14913): CRITICAL **: nm_device_get_iface: assertion `NM_IS_DEVICE (device)' failed - Device: (null) ** (process:14913): CRITICAL **: nm_device_get_driver: assertion `NM_IS_DEVICE (device)' failed Driver:(unknown) Active:no ** (process:14913): CRITICAL **: nm_device_get_capabilities: assertion `NM_IS_DEVICE (device)' failed Capabilities: Supported: no Segmentation fault I'm using a thinkpad t60 with iwl3945 and e100e driven devices. both work fine, but nm-tool doesn't seem to like my system. since nm-applet svn 711, nm-applet doesn't start anymore. when it starts, bug buddy tells me, the applet has crashed. $ nm-applet ** (nm-applet:14850): WARNING **: Could not retrieve dbus connections: Launch helper exited with unknown return code 1. 6d91daf9-4738-49a8-54b19ba7-45e237df is dumped the weird part is that it still connects and then crashes right away. has there anything important been changed and conflicts with old settings now in that commit or what's happening? I'm running arch linux and it worked fine with older versions, and i can still connect to all the networks i could before... maybe this helps: ** (nm-applet:15045): WARNING **: Could not retrieve dbus connections: Launch helper exited with unknown return code 1. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb728a6c0 (LWP 15045)] 0xb76abb05 in free () from /lib/libc.so.6 (gdb) bt full #0 0xb76abb05 in free () from /lib/libc.so.6 No symbol table info available. #1 0xb78da096 in g_free () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0xb78aafac in g_ptr_array_free () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0xb8087422 in fetch_connections_done () from /usr/lib/libnm_glib.so.0 No symbol table info available. #4 0xb80872d1 in org_freedesktop_NetworkManagerSettings_list_connections_async_callback () from /usr/lib/libnm_glib.so.0 No symbol table info available. #5 0xb7b3279f in d_pending_call_notify () from /usr/lib/libdbus-glib-1.so.2 No symbol table info available. #6 0xb79a42c1 in _dbus_pending_call_complete () from /usr/lib/libdbus-1.so.3 No symbol table info available. #7 0xb79936d6 in complete_pending_call_and_unlock () from /usr/lib/libdbus-1.so.3 No symbol table info available. #8 0xb799539c in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3 No symbol table info available. #9 0xb7b2e92d in message_queue_dispatch () from /usr/lib/libdbus-glib-1.so.2 No symbol table info available. #10 0xb78d1f88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 ---Type return to continue, or q return to quit--- No symbol table info available. #11 0xb78d54eb in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #12 0xb78d59ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #13 0x080540bd in main () No symbol table info available. björn 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: [PATCH] hal probe modem caps ondemand
Hi Dan, So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Hmm, does that mean the device will only respond to AT+CPIN until you give it the PIN? basically yes. At least that is what I have observed with modem cards. Maybe we need to investigate if there are models that allow commands before the PIN has been entered. The phone case is different, because in that case you mostly have entered the PIN code already using the phone's UI. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
On Tue, 2008-05-06 at 20:10 +0200, Marcel Holtmann wrote: Hi Dan, So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Hmm, does that mean the device will only respond to AT+CPIN until you give it the PIN? basically yes. At least that is what I have observed with modem cards. Maybe we need to investigate if there are models that allow commands before the PIN has been entered. The phone case is different, because in that case you mostly have entered the PIN code already using the phone's UI. Maybe all that probing code should be moved to NetworkManager itself then, so it can integrate with PIN queries. We'll need to have a prober for Bluetooth devices anyway, as the supported commands set won't be available through HAL. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] hal probe modem caps ondemand
2008/5/6 Bastien Nocera [EMAIL PROTECTED]: On Tue, 2008-05-06 at 20:10 +0200, Marcel Holtmann wrote: Hi Dan, So what we can do now is remove all the matches for individual devices in the fdi file, and just match on the driver name for nozomi, airprime, option, and sierra. We'll have a few left-over items that aren't driven by those, but those devices will either use cdc_acm (and therefore be probed) or we can just tag them to be probed automatically. Not sure how this works on BSD and Solaris though; if they don't have separate drivers to run the mobile broadband cards then they'd have to revert back to the per-device tagging to know when to probe and when not to probe. be careful with this. If the SIM card needs a PIN code first, we might not be able to send any AT commands at all. I tried for example to get the IMEI before entering the PIN, but that never worked on the cards that I own. Hmm, does that mean the device will only respond to AT+CPIN until you give it the PIN? basically yes. At least that is what I have observed with modem cards. Maybe we need to investigate if there are models that allow commands before the PIN has been entered. The phone case is different, because in that case you mostly have entered the PIN code already using the phone's UI. Maybe all that probing code should be moved to NetworkManager itself then, so it can integrate with PIN queries. We'll need to have a prober for Bluetooth devices anyway, as the supported commands set won't be available through HAL. Are you sure that modem doesn't accept any command, e.g. AT? Or there are some commands that willn't work? vitja. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Crash of KNetworkMangager 0.2.2 attempting LEAP on iwl3945
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helmut Schaa wrote: Am Di 06 Mai 2008 17:00:25 CEST schrieb Ryan Novosielski [EMAIL PROTECTED]: Helmut Schaa wrote: Could you please try the following: - Close KNetworkManager - Move ~/.kde/share/config/knetworkmanagerrc anywhere else - Start KNetworkManager That does seem to solve the problem. Now what do I do? :) Just edit the knetworkmanagerrc and remove the part which contains the culprit-network. Afterwards you should be able to configure your network again without any problems. The crash seems to be triggered under some circumstances when the configuration in knetworkmanagerrc does not match the real configuration of your AP. Not sure how to fix that quickly. Helmut I can just assume, then, that the culprit network is the network I'm connecting to when the crash occurs? =R - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIILQlmb+gadEcsb4RAhEPAJ9mUS8aTlHxxcIrGPvceu6nRrHktACeIk1e hQ3fFY8pbIEgf5sQ4kgXupE= =6YRx -END PGP SIGNATURE- begin:vcard fn:Ryan Novosielski n:Novosielski;Ryan org:UMDNJ;IST/AST adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103 email;internet:[EMAIL PROTECTED] title:Systems Programmer II tel;work:(973) 972-0922 tel;fax:(973) 972-7412 tel;pager:(866) 20-UMDNJ x-mozilla-html:FALSE version:2.1 end:vcard ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Crash of KNetworkMangager 0.2.2 attempting LEAP on iwl3945
Am Di 06 Mai 2008 21:40:21 CEST schrieb Ryan Novosielski [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helmut Schaa wrote: Am Di 06 Mai 2008 17:00:25 CEST schrieb Ryan Novosielski [EMAIL PROTECTED]: Helmut Schaa wrote: Could you please try the following: - Close KNetworkManager - Move ~/.kde/share/config/knetworkmanagerrc anywhere else - Start KNetworkManager That does seem to solve the problem. Now what do I do? :) Just edit the knetworkmanagerrc and remove the part which contains the culprit-network. Afterwards you should be able to configure your network again without any problems. The crash seems to be triggered under some circumstances when the configuration in knetworkmanagerrc does not match the real configuration of your AP. Not sure how to fix that quickly. Helmut I can just assume, then, that the culprit network is the network I'm connecting to when the crash occurs? Correct :) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and rf_kill
On Tue, May 6, 2008 at 8:24 PM, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2008-05-06 at 18:08 +0200, Khashayar Naderehvandi wrote: Hi list, When disabling wireless network using nm-applet, NM does not seem to disable the device (by means of /sys/class/net/wlan0/device/rf_kill). This is true both of the 0.6.6 version that Ubuntu Hardy ships and a quite recent svn build that I've compiled myself. The svn build is on a machine with the ipw2200 driver and the 0.6.6 version is on a machine which uses the iwlwifi driver on 4965 chipset. Is this a bug that I should report, or is it a not yet implemented feature? NetworkManager marks the device as down, ie !IFF_UP. Devices that are marked down should enter the lowest possible power saving mode, unfortunately that's not consistent behavior across drivers. That's how power-save works for wired devices and should work for wireless ones. However, it turns out that there are some parts (iwlwifi for example) that cannot detect rfkill unless firmware is loaded, which they do only when the device is up. To fix that, NM is going to switch to simply turning off the TX power of the device. This is only case for 3945 HW. In any case moving device to rfkill will also move it to very low power consumption. This devices were designed to operate under other operating system in mind :) Turning TX power of is currently equivalent to rfkill Unfortunately, we need better support from HAL here, since HAL is not quite verbose enough to tell NM that the radio is hardware-rfkilled or software-rfkilled, which means NM can't know whether or not you can re-enable the radio via software or whether the user actually flipped a switch. True some work need to be done here in distinction between SW and HW RF kill It turns to be quite interesting state machine. One of the problems to face is to preserve rfkill state after resume. This have to be saved in application level. - You don't want to resume your laptop in airplane and crash it down because you didn't closed the radio.. at least what they say you during safety isnstructions Once that is fixed, I'll flip NM over to turning off TX power and then it will probably Just Work for you. dan ___ 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: NetworkManager and rf_kill
On Tue, May 6, 2008 at 8:24 PM, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2008-05-06 at 18:08 +0200, Khashayar Naderehvandi wrote: Hi list, When disabling wireless network using nm-applet, NM does not seem to disable the device (by means of /sys/class/net/wlan0/device/rf_kill). This is true both of the 0.6.6 version that Ubuntu Hardy ships and a quite recent svn build that I've compiled myself. The svn build is on a machine with the ipw2200 driver and the 0.6.6 version is on a machine which uses the iwlwifi driver on 4965 chipset. Is this a bug that I should report, or is it a not yet implemented feature? NetworkManager marks the device as down, ie !IFF_UP. Devices that are marked down should enter the lowest possible power saving mode, unfortunately that's not consistent behavior across drivers. That's how power-save works for wired devices and should work for wireless ones. However, it turns out that there are some parts (iwlwifi for example) that cannot detect rfkill unless firmware is loaded, which they do only when the device is up. To fix that, NM is going to switch to simply turning off the TX power of the device. This is only case for 3945 HW. In any case moving device to rfkill will also move it to very low power consumption. This devices were designed to operate under other operating system in mind :) Turning TX power of is currently equivalent to rfkill Unfortunately, we need better support from HAL here, since HAL is not quite verbose enough to tell NM that the radio is hardware-rfkilled or software-rfkilled, which means NM can't know whether or not you can re-enable the radio via software or whether the user actually flipped a switch. True some work need to be done here in distinction between SW and HW RF kill It turns to be quite interesting state machine. One of the problems to face is to preserve rfkill state after resume. This have to be saved in application level. - You don't want to resume your laptop in airplane and crash it down because you didn't closed the radio.. at least what they say you during safety isnstructions Once that is fixed, I'll flip NM over to turning off TX power and then it will probably Just Work for you. Tomas dan ___ 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
