Re: Wireless connection to (none)
Dan Williams wrote: On Tue, 2009-04-21 at 21:51 -0700, Robert Simpson wrote: I found these archived messages through Google, and I have the same problem - the connection works fine, and the Connection Established message displays the right AP name, but the tray icon says there is a Wireless network connection to '(none)', and there are no bars showing signal strength. nm-list shows the connected AP at the top of the list, but there is no *. What driver? This problem can happen if the driver does not consistently report the currently associated AP in the scan results. It could also happen if the card associates to a new AP that hasn't yet been found from a scan. But in that case, the card should definitely have the beacon from that AP, and should have added that AP to the scan results that NM can get with SIOCGIWSCAN anyway. Dan wl, the proprietary Broadcom STA wireless driver for Broadcom Corporation BCM4312 802.11b/g [14e4:4315], installed by default. I'm not sure how to display the version. Strangely, when left on but with the screen closed for a few hours, the tray icon mysteriously displayed the correct information, but the nm-tool still showed no entries with a *. This was repeatable - it would start out showing no bars and (none), then the tray icon would work suddenly work normally after an extremely long time. Using the Windows driver with ndiswrapper seems to work properly from the start (though it takes a bit longer to connect), and it does show the *. I guess I'll just use that. - Rob Re: Wireless connection to (none) * From: Dan Williams dcbw redhat com * To: sanjeev sharma sanjeevsharmaengg gmail com * Cc: networkmanager-list gnome org * Subject: Re: Wireless connection to (none) * Date: Wed, 04 Feb 2009 11:50:05 -0500 On Wed, 2009-02-04 at 11:39 +0530, sanjeev sharma wrote: Hi Dan, As we had Already Discussed this and I had Created an Patch for this Bug which is in NetworkManager.And you had a look into it earlier.Could I checked in this patch Into NetworkManager CVS.So We could Closed this Bug after checked in patch. I believe my last comment on the patch was that it only covers over the problem, it doesn't actually fix the problem. You'll only get this issue when NetworkManager cannot find the currently associated AP in the scan list, which could be either a driver bug, or a NetworkManager bug. Using nm-tool will help determine whether its in the applet, or in NetworkManager. Dan Regards sanjeev sharma On Tue, Feb 3, 2009 at 10:02 PM, Dan Williams dcbw redhat com wrote: On Sun, 2009-02-01 at 00:57 +0100, Ermanno Bonifazi wrote: Network manager shows in the tooltip to be connected to (none) network name, even if is connected to a specific Wireless LAN (e.g. WLAN) and is correctly working. In fact is I right click on connection information the name WLAN with the correct IP is shown. Any hint? What version of NetworkManager? When you see this bug, and you run 'nm-tool', does a * show up next to the wifi network you should be connected to? Dan ___ NetworkManager-list mailing list NetworkManager-list gnome org http://mail.gnome.org/mailman/listinfo/networkmanager-list * References: o Re: Wireless connection to (none) + From: Dan Williams o Re: Wireless connection to (none) + From: sanjeev sharma ___ 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
VPN, PPTP: send all traffic through the tunnel.
Hello In order to use all the services my university provides I have to connect via VPN (PPTP) and send all the traffic trough the tunnel. I cannot see any option of this sort. Are there any plans to include it? thanks Uwe Brauer ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Issue with static ip in NM
Ok, one last question... NetworkManager is supposed to pick up any changes in
the /etc/NetworkManager/system-connections folder assuming the config file is
set to plugins=keyfile, correct? If this is the case, why would NetworkManager
not be picking up on these changes unless I manually set the file up through
the NetworkManager config utility and then overwrite it? So I guess the big
question is does NetworkManager pick up on new files put in the
system-connections folder as long as they follow the proper syntax?
Jonathan Hooker
Desktop Support - Engineering
Garmin International
Office: 913-440-2767
Need Help? Please Contact the Help Desk: 913-440-2000 or x2000
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 9:08 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: RE: Issue with static ip in NM
On Thu, 2009-04-23 at 07:00 -0500, Hooker, Jonathan wrote:
That makes sense. Unfortunately, I am somewhat new to this level of network
management, would it be possible to maybe get an example? Also remembering
that it is possible to have multiple usb devices connected at the same time...
Right, which is why NM doesn't use device names, since those change with
plug/unplug too. Unfortunately, since most manufacturers seem to ignore
stuff like the USB serial number and populate that field with zeros or
some other non-device-unique value, all we've got left is the MAC
address to uniquely identify a particular device.
But of course, Garmin sets a valid, globally unique serial number on
every device, right? That makes your life a lot easier.
So you'll put some udev rules files in /etc/udev/rules.d (the
user-editable rules directory) that detect the presence of your device,
and run a small helper script which can then assign a MAC to the device
based off the serial number. Check out:
http://reactivated.net/writing_udev_rules.html
You'll be matching sysfs attributes, so something like:
ACTION!=add|change, GOTO=fake_mac_end
SUBSYSTEM!=usb, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idVendor}!=your vid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idProduct}!=your pid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{iSerial}==?*,
ENV{ID_FAKE_MAC_USB_SERIAL}=$attr{iSerial}
SUBSYSTEMS==usb, IMPORT{program}=fake-the-mac $env{ID_FAKE_MAC_USB_SERIAL}
$tempnode, GOTO=fake_mac_end
LABEL=fake_mac_end
then in the script /lib/udev/fake-the-mac, you'll assign a MAC of your
choice (maybe by hashing the serial #) to the device in argv[2] using
ethtool or whatever.
Dan
These are actually development devices. They do have the capability of
getting out on the network but it is just because of some routing rules where
we route its static ip through the eth0 of the machine to allow it on.
Jonathan Hooker
Desktop Support - Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 6:52 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: Re: Issue with static ip in NM
On Thu, 2009-04-23 at 06:09 -0500, Hooker, Jonathan wrote:
Hi,
I am currently having some issues with setting a static ip to a usb0
ethernet device due to the fact that it changes mac addresses every
time I plug it in. Is there any means of predicting this change so
that I can get the its config file
in /etc/NetworkManager/system-connections setup properly? Thanks for
your help!
One way to do this is to set up a udev rules file that will always
assign a custom MAC to the device. Since the MAC comes up random, the
device clearly isn't used to connect to a real ethernet network, and
it's probably a PocketPC/Windows Mobile device?
Dan
Jonathan Hooker
Desktop Support – Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
__
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient. If you are not the intended
recipient, please be aware that any disclosure, copying, distribution
or use of this e-mail or any attachment is prohibited. If you have
received this e-mail in error, please contact the sender and delete
all copies.
Thank you for your cooperation
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.
Thank you for your
Re: How does network manager read rfkill ?
On Thu, 2009-04-23 at 22:35 +0300, Maxim Levitsky wrote: On Thu, 2009-04-23 at 07:15 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 02:16 -0400, eye zak wrote: Hi, I am writing low-level rfkill support in the ath5k driver in compat-wireless-2.6, and I am wondering how network manager knows about my rfkill device ? Hal recognizes it no problem and broadcasts an event on state change, and tracks the current state. But netowork manager (jaunty-latest) does not notice it. NM finds all devices in HAL with the capability 'killswitch', and polls them every 6 seconds to find out if any of them return 0 for GetPower. If any do, it assumes rfkill. Are you sure NM is allowed to talk to HAL on your distribution? Some distros like Debian use different D-Bus permissions styles, and if those are wrong in the /etc/dbus-1/system.d/NetworkManager.conf, NM may not be able to talk to HAL and get the killsiwtch state. Dan Or, it currently ignores platform kill switches, like acer-wmi Do those rfkill switches expose themselves via HAL? If so, then NetworkManager is expected to work with them. If not, then those need to either (a) be ported to the kernel's rfkill subsystem in which case they will be supported by HAL 0.5.12 automatically, or (b) get HAL support otherwise. Obviously (a) is preferred. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disable/Ignore access point
On Thu, 2009-04-23 at 11:29 -0400, Derek Atkins wrote: Dan Williams d...@redhat.com writes: On Mon, 2009-04-20 at 16:15 -0500, Bryan Duff wrote: My situation is that I have a number of accessible access points for me. I'll connect to the AP I want, but at some interval NetworkManager re-scans available AP's and picks an unencrypted AP (that I don't want). So I have to then, via nm-applet, reselect the AP I want to use. So if NM is connecting to it, you must have selected it sometime before. If you won't want to connect to it, you can remove its configuration in the connection editor, and NM won't connect to it automatically any more. That didn't work for me.. Even after removing all remnants NM still wanted to connect to a local linksys network, no matter what I told it. When you say NM, do you mean NetworkManager itself in the logs said it was trying to connect, or do you mean you saw the BSSID of the linksys ap in the results for iwconfig at some point? Was that linksys connection a system connection? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Checkbox instead of radiobutton
On Thu, 2009-04-23 at 20:09 +0530, ritz wrote: Hi On Thu, 2009-04-23 at 10:36 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 20:03 +0530, ritz wrote: Hi On Thu, 2009-04-23 at 10:09 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 17:19 +0530, ritz wrote: Hi Considering that nm support connection to multiple n/w simultaneous with the current incarnation, would it not be better to use a checkbox, instead of radiobutton ? It might for some devices. But in the case of multiple connections (you can have more than one connection for any of the devices), you'd just go back to needing a radio button. I'm not sure switching from a checkbox to a radio button on-the-fly would make a lot of sense. Many devices do support alias. Then again, people who know about this would not bother with nm. In any case, the applet wasn't really designed for multiple active connections, so yeah, this sort of thing is a problem. There are various designs for a new applet that get rid of the menu and thus would fix your issue. Is this in git nm repository ? I have described my idea below Pop-up [x] Wired Connection ( intel pro 1000g ) Hmm, what is the checkbox supposed to mean here? This device is enabled, and we are connected to one the below selected network configuration. At the moment, all available network devices are enabled unless Wireless Enabled or Networking Enabled are unchecked in the right-click menu. There isn't any per-device enable/disable. Even if there were, it doesn't really fit in well with the applet-as-menu, because clicking the checkbox would close the menu, and you'd need ot open the menu again to do anything else. This pretty much gets fixed with a redesign of the applet to not use a menu. Dan o Auto o Home o Office [x] Wired Connection ( user-specified-label ) o Auto o VPN o intranet [ ] Wireless Network ( internal card ) o ... o ... [ ] Wireless Network ( usb dongle ) o ... o ... Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] networkmanager-0.7.0-gentoo-dhclient.patch
On Wed, 2009-04-22 at 12:03 +0100, Robert Piasek wrote: Hi Dan, Could you please include this patch? It specifies standard dhclient.conf location on Gentoo. ref: http://bugs.gentoo.org/show_bug.cgi?id=266982 Committed btw, 33547b8d8b64a10187b9c452eef7325d909889a1 on 0.7.x and also on master. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN, PPTP: send all traffic through the tunnel.
On Fri, 2009-04-24 at 11:00 +0200, Uwe Brauer wrote: Hello In order to use all the services my university provides I have to connect via VPN (PPTP) and send all the traffic trough the tunnel. In 0.7.1, it will be the default unless you check Use this connection only for resources on its network in the Routes... dialog of the IPv4 tab. In 0.7.0, it will be the default if there are no custom routes entered in the Routes... dialog of the IPv4 tab. What version are you using? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
network manager Question
I got a Sierra wireless aircard 881 pc card.I got ubuntu 9.04 and it pick up my pc card but when it try to connect there no light on the pcard when i try t connect to it.I think it the network manger i had no prob in the ubuntu 8.10 i had to update it but there no update for this one. i hope someone can help me.:) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Power on bar
On Thu, 2009-04-23 at 22:33 +0300, Maxim Levitsky wrote: On Wed, 2009-04-22 at 19:48 -0400, Dan Williams wrote: On Sat, 2009-04-18 at 23:15 +0200, Josu Lazkano wrote: Hello everybody, I am new in this mail list. I want to know if is posible to add the power level (on numbers) on the bar for each wifi. You mean an actual % number in addition to the bars? It's possible of course, but I also tend to think it's pretty misleading. Signal strength is pretty ambiguous and you can't really read anything from the difference between 50% to 55%. Given that, I also tend to think that people wanting more specific signal strength probably want to use a different tool that gives them direct dBm or RSSI in addition to NM. We could display that sort of thing in the Information dialog though. Dan It would be very useful. Here at university, sometimes AP are weak, but following rule always works: -79dBm - -82dBm - works fine -83dBm - -85dBm - works at low speeds -86dBm - -89dBm - hardly works at all -90dBm - ... - doesn't work NM shows all these as two bars (sometimes one) Sounds like your driver is not doing the right thing, or that NM has a bug in how it interprets signal strength. What hardware, kernel version, and driver are you using? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Issue with static ip in NM
Ok, I found my problem... NetworkManager is super picky on the ownership and
permissions of the configuration files. They have to be owned by root:root and
have 0700 permissions.
Jonathan Hooker
Desktop Support - Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Friday, April 24, 2009 10:12 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: RE: Issue with static ip in NM
On Fri, 2009-04-24 at 09:05 -0500, Hooker, Jonathan wrote:
Ok, one last question... NetworkManager is supposed to pick up any changes in
the /etc/NetworkManager/system-connections folder assuming the config file is
set to plugins=keyfile, correct? If this is the case, why would
NetworkManager not be picking up on these changes unless I manually set the
file up through the NetworkManager config utility and then overwrite it? So I
guess the big question is does NetworkManager pick up on new files put in the
system-connections folder as long as they follow the proper syntax?
Yeah, if they follow the proper syntax they should be picked up
automatically. The keyfile plugin needs some logging.
Dan
Jonathan Hooker
Desktop Support - Engineering
Garmin International
Office: 913-440-2767
Need Help? Please Contact the Help Desk: 913-440-2000 or x2000
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 9:08 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: RE: Issue with static ip in NM
On Thu, 2009-04-23 at 07:00 -0500, Hooker, Jonathan wrote:
That makes sense. Unfortunately, I am somewhat new to this level of network
management, would it be possible to maybe get an example? Also remembering
that it is possible to have multiple usb devices connected at the same
time...
Right, which is why NM doesn't use device names, since those change with
plug/unplug too. Unfortunately, since most manufacturers seem to ignore
stuff like the USB serial number and populate that field with zeros or
some other non-device-unique value, all we've got left is the MAC
address to uniquely identify a particular device.
But of course, Garmin sets a valid, globally unique serial number on
every device, right? That makes your life a lot easier.
So you'll put some udev rules files in /etc/udev/rules.d (the
user-editable rules directory) that detect the presence of your device,
and run a small helper script which can then assign a MAC to the device
based off the serial number. Check out:
http://reactivated.net/writing_udev_rules.html
You'll be matching sysfs attributes, so something like:
ACTION!=add|change, GOTO=fake_mac_end
SUBSYSTEM!=usb, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idVendor}!=your vid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idProduct}!=your pid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{iSerial}==?*,
ENV{ID_FAKE_MAC_USB_SERIAL}=$attr{iSerial}
SUBSYSTEMS==usb, IMPORT{program}=fake-the-mac $env{ID_FAKE_MAC_USB_SERIAL}
$tempnode, GOTO=fake_mac_end
LABEL=fake_mac_end
then in the script /lib/udev/fake-the-mac, you'll assign a MAC of your
choice (maybe by hashing the serial #) to the device in argv[2] using
ethtool or whatever.
Dan
These are actually development devices. They do have the capability of
getting out on the network but it is just because of some routing rules
where we route its static ip through the eth0 of the machine to allow it on.
Jonathan Hooker
Desktop Support - Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 6:52 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: Re: Issue with static ip in NM
On Thu, 2009-04-23 at 06:09 -0500, Hooker, Jonathan wrote:
Hi,
I am currently having some issues with setting a static ip to a usb0
ethernet device due to the fact that it changes mac addresses every
time I plug it in. Is there any means of predicting this change so
that I can get the its config file
in /etc/NetworkManager/system-connections setup properly? Thanks for
your help!
One way to do this is to set up a udev rules file that will always
assign a custom MAC to the device. Since the MAC comes up random, the
device clearly isn't used to connect to a real ethernet network, and
it's probably a PocketPC/Windows Mobile device?
Dan
Jonathan Hooker
Desktop Support – Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
__
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient. If you are not the intended
recipient, please be aware that any
Re: Power on bar
On Fri, 2009-04-24 at 11:14 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 22:33 +0300, Maxim Levitsky wrote: On Wed, 2009-04-22 at 19:48 -0400, Dan Williams wrote: On Sat, 2009-04-18 at 23:15 +0200, Josu Lazkano wrote: Hello everybody, I am new in this mail list. I want to know if is posible to add the power level (on numbers) on the bar for each wifi. You mean an actual % number in addition to the bars? It's possible of course, but I also tend to think it's pretty misleading. Signal strength is pretty ambiguous and you can't really read anything from the difference between 50% to 55%. Given that, I also tend to think that people wanting more specific signal strength probably want to use a different tool that gives them direct dBm or RSSI in addition to NM. We could display that sort of thing in the Information dialog though. Dan It would be very useful. Here at university, sometimes AP are weak, but following rule always works: -79dBm - -82dBm - works fine -83dBm - -85dBm - works at low speeds -86dBm - -89dBm - hardly works at all -90dBm - ... - doesn't work NM shows all these as two bars (sometimes one) Sounds like your driver is not doing the right thing, or that NM has a bug in how it interprets signal strength. What hardware, kernel version, and driver are you using? iwlwifi from iwlwifi-git + NM from ubuntu 8.10 IWL3945 BG, kernel 2.6.30-rc2 (from iwlwifi.git) I don't think this is a bug, just NM shows all range. In my opinion I don't care if signal strengh is -50 dbm, -60dBm or -70dBm, because all these works in same way, thus I want to see the dBm value somewhere in accessible place (a popup maybe?) (best solution I think is to add an option to replace the bars with dBm value, I would be very happy to see this) Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Sun, 2009-04-19 at 20:17 +0100, David Woodhouse wrote: On Tue, 2009-04-07 at 11:23 -0400, Paul Wouters wrote: Openswan has a GSoC project submission for this. One of the issues is the architecture of NM, which focusses on user-based, and the the architecture of ipsec, which is host-based. This creates some issues, one of which is where and how to store and pass user/host credentials. The original use-case for VPNs was mobile laptop users, and at the time nobody was using IPSec VPNs. We arguably haven't kept up with that, because there's been larger fish to fry (better wifi, multi-device, 3G, etc, better config, etc). The current VPN handling in NM does need a rework, and I started on that last fall but it was too close to release to land. Specific issues that need to be fixed include: - interactive authentication instead of one-shot credentials - multiple VPN connections The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. There's a few things we'll need from the specific VPN stack in *any* case: * Configuration readable on stdin Since config files would need to be written out before starting the connection and removed cleanly after the connection goes away, whatever daemon manages the connection needs to accept configuration on stdin. Command-line based configuration doesn't work because the command line is visible in /proc/pid. * Ability to take secrets from external processes For some of the same reasons config files don't work well; secrets can come from a bunch of different places, so a static config file with the secrets doesn't make a lot of sense. Second, for the same reason that config files don't work well, writing the secret out to a file doesn't work well. OpenVPN uses a management socket here, which works out OK, and vpnc uses config on stdin so that works out OK too (except for periodic reauthentication). * Ability to notify external process of connection failures This is crucial. Users need to know what's going on and when there's a failure. Daemons work well here because when they die, we know the connection is down. * Descriptive error codes Also crucial; vpnc for example doesn't provide much information during the connection process, and only 2 exit error codes. Quite unhelpful if the user can't figure out whether their group password or user password was wrong, and then of course NM can't do anything intelligent about the failure either. NetworkManager has all those problems anyway -- they aren't specific to IPSec. Other VPNs, wireless and even wired connections are system-wide things; once they're set up, any user can use them. None of it is _really_ a per-user thing. It's a complete pain in the arse that my wireless network doesn't come up after I reboot my laptop, for example, until I physically walk up to it and log in. This _used_ to work in early versions of NetworkManager, but then broke because of this misguided per-user thing. Oh come off it David. It *is* a per-user thing if you're not talking about a multi-user system. If I log into my work VPN, but then a house-guest asks to use the system, I'm going to fast-user-switch, and I certainly don't want that person to have access to my VPN. Connections can be *both* per-user in a single-user system, or system-wide on any system. If you're using WPA, you should be using the 0.7.1 snapshots in Fedora testing, and your connections can now be system connections and you can set them up to connect before login. Try it. I'll even fix your bugs too. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Peter Robinson wrote: Openswan has a GSoC project submission for this. One of the issues is btw. that project got the go ahead and we have a student for this now. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. Well there's the ipsec-tools utilities but I suspect any NM support will need something like what was done with wpa_supplicant where there was patches needed. ipsec-tools is not required for ipsec operation using openswan. If people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Oh come off it David. It *is* a per-user thing if you're not talking about a multi-user system. If I log into my work VPN, but then a house-guest asks to use the system, I'm going to fast-user-switch, and I certainly don't want that person to have access to my VPN. Connections can be *both* per-user in a single-user system, or system-wide on any system. That comes back to the Site-to-Site vs Road-Warrior configuration. Its the same argument that no doubt went on for the system wide ethernet vs the login and then connect single user argument and support I take it NM already has some kind of user-switching support that takes this difference into account, and can take down the tunnel. Though if I remember correcty, OSX gave you a preference option for this choice. (you might be transferring data from your vpn and give control to another user while expecting the vpn stas up) Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: The current VPN handling in NM does need a rework, and I started on that last fall but it was too close to release to land. Specific issues that need to be fixed include: - interactive authentication instead of one-shot credentials I would not put too much effort in this. Most interactive authentication (I assume you mean XAUTH password or L2TP password) can be remembered on most OS'es. Openswan for a long time refused to support XAUTH passwords being configured, but we ended up helping people write stupid shell scripts to work around it. Also, not all IPsec devices worked properly with XAUTH rekying, when the credentials are needed again. So in the end we just made it an option and recommend people not to use it. - multiple VPN connections There is no problem from an ipsec/openwan point of view, as long as you pass along unique names for these connections to openswan. Note that there are some unsolvable options, such as ending up having connections to two remote networks with the same IP range, or one with the same IP range as your NAT'ed range. I'd recommend ignoring these problems. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. There's a few things we'll need from the specific VPN stack in *any* case: * Configuration readable on stdin Since config files would need to be written out before starting the connection and removed cleanly after the connection goes away, whatever daemon manages the connection needs to accept configuration on stdin. Command-line based configuration doesn't work because the command line is visible in /proc/pid. How about a socket? NM should be able to talk to the pluto IKE daemon of openswan using a socket and sending it commands via the whack API. * Ability to take secrets from external processes This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. * Ability to notify external process of connection failures This is crucial. Users need to know what's going on and when there's a failure. Daemons work well here because when they die, we know the connection is down. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? * Descriptive error codes Also crucial; vpnc for example doesn't provide much information during the connection process, and only 2 exit error codes. Quite unhelpful if the user can't figure out whether their group password or user password was wrong, and then of course NM can't do anything intelligent about the failure either. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for failure, and we just need to add a way of signaling this back to other applications. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 11:32 -0400, Dan Williams wrote: On Sun, 2009-04-19 at 20:17 +0100, David Woodhouse wrote: On Tue, 2009-04-07 at 11:23 -0400, Paul Wouters wrote: Openswan has a GSoC project submission for this. One of the issues is the architecture of NM, which focusses on user-based, and the the architecture of ipsec, which is host-based. This creates some issues, one of which is where and how to store and pass user/host credentials. The original use-case for VPNs was mobile laptop users, and at the time nobody was using IPSec VPNs. We arguably haven't kept up with that, because there's been larger fish to fry (better wifi, multi-device, 3G, etc, better config, etc). The current VPN handling in NM does need a rework, and I started on that last fall but it was too close to release to land. Specific issues that need to be fixed include: - interactive authentication instead of one-shot credentials This is actually working in some cases, like openconnect. The auth-dialog there is a standalone GUI program in its own right which does a whole bunch of stuff including SSL certificates from file system or TPM, and letting the user fill in arbitrary forms. Then when it's rewarded for a successful login with an HTTP cookie from the server, it just passes that cookie back to the nm-openconnect-service which uses it to make the actual connection. Can IPSec-based VPNs do something similar? * Descriptive error codes Also crucial; vpnc for example doesn't provide much information during the connection process, and only 2 exit error codes. Quite unhelpful if the user can't figure out whether their group password or user password was wrong, and then of course NM can't do anything intelligent about the failure either. Yeah, that would be nice -- I'd give better feedback in OpenConnect if it was actually getting through to the user. NetworkManager has all those problems anyway -- they aren't specific to IPSec. Other VPNs, wireless and even wired connections are system-wide things; once they're set up, any user can use them. None of it is _really_ a per-user thing. It's a complete pain in the arse that my wireless network doesn't come up after I reboot my laptop, for example, until I physically walk up to it and log in. This _used_ to work in early versions of NetworkManager, but then broke because of this misguided per-user thing. Oh come off it David. It *is* a per-user thing if you're not talking about a multi-user system. If you're not talking about a multi-user system, then it is both a per-user thing _and_ a systemwide thing. The whole debate is meaningless in that case -- whichever way you handle it is 'right'. If I log into my work VPN, but then a house-guest asks to use the system, I'm going to fast-user-switch, and I certainly don't want that person to have access to my VPN. Connections can be *both* per-user in a single-user system, or system-wide on any system. I'm guessing that you're in the minority, if you actually bother to set up an account for them and switch to it. To be honest, I don't even know how to do that without resorting to the command line. Many people would just disconnect from the VPN and let their guest use a web browser or SSH client in the existing session. Not the right thing to do according to the tinfoil-hat wearers, arguably -- but common behaviour nonetheless. And I bet that even _fewer_ people actually remove the account after the guest is done using the computer, thus actually preventing said guest from logging into your laptop later from elsewhere, while you're on the VPN... If you're using WPA, you should be using the 0.7.1 snapshots in Fedora testing, and your connections can now be system connections and you can set them up to connect before login. Try it. I'll even fix your bugs too. I'm using WEP, but I don't think that matters. I checked the 'Available to all users' checkbox in the configuration. That name is a strange choice, because it implies that if I _uncheck_ it, you'll install some kind of per-user iptables filtering to, well, stop the network connection being available to all users. But that aside, I think it's working. Thanks for fixing it. -- dwmw2 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 11:50 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Peter Robinson wrote: Openswan has a GSoC project submission for this. One of the issues is btw. that project got the go ahead and we have a student for this now. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. Well there's the ipsec-tools utilities but I suspect any NM support will need something like what was done with wpa_supplicant where there was patches needed. ipsec-tools is not required for ipsec operation using openswan. If people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? Oh come off it David. It *is* a per-user thing if you're not talking about a multi-user system. If I log into my work VPN, but then a house-guest asks to use the system, I'm going to fast-user-switch, and I certainly don't want that person to have access to my VPN. Connections can be *both* per-user in a single-user system, or system-wide on any system. That comes back to the Site-to-Site vs Road-Warrior configuration. Its the same argument that no doubt went on for the system wide ethernet vs the login and then connect single user argument and support I take it NM already has some kind of user-switching support that takes this difference into account, and can take down the tunnel. Though if I remember correcty, OSX gave you a preference option for this choice. (you might be transferring data from your vpn and give control to another user while expecting the vpn stas up) Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 12:03 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: The current VPN handling in NM does need a rework, and I started on that last fall but it was too close to release to land. Specific issues that need to be fixed include: - interactive authentication instead of one-shot credentials I would not put too much effort in this. Most interactive authentication (I assume you mean XAUTH password or L2TP password) can be remembered on most OS'es. Openswan for a long time refused to support XAUTH passwords being configured, but we ended up helping people write stupid shell scripts to work around it. Also, not all IPsec devices worked properly with XAUTH rekying, when the credentials are needed again. So in the end we just made it an option and recommend people not to use it. Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. - multiple VPN connections There is no problem from an ipsec/openwan point of view, as long as you pass along unique names for these connections to openswan. Note that there are some unsolvable options, such as ending up having connections to two remote networks with the same IP range, or one with the same IP range as your NAT'ed range. I'd recommend ignoring these problems. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. There's a few things we'll need from the specific VPN stack in *any* case: * Configuration readable on stdin Since config files would need to be written out before starting the connection and removed cleanly after the connection goes away, whatever daemon manages the connection needs to accept configuration on stdin. Command-line based configuration doesn't work because the command line is visible in /proc/pid. How about a socket? NM should be able to talk to the pluto IKE daemon of openswan using a socket and sending it commands via the whack API. That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. * Ability to take secrets from external processes This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. * Ability to notify external process of connection failures This is crucial. Users need to know what's going on and when there's a failure. Daemons work well here because when they die, we know the connection is down. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? How about an unsolicited message on the whack socket? Isn't there already some mechanism to emit status messages or something? Or does it depend on periodically polling the connection status? * Descriptive error codes Also crucial; vpnc for example doesn't provide much information during the connection process, and only 2 exit error codes. Quite unhelpful if the user can't figure out whether their group password or user password was wrong, and then of course NM can't do anything intelligent about the failure either. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for
RE: Issue with static ip in NM
On Fri, 2009-04-24 at 10:21 -0500, Hooker, Jonathan wrote:
Ok, I found my problem... NetworkManager is super picky on the ownership and
permissions of the configuration files. They have to be owned by root:root
and have 0700 permissions.
Right, since secrets are stored in the files, they shouldn't be readable
by an unprivileged user.
Dan
Jonathan Hooker
Desktop Support - Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Friday, April 24, 2009 10:12 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: RE: Issue with static ip in NM
On Fri, 2009-04-24 at 09:05 -0500, Hooker, Jonathan wrote:
Ok, one last question... NetworkManager is supposed to pick up any changes
in the /etc/NetworkManager/system-connections folder assuming the config
file is set to plugins=keyfile, correct? If this is the case, why would
NetworkManager not be picking up on these changes unless I manually set the
file up through the NetworkManager config utility and then overwrite it? So
I guess the big question is does NetworkManager pick up on new files put in
the system-connections folder as long as they follow the proper syntax?
Yeah, if they follow the proper syntax they should be picked up
automatically. The keyfile plugin needs some logging.
Dan
Jonathan Hooker
Desktop Support - Engineering
Garmin International
Office: 913-440-2767
Need Help? Please Contact the Help Desk: 913-440-2000 or x2000
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 9:08 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: RE: Issue with static ip in NM
On Thu, 2009-04-23 at 07:00 -0500, Hooker, Jonathan wrote:
That makes sense. Unfortunately, I am somewhat new to this level of
network management, would it be possible to maybe get an example? Also
remembering that it is possible to have multiple usb devices connected at
the same time...
Right, which is why NM doesn't use device names, since those change with
plug/unplug too. Unfortunately, since most manufacturers seem to ignore
stuff like the USB serial number and populate that field with zeros or
some other non-device-unique value, all we've got left is the MAC
address to uniquely identify a particular device.
But of course, Garmin sets a valid, globally unique serial number on
every device, right? That makes your life a lot easier.
So you'll put some udev rules files in /etc/udev/rules.d (the
user-editable rules directory) that detect the presence of your device,
and run a small helper script which can then assign a MAC to the device
based off the serial number. Check out:
http://reactivated.net/writing_udev_rules.html
You'll be matching sysfs attributes, so something like:
ACTION!=add|change, GOTO=fake_mac_end
SUBSYSTEM!=usb, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idVendor}!=your vid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{idProduct}!=your pid, GOTO=fake_mac_end
SUBSYSTEMS==usb, ATTRS{iSerial}==?*,
ENV{ID_FAKE_MAC_USB_SERIAL}=$attr{iSerial}
SUBSYSTEMS==usb, IMPORT{program}=fake-the-mac
$env{ID_FAKE_MAC_USB_SERIAL} $tempnode, GOTO=fake_mac_end
LABEL=fake_mac_end
then in the script /lib/udev/fake-the-mac, you'll assign a MAC of your
choice (maybe by hashing the serial #) to the device in argv[2] using
ethtool or whatever.
Dan
These are actually development devices. They do have the capability of
getting out on the network but it is just because of some routing rules
where we route its static ip through the eth0 of the machine to allow it
on.
Jonathan Hooker
Desktop Support - Engineering (Linux)
Garmin International
jonathan.hoo...@garmin.com
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Thursday, April 23, 2009 6:52 AM
To: Hooker, Jonathan
Cc: networkmanager-list@gnome.org
Subject: Re: Issue with static ip in NM
On Thu, 2009-04-23 at 06:09 -0500, Hooker, Jonathan wrote:
Hi,
I am currently having some issues with setting a static ip to a usb0
ethernet device due to the fact that it changes mac addresses every
time I plug it in. Is there any means of predicting this change so
that I can get the its config file
in /etc/NetworkManager/system-connections setup properly? Thanks for
your help!
One way to do this is to set up a udev rules file that will always
assign a custom MAC to the device. Since the MAC comes up random, the
device clearly isn't used to connect to a real ethernet network, and
it's probably a PocketPC/Windows Mobile device?
Dan
Jonathan Hooker
Desktop Support – Engineering (Linux)
Garmin International
Re: How does network manager read rfkill ?
On Fri, 2009-04-24 at 18:16 +0300, Maxim Levitsky wrote: On Fri, 2009-04-24 at 11:06 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 22:35 +0300, Maxim Levitsky wrote: On Thu, 2009-04-23 at 07:15 -0400, Dan Williams wrote: On Thu, 2009-04-23 at 02:16 -0400, eye zak wrote: Hi, I am writing low-level rfkill support in the ath5k driver in compat-wireless-2.6, and I am wondering how network manager knows about my rfkill device ? Hal recognizes it no problem and broadcasts an event on state change, and tracks the current state. But netowork manager (jaunty-latest) does not notice it. NM finds all devices in HAL with the capability 'killswitch', and polls them every 6 seconds to find out if any of them return 0 for GetPower. If any do, it assumes rfkill. Are you sure NM is allowed to talk to HAL on your distribution? Some distros like Debian use different D-Bus permissions styles, and if those are wrong in the /etc/dbus-1/system.d/NetworkManager.conf, NM may not be able to talk to HAL and get the killsiwtch state. Dan Or, it currently ignores platform kill switches, like acer-wmi Do those rfkill switches expose themselves via HAL? If so, then NetworkManager is expected to work with them. If not, then those need to either (a) be ported to the kernel's rfkill subsystem in which case they will be supported by HAL 0.5.12 automatically, or (b) get HAL support otherwise. Obviously (a) is preferred. ma...@maxim-laptop:~$ hald --version HAL package version: 0.5.12 I tried acer-wmi, and NM doesn't see it. It does expose normal rfkill interface What distro? Can you attach the lshal bits for all killswitches contained in 'lshal' ? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
On Fri, 2009-04-24 at 08:12 -0700, Craig wrote: I got a Sierra wireless aircard 881 pc card.I got ubuntu 9.04 and it pick up my pc card but when it try to connect there no light on the pcard when i try t connect to it.I think it the network manger i had no prob in the ubuntu 8.10 i had to update it but there no update for this one. i hope someone can help me.:) After the card is plugged in, does it show in the NetworkManager menu? If not, can you provide the output of 'lsusb' for me? Does it put an icon on the desktop when you plug it in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disable/Ignore access point
Dan Williams d...@redhat.com writes: On Thu, 2009-04-23 at 11:29 -0400, Derek Atkins wrote: Dan Williams d...@redhat.com writes: On Mon, 2009-04-20 at 16:15 -0500, Bryan Duff wrote: My situation is that I have a number of accessible access points for me. I'll connect to the AP I want, but at some interval NetworkManager re-scans available AP's and picks an unencrypted AP (that I don't want). So I have to then, via nm-applet, reselect the AP I want to use. So if NM is connecting to it, you must have selected it sometime before. If you won't want to connect to it, you can remove its configuration in the connection editor, and NM won't connect to it automatically any more. That didn't work for me.. Even after removing all remnants NM still wanted to connect to a local linksys network, no matter what I told it. When you say NM, do you mean NetworkManager itself in the logs said it was trying to connect, or do you mean you saw the BSSID of the linksys ap in the results for iwconfig at some point? Was that linksys connection a system connection? Yes, I mean Network Manager itself connected to the linksys even though I erased it. I even stopped NM, killed nm-applet, killed gconf, deleted all the files, and restarted everything, and it *still* connected to the linksys network against my wishes. I shouldn't have any system connections.. At least I'm pretty sure I never set any up. How do I check? Dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? You tell me. What infrastructure is there for NM? I know there is dbus, but I don't think that channel can be secured at all. Would unauthenticated announcements be okay? Does NM have any other listening or polling methods? Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. That's good. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, David Woodhouse wrote: - interactive authentication instead of one-shot credentials This is actually working in some cases, like openconnect. The auth-dialog there is a standalone GUI program in its own right which does a whole bunch of stuff including SSL certificates from file system or TPM, and letting the user fill in arbitrary forms. Then when it's rewarded for a successful login with an HTTP cookie from the server, it just passes that cookie back to the nm-openconnect-service which uses it to make the actual connection. Can IPSec-based VPNs do something similar? Yes. The only question is who caches the credentials. Currently openswan can cache xauth passwords (from ipsec.secrets, but once we can take them from the socket, NM can give it to us). Upon closing the connection, these credentials could be purged. person to have access to my VPN. Connections can be *both* per-user in a single-user system, or system-wide on any system. I'm guessing that you're in the minority, if you actually bother to set up an account for them and switch to it. To be honest, I don't even know how to do that without resorting to the command line. With fedora, NM seems to be the default manager for all connections, so if it becomes the defacto tool to configure site-to-site tunnels, then this might not even be the minority case. And I bet that even _fewer_ people actually remove the account after the guest is done using the computer, thus actually preventing said guest from logging into your laptop later from elsewhere, while you're on the VPN... A real guest account should automatically purge and put back a skeleton account. I know debian/ubuntu has this feature. I am not sure if Fedora has it. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. Those connections tend to use 8 hour plus IKE/IPsec SA lifetimes, so they basically never rekey. But you are right. There are two ways of handling this. Either you just bring down the IKE connection (while the IPsec SA is still up so packets still flow) and this triggers an event to NM so it can ask for the OTP and then rekey the IKE connection, or you kill the connection and let the user connect from scratch. The latter is mostly found in GUI software. Openswan currently does not have a method for signaling, but if we're building that in via dbus or something anyway, this becomes an easy possibility, and with no packet loss to the end user. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. Agreed. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. There is. The IKE daemon always runs. I am not sure how familiar you are with IKE, so let me give an exec summary. The IKE daemon establish a command channel over which they agree IPsec paramters. These daemons always run. Once they agree something, they inform the kernel, which install the actual keying information along with lifetime information for the tunnel (in time units or in byte units) The kernel never talks to userland IKE, it only listens for it. IKE makes all the decisions. IKE is userland, which is the openswan pluto daemon. That entity will have to listen and talk to NM somehow. That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Not yet, but that modification will be made for you. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. Openswan 2.6.21 has limited support for NSS. The current development release 2.6.22dr1 has (full?) NSS support. So this should not be a problem anymore. This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. I'll need to check that too. Currently, from the unit test in openswan-2.x.y/testing/pluto/*l2tp* I only see us do: echo c server /var/run/l2tp-control I think this is taking the user/password information from /etc/ppp, so if you have a system in place for pppd already, I think this should just work as well. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? How about an unsolicited message on the whack socket? Isn't there already some mechanism to emit status messages or something? Or does it depend on periodically polling the connection status? Yes, you can do the whack equivalent of ipsec auto --status to get a lot of information from the ike daemon. This currently required root to be able to send the whack command. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for failure, and we just need to add a way of signaling this back to other applications. Ok, that should be fine, ideally via the socket used to control the connection. Obviously the client side can only return as much as it knows. That's right. But you might need to depend on whack.h to interpret some of the resulting codes. Then again, you would probably want to link against libwhack anyway, though I don't think we currently export that
Re: How does network manager read rfkill ?
On Fri, 2009-04-24 at 12:49 -0400, Dan Williams wrote:
On Fri, 2009-04-24 at 18:16 +0300, Maxim Levitsky wrote:
On Fri, 2009-04-24 at 11:06 -0400, Dan Williams wrote:
On Thu, 2009-04-23 at 22:35 +0300, Maxim Levitsky wrote:
On Thu, 2009-04-23 at 07:15 -0400, Dan Williams wrote:
On Thu, 2009-04-23 at 02:16 -0400, eye zak wrote:
Hi,
I am writing low-level rfkill support in the ath5k driver in
compat-wireless-2.6, and I am wondering how network manager knows
about my rfkill device ?
Hal recognizes it no problem and broadcasts an event on state
change,
and tracks the current state. But netowork manager (jaunty-latest)
does not notice it.
NM finds all devices in HAL with the capability 'killswitch', and
polls
them every 6 seconds to find out if any of them return 0 for GetPower.
If any do, it assumes rfkill. Are you sure NM is allowed to talk to
HAL
on your distribution? Some distros like Debian use different D-Bus
permissions styles, and if those are wrong in
the /etc/dbus-1/system.d/NetworkManager.conf, NM may not be able to
talk
to HAL and get the killsiwtch state.
Dan
Or, it currently ignores platform kill switches, like acer-wmi
Do those rfkill switches expose themselves via HAL? If so, then
NetworkManager is expected to work with them. If not, then those need
to either (a) be ported to the kernel's rfkill subsystem in which case
they will be supported by HAL 0.5.12 automatically, or (b) get HAL
support otherwise.
Obviously (a) is preferred.
ma...@maxim-laptop:~$ hald --version
HAL package version: 0.5.12
I tried acer-wmi, and NM doesn't see it.
It does expose normal rfkill interface
What distro? Can you attach the lshal bits for all killswitches
contained in 'lshal' ?
Dan
Now I use ubuntu 9.04, but it was always present.
udi =
'/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.parent = '/org/freedesktop/Hal/devices/platform_acer_wmi' (string)
info.product = 'acer-wireless wlan Killswitch' (string)
info.subsystem = 'rfkill' (string)
info.udi =
'/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'
(string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = 'acer-wireless' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'rfkill' (string)
linux.sysfs_path = '/sys/devices/platform/acer-wmi/rfkill/rfkill1' (string)
udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan'
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.parent = '/org/freedesktop/Hal/devices/pci_8086_4222' (string)
info.product = '3945BG wlan Killswitch' (string)
info.subsystem = 'rfkill' (string)
info.udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan'
(string)
info.vendor = 'Intel Corporation' (string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = '3945BG' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'rfkill' (string)
linux.sysfs_path =
'/sys/devices/pci:00/:00:1c.3/:06:00.0/rfkill/rfkill0' (string)
Last time, a week ago or so, I installed ubuntu 9.04
I disabled rfkill support in iwl3945, loaded acer-wmi, and yet NM didn't see
the killswitch, even after a reboot
Best regards,
Maxim Levitsky
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
pppd_timed_out(): Looks like pppd didn't initialize our dbus module
Hi I'm having problem with my umts connection with NM after obtaining ip and other parameters NM emit this warning pppd_timed_out(): Looks like pppd didn't initialize our dbus module and close connection distribution is an ubuntu jaunty dpkg -l | grep network-manager ii network-manager0.7.1~rc4.1.cf199a964-0ubuntu2 network management framework daemon ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 network management framework (GNOME frontend ii network-manager-kde1:0.7svn864988-0ubuntu8 KDE systray applet for controlling NetworkMa ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubuntu2network management framework (OpenVPN plugin ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 network management framework (PPTP plugin) ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 network management framework (VPNC plugin) dpkg -l ppp ii ppp 2.4.5~git20081126t100229-0ubuntu2 Point-to-Point Protocol (PPP) - daemon modem is an Onda et505up below a full log of a connection tell me if you need other info thanks Apr 24 23:57:29 champagne NetworkManager: info Activation (ttyUSB1) starting connection 'TIM' Apr 24 23:57:29 champagne NetworkManager: info (ttyUSB1): device state change: 3 - 4 Apr 24 23:57:29 champagne NetworkManager: info Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) scheduled... Apr 24 23:57:29 champagne NetworkManager: info Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) started... Apr 24 23:57:29 champagne NetworkManager: debug [1240610249.890546] nm_serial_device_open(): (ttyUSB1) opening device... Apr 24 23:57:29 champagne NetworkManager: info Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) complete. Apr 24 23:57:30 champagne NetworkManager: info (ttyUSB1): powering up... Apr 24 23:57:30 champagne NetworkManager: info Registered on Home network Apr 24 23:57:30 champagne NetworkManager: info Associated with network: +COPS: 0,0,Telecom Italia Mobile,2 Apr 24 23:57:30 champagne NetworkManager: info Connected, Woo! Apr 24 23:57:30 champagne NetworkManager: info Activation (ttyUSB1) Stage 2 of 5 (Device Configure) scheduled... Apr 24 23:57:30 champagne NetworkManager: info Activation (ttyUSB1) Stage 2 of 5 (Device Configure) starting... Apr 24 23:57:30 champagne NetworkManager: info (ttyUSB1): device state change: 4 - 5 Apr 24 23:57:30 champagne NetworkManager: info Starting pppd connection Apr 24 23:57:30 champagne NetworkManager: debug [1240610250.404936] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute ttyUSB1 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam/org/freedesktop/NetworkManager/PPP/7 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so Apr 24 23:57:30 champagne NetworkManager: debug [1240610250.406659] nm_ppp_manager_start(): ppp started with pid 28220 Apr 24 23:57:30 champagne NetworkManager: info Activation (ttyUSB1) Stage 2 of 5 (Device Configure) complete. Apr 24 23:57:30 champagne pppd[28220]: Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded. Apr 24 23:57:30 champagne pppd[28220]: pppd 2.4.5 started by root, uid 0 Apr 24 23:57:30 champagne pppd[28220]: Using interface ppp0 Apr 24 23:57:30 champagne pppd[28220]: Connect: ppp0 -- /dev/ttyUSB1 Apr 24 23:57:30 champagne pppd[28220]: Unable to obtain CHAP password for champagne on UMTS_CHAP_SRVR from plugin Apr 24 23:57:30 champagne pppd[28220]: No CHAP secret found for authenticating us to UMTS_CHAP_SRVR Apr 24 23:57:30 champagne pppd[28220]: CHAP authentication succeeded Apr 24 23:57:30 champagne pppd[28220]: CHAP authentication succeeded Apr 24 23:57:33 champagne pppd[28220]: Could not determine remote IP address: defaulting to 10.64.64.64 Apr 24 23:57:33 champagne pppd[28220]: Cannot determine ethernet address for proxy ARP Apr 24 23:57:33 champagne pppd[28220]: local IP address 217.201.129.203 Apr 24 23:57:33 champagne pppd[28220]: remote IP address 10.64.64.64 Apr 24 23:57:33 champagne pppd[28220]: primary DNS address 213.230.129.94 Apr 24 23:57:33 champagne pppd[28220]: secondary DNS address 213.230.155.94 Apr 24 23:57:37 champagne postfix/master[4547]: reload configuration /etc/postfix Apr 24 23:57:46 champagne NetworkManager: WARN pppd_timed_out(): Looks like pppd didn't initialize our dbus module Apr 24 23:57:46 champagne NetworkManager: info (ttyUSB1): device state change: 5 - 9 Apr 24 23:57:46 champagne pppd[28220]: Terminating on signal 15 Apr 24 23:57:46 champagne pppd[28220]: Connect time 0.3 minutes. Apr 24 23:57:46 champagne pppd[28220]: Sent 0 bytes, received 204 bytes. Apr 24 23:57:46 champagne
Re: periodic_update(): Roamed ...
Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
After it plug it will pick up the pc card but will not connect to the internet. --- On Fri, 4/24/09, Dan Williams d...@redhat.com wrote: From: Dan Williams d...@redhat.com Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: networkmanager-list@gnome.org Date: Friday, April 24, 2009, 11:50 AM On Fri, 2009-04-24 at 08:12 -0700, Craig wrote: I got a Sierra wireless aircard 881 pc card.I got ubuntu 9.04 and it pick up my pc card but when it try to connect there no light on the pcard when i try t connect to it.I think it the network manger i had no prob in the ubuntu 8.10 i had to update it but there no update for this one. i hope someone can help me.:) After the card is plugged in, does it show in the NetworkManager menu? If not, can you provide the output of 'lsusb' for me? Does it put an icon on the desktop when you plug it in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCHES] misc (build-system) clean-ups / improvements
Michael Biebl wrote: Hi, attached is a series of patches for NetworkManager, which tries to clean up and update the build system a little, replace deprecated macros, etc. I now put my git branches online at for easier review and merging at http://git.michaelbiebl.de/ clonable urls: git://git.michaelbiebl.de/git/NetworkManager.git git://git.michaelbiebl.de/git/network-manager-applet.git git://git.michaelbiebl.de/git/network-manager-openconnect.git git://git.michaelbiebl.de/git/network-manager-openvpn.git git://git.michaelbiebl.de/git/network-manager-vpnc.git git://git.michaelbiebl.de/git/network-manager-pptp.git Cheers, Michael -- 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
