From owner-freebsd-questions@FreeBSD.ORG Tue Aug 2 04:10:00 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D33216A41F for ; Tue, 2 Aug 2005 04:10:00 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D169B43D45 for ; Tue, 2 Aug 2005 04:09:59 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [192.168.214.218] (c-24-1-232-64.hsd1.tx.comcast.net[24.1.232.64]) by comcast.net (rwcrmhc14) with ESMTP id <2005080204095801400h53c2e>; Tue, 2 Aug 2005 04:09:58 +0000 Message-ID: <42EEF215.8040206@computer.org> Date: Mon, 01 Aug 2005 23:09:57 -0500 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050721) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <42EAD325.60707@errno.com> <42EAD80C.9060707@errno.com> <42EBC41E.4070102@computer.org> <42EBC77F.1010601@errno.com> <42EBD3A0.5070407@computer.org> <42EBF80C.7030702@errno.com> <42EC4EE6.6070606@computer.org> <42EEE99D.6070806@errno.com> In-Reply-To: <42EEE99D.6070806@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions Subject: Re: dhclient and wpa_supplicant X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 04:10:00 -0000 Sam Leffler wrote: > Eric Schuele wrote: > >> Sam Leffler wrote: >> >>> Eric Schuele wrote: >>> >>>> Sam Leffler wrote: >>>> >>>>> Eric Schuele wrote: >>>>> >>>> >>>> >>>> >>>>>> dhclient.conf contains >>>>>> =========================== >>>>>> interface "ath0" { >>>>>> #send option host-name "myhost"; >>>>>> #send option domain-name "nxdomain.org"; >>>>>> send dhcp-client-identifier "myhost"; >>>>>> >>>>>> media >>>>>> ### Home >>>>>> "ssid mode 11b channel 11 wepmode on weptxkey 1 >>>>>> wepkey 0x", >>>>>> ### Office >>>>>> "ssid >>>>> wepkey 0x"; >>>>>> 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="" >>>>>> scan_ssid=1 >>>>>> key_mgmt=NONE >>>>>> wep_tx_keyidx=0 >>>>>> wep_key0="" >>>>>> } >>>>>> >>>>>> # Office Network >>>>>> network={ >>>>>> ssid="" >>>>>> scan_ssid=1 >>>>>> key_mgmt=NONE >>>>>> wep_tx_keyidx=0 >>>>>> wep_key0="" >>>>>> } >>>>>> >>>>> >>>>> 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 >>> "freebsd-questions-unsubscribe@freebsd.org" >>> >> >> 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