Re: ath vap - second hostap _almost_ works

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):
> >
<snip>
> > 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.

<snip>

> 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