Re: Wireless is disabled message
On Mon, 2009-05-11 at 14:46 +0900, Thomas O'Donoghue wrote: I found out about this list through the forum mentioned in the following thread: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00256.html and appear to have the same problem. The person appealed to you guys and seemed to get a fix: I looked through the messages, but was unable to deduce what that fix was. I have the same problem (my internal Intel wireless card doesn't work, so I think the computer automatically assumes that the wireless switch is set to off). I'm using an external card, but cannot enable wireless to use it. Does this happen when you return from suspend/hibernate? If so, please see: https://bugzilla.redhat.com/show_bug.cgi?id=477964 Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: nm-tool doesn't show my mobile broadband card
On Sun, 2009-05-10 at 13:16 -0700, Jochen Wiedmann wrote: Hi, Nicholas, see my original mail: Bus 004 Device 005: ID 0af0:6971 Option That's actually an 'hso' part, not driven by the 'option' driver. What kernel do you have? What version of NetworkManager? Dan Herriot, Nicholas, VF UK - Technology (TS) wrote: Hi Jochen, What stick are you using? i.e. Make and model number? You can find that out with lsusb. Kind regards, Nicholas Herriot. Date: Fri, 8 May 2009 14:38:01 -0700 (PDT) From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: nm-tool doesn't show my mobile broadband card To: NetworkManager-list@gnome.org Message-ID: 23448718.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii Hi, I have a so-called web'n'walk stick. I managed to have it reported not as a USB drive, but as a modem by using usb_modeswitch: [...@mcjwi ~]$ hal-find-by-capability --capability=modem /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_0 /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_1 I also have created an entry under Mobile Broadband using nm-connection-editor. However, I can't get the stick to do any dial attempts. A possible reason might be, that nm-tool shows the Ethernet and Wireless devices, but not my modem. Any ideas, what might be wrong? Thanks, Jochen ___ 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: NM before login?
On Sun, 2009-05-10 at 11:40 +0100, Timothy Murphy wrote: Is there a way of establishing (and keeping) a WiFi connection with NetworkManager before logging in? I've read postings saying it is possible, and others saying it is not. If it is possible, what are the steps one must take to implement this? (I'm running Fedora-10 with KDE.) This is provided by the nm-system-settings service. You'll want to grab the NM from F-10 updates-testing: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3686 and after a reboot, you should be able to use the connection editor to mark your wifi connections as Available to all users, which means they will be available before login. dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-tool doesn't show my mobile broadband card
Hi, Dan, for the kernel: [...@mcjwi ~]$ uname -a Linux mcjwi.eur.ad.sag 2.6.27.21-170.2.56.fc10.i686.PAE #1 SMP Mon Mar 23 23:24:26 EDT 2009 i686 i686 i386 GNU/Linux For the NetworkManager: [...@mcjwi ~]$ rpm -qi NetworkManager Name: NetworkManager Relocations: (not relocatable) Version : 0.7.0.99 Vendor: Fedora Project Release : 5.git20090326.fc10Build Date: Thu 26 Mar 2009 10:36:55 PM CET Install Date: Fri 27 Mar 2009 10:18:39 PM CET Build Host: x86-7.fedora.phx.redhat.com Group : System Environment/Base Source RPM: NetworkManager-0.7.0.99-5.git20090326.fc10.src.rpm Jochen On Mon, May 11, 2009 at 4:59 PM, Dan Williams d...@redhat.com wrote: On Sun, 2009-05-10 at 13:16 -0700, Jochen Wiedmann wrote: Hi, Nicholas, see my original mail: Bus 004 Device 005: ID 0af0:6971 Option That's actually an 'hso' part, not driven by the 'option' driver. What kernel do you have? What version of NetworkManager? Dan Herriot, Nicholas, VF UK - Technology (TS) wrote: Hi Jochen, What stick are you using? i.e. Make and model number? You can find that out with lsusb. Kind regards, Nicholas Herriot. Date: Fri, 8 May 2009 14:38:01 -0700 (PDT) From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: nm-tool doesn't show my mobile broadband card To: NetworkManager-list@gnome.org Message-ID: 23448718.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii Hi, I have a so-called web'n'walk stick. I managed to have it reported not as a USB drive, but as a modem by using usb_modeswitch: [...@mcjwi ~]$ hal-find-by-capability --capability=modem /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_0 /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_seria l_unknown_1 I also have created an entry under Mobile Broadband using nm-connection-editor. However, I can't get the stick to do any dial attempts. A possible reason might be, that nm-tool shows the Ethernet and Wireless devices, but not my modem. Any ideas, what might be wrong? Thanks, Jochen ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Don't trust a government that doesn't trust you. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
On Fri, 2009-05-08 at 01:40 -0700, Marcel Holtmann wrote: Hi Pablo, what do you guys think about moving the ppp-manager part from NetworkManager into ModemManager? What is the actual reason why ModemManager doesn't handle the PPP part of a data connection? Because NetworkManager also happens to support pppoe and friends and with the same argument the support for DSL modems etc. could also be moved into ModemManager. My problem is that if ModemManager as a standalone can not deal with the PPP portion of a dialup connection, then it is nothing more than an AT command parser with D-Bus interface. I am failing to see the point why this code was ever moved outside NetworkManager to begin with then. Not all modems are PPP. The IP layer handling isn't the responsibility of the modem manager, it's the responsibility of the connection manager, since the conneciton manager applies the IP-layer policies and such. There are a number of different IP configuration methods that modems use these days: PPP, static IP, and DHCP. It makes no sense to put PPP into ModemManager without putting the other two in as well. But putting the other two into MM is clearly expanding the scope of MM way beyond what it should be. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM before login?
Dan Williams wrote: On Sun, 2009-05-10 at 11:40 +0100, Timothy Murphy wrote: Is there a way of establishing (and keeping) a WiFi connection with NetworkManager before logging in? I've read postings saying it is possible, and others saying it is not. If it is possible, what are the steps one must take to implement this? (I'm running Fedora-10 with KDE.) This is provided by the nm-system-settings service. You'll want to grab the NM from F-10 updates-testing: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3686 and after a reboot, you should be able to use the connection editor to mark your wifi connections as Available to all users, which means they will be available before login. Thanks very much, I'll try that. Though I am reasonably sure - having followed your suggestion to use nm-tools - that the occasional problem with my Orinoco Gold PCMCIA card is something to do with the orinoco_cs driver rather than NM. Still, it will help to find as soon as possible whether or not a WiFi connection is going to be set up. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
On Mon, 2009-05-11 at 12:24 -0700, Marcel Holtmann wrote: Hi Dan, what do you guys think about moving the ppp-manager part from NetworkManager into ModemManager? What is the actual reason why ModemManager doesn't handle the PPP part of a data connection? Because NetworkManager also happens to support pppoe and friends and with the same argument the support for DSL modems etc. could also be moved into ModemManager. My problem is that if ModemManager as a standalone can not deal with the PPP portion of a dialup connection, then it is nothing more than an AT command parser with D-Bus interface. I am failing to see the point why this code was ever moved outside NetworkManager to begin with then. Not all modems are PPP. The IP layer handling isn't the responsibility of the modem manager, it's the responsibility of the connection manager, since the conneciton manager applies the IP-layer policies and such. There are a number of different IP configuration methods that modems use these days: PPP, static IP, and DHCP. It makes no sense to put PPP into ModemManager without putting the other two in as well. But putting the other two into MM is clearly expanding the scope of MM way beyond what it should be. I am fine with ModemManager not doing IP configuration, but PPP is mostly a transport layer. The IP configuration aspects are only on top of it. So I would expect ModemManager to do the PPP handling and then tell the application the IP details (routing, nameserver etc.) to actually set these details. Ok sure, but this has additional drawbacks: - complicating the API, since you have to funnel the PPP configuration down to ModemManager, including auth methods and auth method setup (potentially including EAP), MPPE, etc. It does mean a lot of additional configuration may need to be sent from the connection manager down to MM. - if PPP gets stuck into MM, why wouldn't DHCP also go into MM? Obviously MM wouldn't set the IP details, but DHCP is logically at the same level here as PPP is, since at the end of either PPP or DHCP, you get nameservers and IP addresses. Seems pretty wrong to put DHCP handling into MM as well. However, clean APIs are hard to come by since the realities of the world intrude. So TBH, I don't really mind putting the PPP bits into MM. This would make PPP-driven devices operate identically to 'hso' devices that use AT_OWANDATA to return IP+DNS information, and MM would simply advertise that the device used the static IP configuration method, and the connection manager would apply the details provided by MM to the IP interface provided by MM (in this case ppp0 or whatever). DHCP-based devices (f3507g for example) would continue to require the connection manager to perform DHCP. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM before login?
On Mon, 2009-05-11 at 20:31 +0100, Timothy Murphy wrote: Dan Williams wrote: On Sun, 2009-05-10 at 11:40 +0100, Timothy Murphy wrote: Is there a way of establishing (and keeping) a WiFi connection with NetworkManager before logging in? I've read postings saying it is possible, and others saying it is not. If it is possible, what are the steps one must take to implement this? (I'm running Fedora-10 with KDE.) This is provided by the nm-system-settings service. You'll want to grab the NM from F-10 updates-testing: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3686 and after a reboot, you should be able to use the connection editor to mark your wifi connections as Available to all users, which means they will be available before login. Thanks very much, I'll try that. Though I am reasonably sure - having followed your suggestion to use nm-tools - that the occasional problem with my Orinoco Gold PCMCIA card is something to do with the orinoco_cs driver rather than NM. Still, it will help to find as soon as possible whether or not a WiFi connection is going to be set up. You might get better luck by using the 'hostap' driver for your card, most of the orinoco cards can be driven by hostap too. However, I've used an airport card (which is essentially orinoco) pretty successfully with recent NM versions. What sort of issues are you having with it, and what kernel version are you running? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM before login?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Williams wrote: On Mon, 2009-05-11 at 20:31 +0100, Timothy Murphy wrote: Dan Williams wrote: On Sun, 2009-05-10 at 11:40 +0100, Timothy Murphy wrote: Is there a way of establishing (and keeping) a WiFi connection with NetworkManager before logging in? I've read postings saying it is possible, and others saying it is not. If it is possible, what are the steps one must take to implement this? (I'm running Fedora-10 with KDE.) This is provided by the nm-system-settings service. You'll want to grab the NM from F-10 updates-testing: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3686 and after a reboot, you should be able to use the connection editor to mark your wifi connections as Available to all users, which means they will be available before login. Thanks very much, I'll try that. Though I am reasonably sure - having followed your suggestion to use nm-tools - that the occasional problem with my Orinoco Gold PCMCIA card is something to do with the orinoco_cs driver rather than NM. Still, it will help to find as soon as possible whether or not a WiFi connection is going to be set up. You might get better luck by using the 'hostap' driver for your card, most of the orinoco cards can be driven by hostap too. However, I've used an airport card (which is essentially orinoco) pretty successfully with recent NM versions. What sort of issues are you having with it, and what kernel version are you running? Is that right? I've been using hermesap on a machine, but now can't upgrade to Linux 2.6 because that driver has essentially dead-ended. This is one of the old old WaveLAN cards (gold) that is actually branded Lucent. If this is true, that would be welcome news. - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/CST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoIkeEACgkQmb+gadEcsb6/BACcCTbkIRPJKszz8Hf4hj7M8rdv aegAn14PqqnTUkcmOD0n6h0cGajlzWRq =Vu8H -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:novos...@umdnj.edu 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: Moving ppp-manager into ModemManager
Hi Dan, what do you guys think about moving the ppp-manager part from NetworkManager into ModemManager? What is the actual reason why ModemManager doesn't handle the PPP part of a data connection? Because NetworkManager also happens to support pppoe and friends and with the same argument the support for DSL modems etc. could also be moved into ModemManager. My problem is that if ModemManager as a standalone can not deal with the PPP portion of a dialup connection, then it is nothing more than an AT command parser with D-Bus interface. I am failing to see the point why this code was ever moved outside NetworkManager to begin with then. Not all modems are PPP. The IP layer handling isn't the responsibility of the modem manager, it's the responsibility of the connection manager, since the conneciton manager applies the IP-layer policies and such. There are a number of different IP configuration methods that modems use these days: PPP, static IP, and DHCP. It makes no sense to put PPP into ModemManager without putting the other two in as well. But putting the other two into MM is clearly expanding the scope of MM way beyond what it should be. I am fine with ModemManager not doing IP configuration, but PPP is mostly a transport layer. The IP configuration aspects are only on top of it. So I would expect ModemManager to do the PPP handling and then tell the application the IP details (routing, nameserver etc.) to actually set these details. Ok sure, but this has additional drawbacks: - complicating the API, since you have to funnel the PPP configuration down to ModemManager, including auth methods and auth method setup (potentially including EAP), MPPE, etc. It does mean a lot of additional configuration may need to be sent from the connection manager down to MM. since ModemManager's API already has auth settings like username, password and also PIN codes, I think it would be fine to have these in there. - if PPP gets stuck into MM, why wouldn't DHCP also go into MM? Obviously MM wouldn't set the IP details, but DHCP is logically at the same level here as PPP is, since at the end of either PPP or DHCP, you get nameservers and IP addresses. Seems pretty wrong to put DHCP handling into MM as well. However, clean APIs are hard to come by since the realities of the world intrude. As I said, DHCP is purely for configuration, but one of of PPP's main purpose encapsulation. Hard to tell which belongs where. I think it would be beneficial if PPP would be done inside ModemManager and then it just hands out the IP configuration via D-Bus (which is does for HSO based devices already). So TBH, I don't really mind putting the PPP bits into MM. This would make PPP-driven devices operate identically to 'hso' devices that use AT_OWANDATA to return IP+DNS information, and MM would simply advertise that the device used the static IP configuration method, and the connection manager would apply the details provided by MM to the IP interface provided by MM (in this case ppp0 or whatever). DHCP-based devices (f3507g for example) would continue to require the connection manager to perform DHCP. I was reading through the pppd code btw. and figure out a way how we might be able to split this or reimplement in a more proper way. The pppd code is kinda ancient and carries a lot of code that is not longer be used in any modern distro. Need to play with this a little bit more and figure out which PPP features we are actually need and which ones are just pointless nowadays. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
On Mon, 2009-05-11 at 14:20 -0700, Marcel Holtmann wrote: Hi Dan, what do you guys think about moving the ppp-manager part from NetworkManager into ModemManager? What is the actual reason why ModemManager doesn't handle the PPP part of a data connection? Because NetworkManager also happens to support pppoe and friends and with the same argument the support for DSL modems etc. could also be moved into ModemManager. My problem is that if ModemManager as a standalone can not deal with the PPP portion of a dialup connection, then it is nothing more than an AT command parser with D-Bus interface. I am failing to see the point why this code was ever moved outside NetworkManager to begin with then. Not all modems are PPP. The IP layer handling isn't the responsibility of the modem manager, it's the responsibility of the connection manager, since the conneciton manager applies the IP-layer policies and such. There are a number of different IP configuration methods that modems use these days: PPP, static IP, and DHCP. It makes no sense to put PPP into ModemManager without putting the other two in as well. But putting the other two into MM is clearly expanding the scope of MM way beyond what it should be. I am fine with ModemManager not doing IP configuration, but PPP is mostly a transport layer. The IP configuration aspects are only on top of it. So I would expect ModemManager to do the PPP handling and then tell the application the IP details (routing, nameserver etc.) to actually set these details. Ok sure, but this has additional drawbacks: - complicating the API, since you have to funnel the PPP configuration down to ModemManager, including auth methods and auth method setup (potentially including EAP), MPPE, etc. It does mean a lot of additional configuration may need to be sent from the connection manager down to MM. since ModemManager's API already has auth settings like username, password and also PIN codes, I think it would be fine to have these in there. The PPP settings are oh-so-much more though. Look through the settings for PPP some time. Many of them are not required, many of them are actually used. I'm not saying this is a show-stopper, I'm just saying that you should understand the scope of PPP configuration. There are a lot of shitty, shitty PPP servers out there, which isn't a surprise, because PPP is such a generic protocol it gets used just about everywhere. - if PPP gets stuck into MM, why wouldn't DHCP also go into MM? Obviously MM wouldn't set the IP details, but DHCP is logically at the same level here as PPP is, since at the end of either PPP or DHCP, you get nameservers and IP addresses. Seems pretty wrong to put DHCP handling into MM as well. However, clean APIs are hard to come by since the realities of the world intrude. As I said, DHCP is purely for configuration, but one of of PPP's main purpose encapsulation. Hard to tell which belongs where. I think it would be beneficial if PPP would be done inside ModemManager and then it just hands out the IP configuration via D-Bus (which is does for HSO based devices already). Yeah. So TBH, I don't really mind putting the PPP bits into MM. This would make PPP-driven devices operate identically to 'hso' devices that use AT_OWANDATA to return IP+DNS information, and MM would simply advertise that the device used the static IP configuration method, and the connection manager would apply the details provided by MM to the IP interface provided by MM (in this case ppp0 or whatever). DHCP-based devices (f3507g for example) would continue to require the connection manager to perform DHCP. I was reading through the pppd code btw. and figure out a way how we might be able to split this or reimplement in a more proper way. The pppd code is kinda ancient and carries a lot of code that is not longer be used in any modern distro. Need to play with this a little bit more and figure out which PPP features we are actually need and which ones are just pointless nowadays. Yeah, PPP code is icky. But just like dhclient, it doesn't need rewriting. There are certainly more worthwhile things to spend time on. It's got a responsive upstream who accepts patches, why not fix the specific issues you have and upstream the patches. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
Hi Dan, I was reading through the pppd code btw. and figure out a way how we might be able to split this or reimplement in a more proper way. The pppd code is kinda ancient and carries a lot of code that is not longer be used in any modern distro. Need to play with this a little bit more and figure out which PPP features we are actually need and which ones are just pointless nowadays. Yeah, PPP code is icky. But just like dhclient, it doesn't need rewriting. There are certainly more worthwhile things to spend time on. It's got a responsive upstream who accepts patches, why not fix the specific issues you have and upstream the patches. accepts that non of the distros feed their patches back into pppd upstream right now. This is a big problem actually. I am just looking into this from a pure academic point of view in what is the minimum requirement to get PPP up. For example on a 3G network that doesn't do auth or anything. Just pure PPP encapsulation. And I do wanna enable PPP over RFCOMM sockets directly. That is just the reason why I started looking into it. Since RFCOMM TTYs are just stupid and painful. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM before login?
Dan Williams wrote: Is there a way of establishing (and keeping) a WiFi connection with NetworkManager before logging in? I've read postings saying it is possible, and others saying it is not. This is provided by the nm-system-settings service. You'll want to grab the NM from F-10 updates-testing: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3686 and after a reboot, you should be able to use the connection editor to mark your wifi connections as Available to all users, which means they will be available before login. Thanks very much, I'll try that. Though I am reasonably sure - having followed your suggestion to use nm-tools - that the occasional problem with my Orinoco Gold PCMCIA card is something to do with the orinoco_cs driver rather than NM. You might get better luck by using the 'hostap' driver for your card, most of the orinoco cards can be driven by hostap too. Well, WiFi is working sufficiently well at the moment that I don't like to disturb it. I did try hostap in the distant past, but didn't find it as good as orinoco_cs with my cards. However, I've used an airport card (which is essentially orinoco) pretty successfully with recent NM versions. What sort of issues are you having with it, and what kernel version are you running? I'm running Fedora-10 with KDE, and always keep it up to date; at present my kernel is 2.6.27.21-170.2.56 . The only issue is that about 1 time in 5 WiFi does not come up when I re-boot. I haven't found anything that works then except re-booting again. When I do that WiFi almost always works - perhaps 9 times out of 10. I find that when I suspend to RAM with WiFi working it is nearly always still working when the machine awakes. Dan -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
On Mon, 2009-05-11 at 16:31 -0700, Marcel Holtmann wrote: Hi Dan, I was reading through the pppd code btw. and figure out a way how we might be able to split this or reimplement in a more proper way. The pppd code is kinda ancient and carries a lot of code that is not longer be used in any modern distro. Need to play with this a little bit more and figure out which PPP features we are actually need and which ones are just pointless nowadays. Yeah, PPP code is icky. But just like dhclient, it doesn't need rewriting. There are certainly more worthwhile things to spend time on. It's got a responsive upstream who accepts patches, why not fix the specific issues you have and upstream the patches. accepts that non of the distros feed their patches back into pppd upstream right now. This is a big problem actually. Is that the distros fault? Quite possibly. Upstream was dormant for a while, but they picked up again about 6 months ago, and even accepted a boatload of patches. Time to try again. I am just looking into this from a pure academic point of view in what is the minimum requirement to get PPP up. For example on a 3G network that doesn't do auth or anything. Just pure PPP encapsulation. Right, but managing modems isn't purely about 3G. It's also about plain old 56k, which a lot of people still use. And don't expect all 3G modems to work the same way WRT PPP implementation, I've seen enough variation here already. The recent bogus DNS server issue is one symptom of that that upstream has already corrected. And I do wanna enable PPP over RFCOMM sockets directly. That is just the reason why I started looking into it. Since RFCOMM TTYs are just stupid and painful. So maybe a pppd plugin is in order here. If PPTP does it, I don't see why rfcomm cannot. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Talking to NM 0.7 with dbus vs. libnm_glib
On Wed, 2009-05-06 at 22:42 +0200, Christian Huff wrote:
Hi,
I am currently working at the libpurple/pidgin NetworkManager
integration code to improve to user experience with roaming with
multiple devices. Currently, libpurple only reacts to the global
StateChange signal, which does not change if one device goes offline or
online and there is another active device. In effect, this often results
in the inability to send or receive messages - the apps stalls until a
timeout occurs.
libpurple gets the current global NM state through Dbus, so, being kinda
new to glib programming, I tried to get NM's devices, connect to device
StateChanged, DeviceAdded and DeviceRemoved signals using
dbus_g_proxy_connect_signal. Doing so, I found I needed to register
custom marshallers as NetworkManager.h didn't provide them (this was
with 0.7.0, I haven't checked 0.7.1 yet). Also, I had to store a proxy
for each device, effectively producing some overly complicated code that
wouldn't make it into libpurple...
libnm-glib makes this easy for you, as it will proxy these signals into
GObject signals. You shouldn't really need to touch dbus-glib at all
here. Using libnm-glib, you could have created a new NMClient object,
then queried that object for the list of devices, or attached to the
'device-added' / 'device-removed' signals or 'state' properties. I can
explain more if you like.
But the approach you took was wrong. Not a problem though, given you
hadn't done this before :)
So I read that libnm_glib was rewritten with 0.7, and rewrote my patch
using it. The code turned out much cleaner, yet I found some problems
that I want to share with you. One of the goals I had set myself was to
minimize the number of unnecessary reconnects. A scheme to do so would
be to track the devices that are active at a connect action, and
reconnect only if such a critical device goes down. Another would be
to see if the device currently going down is part of an Active
Connection (NMActiveConnection) that NM reports as being the/a default
connection for DNS and routes.
Yeah, I'd expect that whenever the 'default' property on an active
connection changes, that's when you'd want to see if you should
reconnect.
While the former scheme was not perfect, the latter wasn't reliable,
either. I found nm_active_connection_get_default() to often return true
for multiple active connections, and sometimes the value from before and
sometimes the predicted value from after the device StateChanged event.
That kind of synchronisation problems currently prevent me from
implementing that scheme.
That behavior seems wrong. The NM code should ensure that only one
active connection object has the default property at the same time, but
there may be some latency issues in libnm-glib's proxying of properties.
Or, you may have been checking things at the wrong time. Can you post
some code, or ideally a distilled testcase?
If libnm-glib is reporting two NMActiveConnection objects having
default=True at the same time, that's something that should get
identified and fixed.
Also, I tried to entirely replace the dbus functionality, but
libnm_glib_get_network_state() does not return values equivalent to the
StateChanged signal, and I didn't find the signal in the libnm_glib docs.
No, it doesn't. libnm_glib_get_network_state() is the old interface
from NM 0.6 that was preserved for minimal compatibility. You'd want to
create a new NMClient object and attach signals to it:
static void
state_changed (NMClient *client,
GParamSpec *pspec,
gpointer user_data)
{
NMState state;
state = nm_client_get_state (client);
do something here
}
static void
active_connections_changed (NMClient *client,
GParamSpec *pspec,
gpointer user_data)
{
const GPtrArray *acs = nm_client_get_active_connections (client);
int i;
for (i = 0; i acs-len; i++) {
NMActiveConnection *ac = g_ptr_array_index (acs, i);
if (nm_active_connection_get_default (ac))
its default
}
}
int main (...)
{
NMClient *client;
client = nm_client_new ();
/* Monitor state */
g_signal_connect (client, notify::state,
G_CALLBACK (state_changed), my_data);
g_signal_connect (client, notify::active-connections,
G_CALLBACK (active_connections_changed), my_data);
g_main_loop_run (loop);
g_object_unref (client);
}
Dan
The current version of my patch reconnects any time a device enters or
leaves the NM_DEVICE_STATE_ACTIVATED state, and can be found at:
http://developer.pidgin.im/ticket/8694
thanks for your feedback,
Christian Huff (Pedric)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Detecting network profiles using mac address of default gateway
On Wed, 2009-05-06 at 11:44 +0100, Giles Westwood wrote: Hi list, Apologies if this has been asked before, I did try searching first and couldn't find anything. I was going to hack something myself but I'd rather use the network manager instead if it's possible. I'm wanting to set a list of custom search domains at home and at the office so I'm using address only dhcp and setting dns servers and search domains manually in two different profiles. I'd rather that the network manager could get my dhcp lease, and use the mac address of the default gateway to determine what my location is, then select the correct network profile. Any pointers on how to do this much appreciated otherwise I'll be running a cron job and hacking things manually. This sort of thing isn't implemented at this time; but we've discussed it a lot before. It would be an opt-in sort of thing, certainly not on by default, because it risks spamming the network quite heavily. While it would probably be done slightly differently than you suggest, I think the outcome would be the same. Somebody needs to come up with a suggested strawman implementation that we can beat about though. Note that for 802.1x, we apparently *can* autodetect what connection to use because there are some frames the switch transmits that we can pick up on. We'd still need arping or something for non-802.1X ethernet though. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Question in function nm_device_state_changed()
On Wed, 2009-05-06 at 11:40 +0800, 代尔欣 wrote:
Hi all,
I have a question about the NetworkManager-0.7.1 codes.
In NetworkManager-0.7.1/src/nm-device.c:
void nm_device_state_changed (NMDevice *device,
NMDeviceState state,
NMDeviceStateReason reason)
{
...
// Here the fifth parameter is set to 0. I think it should be set
to reason so that the receiver of the signal state-changed can
do
The question is what event is causing the reason to be 0. Was it a
user-requested disconnection? Was it something else? There may
definitely be some places in NM that don't set the code correctly, but
we need to identify which scenario you've hit here.
// something special base on the state change reason. e.g. When
NM_DEVICE_STATE_DISCONNECTED state signaled, if
// the reason is NM_DEVICE_STATE_REASON_USER_REQUESTED then we
do not schedule auto connect in
// NetworkManagerPolicy.c device_state_changed() or
// set a flag in device-related device_state_changed() and reload
the can_activate() function to check this flag.
g_signal_emit_by_name (device, state-changed, state, old_state,
0);
...
The reason we probably don't schedule autoconnection on disconnect is
precisely because the user chose to manually disconnect. If we did
reschedule the autoconnect, then NM would simply reconnect the
connection the user just disconnected.
Dan
}
If I'm wrong, please point out. Thanks!
___
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: Operation from command line?
On Wed, 2009-05-06 at 12:51 -0700, don fisher wrote: Is it possible to use NM from the command line? I do not know how to run the nm-applet in that environment. NM exposes a D-Bus interface that can be manipulated through command-line utilities. There have been a number of them started, but apparently none really finished. Some control can be done via dbus-send, or you can use python quite easily. A command-line utility is definitely something on the todo-list. Also, is there a document that describes what NM is doing an what files it accesses. I am trying to get half way back to the old situation where the files were in etc like /etc/sysconfig/network-scripts/ifcfg-eth0. nm-system-settings translates system config files and provides those to NetworkManager. If those files are marked with ONBOOT=yes, then NM will activate them automatically. If they aren't, some simple python would allow you to essentially ifup/ifdown those. I think in the future we do actually want to hook up Fedora's ifup/ifdown to NM when NM is being used. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - Disconnect option broken? [PATCH]
On Thu, 2009-05-07 at 15:05 -0400, Raul Gutierrez Segales wrote: Dan, The attached patch fixed the problem for me. The out_active variable wasn't been assigned in applet_find_active_connection_for_device. Sounds correct? Yup, committed, thanks! Dan On Thu, 2009-05-07 at 13:47 -0400, Dan Williams wrote: On Thu, 2009-05-07 at 11:17 -0400, Raul Gutierrez Segales wrote: Dan, On Thu, 2009-05-07 at 10:51 -0400, Dan Williams wrote: On Mon, 2009-05-04 at 23:50 -0400, Raul Gutierrez Segales wrote: Hi, I am running Network Manager version 0.7.1~rc4.1.cf199a964-0ubuntu2 on Ubuntu 9.04. For some reason that I haven't been able to debug yet, the network-manager-applet completely ignores the disconnect command for 3G GSM connection. My 3G modem is a (output from lsusb) : Bus 005 Device 002: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem Is this known to be broken? Seems like a matter of capturing the event and killing pppd (I have to do it by hand now..). I'd need some logs from /var/log/messages, /var/log/daemon.log, or /var/log/NetworkManager.log (wherever your distro puts NM log output which goes to the syslog 'daemon' facility), and then some logs from ~/.xsession-errors, which is where applet error output would go. Nothing interesting comes out on /var/log/daemon.log (daemon facility) when trying to disconnect, I am attaching it though. But here is what I got on ~/.xsession-errors when clicking the Disconnect item : ** (nm-applet:4990): WARNING **: gsm_menu_item_deactivate: couldn't find active connection to deactive When you get this error, can you run 'nm-tool' and tell me what the output is? dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless is disabled message
No, I never suspend or hibernate my computer (it doesn't work: another problem to fix later!). To summarise: My computer acknowledges the existence of the wireless cards, but it won't let me connect to the internet via wireless (see pic in this thread: http://ubuntuforums.org/showthread.php?t=1151646). When my laptop arrived with windows on, the external (belkin) wireless card picked up the internet. The intel wireless card doesn't work. The person in the linked conversation had exactly the same problem, and the solution he arrived at in the thread he started in Fedora Forums was: After not getting answers in this forum i inquired at the NetworkManager mailing list, and got the above information. I was told that NetworkManager code honors and checks the HAL killswitch, with no user option to make it NOT honor it (software author's decision). however, the author(s) were kind enough to share a quick hack of the source code to disable the honoring of the killswitch, which worked like a charm, making NetworkManager detect and control my removable WiFi card. If it helps, I'm using Linux Mint. The first time I plugged in the wireless card it acknowledged it and set up the drivers for it, which is why I think it's Network Manager which believes the wireless kill switch to be off when it is in fact hooked up to a defective wireless device. I did read somewhere that Network Manager honours the kill switch, and uses it for ALL network devices rather than allowing control of individual devices. I think there's a clear argument that the downstream user should be able to enable and disable individual devices, in the event they have a problem like mine. Regards, Tom 2009/5/11 Dan Williams d...@redhat.com On Mon, 2009-05-11 at 14:46 +0900, Thomas O'Donoghue wrote: I found out about this list through the forum mentioned in the following thread: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00256.html and appear to have the same problem. The person appealed to you guys and seemed to get a fix: I looked through the messages, but was unable to deduce what that fix was. I have the same problem (my internal Intel wireless card doesn't work, so I think the computer automatically assumes that the wireless switch is set to off). I'm using an external card, but cannot enable wireless to use it. Does this happen when you return from suspend/hibernate? If so, please see: https://bugzilla.redhat.com/show_bug.cgi?id=477964 Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
