[Fwd: system wide settings again ^^]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, This time I've got different question about system wide settings. Don't know if the problem is on my end or NM Makefile. The file: /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service contains entry: Exec=/usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf but after default installation I had no /etc/NetworkManager/nm-system-settings.conf file So I've created /etc/NetworkManager/nm-system-settings.conf as follow: [main] plugins=keyfile When I tried to save the system wide settings I got another error (can't find it right now to link), but it was complaining that can't save the settings. As I found out later on, /etc/NetworkManager/system-connections/ didn't exist. NM tried to create it, but it created a FILE and die with an error. When I created the directory manually and saved the example file everything worked fine. Now my question is, does networkmanager create these files/folders by default during make install, or should it create when you try to save config file for the first time? I've checked files which are installed by my script (which generally runs make install): (linked only etc files): = [dir] /etc = [dir] /etc/dbus-1 = [dir] /etc/dbus-1/system.d |- [obj] /etc/dbus-1/system.d/NetworkManager.conf |- [obj] /etc/dbus-1/system.d/nm-dhcp-client.conf |- [obj] /etc/dbus-1/system.d/nm-dispatcher.conf |- [obj] /etc/dbus-1/system.d/nm-avahi-autoipd.conf |- [obj] /etc/dbus-1/system.d/nm-system-settings.conf = [dir] /etc/NetworkManager = [dir] /etc/NetworkManager/dispatcher.d = [dir] /etc/init.d |- [obj] /etc/init.d/NetworkManager I've also checked src/Makefile.am and there is only: rundir=$(localstatedir)/run/NetworkManager dispatcherdir=$(sysconfdir)/NetworkManager/dispatcher.d install-data-hook: ~ $(mkinstalldirs) -m 0700 $(DESTDIR)$(rundir) ~ $(mkinstalldirs) -m 0755 $(DESTDIR)$(dispatcherdir) CLEANFILES = $(BUILT_SOURCES) Should it be patched in NM or should distros come up with their own patches for it? Thanks, Rob -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJImHUQAAoJELvLB8ABrzqYVt8QAM00u+5pYysyjmZCpmoY9CB9 gswlLvULTDjj5wKToOVVBkTUQ/plfVOiwWwg58rnohFZjp3rtG2WWiJlHWPsumuU 2UZXlupo48fskuVJU6QpMn4yLPnkf9SwKsS/t9BCohM5mtECbQiSSAPnDKDchrS+ /nk0mmX560wFEcAdtveZlHYQ0msFc9hBVsigysagtLN1WFAzrU9U175V3GyCY4W4 Hu18s74TR1UOwB9kGT/reGhlmirEl7sIn5Uf1g5Fcl8GSPMuh4k5/AvRy25cqtZ5 xPsiKF7JgvReCz38dzFa7Q+L+hw6qdp7RU9gGdkJk+frASZYz0MIOVbig3B+sLCv eG20TBoDRG4hAey41sDdkQWn4WUw0vglSelaEMq3/UZCnalR+wP5Z4wIlnyNRrXy E0aUq+AsSykslgOjv5r/PxfP9mXnJJ5S2g092/c/9UgXuMzT8+UYIkBcIpf7XiKw i6xwdn5PRHVT5RcQgrTsLry+zgQlSsZwITuKg0BIZ7JoOMxdjCVCCN2LUX2le3Np +vzO412akAJXQjk52wh8YYwnS1a9H3++NZUqSSo9ZpzaEabXbPAnF+vyANHo45B5 NFrMBoTp/CO+yD20G3SXzTfDhAkVOsna1NM47PCxx//hlpV2mNefLfTCY0oIGkpV 2fv65bWBNJBQPoYgzR1A =1GnW -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Fwd: system wide settings again ^^]
On Tue, 2008-08-05 at 16:43 +0100, Robert Piasek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dan, This time I've got different question about system wide settings. Don't know if the problem is on my end or NM Makefile. The file: /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service contains entry: Exec=/usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf but after default installation I had no /etc/NetworkManager/nm-system-settings.conf file On my F9 machine the above file was created contining: [main] plugins=ifcfg-fedora So I've created /etc/NetworkManager/nm-system-settings.conf as follow: [main] plugins=keyfile When I tried to save the system wide settings I got another error (can't find it right now to link), but it was complaining that can't save the settings. As I found out later on, /etc/NetworkManager/system-connections/ didn't exist. NM tried to create it, but it created a FILE and die with an error. When I created the directory manually and saved the example file everything worked fine. Now my question is, does networkmanager create these files/folders by default during make install, or should it create when you try to save config file for the first time? I've checked files which are installed by my script (which generally runs make install): (linked only etc files): = [dir] /etc = [dir] /etc/dbus-1 = [dir] /etc/dbus-1/system.d |- [obj] /etc/dbus-1/system.d/NetworkManager.conf |- [obj] /etc/dbus-1/system.d/nm-dhcp-client.conf |- [obj] /etc/dbus-1/system.d/nm-dispatcher.conf |- [obj] /etc/dbus-1/system.d/nm-avahi-autoipd.conf |- [obj] /etc/dbus-1/system.d/nm-system-settings.conf = [dir] /etc/NetworkManager = [dir] /etc/NetworkManager/dispatcher.d = [dir] /etc/init.d |- [obj] /etc/init.d/NetworkManager I've also checked src/Makefile.am and there is only: rundir=$(localstatedir)/run/NetworkManager dispatcherdir=$(sysconfdir)/NetworkManager/dispatcher.d install-data-hook: ~ $(mkinstalldirs) -m 0700 $(DESTDIR)$(rundir) ~ $(mkinstalldirs) -m 0755 $(DESTDIR)$(dispatcherdir) CLEANFILES = $(BUILT_SOURCES) Should it be patched in NM or should distros come up with their own patches for it? Thanks, Rob -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJImHUQAAoJELvLB8ABrzqYVt8QAM00u+5pYysyjmZCpmoY9CB9 gswlLvULTDjj5wKToOVVBkTUQ/plfVOiwWwg58rnohFZjp3rtG2WWiJlHWPsumuU 2UZXlupo48fskuVJU6QpMn4yLPnkf9SwKsS/t9BCohM5mtECbQiSSAPnDKDchrS+ /nk0mmX560wFEcAdtveZlHYQ0msFc9hBVsigysagtLN1WFAzrU9U175V3GyCY4W4 Hu18s74TR1UOwB9kGT/reGhlmirEl7sIn5Uf1g5Fcl8GSPMuh4k5/AvRy25cqtZ5 xPsiKF7JgvReCz38dzFa7Q+L+hw6qdp7RU9gGdkJk+frASZYz0MIOVbig3B+sLCv eG20TBoDRG4hAey41sDdkQWn4WUw0vglSelaEMq3/UZCnalR+wP5Z4wIlnyNRrXy E0aUq+AsSykslgOjv5r/PxfP9mXnJJ5S2g092/c/9UgXuMzT8+UYIkBcIpf7XiKw i6xwdn5PRHVT5RcQgrTsLry+zgQlSsZwITuKg0BIZ7JoOMxdjCVCCN2LUX2le3Np +vzO412akAJXQjk52wh8YYwnS1a9H3++NZUqSSo9ZpzaEabXbPAnF+vyANHo45B5 NFrMBoTp/CO+yD20G3SXzTfDhAkVOsna1NM47PCxx//hlpV2mNefLfTCY0oIGkpV 2fv65bWBNJBQPoYgzR1A =1GnW -END PGP SIGNATURE- ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- === Take that, you hostile sons-of-bitches! -- James Coburn, in the finale of _The_President's_Analyst_ === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add dhcp timeout and anycast config options
On Mon, Aug 04, 2008 at 06:30:35PM -0400, Dan Williams wrote: On Mon, 2008-08-04 at 12:28 +0100, Sjoerd Simons wrote: Add configuration options for apply a dhcp timeout and using DHCP using anycast instead of broadcast. So; does the DHCP timeout change for the mesh devices at all in the new scheme? At what points might the DHCP timeout be something other than the max or the min? I'm not sure what you mean with max and min here. But the olpc connection algorithm is afaik to basically try out the three ``standard'' mesh frequencies one by one using dhcp to see if there is a school server around. In this case the 45 second timeout is a bit long. Which is why the possibility to set a smaller timeout is desirable. I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Sjoerd -- It's very inconvenient to be mortal -- you never know when everything may suddenly stop happening. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add dhcp timeout and anycast config options
Yes that would be useful as for 3G devices the data path can take a few seconds to stabilise and get the DHCP packets through after a connect is established. I was looking at how to change the DHCP time-out for these and perhaps get it to make a couple of requests rather than the default of useing a default IP address. -- Stuart Ward M +44 7782325143 On Tue, Aug 5, 2008 at 6:10 PM, Sjoerd Simons [EMAIL PROTECTED] wrote: On Mon, Aug 04, 2008 at 06:30:35PM -0400, Dan Williams wrote: On Mon, 2008-08-04 at 12:28 +0100, Sjoerd Simons wrote: Add configuration options for apply a dhcp timeout and using DHCP using anycast instead of broadcast. So; does the DHCP timeout change for the mesh devices at all in the new scheme? At what points might the DHCP timeout be something other than the max or the min? I'm not sure what you mean with max and min here. But the olpc connection algorithm is afaik to basically try out the three ``standard'' mesh frequencies one by one using dhcp to see if there is a school server around. In this case the 45 second timeout is a bit long. Which is why the possibility to set a smaller timeout is desirable. I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Sjoerd -- It's very inconvenient to be mortal -- you never know when everything may suddenly stop happening. ___ 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: [PATCH] Add dhcp timeout and anycast config options
On Tue, 2008-08-05 at 18:17 +0100, Stuart Ward wrote: Yes that would be useful as for 3G devices the data path can take a few seconds to stabilise and get the DHCP packets through after a connect is established. I was looking at how to change the DHCP time-out for these and perhaps get it to make a couple of requests rather than the default of useing a default IP address. In what cases will 3G use DHCP? AFAIK its either PPP (most cards) or handled internally by the card (Option 3G driven by hso). Is this a BT PAN or USB ethernet connection to a phone that just bridges that to the packet data network or something? What phone model and service provider, and how do you end up setting things like APN and preferred bands in this case? Dan -- Stuart Ward M +44 7782325143 On Tue, Aug 5, 2008 at 6:10 PM, Sjoerd Simons [EMAIL PROTECTED] wrote: On Mon, Aug 04, 2008 at 06:30:35PM -0400, Dan Williams wrote: On Mon, 2008-08-04 at 12:28 +0100, Sjoerd Simons wrote: Add configuration options for apply a dhcp timeout and using DHCP using anycast instead of broadcast. So; does the DHCP timeout change for the mesh devices at all in the new scheme? At what points might the DHCP timeout be something other than the max or the min? I'm not sure what you mean with max and min here. But the olpc connection algorithm is afaik to basically try out the three ``standard'' mesh frequencies one by one using dhcp to see if there is a school server around. In this case the 45 second timeout is a bit long. Which is why the possibility to set a smaller timeout is desirable. I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Sjoerd -- It's very inconvenient to be mortal -- you never know when everything may suddenly stop happening. ___ 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: [PATCH] Add dhcp timeout and anycast config options
On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: On Mon, Aug 04, 2008 at 06:30:35PM -0400, Dan Williams wrote: On Mon, 2008-08-04 at 12:28 +0100, Sjoerd Simons wrote: Add configuration options for apply a dhcp timeout and using DHCP using anycast instead of broadcast. So; does the DHCP timeout change for the mesh devices at all in the new scheme? At what points might the DHCP timeout be something other than the max or the min? I'm not sure what you mean with max and min here. But the olpc connection algorithm is afaik to basically try out the three ``standard'' mesh frequencies one by one using dhcp to see if there is a school server around. In this case the 45 second timeout is a bit long. Which is why the possibility to set a smaller timeout is desirable. Right; I had hardcoded it to 20s on the nm-0-6-olpc branch. Since that value doesn't really need to be changed by the user on per-connection basis, it doesn't need to be part of the IP4 setting at all. I was referring to the bits in the patch that modify nm-setting-ip4-config.c in verify() and also the GObject property. I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Well, the mesh code is specific for OLPC, and the DHCP timeouts there were tuned to the specific mesh cases and behavior that we had with OLPC. Furthermore, DHCP timeouts shouldn't need to be changed in general anyway. People always try to get the DHCP timeout raised for wireless stuff, but the fact is that if you're not connected in 45 seconds, the driver has a bug, your key is wrong, or you're waaay out of range. There is no good reason to allow user-configurable DHCP timeouts at this point. Just because the option can be tweaked doesn't mean it should in 99% of cases. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add dhcp timeout and anycast config options
On Tue, Aug 05, 2008 at 02:05:51PM -0400, Dan Williams wrote: On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Well, the mesh code is specific for OLPC, and the DHCP timeouts there were tuned to the specific mesh cases and behavior that we had with OLPC. Well hopefully the mesh code will become less OLPC specific soon. As mesh-support is now in the mainline linux kernel and should work with all mac80211s devices. But indeed this change is indeed a tad specific to the OLPC usecase. Furthermore, DHCP timeouts shouldn't need to be changed in general anyway. People always try to get the DHCP timeout raised for wireless stuff, but the fact is that if you're not connected in 45 seconds, the driver has a bug, your key is wrong, or you're waaay out of range. There is no good reason to allow user-configurable DHCP timeouts at this point. Just because the option can be tweaked doesn't mean it should in 99% of cases. Just because you can set the property in the D-Bus interface doesn't mean you have to :) But yeah, i'll rewrite this to not expose the dhcp timeout setting in the general ip4 config properties. What are your feelings about the anycast property, as it's probably even more specific to OLPC? Sjoerd -- Science and religion are in full accord but science and faith are in complete discord. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add dhcp timeout and anycast config options
On Tue, 2008-08-05 at 19:52 +0100, Sjoerd Simons wrote: On Tue, Aug 05, 2008 at 02:05:51PM -0400, Dan Williams wrote: On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: I'd rather not have configurable DHCP timeouts in this manner because for non-mesh cases, the DHCP timeout never needs to change. If we can set the DHCP timeout for mesh operations in the activation request like the old code did, that would be preferable. I guess i could do that. But that would mean mixing device configuration and ip configuration for mesh devices, which doesn't seem the right way to me. I don't really see any harm in exposing this functionality for all devices (although maybe we should clamp it to a certain min and max value)? Well, the mesh code is specific for OLPC, and the DHCP timeouts there were tuned to the specific mesh cases and behavior that we had with OLPC. Well hopefully the mesh code will become less OLPC specific soon. As mesh-support is now in the mainline linux kernel and should work with all mac80211s devices. But indeed this change is indeed a tad specific to the OLPC usecase. Furthermore, DHCP timeouts shouldn't need to be changed in general anyway. People always try to get the DHCP timeout raised for wireless stuff, but the fact is that if you're not connected in 45 seconds, the driver has a bug, your key is wrong, or you're waaay out of range. There is no good reason to allow user-configurable DHCP timeouts at this point. Just because the option can be tweaked doesn't mean it should in 99% of cases. Just because you can set the property in the D-Bus interface doesn't mean you have to :) But yeah, i'll rewrite this to not expose the dhcp timeout setting in the general ip4 config properties. What are your feelings about the anycast property, as it's probably even more specific to OLPC? My feeling is that anycast should stay specific to the OLPC case, since it's an OLPC implementation detail. We can put some stuff internally to make anycast and the 'initial-interval' stuff easier for the OLPC mesh device, but I don't think we need to expose it. Maybe the better approach here is to create an olpc-mesh setting type which would be used in the NMSettingConnection's -type field. This type would only be valid when used with the OLPC mesh device class and when NM saw this connection type in a connection, it would know to activate the mesh device if needed. Thus, you could add some OLPC specific stuff like anycast address, and whether to start MPP on that particular connection or not to the setting. I'm not sure what the implications of having two separate connections here are (one for the 802.11 wifi device and one for the mesh device) and how they'd interact, but this approach might work. The real logic in the OLPC NM builds was to do the handoffs between the WiFi and mesh interfaces, but they each had their own individual configuration in the end. Since each NMConnection provides individual configuration that might be a way to go with this. So what actual mesh-specific tunables (besides anycast address) would you anticipate needing? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Fwd: system wide settings again ^^]
On Tuesday 05 August 2008 16:57:57 Aaron Konstam wrote: but after default installation I had no /etc/NetworkManager/nm-system-settings.conf file On my F9 machine the above file was created contining: [main] plugins=ifcfg-fedora Did you install precompiled package or build from source? Rob ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
56k questions
First of all, I'd like to thank everyone for their hard work on this project, NM is an awesome tool. This post isn't so much a complaint as it is feedback and an inquiry, so sorry if it comes off harsh. I'm an Ubuntu 8.04 user and occasionally I need to use my Dell laptop's modem because I am not near any wireless or wired connections. After finally getting the drivers up and running, I noticed that using a modem in nm is a little awkward. I have two options: connect to ppp0 and disconnect from ppp0. I'm trying to figure out what was the design decision behind having it that way. I feel like I have no real control over my modem when using nm because I get no feedback about what my modem is doing. As a recent convert to Linux, here's my experience using nm for dialup for the first time: 1. I press connect to ppp0, nothing happens, so I press it again. I'm wondering hmm, how do I know if it's dialing? after trying again, a few seconds it starts to dial. I think to myself that was weird, but oh well, it's working now 2. After the dialing process and all those classic beeps and boops and screeches that we've all come to love have finished, nothing happens. The icon of nm stays in the disconnected state (two computers with a red [X]) I'm thinking wait, did it connect or what? 3. I go to the dialup connections menu in nm and see that my 2 choices are still connect to ppp0 and disconnect from ppp0. I open my browser to discover that I do in fact have a connection, but I'm still confused. 4. When I have concluded the use of the internet, I go to disconnect from ppp0, and once again, I find no indication that it has successfully disconnected. Now, as a little background, I'm a computer science student in college, so if it confused me, I'd hate to be in the situation of other users. And while some of you may suggest that there are other programs out there instead of nm, if nm is the default manager for a distro like ubuntu, then making it as transparent to users as possible is probably a goal. I guess what I'd like to see is some sort of feedback from nm during the use of dialup connections. Are there technical limitations that prevent this, or is it more of a lack of manpower? If I can learn about the situation, then perhaps I may be able to contribute to make nm just as amazing for dialup as it is for wired/wireless connections. - Jess Bermudes ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 56k questions
On Tue, Aug 5, 2008 at 7:12 PM, Jess Bermudes [EMAIL PROTECTED] wrote: First of all, I'd like to thank everyone for their hard work on this project, NM is an awesome tool. This post isn't so much a complaint as it is feedback and an inquiry, so sorry if it comes off harsh. I'm an Ubuntu 8.04 user and occasionally I need to use my Dell laptop's modem because I am not near any wireless or wired connections. After finally getting the drivers up and running, I noticed that using a modem in nm is a little awkward. I have two options: connect to ppp0 and disconnect from ppp0. I'm trying to figure out what was the design decision behind having it that way. I feel like I have no real control over my modem when using nm because I get no feedback about what my modem is doing. As a recent convert to Linux, here's my experience using nm for dialup for the first time: 1. I press connect to ppp0, nothing happens, so I press it again. I'm wondering hmm, how do I know if it's dialing? after trying again, a few seconds it starts to dial. I think to myself that was weird, but oh well, it's working now 2. After the dialing process and all those classic beeps and boops and screeches that we've all come to love have finished, nothing happens. The icon of nm stays in the disconnected state (two computers with a red [X]) I'm thinking wait, did it connect or what? 3. I go to the dialup connections menu in nm and see that my 2 choices are still connect to ppp0 and disconnect from ppp0. I open my browser to discover that I do in fact have a connection, but I'm still confused. 4. When I have concluded the use of the internet, I go to disconnect from ppp0, and once again, I find no indication that it has successfully disconnected. Now, as a little background, I'm a computer science student in college, so if it confused me, I'd hate to be in the situation of other users. And while some of you may suggest that there are other programs out there instead of nm, if nm is the default manager for a distro like ubuntu, then making it as transparent to users as possible is probably a goal. I guess what I'd like to see is some sort of feedback from nm during the use of dialup connections. Are there technical limitations that prevent this, or is it more of a lack of manpower? If I can learn about the situation, then perhaps I may be able to contribute to make nm just as amazing for dialup as it is for wired/wireless connections. - Jess Bermudes ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list Ubuntu 8.04 ships with 0.6.6 which does not have dial-up support so I think you are seeing some Ubuntu specific additions. If I remember right what you are seeing is that it just calls the Gnome dialup tools rather than network manager doing anything which is why NM shows you as disconnected. I think version 0.7 of Network Manager will have much better integrated for modems ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
