ok, part 1, starting with a new and freshly-updated F7 install on a gateway MX7120, here's the current situation without doing *anything* additional, and what someone might want to check just for sanity.
from /var/log/dmesg: ... bcm43xx-phy0: Broadcom 4318 WLAN found ssb: Switching to IEEE 802.11 core, index 1 bcm43xx-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 bcm43xx-phy0 debug: Radio turned off ...
# ls /lib/firmware/ ipw2100-1.3.fw ipw2200-sniffer.fw ipw-2.4-ibss_ucode.fw LICENSE.ipw2200 ipw2100-1.3-i.fw ipw-2.4-boot.fw ipw-2.4-sniffer.fw zd1211 ipw2100-1.3-p.fw ipw-2.4-bss.fw ipw-2.4-sniffer_ucode.fw ipw2200-bss.fw ipw-2.4-bss_ucode.fw iwlwifi-3945.ucode ipw2200-ibss.fw ipw-2.4-ibss.fw LICENSE.ipw2100
# iwconfig lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11g ESSID:"" Mode:Managed Channel:0 Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
# lsmod ... bcm43xx_mac80211 400289 0 firewire_ohci 20673 0 snd_pcm 74949 4 snd_atiixp,snd_atiixp_modem,snd_ac97_codec,snd_pcm_oss firewire_core 43137 1 firewire_ohci ssb 34757 1 bcm43xx_mac80211 mac80211 147017 2 rc80211_simple,bcm43xx_mac80211 ...
is there anything else that would be worth examining and recording before going any further? i like making a record of stuff like this so i can compare what changes.
rday
Somebody in the thread at some point said:
is there anything else that would be worth examining and recording before going any further? i like making a record of stuff like this so i can compare what changes.
If you're on WPA, you might also be interested to capture the default
/etc/wpa_supplicant/wpa_supplicant.conf /etc/sysconfig/wpa_supplicant
The sysconfig one is particularly insane by default.
-Andy
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
is there anything else that would be worth examining and recording before going any further? i like making a record of stuff like this so i can compare what changes.
If you're on WPA, you might also be interested to capture the default
/etc/wpa_supplicant/wpa_supplicant.conf /etc/sysconfig/wpa_supplicant
The sysconfig one is particularly insane by default.
ah, good point. i'm just going with WEP for now but i'll make a side note of that.
and onward, i've just installed the "bcm43xx-fwcutter" package, and i'm downloading the firmware from http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 which is what is listed as the appropriate content for F7.
so far, so good? i just want to verify that that's the right firmware file before going any further. i'm paranoid that way. :-)
rday
Somebody in the thread at some point said:
so far, so good? i just want to verify that that's the right firmware file before going any further. i'm paranoid that way. :-)
I'm sorry I don't have that device, I don't know. But it is the case that "firmware" is a bit of a misnomer for the wireless devices I have met, in fact this file is getting loaded into SRAM on the device, not flash or anything. So any problems caused by the wrong firmware should not live through a powerdown of the device.
WEP is completely unsafe though, aircrack and related tools can crack it with relative ease. Unless you live in the wilderness WPA is a necessity (and I use ssh tunnels for everything, including all web traffic proxied through one, inside that in addition).
-Andy
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
so far, so good? i just want to verify that that's the right firmware file before going any further. i'm paranoid that way. :-)
I'm sorry I don't have that device, I don't know. But it is the case that "firmware" is a bit of a misnomer for the wireless devices I have met, in fact this file is getting loaded into SRAM on the device, not flash or anything. So any problems caused by the wrong firmware should not live through a powerdown of the device.
agreed.
WEP is completely unsafe though, aircrack and related tools can crack it with relative ease. Unless you live in the wilderness WPA is a necessity (and I use ssh tunnels for everything, including all web traffic proxied through one, inside that in addition).
i agree. but, for the moment, i'm actually going to try to get wireless working with no encryption whatsoever, just to make sure that *that's* not the problem. just trying to minimize the number of potential issues.
rday
WEP is completely unsafe though, aircrack and related tools can crack it with relative ease. Unless you live in the wilderness WPA is a necessity (and I use ssh tunnels for everything, including all web traffic proxied through one, inside that in addition).
If you are worried about security then run an ipsec or similar encrypted tunnel and don't bother with WEP or WPA or anything but the tunnel. That way and card works and the management is much easier
Somebody in the thread at some point said:
WEP is completely unsafe though, aircrack and related tools can crack it with relative ease. Unless you live in the wilderness WPA is a necessity (and I use ssh tunnels for everything, including all web traffic proxied through one, inside that in addition).
If you are worried about security then run an ipsec or similar encrypted tunnel and don't bother with WEP or WPA or anything but the tunnel. That way and card works and the management is much easier
It's a little bit more complicated than that here -- I am not the only user of the wireless network. The rest of the family don't want the hassle of dealing with ssh-agent passphrases every boot, so the WPA over everything still gives them one layer of privacy. I also have embedded devices that can be on the WPA network but can't handle ipsec.
WPA recently had another unexpected use... due to "unauthorized bittorrent usage" a certain teenage client needed to drop off the Internet for a while to ponder his misdeeds, changing the AP WPA key and updating the rest of the boxes' /etc/wpa_supplicant/wpa_supplicant.conf was a neat solution that didn't have a workaround.
-Andy
On Thu, 2007-08-02 at 11:07 +0100, Andy Green wrote:
Somebody in the thread at some point said:
so far, so good? i just want to verify that that's the right firmware file before going any further. i'm paranoid that way. :-)
I'm sorry I don't have that device, I don't know. But it is the case that "firmware" is a bit of a misnomer for the wireless devices I have met, in fact this file is getting loaded into SRAM on the device, not flash or anything. So any problems caused by the wrong firmware should not live through a powerdown of the device.
WEP is completely unsafe though, aircrack and related tools can crack it with relative ease. Unless you live in the wilderness WPA is a necessity (and I use ssh tunnmenteels for everything, including all web traffic proxied through one, inside that in addition).
-Andy
This seems my day to be difficult. This statement that WEP is easy to crack must be taken with a grain of salt. One has to visualize crackers driving down my street and cracking my WEP passphrase or strange people , probably with speakers in their ears and raincoats, wandering through the office. It could happen but on my street which goes nowhere they would stand out.
Although, if they want to do that let them. My communication with other machines is all encrypted (e.g, mail is ssl encrypted) so I am not sure what they would find out. -- ======================================================================= A violent man will die a violent death. -- Lao Tsu ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Somebody in the thread at some point said:
This seems my day to be difficult. This statement that WEP is easy to crack must be taken with a grain of salt. One has to visualize crackers driving down my street and cracking my WEP passphrase or strange people , probably with speakers in their ears and raincoats, wandering through the office. It could happen but on my street which goes nowhere they would stand out.
"WEP the protocol" is definitely unsafe. They even have a game where they keep prodding the access point to send something to give them more grist for the cracking mill.
Your personal WEP network is only crackable by people physically close to you, obviously, which cuts down the probability of attack hugely compared to an internet connected device, for example.
Although, if they want to do that let them. My communication with other machines is all encrypted (e.g, mail is ssl encrypted) so I am not sure what they would find out.
They could find out what machines you are talking to if it isn't inside an encrypted tunnel. Depending on who is looking and why that could be bad. If it's just that you mostly use SSL sites, don't forget that there can be serious information leakage through Google query URLs that are standard http, depending on what you use it for.
Anyway the chances anyone around you personally is interested in cracking your WEP key is quite low as you suggest, but the thing itself is quite easily cracked if anyone close enough wants to.
-Andy
Aaron Konstam:
This statement that WEP is easy to crack must be taken with a grain of salt. One has to visualize crackers driving down my street and cracking my WEP passphrase or strange people , probably with speakers in their ears and raincoats, wandering through the office. It could happen but on my street which goes nowhere they would stand out.
Although, if they want to do that let them. My communication with other machines is all encrypted (e.g, mail is ssl encrypted) so I am not sure what they would find out.
I think there's been enough proofs on the net that it is easy to crack, in itself. Yes, the chances of it happening if you're not in the thick of things is slimmer, but don't forget that someone trying to steal free net (or do illegal things through someone else's internet) can do so at a distance with a good enough antenna. They don't do it just to see what you're up to, they mightn't even care, they're more interested in connected to the internet.
Depending on how you did you mail, it may only be the password authentication that's encrypted, the message content may be sent in the clear. That can be a concern for some people.
On Sat, 2007-08-04 at 02:33 +0930, Tim wrote:
Aaron Konstam:
This statement that WEP is easy to crack must be taken with a grain of salt. One has to visualize crackers driving down my street and cracking my WEP passphrase or strange people , probably with speakers in their ears and raincoats, wandering through the office. It could happen but on my street which goes nowhere they would stand out.
Although, if they want to do that let them. My communication with other machines is all encrypted (e.g, mail is ssl encrypted) so I am not sure what they would find out.
I think there's been enough proofs on the net that it is easy to crack, in itself. Yes, the chances of it happening if you're not in the thick of things is slimmer, but don't forget that someone trying to steal free net (or do illegal things through someone else's internet) can do so at a distance with a good enough antenna. They don't do it just to see what you're up to, they mightn't even care, they're more interested in connected to the internet.
At home that is AT&T's problem not mine. At work since anyone with a wireless card can connect to the system again it is not really my problem. And I can only use security methods that they support.
Depending on how you did you mail, it may only be the password authentication that's encrypted, the message content may be sent in the clear. That can be a concern for some people.
No all of my e-mail is encrypted.
-- ======================================================================= "I'd love to go out with you, but I want to spend more time with my blender." ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Tim:
I think there's been enough proofs on the net that it is easy to crack, in itself. Yes, the chances of it happening if you're not in the thick of things is slimmer, but don't forget that someone trying to steal free net (or do illegal things through someone else's internet) can do so at a distance with a good enough antenna.
Aaron Konstam:
At home that is AT&T's problem not mine.
Hmm, I wouldn't like to get into legal wrangles if someone else did something nefarious through *your* connection. But leaving aside that, does your internet have limits (bandwidth limiting, monthly download allowances), or extra costs for downloading more than a certain amount? If so, that's another reason to guard your network.
On Sat, 2007-08-04 at 16:10 +0930, Tim wrote:
Tim:
I think there's been enough proofs on the net that it is easy to crack, in itself. Yes, the chances of it happening if you're not
in
the thick of things is slimmer, but don't forget that someone
trying
to steal free net (or do illegal things through someone else's internet) can do so at a distance with a good enough antenna.
Aaron Konstam:
At home that is AT&T's problem not mine.
Hmm, I wouldn't like to get into legal wrangles if someone else did something nefarious through *your* connection. But leaving aside that, does your internet have limits (bandwidth limiting, monthly download allowances), or extra costs for downloading more than a certain amount? If so, that's another reason to guard your network.
Of course you are correct and I was just being difficult for no reason. Well there is a slight reason. I get bothered when people overplay the security card. The rule is that the strength of the lock on a safe should be proportional to to the value of what is inside.
-- ======================================================================= It's not enough to be Hungarian; you must have talent too. -- Alexander Korda ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
and, moving on, here's what appears to be the final(?) steps in the recipe (from http://forums.fedoraforum.org/forum/showthread.php?t=156282):
# bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist # modprobe -r bcm43xx # modprobe -r ieee80211softmac # modprobe -r ieee80211_crypt # modprobe -r ieee80211 # modprobe -r bcm43xx_mac80211 # modprobe bcm43xx_mac80211
"Then I plugged along and enabled NetworkManager and NetworkManagerDispatcher"
does all of that sound sane? if so, i'll give it a shot.
rday
Somebody in the thread at some point said:
and, moving on, here's what appears to be the final(?) steps in the recipe (from http://forums.fedoraforum.org/forum/showthread.php?t=156282):
# bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist # modprobe -r bcm43xx # modprobe -r ieee80211softmac # modprobe -r ieee80211_crypt # modprobe -r ieee80211 # modprobe -r bcm43xx_mac80211 # modprobe bcm43xx_mac80211
"Then I plugged along and enabled NetworkManager and NetworkManagerDispatcher"
does all of that sound sane? if so, i'll give it a shot.
Since both the old ieee80211 stack driver and the new mac80211-based one both want to own the same device ID at the moment, your workaround sounds very needed.
I was never able to get Network Manager to work with my WPA network past scanning for APs, maybe it can work okay with no encryption though.
-Andy
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
and, moving on, here's what appears to be the final(?) steps in the recipe (from http://forums.fedoraforum.org/forum/showthread.php?t=156282):
# bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist # modprobe -r bcm43xx # modprobe -r ieee80211softmac # modprobe -r ieee80211_crypt # modprobe -r ieee80211 # modprobe -r bcm43xx_mac80211 # modprobe bcm43xx_mac80211
"Then I plugged along and enabled NetworkManager and NetworkManagerDispatcher"
does all of that sound sane? if so, i'll give it a shot.
Since both the old ieee80211 stack driver and the new mac80211-based one both want to own the same device ID at the moment, your workaround sounds very needed.
the workaround of the blacklisting, is that what you meant? and i just reproduced the above from the URL above, so it's not really *my* workaround, i just wanted a few more eyeballs to see if anything looked out of whack. ok, time to give it a shot.
rday
the final configuration -- after messing with "modprobe" and blacklisting the bcm43xx module, i started the NetworkManager and NetworkManagerDispatch services and rebooted, to see this (eth0 is the wired interface, of course):
# ifconfig eth0 Link encap:Ethernet HWaddr 00:03:25:35:4D:61 inet addr:192.168.1.114 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::203:25ff:fe35:4d61/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:157 errors:0 dropped:0 overruns:0 frame:0 TX packets:209 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15177 (14.8 KiB) TX bytes:38644 (37.7 KiB) Interrupt:20
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:11273 errors:0 dropped:0 overruns:0 frame:0 TX packets:11273 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:88407696 (84.3 MiB) TX bytes:88407696 (84.3 MiB)
wlan0 Link encap:Ethernet HWaddr 00:14:A5:5C:CA:D0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wmaster0 Link encap:UNSPEC HWaddr 00-14-A5-5C-CA-D0-08-1F-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
# iwconfig lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11g ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
sit0 no wireless extensions.
# iwlist wlan0 scan ... i can see! i can see! ...
does this look reasonable? at this point, i assume i would go into network admin and configure wlan0 for the SSID, channel and so on, yes?
rday
Somebody in the thread at some point said:
# iwlist wlan0 scan ... i can see! i can see! ...
does this look reasonable? at this point, i assume i would go into
Yes it looks fine, but you are not associated to any AP. This is the wired ethernet equivalent of not having a cable plugged in. You can try to force association by hand if you like
iwconfig wlan0 ap 11:22:33:44:55:66 <--- AP MAC
or go on with your plan to do the same thing the official way...
network admin and configure wlan0 for the SSID, channel and so on, yes?
Well, give system-config-network a try, I have had variable luck with that recognizing the wireless interface as well. This is why I am focused on doing it all on the commandline.
-Andy
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
# iwlist wlan0 scan ... i can see! i can see! ...
does this look reasonable? at this point, i assume i would go into
Yes it looks fine, but you are not associated to any AP. This is the wired ethernet equivalent of not having a cable plugged in. You can try to force association by hand if you like
iwconfig wlan0 ap 11:22:33:44:55:66 <--- AP MAC
or go on with your plan to do the same thing the official way...
well, it's not surprising that i'm not associated with any AP, since i haven't done anything to finish that part of the process. my plan was, as i mentioned, to just use the GUI menu entry for network admin -- i didn't realize i could also use iwconfig as above to do the same thing.
but other than that, things are looking good.
rday
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
# iwlist wlan0 scan ... i can see! i can see! ...
does this look reasonable? at this point, i assume i would go into
Yes it looks fine, but you are not associated to any AP. This is the wired ethernet equivalent of not having a cable plugged in. You can try to force association by hand if you like
iwconfig wlan0 ap 11:22:33:44:55:66 <--- AP MAC
or go on with your plan to do the same thing the official way...
network admin and configure wlan0 for the SSID, channel and so on, yes?
Well, give system-config-network a try, I have had variable luck with that recognizing the wireless interface as well. This is why I am focused on doing it all on the commandline.
i think i see your point. even after all the previous output looked good, when i ran system-config-network to configure the wireless interface, i tried to add a new wireless connection, and all i got for a choice of wireless card was "other wireless card." i was assuming i would at least get presented with the wireless interface that was in the laptop.
and in that drop-down list of choices, the only broadcom chip was "Tigon3" which i'm guessing is not the right choice. but, really, i was hoping that the config utility would see the chip. was i being hopelessly optimistic and naive?
rday
Somebody in the thread at some point said:
and in that drop-down list of choices, the only broadcom chip was "Tigon3" which i'm guessing is not the right choice. but, really, i was hoping that the config utility would see the chip. was i being hopelessly optimistic and naive?
IIRC system-config-network "New" buttons and the like are modal based on which tab you are on (sigh)... I think you want to be on the "Devices" tab and click New, it does something different than if you are on the Hardware tab and click the same New button on the top toolbar.
-Andy
On Thu, 2 Aug 2007, Andy Green wrote:
Somebody in the thread at some point said:
and in that drop-down list of choices, the only broadcom chip was "Tigon3" which i'm guessing is not the right choice. but, really, i was hoping that the config utility would see the chip. was i being hopelessly optimistic and naive?
IIRC system-config-network "New" buttons and the like are modal based on which tab you are on (sigh)... I think you want to be on the "Devices" tab and click New, it does something different than if you are on the Hardware tab and click the same New button on the top toolbar.
i already noticed and tried that, but i got the same drop-down list. so i think i'll just go with iwconfig on the command line. anyway, must dash, more later. thanks for all the advice.
rday
p.s. if anyone wants to chime in about whether i should be able to do the above thru system-config-network, i'm all ears.
On Thu, Aug 02, 2007 at 11:52:57AM +0100, Andy Green wrote:
Somebody in the thread at some point said:
and, moving on, here's what appears to be the final(?) steps in the recipe (from http://forums.fedoraforum.org/forum/showthread.php?t=156282):
# bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist # modprobe -r bcm43xx # modprobe -r ieee80211softmac # modprobe -r ieee80211_crypt # modprobe -r ieee80211 # modprobe -r bcm43xx_mac80211 # modprobe bcm43xx_mac80211
"Then I plugged along and enabled NetworkManager and NetworkManagerDispatcher"
does all of that sound sane? if so, i'll give it a shot.
Since both the old ieee80211 stack driver and the new mac80211-based one both want to own the same device ID at the moment, your workaround sounds very needed.
The Fedora kernels carry a patch to geld the PCI ID table of the bcm43xx driver. So, all that modprobing and blacklisting should be unnecessary.
John
On Thu, 2 Aug 2007, John W. Linville wrote:
On Thu, Aug 02, 2007 at 11:52:57AM +0100, Andy Green wrote:
Somebody in the thread at some point said:
and, moving on, here's what appears to be the final(?) steps in the recipe (from http://forums.fedoraforum.org/forum/showthread.php?t=156282):
# bcm43xx-fwcutter -w /lib/firmware ~fedora/wl_apsta.o # echo 'blacklist bcm43xx' >> /etc/modprobe.d/blacklist # modprobe -r bcm43xx # modprobe -r ieee80211softmac # modprobe -r ieee80211_crypt # modprobe -r ieee80211 # modprobe -r bcm43xx_mac80211 # modprobe bcm43xx_mac80211
"Then I plugged along and enabled NetworkManager and NetworkManagerDispatcher"
does all of that sound sane? if so, i'll give it a shot.
Since both the old ieee80211 stack driver and the new mac80211-based one both want to own the same device ID at the moment, your workaround sounds very needed.
The Fedora kernels carry a patch to geld the PCI ID table of the bcm43xx driver. So, all that modprobing and blacklisting should be unnecessary.
but i don't always use fedora kernels, i frequently use the latest source and roll my own, so i'm assuming i should still use the above in those cases, right?
and will that fedora patch eventually be pushed upstream?
rday
On Thu, Aug 02, 2007 at 12:17:52PM -0400, Robert P. J. Day wrote:
On Thu, 2 Aug 2007, John W. Linville wrote:
The Fedora kernels carry a patch to geld the PCI ID table of the bcm43xx driver. So, all that modprobing and blacklisting should be unnecessary.
but i don't always use fedora kernels, i frequently use the latest source and roll my own, so i'm assuming i should still use the above in those cases, right?
I suppose so.
and will that fedora patch eventually be pushed upstream?
Not as-is, no. The future disposition of conflicts between the bcm43xx and bcm43xx-mac80211 drivers is still unresolved. FWIW, the bcm43xx-mac80211 driver is still not in mainline kernels.
John
On Thu, 2007-08-02 at 09:49 +0100, Andy Green wrote:
Somebody in the thread at some point said:
is there anything else that would be worth examining and recording before going any further? i like making a record of stuff like this so i can compare what changes.
If you're on WPA, you might also be interested to capture the default
/etc/wpa_supplicant/wpa_supplicant.conf /etc/sysconfig/wpa_supplicant
The sysconfig one is particularly insane by default.
-Andy
Let me share something that most people miss. If you are using NM just left click on the nm-applet and choose an option : Comnnect to Other Wireless Network You will be given a gui window which alllow you to choose a series of authentication methods that most people never see.
-
Aaron Konstam -
Alan Cox -
Andy Green -
John W. Linville -
Robert P. J. Day -
Tim