Re: knetworkmanager autostart issue
Hi Dawid, Am Dienstag, 7. August 2007 17:47:17 schrieb Dawid Wróbel: Hi, After updating to 0.2 I somehow cannot force knetworkmanager to start automatically after logging in to my kde session. Note, that I have the start knetworkmanager auotmatically on login box checked in configuration. I also have a saving and restoring the kde session option set up in kde configuration (not sure if that's the correct name for this option, I am using localized KDE). Any idea? Which distro do you use? Please verify that Autostart=yes is set in your knetworkmanagerrc (~/.kde/share/config). Regards, Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Add WPA2 to allowed protocols
Hi,
attached is a patch against trunk which adds WPA2 to the allowed protocols for
wpa_supplicant. Is there any reason why it was not in the list yet? If not
please commit to trunk.
Thanks,
Helmut
Index: src/supplicant-manager/nm-supplicant-settings-verify.c
===
--- src/supplicant-manager/nm-supplicant-settings-verify.c (Revision 2656)
+++ src/supplicant-manager/nm-supplicant-settings-verify.c (Arbeitskopie)
@@ -65,7 +65,7 @@
const char * pairwise_allowed[] = { CCMP, TKIP, NONE, NULL };
const char * group_allowed[] ={ CCMP, TKIP, WEP104, WEP40, NULL };
-const char * proto_allowed[] ={ WPA, RSN, NULL };
+const char * proto_allowed[] ={ WPA, RSN, WPA2, NULL };
const char * key_mgmt_allowed[] = { WPA-PSK, WPA-EAP, IEEE8021X,
NONE, NULL };
const char * auth_alg_allowed[] = { OPEN, SHARED, LEAP, NULL };
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
Hey,
On 8/7/07, Helmut Schaa [EMAIL PROTECTED] wrote:
while porting KNetworkManager to NM 0.7 I found a few issues which need fixing
in NM. Attached are three patches which apply cleanly against trunk.
1) allow_linking_with_cpp.patch:
As the filename indicates this patch adds support for using libnm_util and
libnm_glib from within C++.
I'll replace these with G_BEGIN_DECLS / G_END_DECLS (macros that
expand to exactly the same but will make editors not indent the whole
content of header file because of { }).
2) fix_segfault.patch:
This patch fixes a segfault caused by some ssid being NULL. I don't know if it
is desired to have ssid's being NULL but in current trunk using my ipw2200
I've got a lot of these.
It's NULL for all hidden APs, looks good.
3) fix_memory_corruption.patch
The most important one (it took hours to find the cause). Call to g_object_get
writes a gint (4 byte) into the gint8 output buffer (1 byte) and thus
overwrites some other data (in my case the last_seen property).
Nice catch. The proper fix would be to not write 4 bytes to that
pointer though, I'll commit a fix for that instead.
Please have a look at the patches and commit to trunk.
Thanks! I'll commit all these changes shortly.
Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
Am Mittwoch, 8. August 2007 12:39:01 schrieb Tambet Ingo:
1) allow_linking_with_cpp.patch:
As the filename indicates this patch adds support for using libnm_util
and libnm_glib from within C++.
I'll replace these with G_BEGIN_DECLS / G_END_DECLS (macros that
expand to exactly the same but will make editors not indent the whole
content of header file because of { }).
Nice, thanks.
3) fix_memory_corruption.patch
The most important one (it took hours to find the cause). Call to
g_object_get writes a gint (4 byte) into the gint8 output buffer (1 byte)
and thus overwrites some other data (in my case the last_seen property).
Nice catch. The proper fix would be to not write 4 bytes to that
pointer though, I'll commit a fix for that instead.
Indeed, but g_object_get is a glib function ;-)
Regards,
Helmut
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: knetworkmanager autostart issue
Dnia Wed, 8 Aug 2007 09:43:50 +0200 Helmut Schaa [EMAIL PROTECTED] napisał: Which distro do you use? Archlinux Please verify that Autostart=yes is set in your knetworkmanagerrc (~/.kde/share/config). I have Autostart=true set. -- Regards, Dawid Wróbel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Tue, 2007-08-07 at 00:28 -0200, Thomas M Steenholdt wrote:
Thomas M Steenholdt wrote:
I'll force it to use 1 or 2 this evening, and see what kind of success
that will give me.
I'll keep you guys posted.
I've been experimenting a bit tonight and this is what I've found.
AP_SCAN 2 : ESSID is set on the wireless device, but it never
associates. Presumably because it cannot find the AP.
AP_SCAN 1: ESSID does NOT get set on the wireless device, so does not
work alone - during the device setup phase, if you issue an iwconfig
wlan0 essid whatever, the device will associate fine.
So the problem with this patch is that it doesn't actually take account
of what AP_SCAN values actually do... That said, AP_SCAN is _horrible_
and reflects wpa_supplicant assuming too much about what it should be
doing.
# 1: wpa_supplicant initiates scanning and AP selection
# 0: driver takes care of scanning, AP selection, and IEEE 802.11 association
#parameters (e.g., WPA IE generation); this mode can also be used with
#non-WPA drivers when using IEEE 802.1X mode; do not try to associate with
#APs (i.e., external program needs to control association). This mode must
#also be used when using wired Ethernet drivers.
# 2: like 0, but associate with APs using security policy and SSID (but not
#BSSID); this can be used, e.g., with ndiswrapper and NDIS drivers to
#enable operation with hidden SSIDs and optimized roaming; in this mode,
#the network blocks in the configuration file are tried one by one until
#the driver reports successful association; each network block should have
#explicit security policy (i.e., only one option in the lists) for
#key_mgmt, pairwise, group, proto variables
We never use 0, because that's only for wired.
1 means wpa_supplicant scans around and tries to find the AP. But if
the AP is hidden, wpa_supplicant won't find it because wpa_supplicant
doesn't know how to find hidden APs. NM works around that by caching
the BSSID after a successful connection, and when it finds that BSSID in
scan results, filling in the SSID.
2 means NM must fill out the config for the network completely, and
wpa_supplicant just blows those settings to the card and waits for the
association to succeed. This is most closely analogous to a lot of
'iwconfig' commands. Only in this mode can wpa_supplicant really
connect to a hidden network, because NM would have given wpa_supplicant
both SSID and BSSID.
So it's understandable why wpa_supplicant doesn't set the SSID on the
card when you give it AP_SCAN=1, because it can't _find_ that SSID in
scan results precisely because the SSID isn't broadcasting it's SSID.
In this case I'd more suspect driver issues. Or, you could try a
straight wpa_supplicant configuration with both AP_SCAN=1 and AP_SCAN=2
and see which one works, without NM in the picture.
Dan
So I made a patch to incorporate the two and to prove a point. :)
Please note, that this patch is intended to prove that the association
to hidden IS possible, even with ipw4965 devices. The patch changes the
AP_SCAN value for hidden networks and I have no clue as to what that
will do for other wireless devices. Also, since I've not gotten
acquainted to very much of the NetworkManager code, there might be
better places to put some of these things. So it should at the very
least be reviewed by someone more familiar with the code than myself.
(there - the disclaimer is double the size of the patch itself ;-p)
Try it out and let me know how it works for you.
My testing was performed on Fedora 7 - 0.6.5 version of NetworkManager.
Obviously 0.6.5 is also the version that this patch is most likely to
apply to.
Good luck. Patch below!
/Thomas
--- NetworkManager-0.6.5/src/nm-device-802-11-wireless.c.fix-hidden
2007-06-07 13:22:21.0 -0200
+++ NetworkManager-0.6.5/src/nm-device-802-11-wireless.c 2007-08-07
00:14:29.0 -0200
@@ -2838,13 +2838,19 @@
|| (caps NM_802_11_CAP_PROTO_WPA2);
/* Use AP_SCAN 2 if:
- * - The wireless network is non-broadcast or Ad-Hoc
+ * - The wireless network is Ad-Hoc
* - The wireless driver does not support WPA (stupid drivers...)
*/
is_adhoc = (nm_ap_get_mode(ap) == IW_MODE_ADHOC);
- if (!nm_ap_get_broadcast (ap) || is_adhoc || !supports_wpa)
+ if (is_adhoc || !supports_wpa)
ap_scan = AP_SCAN 2;
+ /* Use AP_SCAN 1 if:
+ * - The wireless network is non-broadcast
+ */
+ if (!nm_ap_get_broadcast (ap))
+ ap_scan = AP_SCAN 1;
+
/* Tell wpa_supplicant that we'll do the scanning */
if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__,
NULL, ap_scan))
goto out;
@@ -2877,6 +2883,14 @@
*/
if (!nm_ap_get_broadcast (ap) !is_adhoc)
{
+ /*
+ * since using AP_SCAN 1 for
Re: [PATCH] Add WPA2 to allowed protocols
On Wed, 2007-08-08 at 10:45 +0200, Helmut Schaa wrote: Hi, attached is a patch against trunk which adds WPA2 to the allowed protocols for wpa_supplicant. Is there any reason why it was not in the list yet? If not please commit to trunk. Because RSN == WPA2 for wpa_supplicant. We only need one. The user agent/applet is free to show what it likes in the UI, but it should pass only RSN to NetworkManager for the configuration. Dan Thanks, Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add WPA2 to allowed protocols
Am Mittwoch, 8. August 2007 13:37:07 schrieb Dan Williams:
On Wed, 2007-08-08 at 10:45 +0200, Helmut Schaa wrote:
attached is a patch against trunk which adds WPA2 to the allowed
protocols for wpa_supplicant. Is there any reason why it was not in the
list yet? If not please commit to trunk.
Because RSN == WPA2 for wpa_supplicant. We only need one. The user
agent/applet is free to show what it likes in the UI, but it should pass
only RSN to NetworkManager for the configuration.
Thanks for the explanation ;-)
Therefore a more appropriate patch would be to replace WPA2 options in NM
itself by RSN. Right? Here you are.
Regards,
Helmut
Index: nm-ap-security-wpa-eap.c
===
--- src/nm-ap-security-wpa-eap.c (Revision 2656)
+++ src/nm-ap-security-wpa-eap.c (Arbeitskopie)
@@ -199,7 +199,7 @@
if (!nm_supplicant_config_add_option (config, proto, WPA, -1))
goto out;
} else {
- if (!nm_supplicant_config_add_option (config, proto, WPA2, -1))
+ if (!nm_supplicant_config_add_option (config, proto, RSN, -1))
goto out;
}
Index: nm-ap-security-wpa-psk.c
===
--- src/nm-ap-security-wpa-psk.c (Revision 2656)
+++ src/nm-ap-security-wpa-psk.c (Arbeitskopie)
@@ -148,7 +148,7 @@
if (!nm_supplicant_config_add_option (config, proto, WPA, -1))
goto out;
} else if (self-priv-wpa_version == IW_AUTH_WPA_VERSION_WPA2) {
- if (!nm_supplicant_config_add_option (config, proto, WPA2, -1))
+ if (!nm_supplicant_config_add_option (config, proto, RSN, -1))
goto out;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
On 8/8/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Mittwoch, 8. August 2007 12:39:01 schrieb Tambet Ingo: Nice catch. The proper fix would be to not write 4 bytes to that pointer though, I'll commit a fix for that instead. Indeed, but g_object_get is a glib function ;-) ... which calls NetworkManagerAP.c:set_property() for actual assignment. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
Am Mittwoch, 8. August 2007 14:02:22 schrieb Tambet Ingo: On 8/8/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Mittwoch, 8. August 2007 12:39:01 schrieb Tambet Ingo: Nice catch. The proper fix would be to not write 4 bytes to that pointer though, I'll commit a fix for that instead. Indeed, but g_object_get is a glib function ;-) ... which calls NetworkManagerAP.c:set_property() for actual assignment. ... which only sets a GValue but does not copy the raw data over. I think that does glib again :) Helmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Dan Williams wrote: So the problem with this patch is that it doesn't actually take account of what AP_SCAN values actually do... That said, AP_SCAN is _horrible_ and reflects wpa_supplicant assuming too much about what it should be doing. .. snip .. 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. 2 means NM must fill out the config for the network completely, and wpa_supplicant just blows those settings to the card and waits for the association to succeed. This is most closely analogous to a lot of 'iwconfig' commands. Only in this mode can wpa_supplicant really connect to a hidden network, because NM would have given wpa_supplicant both SSID and BSSID. So it's understandable why wpa_supplicant doesn't set the SSID on the card when you give it AP_SCAN=1, because it can't _find_ that SSID in scan results precisely because the SSID isn't broadcasting it's SSID. In this case I'd more suspect driver issues. Or, you could try a straight wpa_supplicant configuration with both AP_SCAN=1 and AP_SCAN=2 and see which one works, without NM in the picture. Dan As I mentiond, plain wpa_supplicant, iwconfig works fine for me. In my wpa_supplicant.conf i don't even have an AP_SCAN option and as I see it, wpa_supplicant uses a default of 1 in that case. I could be mistaken here. NM uses AP_SCAN 2 for all hidden networks. If NM needs to fill in all the info, including BSSID, for wpa_supplicant, then that's probably exactly what fails. John W. Linville pointed out that there are some issues with mac80211 pre-authentication scanning, making it unable to see hidden networks. AP_SCAN 2, in this case, just doesn't work (note: using my old 3945 device, I haven't had any problems like this for a long time). So whether You think that the patch ignores the purpose of the AP_SCAN values, using 1 and an SSID push to device makes it work better here :). I'm not trying to defend the patch in any way, since it's clearly a sort of proof of concept patch. It makes NM push AP_SCAN 1 to wpa_supplicant and sets the SSID on the device in order to make the association happen. As you point out, this is probably no the right(tm) way to do this, but it makes wireless usable for me. AP_SCAN 1 also seems less secure than 2, since it doesn't care about the BSSID to make the association. The right way to fix the problem as I see it, would probably be to get the mac80211 pre-auth scanning working properly. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On 8/8/07, Thomas M Steenholdt [EMAIL PROTECTED] wrote: The right way to fix the problem as I see it, would probably be to get the mac80211 pre-auth scanning working properly. whatever the right way is, this really needs to be fixed. NM is entirely needed for users who depend on gui utilities to attach to networks. (ie me, and my peers, and the 150 or so knowledge workers whom I am trying to convince to use a linux desktop) Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
On 8/8/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Mittwoch, 8. August 2007 14:22:10 schrieben Sie: g_object_class_install_property (object_class, PROP_STRENGTH, g_param_spec_int (...)) Exactly ;-) I was at the same point yesterday but could not find a way to specify an int8-property. If that's possible I would like to know about. g_param_spec_char Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Website correction
Hi there I discovered a spurious to at http://www.gnome.org/projects/NetworkManager mid page in the section Flexible, Extendable, Open: it's easy to to build network-aware applications Cheers Marcel -- Marcel Ziswiler mailto:[EMAIL PROTECTED] Schuelmatt 7https://www.ziswiler.net CH-6018 Buttisholz mobile: +41 (76) 338-0382 Switzerland phone: +41 (41) 928-0509 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: knetworkmanager autostart issue
Dawid Wróbel wrote: Dnia Wed, 8 Aug 2007 09:43:50 +0200 Helmut Schaa [EMAIL PROTECTED] napisał: Which distro do you use? Archlinux Does archlinux install an autostart file for knm? (check /usr/share/autostart) Michael ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, 2007-08-08 at 10:30 -0200, Thomas M Steenholdt wrote: Dan Williams wrote: So the problem with this patch is that it doesn't actually take account of what AP_SCAN values actually do... That said, AP_SCAN is _horrible_ and reflects wpa_supplicant assuming too much about what it should be doing. .. snip .. 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. 2 means NM must fill out the config for the network completely, and wpa_supplicant just blows those settings to the card and waits for the association to succeed. This is most closely analogous to a lot of 'iwconfig' commands. Only in this mode can wpa_supplicant really connect to a hidden network, because NM would have given wpa_supplicant both SSID and BSSID. So it's understandable why wpa_supplicant doesn't set the SSID on the card when you give it AP_SCAN=1, because it can't _find_ that SSID in scan results precisely because the SSID isn't broadcasting it's SSID. In this case I'd more suspect driver issues. Or, you could try a straight wpa_supplicant configuration with both AP_SCAN=1 and AP_SCAN=2 and see which one works, without NM in the picture. Dan As I mentiond, plain wpa_supplicant, iwconfig works fine for me. In my wpa_supplicant.conf i don't even have an AP_SCAN option and as I see it, wpa_supplicant uses a default of 1 in that case. I could be mistaken here. Can you post the output of wpa_supplicant with the -ddd option please? I'd love to see _why_ it works for you with a hidden network, because it likely shouldn't. dan NM uses AP_SCAN 2 for all hidden networks. If NM needs to fill in all the info, including BSSID, for wpa_supplicant, then that's probably exactly what fails. John W. Linville pointed out that there are some issues with mac80211 pre-authentication scanning, making it unable to see hidden networks. AP_SCAN 2, in this case, just doesn't work (note: using my old 3945 device, I haven't had any problems like this for a long time). So whether You think that the patch ignores the purpose of the AP_SCAN values, using 1 and an SSID push to device makes it work better here :). I'm not trying to defend the patch in any way, since it's clearly a sort of proof of concept patch. It makes NM push AP_SCAN 1 to wpa_supplicant and sets the SSID on the device in order to make the association happen. As you point out, this is probably no the right(tm) way to do this, but it makes wireless usable for me. AP_SCAN 1 also seems less secure than 2, since it doesn't care about the BSSID to make the association. The right way to fix the problem as I see it, would probably be to get the mac80211 pre-auth scanning working properly. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add WPA2 to allowed protocols
On Wed, 2007-08-08 at 13:57 +0200, Helmut Schaa wrote: Am Mittwoch, 8. August 2007 13:37:07 schrieb Dan Williams: On Wed, 2007-08-08 at 10:45 +0200, Helmut Schaa wrote: attached is a patch against trunk which adds WPA2 to the allowed protocols for wpa_supplicant. Is there any reason why it was not in the list yet? If not please commit to trunk. Because RSN == WPA2 for wpa_supplicant. We only need one. The user agent/applet is free to show what it likes in the UI, but it should pass only RSN to NetworkManager for the configuration. Thanks for the explanation ;-) Therefore a more appropriate patch would be to replace WPA2 options in NM itself by RSN. Right? Here you are. Well, all the NMAPSecurity junk will be going away momentarily... :) It's dumb code (I know, I wrote it!) and there's a much better interface that Rodrigo will land quite soon, specified by: http://mail.gnome.org/archives/networkmanager-list/2007-February/msg00157.html The configuration stuff is more specified by the NetworkManagerConfiguration and NetworkManagerConfigurationSpecification pages on live.gnome.org. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Dan Williams wrote: Can you post the output of wpa_supplicant with the -ddd option please? I'd love to see _why_ it works for you with a hidden network, because it likely shouldn't. I'm using iwconfig to set the ssid onto the device, just like NM does with the proof-of-concept patch applied. Perhaps that's the key here. Perhaps that's not normally required? If this doesn't explain the situation. I'd be happy to post the debug info tonight(WGST). I don't have that particular laptop with me right now. :) /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: knetworkmanager autostart issue
Dnia Wed, 08 Aug 2007 16:18:50 +0200 Michael Biebl [EMAIL PROTECTED] napisał: Does archlinux install an autostart file for knm? (check /usr/share/autostart) I am affraid it does not. Should the package include this file? -- Regards, Dawid Wróbel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, Aug 08, 2007 at 10:30:14AM -0200, Thomas M Steenholdt wrote: The right way to fix the problem as I see it, would probably be to get the mac80211 pre-auth scanning working properly. AFAICT, that patch is working. If NM is still failing, there would seem to be another issue? John -- John W. Linville [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Tue, Aug 07, 2007 at 04:32:21PM -0200, Thomas M Steenholdt wrote: John W. Linville wrote: I have been testing the patch below with some success using the wireless-tools package. However, NM still seems unable to get an association, at least not on the first try. Sometimes/often the 2nd or 3rd try works, whereas w/o the patch it basically never succeeds without some sort of command-line intervention. If there's indeed a problem with the kernel, it would clearly be better to fix the problem than trying to work around it. That said - the NM patch works around the problem for me. :) As I was trying to say, the patch I posted seems to fix the problem with the kernel (as evidenced through use of wireless-tools). Yet, NM still seemed to trip over it. I was trying to give you a heads-up that the patch (or something equivalent) was coming to the kernel so you could test your NM patches appropriately... John -- John W. Linville [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Tue, Aug 07, 2007 at 11:09:26PM -0200, Thomas M Steenholdt wrote: John W. Linville wrote: FWIW, there _is_ a problem w/ mac80211's pre-authentication scanning. It doesn't probe for SSID, so it can't see hidden networks. I have been testing the patch below with some success using the wireless-tools package. However, NM still seems unable to get an association, at least not on the first try. Sometimes/often the 2nd or 3rd try works, whereas w/o the patch it basically never succeeds without some sort of command-line intervention. Anyway, perhaps you can test w/ the kernel patch below applied? It is also available in the Fedora rawhide kernels here: http://koji.fedoraproject.org/koji/buildinfo?buildID=13001 Thoughts? I installed 2.6.23-0.73.rc2.fc8 from koji, but it really made no difference. Using a plain (from updates repo) NetworkManager, I'm simply unable to get a network connection going. No matter what I seem to do. Did you try the old vs. new kernels with a manual (i.e. wireless-tools) configuration? I think you will find that the new ones work better with hidden SSIDs than the old ones do. Of course, this is most easily confirmed with WEP or open networks. Using the patched NM, I can Connect to other wireless network and it works. But I noticed a different problem. After a warm reboot, NM will notice the network and connect when I log in. After a cold boot, I'll have to Connect to other wireless network again. Probably due to the Beats me -- what hardware are you using? The Intel cards use hardware scanning, so maybe they are caching some results? John -- John W. Linville [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, Aug 08, 2007 at 07:34:47AM -0400, Dan Williams wrote: 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. Just caught this -- so, how does NM find that BSSID in the first place? Someone un-hides the network long enough to connect, then NM just remembers? Or is this ask for the SSID, expect driver scanning routines to find it _somehow_, then cache the results? John -- John W. Linville [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, Aug 08, 2007 at 07:34:47AM -0400, Dan Williams wrote: 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. 2 means NM must fill out the config for the network completely, and wpa_supplicant just blows those settings to the card and waits for the association to succeed. This is most closely analogous to a lot of 'iwconfig' commands. Only in this mode can wpa_supplicant really connect to a hidden network, because NM would have given wpa_supplicant both SSID and BSSID. So it's understandable why wpa_supplicant doesn't set the SSID on the card when you give it AP_SCAN=1, because it can't _find_ that SSID in scan results precisely because the SSID isn't broadcasting it's SSID. So, wpa_supplicant only requests a scan? It never sends any probes itself? Forgive me if this is an ignorant question -- I haven't peered much into these userland bits... John -- John W. Linville [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, 2007-08-08 at 10:58 -0400, John W. Linville wrote: On Wed, Aug 08, 2007 at 07:34:47AM -0400, Dan Williams wrote: 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. Just caught this -- so, how does NM find that BSSID in the first place? Someone un-hides the network long enough to connect, then NM just remembers? Or is this ask for the SSID, expect driver scanning routines to find it _somehow_, then cache the results? After the first successful connect, NM grabs the BSSID off the card and caches that BSSID. If the ESSID stays the same but the BSSID changes (ie, the firmware/driver has decided to roam), NM caches that BSSID too. Therefore, when scan results come back, NM can match up the BSSID in a hidden scan result with an ESSID based on it's list of cached BSSID-ESSID mappings. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On Wed, 2007-08-08 at 10:53 -0400, John W. Linville wrote: On Wed, Aug 08, 2007 at 07:34:47AM -0400, Dan Williams wrote: 1 means wpa_supplicant scans around and tries to find the AP. But if the AP is hidden, wpa_supplicant won't find it because wpa_supplicant doesn't know how to find hidden APs. NM works around that by caching the BSSID after a successful connection, and when it finds that BSSID in scan results, filling in the SSID. 2 means NM must fill out the config for the network completely, and wpa_supplicant just blows those settings to the card and waits for the association to succeed. This is most closely analogous to a lot of 'iwconfig' commands. Only in this mode can wpa_supplicant really connect to a hidden network, because NM would have given wpa_supplicant both SSID and BSSID. So it's understandable why wpa_supplicant doesn't set the SSID on the card when you give it AP_SCAN=1, because it can't _find_ that SSID in scan results precisely because the SSID isn't broadcasting it's SSID. So, wpa_supplicant only requests a scan? It never sends any probes itself? Forgive me if this is an ignorant question -- I haven't peered much into these userland bits... Right. WEXT has a very murky API here that almost none of the drivers implement. It's sort of assumed that if userland sets the BSSID/ESSID on the card, that the card can handle the probe request or some other mechanism of finding that AP to connect to it. In practice, that means that if the driver doesn't have the SSID in it's scan list, it sends out an active scan for that SSID, and connects if it gets a positive result. WEXT has some defines for scanning behavior that perhaps wpa_supplicant should be modified to use: #define IW_SCAN_ALL_ESSID 0x0001 /* Scan all ESSIDs */ #define IW_SCAN_THIS_ESSID 0x0002 /* Scan only this ESSID */ #define IW_SCAN_ALL_FREQ0x0004 /* Scan all Frequencies */ #define IW_SCAN_THIS_FREQ 0x0008 /* Scan only this Frequency */ #define IW_SCAN_ALL_MODE0x0010 /* Scan all Modes */ #define IW_SCAN_THIS_MODE 0x0020 /* Scan only this Mode */ #define IW_SCAN_ALL_RATE0x0040 /* Scan all Bit-Rates */ #define IW_SCAN_THIS_RATE 0x0080 /* Scan only this Bit-Rate */ #define IW_SCAN_TYPE_ACTIVE 0 #define IW_SCAN_TYPE_PASSIVE 1 but almost nobody uses them because the drivers don't really support them. Plus the assumption that drivers have some intelligence themselves and that if they are given an SSID and/or a BSSID, they can figure out what to connect to. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Dan Williams wrote: Well, by doing this you're telling the driver what ESSID to use, and that's exactly what AP_SCAN=2 _should_ be doing already. Okay. Then it would appear that that's the part that doesn't work for the iwl4965 driver atm. Hmm. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
John W. Linville wrote: On Wed, Aug 08, 2007 at 10:30:14AM -0200, Thomas M Steenholdt wrote: The right way to fix the problem as I see it, would probably be to get the mac80211 pre-auth scanning working properly. AFAICT, that patch is working. If NM is still failing, there would seem to be another issue? John I'll be experimenting with it a little later, now that I'm beginning to understand how these things should work together. I was merely trying to get it working with NM yesterday, with no luck at all. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
John W. Linville wrote: Did you try the old vs. new kernels with a manual (i.e. wireless-tools) configuration? I think you will find that the new ones work better with hidden SSIDs than the old ones do. Of course, this is most easily confirmed with WEP or open networks. Will do! Using the patched NM, I can Connect to other wireless network and it works. But I noticed a different problem. After a warm reboot, NM will notice the network and connect when I log in. After a cold boot, I'll have to Connect to other wireless network again. Probably due to the Beats me -- what hardware are you using? The Intel cards use hardware scanning, so maybe they are caching some results? This is Intel iwl4965 - previously I had a 3945 card and didn't have these problems - of course, the entire driver stack for those devices has been replaced since :). But the phenomenon about the cold vs warm boot feels like it could be h/w caching kicking in. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Dan Williams wrote:
Can you post the output of wpa_supplicant with the -ddd option please?
I'd love to see _why_ it works for you with a hidden network, because it
likely shouldn't.
I have performed a number of tests using wpa_supplicant/wireless-tools.
wpa_supplicant only - ap_scan=1:
The hidden network is found during the scanning, but is never identified
as my network, since wpa_supplicant expects a certain SSID and the
hidden net shows an SSID of (SSID mismatch). The device SSID is
never set.
(as soon as I set the device SSID with iwconfig in this mode,
wpa_supplicant makes the association happen)
wpa_supplicant only - ap_scan=2:
The ESSID is set correctly, and scanning starts. I can't tell for sure
if wpa_supplicant finds the right AP during this, logging differs, but
running an iwlist wlan0 scanning in another shell shows my hidden
network, so it should. Still, scanning just goes on and on and on -
never associates.
So rather that showing it working with AP_SCAN=1 (since that has already
been explained - i set the ESSID manually) This is a clean (no help)
AP_SCAN=2 failing. Perhaps you'll be able to see something from this.
There are a few ioctl errors in there that I can't judge the severity of.
This is the wpa_supplicant.conf used:
-
ap_scan=1
network={
ssid=tmus_wrt
bssid=00:18:39:BF:EF:2B
scan_ssid=1
key_mgmt=WPA-PSK
proto=WPA2
group=CCMP
pairwise=CCMP
psk=rEmoVedfOrprIvacY
}
-
wpa_supplicant output:
-
Initializing interface 'wlan0' conf
'/etc/wpa_supplicant/wpa_supplicant.conf' driver 'wext' ctrl_interface
'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -
'/etc/wpa_supplicant/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group='wheel' (DEPRECATED)
ap_scan=2
Line: 11 - start of a new network block
ssid - hexdump_ascii(len=8):
74 6d 75 73 5f 77 72 74 tmus_wrt
BSSID - hexdump(len=6): 00 18 39 bf ef 2b
scan_ssid=1 (0x1)
key_mgmt: 0x2
proto: 0x2
group: 0x10
pairwise: 0x10
PSK (ASCII passphrase) - hexdump_ascii(len=16): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid='tmus_wrt'
Initializing interface (2) 'wlan0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
capabilities: key_mgmt 0xf enc 0xf
WEXT: Operstate: linkmode=1, operstate=5
Own MAC address: 00:13:e8:47:98:19
wpa_driver_wext_set_wpa
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - wpa_driver_wext_set_drop_unencrypted
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 5 value 0x1 - Setting scan request: 0 sec 10 usec
ctrl_interface_group=10 (from group name 'wheel')
Added interface wlan0
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b06 len=8
State: DISCONNECTED - SCANNING
Trying to associate with SSID 'tmus_wrt'
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
WPA: No WPA/RSN IE available from association info
WPA: Set cipher suites based on configuration
WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2
WPA: clearing AP WPA IE
WPA: clearing AP RSN IE
WPA: using GTK CCMP
WPA: using PTK CCMP
WPA: using KEY_MGMT WPA-PSK
WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04
01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 5 value 0x1 - State: SCANNING - ASSOCIATING
wpa_driver_wext_set_operstate: operstate 0-0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_associate
Setting authentication timeout: 60 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b1a len=16
RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b19 len=8
Received 730 bytes of scan results (3 BSSes)
Scan results: 3
Authentication with 00:00:00:00:00:00 timed out.
Added BSSID 00:00:00:00:00:00 into blacklist
State: ASSOCIATING -
Re: NM does not work with iwl4965 device
On 8/8/07, Thomas M Steenholdt [EMAIL PROTECTED] wrote: wpa_supplicant only - ap_scan=1: The hidden network is found during the scanning, but is never identified as my network, since wpa_supplicant expects a certain SSID and the hidden net shows an SSID of (SSID mismatch). The device SSID is never set. (as soon as I set the device SSID with iwconfig in this mode, wpa_supplicant makes the association happen) perhaps I am just being dull ... but is not the above exactly what should happen? From the perspective of NM, if an SSID is hidden, a user would need to supply it by choosing connect to other wireless network. Once the user types in the SSID, NM *should* pass that to wpa_supplicant, and then association should occur. Or, am I missing something? In my case ... since connect to other wireless network does not work, it appears that one of two things must be going wrong: 1)NM is not properly handing the SSID to wpa_supplicant (is failing to do what iwconfig does when you use it to set SSID), or 2)wpa_supplicant is not running in ap_scan=1 mode So ... either the hand-off is broken or the mode is wrong. (and the mode appears to be unsettable from the NM gui, which is another issue to my mind --- linux is about choice, right?) :-) Anyway ... we don't need wpa_supplicant to find the hidden SSID, do we? We just need it to succeed connecting, when we TELL it the SSID. Peter ps -- sorry if I am being obtuse, perhaps my sig line below applies? :-) -- Everything is vague to a degree you do not realize till you have tried to make it precise. Bertrand Russell www.the-brights.net ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Peter Van Lone wrote: 1)NM is not properly handing the SSID to wpa_supplicant (is failing to do what iwconfig does when you use it to set SSID), or 2)wpa_supplicant is not running in ap_scan=1 mode In the released version of NM, it uses AP_SCAN 2 for hidden networks and rely on that to work, which it just doesn't in this case. As to why we don't just use the AP_SCAN 1 workaround - AP_SCAN 2 works for other drivers, it should work for the iwl4965 people too. This is a problem of fixing things in the place that need fixing, not working around thing everywhere else. That said - the workaround is a temporary solution if you need it *now*. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On 8/8/07, Thomas M Steenholdt [EMAIL PROTECTED] wrote: As to why we don't just use the AP_SCAN 1 workaround - AP_SCAN 2 works for other drivers, it should work for the iwl4965 people too. This is a problem of fixing things in the place that need fixing, not working around thing everywhere else. That said - the workaround is a temporary solution if you need it *now*. ok, so the fix then is to correct the faulty behaviour of AP_SCAN mode 2 .. since I am not going to be helpful in that regard, I have a few more questions: my wireless driver is: IPW3945 Intel PRO/Wireless 3945ABG Network connection 1)is that one of the devices that is supposed to be effected (I am not familiar with iwl4965)? 2)Has setting the SSID using NM with the AP_SCAN mode at 1 (instead of using iwconfig to set the SSID) been tested and it works? 3)if simply changing the AP_SCAN mode to 1 will work, then how would one do this, and still use NetworkManager ... is it as simple as creating a wpa_supplicant.conf file and specifying that value? Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
Peter Van Lone wrote: my wireless driver is: IPW3945 Intel PRO/Wireless 3945ABG Network connection That's strange. I've been running with that device for ages with no problem at all. What's your distro/version etc.? 1)is that one of the devices that is supposed to be effected (I am not familiar with iwl4965)? I've only had the problem with the new Intel n-draft 4965 device 2)Has setting the SSID using NM with the AP_SCAN mode at 1 (instead of using iwconfig to set the SSID) been tested and it works? By me and yes - but it's a hack in the current state of affairs. 3)if simply changing the AP_SCAN mode to 1 will work, then how would one do this, and still use NetworkManager ... is it as simple as creating a wpa_supplicant.conf file and specifying that value? Nope - You'd have to apply my patch and rebuild the application as things are now. /Thomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not work with iwl4965 device
On 8/8/07, Thomas M Steenholdt [EMAIL PROTECTED] wrote: That's strange. I've been running with that device for ages with no problem at all. What's your distro/version etc.? SLED10 -- no sp1 yet By me and yes - but it's a hack in the current state of affairs. 3)if simply changing the AP_SCAN mode to 1 will work, then how would one do this, and still use NetworkManager ... is it as simple as creating a wpa_supplicant.conf file and specifying that value? Nope - You'd have to apply my patch and rebuild the application as things are now. bummer - I guess I'll wait p ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
