Re: Another dropped connection with iwl3945 and NM-0.6.5 on FC7
On Tue, 2007-12-04 at 19:02 -0500, Derek Atkins wrote: Here's the dmesg output: eth1: RX deauthentication from 00:19:a9:47:56:91 (reason=1) eth1: deauthenticated eth1: authenticate with AP 00:19:a9:47:56:91 eth1: RX authentication from 00:19:a9:47:56:91 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:19:a9:47:56:91 eth1: RX ReassocResp from 00:19:a9:47:56:91 (capab=0x1 status=0 aid=80) eth1: associated eth1: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 eth1: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 eth1: No ProbeResp from current AP 00:19:a9:47:56:91 - assume out of range eth1: No STA entry for own AP 00:19:a9:47:56:91 eth1: No STA entry for own AP 00:19:a9:47:56:91 bridge-eth1: disabling the bridge bridge-eth1: down bridge-eth1: enabling the bridge bridge-eth1: up Looks like the driver decided that the AP had gone away. It probably missed too many beacons or probe responses due to the RF heavy environment or something? Could need a driver tweak. Dan At this point the network was down. Then I told nm-applet to re-connect: eth1: Initial auth_alg=0 eth1: authenticate with AP 00:19:a9:45:36:d1 eth1: authenticate with AP 00:19:a9:45:36:d1 eth1: RX authentication from 00:19:a9:45:36:d1 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:19:a9:45:36:d1 eth1: RX AssocResp from 00:19:a9:45:36:d1 (capab=0x1 status=0 aid=75) eth1: associated eth1: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 eth1: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 eth1: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 eth1: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 eth1: RX deauthentication from 00:19:a9:45:36:d1 (reason=2) eth1: deauthenticated eth1: authenticate with AP 00:19:a9:45:36:d1 eth1: RX authentication from 00:19:a9:45:36:d1 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:19:a9:45:36:d1 eth1: RX ReassocResp from 00:19:a9:45:36:d1 (capab=0x1 status=0 aid=77) eth1: associated And here I was connected again. -derek ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Fwd: NetworkManager no-go
I have been informed that the behavior below evidently is a bug in NetworkManager. I am using NetworkManager Applet 0.6.4 under RHEL 5, and NetworkManager and NetworkManagerDispatcher 0.6.5 . NetworkManager did not offer me any choices in network, nor did it change from the pre-existing channel 11 under the circumstances below. Is this a bug? If so, what is the fix? I have now tried NetworkManager on the University 802.11g from my office. No go. Here is the output from scan (I wrote a small script to run the scan and remind me that I needed to be root for the scan to work -- output captured via script in a typescript file): Script started on Tue 04 Dec 2007 11:34:40 AM PST ^[]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]$ su Password: ^[]0;[EMAIL PROTECTED]:/home/[EMAIL PROTECTED] ykarant]# ./iwlist-scan You need to be root to get a current scan eth1 Scan completed : Cell 01 - Address: 00:12:00:51:BC:60 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:1 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=82/100 Signal level=-48 dBm Extra: Last beacon: 27ms ago Cell 02 - Address: 00:15:F9:A6:76:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=31/100 Signal level=-81 dBm Extra: Last beacon: 724ms ago Cell 03 - Address: 00:1B:54:25:15:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=44/100 Signal level=-74 dBm Extra: Last beacon: 1058ms ago ^[]0;[EMAIL PROTECTED]:/home/[EMAIL PROTECTED] ykarant]# exit exit ^[]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]$ Gexit exit At home, using /usr/sbin/system-config-network-gui (that does the same thing as manually editing the files, reloading, etc.), the WLAN is set to channel 11. NetworkManager only showed one CSUSB WLAN, and refused to connect. system-config-network-gui showed that the WNIC was still on channel 11. I manually changed this via system-config-network-gui to channel 1 (please see the scan above), and everything worked, including NetworkManager. However, NetworkManager would not automatically go to channel 1 nor would it allow me to choose channels. Is this fixable via a NetworkManager post-build configuration file? Is this fixable via a NetworkManager configuration file that is used during the build process? - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Dec 4, 2007 4:17 PM, Jon Escombe [EMAIL PROTECTED] wrote: Good stuff, got connected first time ;) Only issues were that it didn't set up resolv.conf, and also added three entries to the applet menu (as the card presents three ports). Both of these issues should be fixed in the SVN now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Wed, 2007-12-05 at 18:38 +, Jon Escombe wrote: Tambet Ingo wrote: On Dec 4, 2007 4:17 PM, Jon Escombe [EMAIL PROTECTED] wrote: Good stuff, got connected first time ;) Only issues were that it didn't set up resolv.conf, and also added three entries to the applet menu (as the card presents three ports). Both of these issues should be fixed in the SVN now. Tambet Confirmed, thanks! Latest bits are in http://koji.fedoraproject.org/koji/taskinfo?taskID=276538 too, which should get pushed out as an update. I haven't disabled the PPP functionality for F8 updates because you still need the .fdi file to enable the 3G cards for now. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Pre-populate NM-vpnc profiles?
On Wed, 2007-12-05 at 14:20 -0500, Brian Long wrote: Hello, I would like to use gconftool-2 or something to pre-populate various system-wide VPN profiles for NetworkManager-vpnc. Is there any documentation on how to do this? I have various Cisco pcf files from which I can extract the Gateway, Group, Group Password, etc. Is there an easy way to add a bunch of NM-vpnc profiles from the command-line? This would allow me to wrap it inside an RPM, etc. gconftool-2 is your friend. Or, the easier way is to use gconftool-2 to dump a setting to XML. Then in your RPM, use gconftool-2 to apply that schema. You may need to do some magic to find the last connection number, pick a free one, and then modify the XML dump to use that free number, then apply with gconftool-2. But the whole connection framework with the GNOME applet has been developed with this usecase in mind. TO allow sysadmins to deploy connections via packages or other automatic means. Later on you can drop some files somewhere and they'll get picked up by the system settings service, with options to lock NM down and disallow the user from connecting to random stuff if you (as the sysadmin) like. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager-list Digest, Vol 39, Issue 18
will you pls quit sending to me, -- Original Message: - From:[EMAIL PROTECTED] To: networkmanager-list@gnome.org Subject: NetworkManager-list Digest, Vol 39, Issue 18 Date:Wed, 5 Dec 2007 19:08:48 + Send NetworkManager-list mailing list submissions to networkmanager-list@gnome.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.gnome.org/mailman/listinfo/networkmanager-list or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of NetworkManager-list digest... Today's Topics: 1. Re: Fwd: NetworkManager no-go (Dan Williams) 2. Re: ppp using NM (Tambet Ingo) 3. Re: scan list limitation -- doesn't like 127 APs? (Derek Atkins) 4. Re: Another dropped connection with iwl3945 and NM-0.6.5 on FC7 (Derek Atkins) 5. Re: ppp using NM (Jon Escombe) 6. Re: VPN API (Jon Escombe) 7. Re: ppp using NM (Dan Williams) 8. Re: VPN API (Casey Harkins) -- Message: 1 Date: Wed, 05 Dec 2007 11:56:23 -0500 From: Dan Williams [EMAIL PROTECTED] Subject: Re: Fwd: NetworkManager no-go To: Yasha Karant [EMAIL PROTECTED] Cc: networkmanager-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain On Tue, 2007-12-04 at 19:07 -0800, Yasha Karant wrote: I have been informed that the behavior below evidently is a bug in NetworkManager. I am using NetworkManager Applet 0.6.4 under RHEL 5, and NetworkManager and NetworkManagerDispatcher 0.6.5 . NetworkManager did not offer me any choices in network, nor did it change from the pre-existing channel 11 under the circumstances below. Is this a bug? If so, what is the fix? Best thing to do is to file a bug in Red Hat bugzilla and then we can diagnose this issue further. If you could put some more details into the bug report, like: 1) What kernel version, what wireless card, and what driver the card is using 2) Attach a /var/log/messages that shows a NetworkManager connection attempt to the bug report #2 is important; without that it's hard to figure out where things are going wrong. Thanks, Dan I have now tried NetworkManager on the University 802.11g from my office. No go. Here is the output from scan (I wrote a small script to run the scan and remind me that I needed to be root for the scan to work -- output captured via script in a typescript file): Script started on Tue 04 Dec 2007 11:34:40 AM PST ^[]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]$ su Password: ^[]0;[EMAIL PROTECTED]:/home/[EMAIL PROTECTED] ykarant]# ./iwlist-scan You need to be root to get a current scan eth1 Scan completed : Cell 01 - Address: 00:12:00:51:BC:60 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:1 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=82/100 Signal level=-48 dBm Extra: Last beacon: 27ms ago Cell 02 - Address: 00:15:F9:A6:76:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=31/100 Signal level=-81 dBm Extra: Last beacon: 724ms ago Cell 03 - Address: 00:1B:54:25:15:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s
Re: Another dropped connection with iwl3945 and NM-0.6.5 on FC7
Dan Williams [EMAIL PROTECTED] writes: On Tue, 2007-12-04 at 19:02 -0500, Derek Atkins wrote: Here's the dmesg output: eth1: RX deauthentication from 00:19:a9:47:56:91 (reason=1) eth1: deauthenticated eth1: authenticate with AP 00:19:a9:47:56:91 eth1: RX authentication from 00:19:a9:47:56:91 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:19:a9:47:56:91 eth1: RX ReassocResp from 00:19:a9:47:56:91 (capab=0x1 status=0 aid=80) eth1: associated eth1: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 eth1: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 eth1: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 eth1: No ProbeResp from current AP 00:19:a9:47:56:91 - assume out of range eth1: No STA entry for own AP 00:19:a9:47:56:91 eth1: No STA entry for own AP 00:19:a9:47:56:91 bridge-eth1: disabling the bridge bridge-eth1: down bridge-eth1: enabling the bridge bridge-eth1: up Looks like the driver decided that the AP had gone away. It probably missed too many beacons or probe responses due to the RF heavy environment or something? Could need a driver tweak. Maybe. It's the iwl3945. Maybe it was scanning? ;) The IETF really is a great testbed. Frustrating as a user, but a great testbed. 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 [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Pre-populate NM-vpnc profiles?
Brian Long wrote: Hello, I would like to use gconftool-2 or something to pre-populate various system-wide VPN profiles for NetworkManager-vpnc. Is there any documentation on how to do this? I have various Cisco pcf files from which I can extract the Gateway, Group, Group Password, etc. Is there an easy way to add a bunch of NM-vpnc profiles from the command-line? This would allow me to wrap it inside an RPM, etc. Not necessarily any documentation, however you should be able to extract the relevant configuration from gconf directly. Configure at least one vpn (I believe you can even import the pcf files in the vpn configuration dialog), then use gconf-editor or something to find the appropriate configuration under /system/networking/connections/. There are a couple of problems that will have to be overcome. First, all NM connections (including wired/wifi/vpn) are enumerated beneath that gconf location (at least on 0.7). I'm not sure how NM will react if these are out of order or non numeric. Depending on the configuration needed, it might be necessary to do this from a login script for the user, rather than as system-wide gconf settings (if key locations/usernames etc are stored in gconf). Good luck. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN API
Jon Escombe wrote: Dan Williams wrote: On Wed, 2007-12-05 at 09:28 +, Jon Escombe wrote: Casey Harkins wrote: If you're interested, the attached patch fixes the glade issue as well as an improper key being used in a hash table. I just started looking into the auth dialog which is also failing for me. -casey Thanks, that patch has got the configuration dialogs working here. But having got that bit further, it's now failing to save the configuration to gconf... Still - it's all moving in the right direction ;) Working on that; should be fixed in an hour or so. That particular issue affected all VPN plugins. Dan Thanks, I see the connection configuration is getting written into gconf now. Still not quite working yet though, now onto an Invalid connection error when I attempt to start the VPN, will keep digging ;) I've got that one solved too. I'll get a patch up soon (right now the code is littered with a ridiculous number of nm_debug calls). I'm able to initiate the vpn connection from nm-applet and the openvpn binary is getting called but erroring out. I can manually run the openvpn binary using the same options and connect to the management interface and everything works. Pretty close to getting it working. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Pre-populate NM-vpnc profiles?
On Wed, 2007-12-05 at 13:33 -0600, Casey Harkins wrote:
Brian Long wrote:
Hello,
I would like to use gconftool-2 or something to pre-populate various
system-wide VPN profiles for NetworkManager-vpnc. Is there any
documentation on how to do this? I have various Cisco pcf files from
which I can extract the Gateway, Group, Group Password, etc. Is there
an easy way to add a bunch of NM-vpnc profiles from the command-line?
This would allow me to wrap it inside an RPM, etc.
Not necessarily any documentation, however you should be able to extract
the relevant configuration from gconf directly. Configure at least one
vpn (I believe you can even import the pcf files in the vpn
configuration dialog), then use gconf-editor or something to find the
appropriate configuration under /system/networking/connections/.
There are a couple of problems that will have to be overcome. First, all
NM connections (including wired/wifi/vpn) are enumerated beneath that
gconf location (at least on 0.7). I'm not sure how NM will react if
these are out of order or non numeric. Depending on the configuration
needed, it might be necessary to do this from a login script for the
user, rather than as system-wide gconf settings (if key
locations/usernames etc are stored in gconf).
(I'm talking about 0.7 here)
It shouldn't matter what the path is in GConf. Numerics got picked as
the default paths just because they're pretty easy to handle. If you
wanted to use a string that should work too (in fact, give it a shot and
let me know if the connection doesn't get found and I'll look into it).
So if you really want a stable connection, export the connection details
with:
gconftool-2 --dump /system/networking/connections/6 my-connection.xml
Edit the resulting xml to change base directory to, say, CompanyNet:
entrylist base=/system/networking/connections/CompanyNet
then, roll that .xml file into an RPM and in the %install section do
something like:
gconftool-2 --load %{SOURCE0}
Not sure if you need to give a directory to load stuff into with --load,
you might.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN API
Dan Williams wrote: On Wed, 2007-12-05 at 09:28 +, Jon Escombe wrote: Casey Harkins wrote: If you're interested, the attached patch fixes the glade issue as well as an improper key being used in a hash table. I just started looking into the auth dialog which is also failing for me. -casey Thanks, that patch has got the configuration dialogs working here. But having got that bit further, it's now failing to save the configuration to gconf... Still - it's all moving in the right direction ;) Working on that; should be fixed in an hour or so. That particular issue affected all VPN plugins. Dan Thanks, I see the connection configuration is getting written into gconf now. Still not quite working yet though, now onto an Invalid connection error when I attempt to start the VPN, will keep digging ;) Regards, Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager-list Digest, Vol 39, Issue 18
[EMAIL PROTECTED] wrote: will you pls quit sending to me, You'll need to unsubscribe yourself, the details are at the top of each of these digest messages you've been receiving (see below). To subscribe or unsubscribe via the World Wide Web, visit http://mail.gnome.org/mailman/listinfo/networkmanager-list -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: NetworkManager no-go
On Tue, 2007-12-04 at 19:07 -0800, Yasha Karant wrote: I have been informed that the behavior below evidently is a bug in NetworkManager. I am using NetworkManager Applet 0.6.4 under RHEL 5, and NetworkManager and NetworkManagerDispatcher 0.6.5 . NetworkManager did not offer me any choices in network, nor did it change from the pre-existing channel 11 under the circumstances below. Is this a bug? If so, what is the fix? Best thing to do is to file a bug in Red Hat bugzilla and then we can diagnose this issue further. If you could put some more details into the bug report, like: 1) What kernel version, what wireless card, and what driver the card is using 2) Attach a /var/log/messages that shows a NetworkManager connection attempt to the bug report #2 is important; without that it's hard to figure out where things are going wrong. Thanks, Dan I have now tried NetworkManager on the University 802.11g from my office. No go. Here is the output from scan (I wrote a small script to run the scan and remind me that I needed to be root for the scan to work -- output captured via script in a typescript file): Script started on Tue 04 Dec 2007 11:34:40 AM PST ^[]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]$ su Password: ^[]0;[EMAIL PROTECTED]:/home/[EMAIL PROTECTED] ykarant]# ./iwlist-scan You need to be root to get a current scan eth1 Scan completed : Cell 01 - Address: 00:12:00:51:BC:60 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:1 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=82/100 Signal level=-48 dBm Extra: Last beacon: 27ms ago Cell 02 - Address: 00:15:F9:A6:76:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=31/100 Signal level=-81 dBm Extra: Last beacon: 724ms ago Cell 03 - Address: 00:1B:54:25:15:80 ESSID:CSUSB Protocol:IEEE 802.11bg Mode:Master Channel:6 Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=44/100 Signal level=-74 dBm Extra: Last beacon: 1058ms ago ^[]0;[EMAIL PROTECTED]:/home/[EMAIL PROTECTED] ykarant]# exit exit ^[]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]$ Gexit exit At home, using /usr/sbin/system-config-network-gui (that does the same thing as manually editing the files, reloading, etc.), the WLAN is set to channel 11. NetworkManager only showed one CSUSB WLAN, and refused to connect. system-config-network-gui showed that the WNIC was still on channel 11. I manually changed this via system-config-network-gui to channel 1 (please see the scan above), and everything worked, including NetworkManager. However, NetworkManager would not automatically go to channel 1 nor would it allow me to choose channels. Is this fixable via a NetworkManager post-build configuration file? Is this fixable via a NetworkManager configuration file that is used during the build process? __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org
Re: VPN API
On Tue, 2007-12-04 at 23:51 +0100, Denis Leroy wrote: Dan Williams wrote: On Tue, 2007-12-04 at 15:03 -0600, Casey Harkins wrote: I understand that the VPN API is currently in flux, but am looking for any documentation on the current API or the direction the API is going. (Or is this all just locked up in someone's head). NetworkManager-openvpn on Fedora 8 is broken. I'm happy to try to whip it into shape, but have no familiarity with how all of the NetworkManager pieces fit together, especially how NetworkManager calls out to the VPN plugins. Are either the vpnc or pptp plugins being kept up to date with API changes? If so, at least I have known working code to work from. vpnc is; and upstream openvpn has already been fixed up to conform to the new API bits. Nobody's been around to test it yet. What we probably should do is to build what's upstream for Fedora, push it out (it can't possibly be _less_ broken than whats in F8 already) and wait for the bug reports. Still the F-8 vpnc has a number of protocol-related issues, such as login failures not being reported. It throws a D-bus failure signal that nobody catches (which seems redundant with the state_change signals). Or the lock icon sometimes not showing up when it's supposed to be. I was looking into that code recently, but didn't really know how the pieces were meant to fit together. Any guidance would be helpful, so I can work on a patch. I had started to clean that up but needed to ensure that NM sent the right VPN status reason in the right places. I think there are 1 or 2 cases where the reason code isn't appropriate to allow clients to just mirror the reason code as the notification to the user. Basically, in applet.c's show_vpn_state() function, there should be a switch statement or something for the VPN state, and then if the state is NM_VPN_CONNECTION_STATE_FAILED it should translate the reason code as appropriate and display the notification to the user as to why the connection failed. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Pre-populate NM-vpnc profiles?
Hello, I would like to use gconftool-2 or something to pre-populate various system-wide VPN profiles for NetworkManager-vpnc. Is there any documentation on how to do this? I have various Cisco pcf files from which I can extract the Gateway, Group, Group Password, etc. Is there an easy way to add a bunch of NM-vpnc profiles from the command-line? This would allow me to wrap it inside an RPM, etc. Thanks. /Brian/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: scan list limitation -- doesn't like 127 APs?
Dan Williams [EMAIL PROTECTED] writes: Can you file a bug on gnome.org? http://bugzilla.gnome.org/show_bug.cgi?id=501835 -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 [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
On Wed, 2007-12-05 at 16:08 -0600, Casey Harkins wrote: Dan Williams wrote: Is this dependent on a specific openVPN version? Because some of the config options and command line things look like they've changed... The only change with openvpn interaction I made is reading the ip address from the ifconfig_local environment variable, rather than ipconfig_local. This change was introduced in NetworkManager revision #2952 [1], which was likely just a typo as the code was reworked. So, no this shouldn't be dependent on a specific openvpn version (at least not any different than all previous versions of the openvpn plugin). Here's a quick summary of my changes by file: nm-openvpn-service-openvpn-helper.c: * Get ip from ifconfig_local, not ipconfig_local. nm-openvpn-service.c: * Add PASSWORD and CERTPASS to the props list for validation. * Convert remote prop to string before passing to openvpn. * Change an error message from vpnc to openvpn. nm-openvpn.c: * Fix wrong key being used to store TA_DIR property. * Make advanced settings widgets load properly from glade. auth-dialog/main.c: * Fix gconf paths (prefix subpaths with leading slash). * Fix a missed name - id change. * Don't overwrite proper needpass/certpass. * Dump key names out with passwords. I noticed a couple places where I think there's some leaking going on that I'll come back and address later. (I'm assuming GladeXML*'s should be unref'ed when we're done with them?) I especially like the comment, The string here is leaked, big deal. in nm-openvpn-service.c. ;-) Yes, they get g_object_unref()-ed when you're done with them. Thanks for the explanation, I think I'll go ahead and commit the patch. Cheers, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
On Wed, 2007-12-05 at 14:56 -0600, Casey Harkins wrote: Attached is a patch with a number of fixes for openvpn against svn revision 3138. I'm still having some crashes creating/editing properties, but can consistently create new working settings by running /usr/bin/nm-vpn-properties directly. Connecting is working fine for me (X509 with password, TA and UDP). I'm going to continue poking away at the property issues and see if I can eliminate the remaining issues. Committed, thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn fixes against svn 3138
Attached is a patch with a number of fixes for openvpn against svn
revision 3138. I'm still having some crashes creating/editing
properties, but can consistently create new working settings by running
/usr/bin/nm-vpn-properties directly. Connecting is working fine for me
(X509 with password, TA and UDP).
I'm going to continue poking away at the property issues and see if I
can eliminate the remaining issues.
-casey
Index: vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c (revision 3138)
+++ vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c (working copy)
@@ -212,7 +212,7 @@
helper_failed (connection, Tunnel Device);
/* IP address */
- val = addr_to_gvalue (getenv (ipconfig_local));
+ val = addr_to_gvalue (getenv (ifconfig_local));
if (val)
g_hash_table_insert (config, NM_VPN_PLUGIN_IP4_CONFIG_ADDRESS, val);
else
Index: vpn-daemons/openvpn/src/nm-openvpn-service.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service.c (revision 3138)
+++ vpn-daemons/openvpn/src/nm-openvpn-service.c (working copy)
@@ -99,6 +99,8 @@
{ NM_OPENVPN_KEY_TA, G_TYPE_STRING },
{ NM_OPENVPN_KEY_TA_DIR, G_TYPE_STRING },
{ NM_OPENVPN_KEY_USERNAME,G_TYPE_STRING },
+ { NM_OPENVPN_KEY_PASSWORD,G_TYPE_STRING },
+ { NM_OPENVPN_KEY_CERTPASS,G_TYPE_STRING },
{ NULL, G_TYPE_NONE }
};
@@ -386,7 +388,7 @@
tmp = g_hash_table_lookup (properties, NM_OPENVPN_KEY_REMOTE);
if (tmp) {
g_ptr_array_add (openvpn_argv, (gpointer) --remote);
- g_ptr_array_add (openvpn_argv, tmp);
+ g_ptr_array_add (openvpn_argv, (gpointer) g_value_get_string ((GValue *) tmp));
}
tmp = g_hash_table_lookup (properties, NM_OPENVPN_KEY_COMP_LZO);
@@ -635,7 +637,7 @@
NM_VPN_PLUGIN_ERROR,
NM_VPN_PLUGIN_ERROR_LAUNCH_FAILED,
%s,
- Could not start vpnc binary.);
+ Could not start openvpn binary.);
goto out;
}
Index: vpn-daemons/openvpn/properties/nm-openvpn.c
===
--- vpn-daemons/openvpn/properties/nm-openvpn.c (revision 3138)
+++ vpn-daemons/openvpn/properties/nm-openvpn.c (working copy)
@@ -331,7 +331,7 @@
else
dir = ;
- g_hash_table_insert (properties, NM_OPENVPN_KEY_TA, str_to_gvalue (dir));
+ g_hash_table_insert (properties, NM_OPENVPN_KEY_TA_DIR, str_to_gvalue (dir));
}
}
@@ -1637,7 +1637,37 @@
impl-last_fc_dir = NULL;
+ /* advanced settings */
glade_file = g_strdup_printf (%s/%s, GLADEDIR, nm-openvpn-dialog.glade);
+ impl-xml = glade_xml_new (glade_file, nm-openvpn-advanced-dialog, GETTEXT_PACKAGE);
+ g_free( glade_file );
+ if (impl-xml == NULL)
+ goto error;
+
+ impl-advanced = GTK_DIALOG (glade_xml_get_widget(impl-xml, nm-openvpn-advanced-dialog));
+
+ impl-w_port = GTK_ENTRY (glade_xml_get_widget (impl-xml, openvpn-port));
+ impl-w_use_routes = GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-routes));
+ impl-w_routes = GTK_ENTRY (glade_xml_get_widget (impl-xml, openvpn-routes));
+
+ impl-w_use_lzo= GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-lzo));
+ impl-w_use_tap= GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-tap));
+ impl-w_use_tcp= GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-tcp));
+
+ impl-w_use_cipher = GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-cipher));
+ impl-w_cipher = GTK_COMBO_BOX( glade_xml_get_widget( impl-xml, openvpn-cipher ) );
+ populate_cipher(impl-w_cipher);
+
+ impl-w_use_ta = GTK_CHECK_BUTTON (glade_xml_get_widget (impl-xml, openvpn-use-ta));
+ impl-w_ta = GTK_ENTRY( glade_xml_get_widget( impl-xml, openvpn-ta ) );
+ impl-w_button_ta = GTK_BUTTON( glade_xml_get_widget( impl-xml, openvpn-but-ta ) );
+ impl-w_ta_dir_label = GTK_LABEL( glade_xml_get_widget( impl-xml, openvpn-ta-dir-label ) );
+ impl-w_ta_dir_none= GTK_RADIO_BUTTON( glade_xml_get_widget( impl-xml, openvpn-ta-dir-none ) );
+ impl-w_ta_dir_zero= GTK_RADIO_BUTTON( glade_xml_get_widget( impl-xml, openvpn-ta-dir-zero ) );
+ impl-w_ta_dir_one = GTK_RADIO_BUTTON( glade_xml_get_widget( impl-xml, openvpn-ta-dir-one ) );
+
+ /* normal settings */
+ glade_file = g_strdup_printf (%s/%s, GLADEDIR, nm-openvpn-dialog.glade);
impl-xml = glade_xml_new (glade_file, nm-openvpn-widget, GETTEXT_PACKAGE);
g_free( glade_file );
if (impl-xml == NULL)
@@ -1646,18 +1676,13 @@
impl-widget = glade_xml_get_widget(impl-xml, nm-openvpn-widget);
g_object_ref_sink (impl-widget);
- impl-advanced = GTK_DIALOG (glade_xml_get_widget(impl-xml,
Re: scan list limitation -- doesn't like 127 APs?
On Tue, 2007-12-04 at 18:25 -0500, Derek Atkins wrote: I just roamed and got kicked off the network. DMESG shows: eth1: No ProbeResp from current AP 00:19:a9:45:2f:a1 - assume out of range eth1: No STA entry for own AP 00:19:a9:45:2f:a1 eth1: Initial auth_alg=0 eth1: authenticate with AP 00:19:a9:45:2f:a1 eth1: Initial auth_alg=0 eth1: authenticate with AP 00:19:a9:45:2f:a1 eth1: authenticate with AP 00:19:a9:45:2f:a1 eth1: authenticate with AP 00:19:a9:45:2f:a1 eth1: authentication with AP 00:19:a9:45:2f:a1 timed out And then I noticed this in my /var/log/messages: Dec 4 18:21:49 pgpdev NetworkManager: WARN request_and_convert_scan_results(): unknown error, or the card returned too much scan info: Argument list too long NM 0.6.5 will stop trying to get scan results after the buffer size reaches 100K. That's actually somewhat false, since it doubles the buffer size (like iwlist and wpa_supplicant do) each time the driver says that the buffer size is too small. So that would lead NM 0.6.5 to quit trying to get scan results when the buffer size is = 50,000 bytes. That cutoff should probably be raised though, and the algorithm fixed. Can you file a bug on gnome.org? 0.7 grabs APs from wpa_supplicant over D-Bus, so it doesn't have this problem. Thanks, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
Dan Williams wrote: On Wed, 2007-12-05 at 14:56 -0600, Casey Harkins wrote: Attached is a patch with a number of fixes for openvpn against svn revision 3138. I'm still having some crashes creating/editing properties, but can consistently create new working settings by running /usr/bin/nm-vpn-properties directly. Connecting is working fine for me (X509 with password, TA and UDP). I'm going to continue poking away at the property issues and see if I can eliminate the remaining issues. No problem. They'll be more coming. There's still some config crashes, DNS is not getting set up correctly and there is a long standing bug when specifying custom routes that I plan on fixing now that I've started familiarizing myself with the code. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN API
On Wed, 2007-12-05 at 09:28 +, Jon Escombe wrote: Casey Harkins wrote: If you're interested, the attached patch fixes the glade issue as well as an improper key being used in a hash table. I just started looking into the auth dialog which is also failing for me. -casey Thanks, that patch has got the configuration dialogs working here. But having got that bit further, it's now failing to save the configuration to gconf... Still - it's all moving in the right direction ;) Working on that; should be fixed in an hour or so. That particular issue affected all VPN plugins. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager-list Digest, Vol 39, Issue 18
On Wed, 2007-12-05 at 15:03 -0600, Casey Harkins wrote: [EMAIL PROTECTED] wrote: will you pls quit sending to me, You'll need to unsubscribe yourself, the details are at the top of each of these digest messages you've been receiving (see below). FYI, I've handled this. dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
On Dec 5, 2007 5:59 PM, Casey Harkins [EMAIL PROTECTED] wrote: No problem. They'll be more coming. There's still some config crashes, DNS is not getting set up correctly and there is a long standing bug when specifying custom routes that I plan on fixing now that I've started familiarizing myself with the code. -casey You will be a hero to a lot of people if you can fix this last one! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
Tambet Ingo wrote: On Dec 4, 2007 4:17 PM, Jon Escombe [EMAIL PROTECTED] wrote: Good stuff, got connected first time ;) Only issues were that it didn't set up resolv.conf, and also added three entries to the applet menu (as the card presents three ports). Both of these issues should be fixed in the SVN now. Tambet Confirmed, thanks! Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
Dan Williams wrote: Is this dependent on a specific openVPN version? Because some of the config options and command line things look like they've changed... The only change with openvpn interaction I made is reading the ip address from the ifconfig_local environment variable, rather than ipconfig_local. This change was introduced in NetworkManager revision #2952 [1], which was likely just a typo as the code was reworked. So, no this shouldn't be dependent on a specific openvpn version (at least not any different than all previous versions of the openvpn plugin). Here's a quick summary of my changes by file: nm-openvpn-service-openvpn-helper.c: * Get ip from ifconfig_local, not ipconfig_local. nm-openvpn-service.c: * Add PASSWORD and CERTPASS to the props list for validation. * Convert remote prop to string before passing to openvpn. * Change an error message from vpnc to openvpn. nm-openvpn.c: * Fix wrong key being used to store TA_DIR property. * Make advanced settings widgets load properly from glade. auth-dialog/main.c: * Fix gconf paths (prefix subpaths with leading slash). * Fix a missed name - id change. * Don't overwrite proper needpass/certpass. * Dump key names out with passwords. I noticed a couple places where I think there's some leaking going on that I'll come back and address later. (I'm assuming GladeXML*'s should be unref'ed when we're done with them?) I especially like the comment, The string here is leaked, big deal. in nm-openvpn-service.c. ;-) -casey [1]http://svn.gnome.org/viewvc/NetworkManager/trunk/vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c?r1=2118r2=2952 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
On Wed, 2007-12-05 at 14:56 -0600, Casey Harkins wrote: Attached is a patch with a number of fixes for openvpn against svn revision 3138. I'm still having some crashes creating/editing properties, but can consistently create new working settings by running /usr/bin/nm-vpn-properties directly. Connecting is working fine for me (X509 with password, TA and UDP). I'm going to continue poking away at the property issues and see if I can eliminate the remaining issues. Is this dependent on a specific openVPN version? Because some of the config options and command line things look like they've changed... Thanks for the patch though; can I get some more people to test it out before I commit? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
Casey Harkins wrote: Dan Williams wrote: On Wed, 2007-12-05 at 14:56 -0600, Casey Harkins wrote: Attached is a patch with a number of fixes for openvpn against svn revision 3138. I'm still having some crashes creating/editing properties, but can consistently create new working settings by running /usr/bin/nm-vpn-properties directly. Connecting is working fine for me (X509 with password, TA and UDP). I'm going to continue poking away at the property issues and see if I can eliminate the remaining issues. No problem. They'll be more coming. There's still some config crashes, DNS is not getting set up correctly and there is a long standing bug when specifying custom routes that I plan on fixing now that I've started familiarizing myself with the code. -casey Thanks for the patches, I've had a few issues while testing -- Error in nm-vpn-connection.c / get_secrets_cb(), due to a mandatory check for a secret. Presumably there are no secrets for my X509 Certificates connection type? Error in nm-openvpn-service-openvpn-helper.c / main(), due to a mandatory check for ifconfig_remote which isn't specified on a TAP connection. Also, I'm not getting a route added for the VPN subnet. I've just commented these first two checks out for now, and have finally managed to make a VPN connection from F8! Keep up the good work ;) Regards, Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Roaming to (none) ((none))
Hi, I'm running latest NM 0.7 from svn and it works fine so far. The only strange issue I encounter is, that NM after succesfully establishing a connection to my WLAN router wgrouter, seems to roam to an unknown AP. Please see the attached NM log. As a result in the nm-applet wlan list menu, my wgrouter network is not selected (see attached screenshot). Any idea what's going wrong? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? Dec 5 22:26:11 pluto NetworkManager: info starting... Dec 5 22:26:11 pluto NetworkManager: info Found radio killswitch /org/freedesktop/Hal/devices/ipw_wlan_switch Dec 5 22:26:11 pluto NetworkManager: info eth0: Device is fully-supported using driver '8139cp'. Dec 5 22:26:11 pluto NetworkManager: info (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_02_3f_65_9b_85 Dec 5 22:26:11 pluto NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Dec 5 22:26:11 pluto NetworkManager: info Bringing up device eth0 Dec 5 22:26:11 pluto NetworkManager: info Deactivating device eth0. Dec 5 22:26:12 pluto NetworkManager: info wlan0: Device is fully-supported using driver 'ipw2100'. Dec 5 22:26:12 pluto NetworkManager: info (wlan0): exporting device as /org/freedesktop/Hal/devices/net_00_04_23_5c_2d_ea Dec 5 22:26:12 pluto NetworkManager: info Now managing wireless (802.11) device 'wlan0'. Dec 5 22:26:12 pluto NetworkManager: info Bringing up device wlan0 Dec 5 22:26:12 pluto NetworkManager: info Deactivating device wlan0. Dec 5 22:26:12 pluto NetworkManager: info (eth0) supplicant interface is now in state 2 (from 1). Dec 5 22:26:12 pluto NetworkManager: info (wlan0) supplicant interface is now in state 2 (from 1). Dec 5 22:26:56 pluto NetworkManager: info SWITCH: no current connection, found better connection 'Auto wgrouter (wlan0)'. Dec 5 22:26:56 pluto NetworkManager: info Activating device wlan0 Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0/wireless): access point 'Auto wgrouter' has security, but secrets are required. Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Dec 5 22:26:56 pluto NetworkManager: Missing or invalid key management Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0/wireless): connection 'Auto wgrouter' has security, and secrets exist. No new secrets needed. Dec 5 22:26:56 pluto NetworkManager: info Config: added 'ssid' value 'wgrouter' Dec 5 22:26:56 pluto NetworkManager: info Config: added 'key_mgmt' value 'WPA-PSK' Dec 5 22:26:56 pluto NetworkManager: info Config: added 'psk' value 'omitted' Dec 5 22:26:56 pluto NetworkManager: info Config: added 'proto' value 'WPA RSN' Dec 5 22:26:56 pluto NetworkManager: info Config: added 'pairwise' value 'TKIP CCMP' Dec 5 22:26:56 pluto NetworkManager: info Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Dec 5 22:26:56 pluto NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Dec 5 22:26:56 pluto NetworkManager: info (wlan0) Supplicant interface state change: 2 - 0 Dec 5 22:26:56 pluto NetworkManager: info Config: set interface ap_scan to 1 Dec 5 22:26:56 pluto NetworkManager: info (wlan0) Supplicant interface state change: 0 - 2 Dec 5 22:26:57 pluto NetworkManager: info (wlan0) Supplicant interface state change: 2 - 3 Dec 5 22:26:58 pluto NetworkManager: info (wlan0) Supplicant interface state change: 3 - 4 Dec 5 22:27:02 pluto NetworkManager: info (wlan0) Supplicant interface state change: 4 - 5 Dec 5 22:27:03 pluto NetworkManager: info (wlan0) Supplicant interface state change: 5 - 6 Dec 5 22:27:06 pluto NetworkManager: info (wlan0) Supplicant interface state change: 6 - 7 Dec 5 22:27:06 pluto NetworkManager: info Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected
Re: RFC 4833 / TimeZone by DHCP
On Mon, 2007-12-03 at 19:08 -0500, Dan Williams wrote: Or the international clock listens and makes the change since it knows how to do that. Exactly; that's the ideal case. I want the model to be pull _from_ NetworkManager provided information, not have NM push stuff out. I'm a bit late into the conversation. How would this work? 1. Clock listens for network went up/down 2. When the network goes up, the clock asks NM for gimme the DHCP data 3. Clock sets the timezone. What happens if you don't have a clock applet? :) Should NM just have a magic script to set the timezone? Federico ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3140
Attached is a patch which fixes DNS (and WINS) for openvpn. There was an
off by one issue when ensuring a DNS server was provided.
Jon Escombe wrote:
Error in nm-vpn-connection.c / get_secrets_cb(), due to a mandatory
check for a secret. Presumably there are no secrets for my X509
Certificates connection type?
I'll look into it. If your X509 key is not encrypted, the openvpn plugin
won't ask for a password (from what I can tell). So the question is
whether NM always expects some secret back, or if the openvpn plugin is
not telling NM it doesn't need any secret.
Error in nm-openvpn-service-openvpn-helper.c / main(), due to a
mandatory check for ifconfig_remote which isn't specified on a TAP
connection.
I'll take care of this.
Also, I'm not getting a route added for the VPN subnet.
Are you talking about the Only use VPN connection for these addresses
option, or it's not setting your default route to your TAP device?
-casey
Index: vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c (revision 3140)
+++ vpn-daemons/openvpn/src/nm-openvpn-service-openvpn-helper.c (working copy)
@@ -166,7 +166,7 @@
g_strfreev (split);
- if (!value_array array-len 1) {
+ if (!value_array array-len 0) {
value_array = g_slice_new0 (GValue);
g_value_init (value_array, DBUS_TYPE_G_UINT_ARRAY);
g_value_set_boxed (value_array, array);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn fixes against svn 3138
Darren Albers wrote: On Dec 5, 2007 5:59 PM, Casey Harkins [EMAIL PROTECTED] wrote: No problem. They'll be more coming. There's still some config crashes, DNS is not getting set up correctly and there is a long standing bug when specifying custom routes that I plan on fixing now that I've started familiarizing myself with the code. -casey You will be a hero to a lot of people if you can fix this last one! I'm assuming you're referring to NM leaving you with no default route when specifying specific routes from the VPN configuration? If so, is it a problem for all vpn plugins, or specific to the openvpn plugin? For the openvpn plugin (though I'd imagine something similar could be done for other VPN plugins as well), I want to extend the Only use VPN connection for these addresses to include a checkbox for and addresses specified by the VPN server. -casey ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
