From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 16:45:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33F231065676; Tue, 22 Jul 2008 16:45:17 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 1208D8FC19; Tue, 22 Jul 2008 16:45:16 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [172.17.2.20] (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6MGWXJP071467; Tue, 22 Jul 2008 12:32:34 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Tue, 22 Jul 2008 12:32:29 -0400 User-Agent: KMail/1.9.7 References: <200807221048.48729.lists@jnielsen.net> <4885FD12.1090408@freebsd.org> In-Reply-To: <4885FD12.1090408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221232.29323.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Sam Leffler Subject: Re: ath vap - second hostap _almost_ works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 16:45:17 -0000 On Tuesday 22 July 2008 11:30:26 am Sam Leffler wrote: > John Nielsen wrote: > > I'm trying to set up a second access point for an "insecure" network. > > I am able to create and configure the wlan1 interface and clients can > > see the SSID and associate to the network. However the access point > > is unable to send traffic over the interface (the 103 network below): > > > > stealth# egrep "ath|wlan" /etc/rc.conf | grep -v "^#" > > wlans_ath0="wlan0 wlan1" > > create_args_wlan0="wlanmode hostap" > > create_args_wlan1="wlanmode hostap wlanaddr 10:0d:88:a6:61:a8" > > FWIW, it's better to just use "wlanmode hostap bssid" to get a unique > address. Thanks. That's cleaner but no functional difference (as expected). > > ifconfig_wlan0="inet 192.168.3.10 netmask 255.255.255.0 ssid sixten > > wepmode on deftxkey 1 wepkey 1:0x[26 digit hex key]" > > ifconfig_wlan1="inet 192.168.103.1 netmask 255.255.255.0 ssid > > freewifi wepmode off" > > What happens if you disable WEP use? Same result. The wlan0 network is able to send/receive traffic, the wlan1 one is able to receive only. > I'll need to setup this config as I don't think I've ever tested one > like it (my vap's are typically bridged and don't terminate on the > wireless host). I played w/ bridging when I first set this up but decided to go this way to avoid broadcast issues, link speed and MTU differences, etc. And in the case of the insecure wireless network the whole point is to keep it separate from other segments. :) > You might check wlanstats of each vap to see if > packets are being tossed. Nothing stands out to me but this is the first time I've run it: %wlanstats 1 rx from wrong bssid 8 rx discard 'cuz dup 6 rx w/ wrong direction 6 rx ctrl frames 1791 rx beacon frames 2905 rx element unknown 130 rx frame ssid mismatch 1 rx deauthentication 1 active scans started 6 ps-poll received with nothing to send 1971 rx management frames 272 total data frames transmit 272 multicast data frames sent 0M current transmit rate > Otherwise you'll need to look at a lower > level to find where the packets are being lost; e.g. use tcpdump -y > IEEE802_11 on the wlan devices to see if the missing frames are being > dispatched from the ath driver. I never knew how chatty my neighbors' access points were! :) Again though I see the DHCP requests from the client but no replies. I don't know enough about the protocol stack to do much theorizing, but I'm not convinced that the packets are going far enough down the stack to even hit the hardware. What I'm seeing looks exactly like what I see on an OpenVPN TAP interface when the interface is up but the VPN link is down. Anyone have any ideas on how I could dig in to this further? > If you can't find the reason please file a PR w/ the details you've > provided. I'll do that. Thanks! JN