Sam Leffler wrote:
Eric Schuele wrote:
Sam Leffler wrote:
Eric Schuele wrote:
Sam Leffler wrote:
Eric Schuele wrote:
<big-snip>
dhclient.conf contains
===========================
interface "ath0" {
#send option host-name "myhost";
#send option domain-name "nxdomain.org";
send dhcp-client-identifier "myhost";
media
### Home
"ssid <home_ssid> mode 11b channel 11 wepmode on weptxkey 1
wepkey 0x<home_wepkey>",
### Office
"ssid <office_ssid mode 11b channel 6 wepmode on weptxkey 1
wepkey 0x<office_wepkey>";
request subnet-mask, broadcast-address, routers,
domain-name-servers, domain-name;
}
Do not use media statements to setup wireless parameters; this does
not work. You need to run wpa_supplicant and let it identify the
network and setup the key parameters.
How do I tell wpa_supplicant about the network media? I had found
an older post of yours regarding NOT doing it in dhclient.conf....
but I've found no other way to accomplish it.
The above dhclient.conf lists media settings that are all handled by
wpa_supplicant so you don't specify any of them. Specifically you
set ssid, band, channel, and wep parameters; all these are handled by
wpa_supplicant.
ok... I removed the lines from dhclient.conf. I reboot, and run
wpa_supplicant manually with -d. The output is attached. My AP shows
up as "", while my neighbors ssids are not hidden ('linksys' and
'default').
The intent is that dhclient deal only with the dhcp protocol and stop
being involved in the discovery and selection of wireless networks (a
job wpa_supplicant is better equipped to handle).
wpa_supplicant.conf
=============================
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
# Home Network
network={
ssid="<home_ssid>"
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0="<home_wepkey>"
}
# Office Network
network={
ssid="<office_ssid>"
scan_ssid=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0="<office_wepkey>"
}
Not sure you need scan_ssid set, I'd leave it out.
If you have problems try disabling auto-startup of ath0 and run
wpa_supplicant by hand with the -d flag to see what it's doing.
Once that's going then enable startup in rc.conf. If you continue
to have problems provide the output wpa_supplicant -d -i ath0 -c
/etc/wpa_supplicant.conf (or similar) when you have trouble. There is
also a pending issue with locating some ap's that are setup to hide
their ssid. If one of the ap's is configured in this way contact
me directly--I've been trying to collect the info I need to
identify what's going on.
Both my APs (home and office) hide their ssids. One is a wrt54g
(home), the other is linksys as well... though I forget the model at
the moment (FWIW its a/b/g). What can I do to provide the info you
need?
These should work; I've had reports of problems with certain Cisco
ap's. Note however that configuring an ap to hide it's ssid adds no
real security.
I realize hidden ssids are of no real world use... but they keep *my*
neighbors out (you'll notice their ssids in the wpa_supp output).
Actually you can do just as well using mac acl's to restrict access.
Yes... I restrict those as well.
Neither hidden ssid or mac acls are particularly useful except to keep
nuisance traffic out. Both can be trivially subverted; you need to go
to something like 802.1x or wpa for reasonable authentication of
stations (wpa-psk is inexpensive and easy to setup and is my preferred
method).
I'm on my way to wpa+... just wanted to confirm I had things working in
their previously operational configuration (WEP was all that was
available at the time).
Understand that hidden ssid use comes at a price. Normally a station
will scan by sending a "broadcast probe request" frame on a channel and
listen for responses from all ap's. When an ap hides its ssid the
station must send a "directed probe request" frame for each ap that it
might be looking for. If you've got lots of ap's on the wire and/or
lots of ap's you're searching for your scan will take more time and soak
more air time. Given that it's trivial to passively monitor a network
and collect the ssid for an ap you can see why I suggest it's better to
use a mac acl if your intent is just to keep out naive users.
Noted. Thanks.
Sam
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
Any idea why my machine will never associate with my AP using
wpa_supplicant? Anything else I can provide that may shed some light?
I am using WEP... not WPA... could that part of the problem. Since
WPA was not previously supported I had been using WEP... and figured
I'd move up to WPA one step at a time.
All help is appreciated.
<...stuff deleted...>
The problem is that the current wpa_supplicant scanning code is pretty
simplistic. wpa_supplicant is a great bit of work but was written for
the least-common denominator device. When scanning it does not (yet)
handle ap's using hidden ssid except by deferring the work to the
operating system. Unfortunately the current scanning code in the os
also is very simplistic. The end result is that wpa_supplicant can only
scan for 1 ap using a hidden ssid and when it does that it can't also
scan for ap's that don't hide their ssid (you get one or the other). To
do the right thing the api provided by the kernel must be changed. I've
got work that does that uncommitted but it's unlikely to go into 6.x
because it'll break internal ABI's and that's a no-no.
Bottom line is for the monent avoid using hidden ssid.
Ok. I'll avoid hidden ssids till future dates.
I'll see if I
can come up with an interim solution but it's unlikely to happen before
6.0 releases. Sorry.
No apologies necessary. I appreciate your responses, and all your work
towards the project as a whole.
Sam
--
Regards,
Eric
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
