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
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 wrote: From: Dan Williams Subject: Re: network manager Question To: "Craig" 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: detecting resolv.conf changes
networkmanager-list-requ...@gnome.org wrote: Date: Thu, 23 Apr 2009 09:42:35 -0400 From: "Eric S. Johansson" Howard Chu wrote: Date: Wed, 22 Apr 2009 17:55:29 -0400 From: "Eric S. Johansson" how do I detect that resolv.conf changes? I'm trying to fix a multiple name server problem by using dnsmasq as an intermediary and I need to keep resolv.conf pointing at localhost. See this post: http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00042.html did these patches get incorporated into the mainline? If so, what version? No, there was general disagreement about the policies involved in using dnsmasq this way and it was felt that the change was too drastic for the 0.7.0 release. I suppose it's time to raise the question again though. given my previous successes with installing network manager from scratch (usually ending in a reinstall), I am reluctant to touch anything that requires patching. I'm going to experiment with and inotify based solution. That may be a little less destructive to my mental and laptop well-being. Understood. At any rate, it works for me; I run by own build from git with this patch (plus the no-scanning-while-connected patch). (It's far better than what I used to have to do, rewriting BIND's forwarders.conf file on every interface change and restarting it. And using a laptop without a local caching nameserver is just a bad idea, particularly when you're using a GSM modem and every byte costs 1.5cents.) -- -- 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: 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
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: Activation (ttyUSB1) starting connection 'TIM' Apr 24 23:57:29 champagne NetworkManager: (ttyUSB1): device state change: 3 -> 4 Apr 24 23:57:29 champagne NetworkManager: Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) scheduled... Apr 24 23:57:29 champagne NetworkManager: Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) started... Apr 24 23:57:29 champagne NetworkManager: [1240610249.890546] nm_serial_device_open(): (ttyUSB1) opening device... Apr 24 23:57:29 champagne NetworkManager: Activation (ttyUSB1) Stage 1 of 5 (Device Prepare) complete. Apr 24 23:57:30 champagne NetworkManager: (ttyUSB1): powering up... Apr 24 23:57:30 champagne NetworkManager: Registered on Home network Apr 24 23:57:30 champagne NetworkManager: Associated with network: +COPS: 0,0,"Telecom Italia Mobile",2 Apr 24 23:57:30 champagne NetworkManager: Connected, Woo! Apr 24 23:57:30 champagne NetworkManager: Activation (ttyUSB1) Stage 2 of 5 (Device Configure) scheduled... Apr 24 23:57:30 champagne NetworkManager: Activation (ttyUSB1) Stage 2 of 5 (Device Configure) starting... Apr 24 23:57:30 champagne NetworkManager: (ttyUSB1): device state change: 4 -> 5 Apr 24 23:57:30 champagne NetworkManager: Starting pppd connection Apr 24 23:57:30 champagne NetworkManager: [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: [1240610250.406659] nm_ppp_manager_start(): ppp started with pid 28220 Apr 24 23:57:30 champagne NetworkManager: 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: pppd_timed_out(): Looks like pppd didn't initialize our dbus module Apr 24 23:57:46 champagne NetworkManager: (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 NetworkManager: [1240610266.003519] nm_serial_device_close(): Closing de
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
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 exp
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: 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: Disable/Ignore access point
Dan Williams writes: > On Thu, 2009-04-23 at 11:29 -0400, Derek Atkins wrote: >> Dan Williams 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: 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: 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: 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}!="", GOTO="fake_mac_end"
> > SUBSYSTEMS=="usb", ATTRS{idProduct}!="", 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 co
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 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
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
>> > 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). Well there's two main types of vpn connection. There's the site to site type and the road-warrior type. The first type is generally run on a server or router and connects multiple sites, then the later is very much like the wifi use case of NetworkManager. Its probably quite like network support in that NM initially supported the single user case and then later added they system case as well. > 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: Other than the proprietary or non standard clients like openvpn and the cisco stuff I suspect most support would be achievable with two clients. One that supports IPSEC vpns and one that supports SSL vpns. After that some templates which work with each of the different vendors interpretation of the standards as part of the setup wizard would be probably all thats required (not that its a small amount of work) to make them cover most of the common instances. I mentioned previously that through my work I have access to alot of the different vendors products and would be quite happy to assist in testing to get the settings for templates. > 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. > 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. 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 Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/
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: 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: 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}!="", GOTO="fake_mac_end"
> SUBSYSTEMS=="usb", ATTRS{idProduct}!="", 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
> > >
> > >
> > >
> > >
> > > __
Re: How does network manager read rfkill ?
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 Regards, Maxim Levitsky > Dan > ___ 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
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: 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
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}!="", GOTO="fake_mac_end"
> SUBSYSTEMS=="usb", ATTRS{idProduct}!="", 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
> > > __
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: 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: Disable/Ignore access point
On Thu, 2009-04-23 at 11:29 -0400, Derek Atkins wrote: > Dan Williams 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: 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: 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}!="", GOTO="fake_mac_end"
SUBSYSTEMS=="usb", ATTRS{idProduct}!="", 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
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
