Re: ath(4) driver problems with WEP...

> I've got a Netgear WAG511 (Atheros 5212-based card) and a Netgear FWAG114
> wireless router.
> 
> I've been trying to get the card and the router talking under FreeBSD.
> (Both 802.11a and 802.11g work fine under Windows on the same machine.)
> 
> I'm using -current from September 15th.
> 
> Anyway, whenever I try to get the card talking to the router, which is
> running WEP (128 bit keys) on both the a and b/g sides, I get:
> 
> ath0: authentication failed (reason 13) for [ base station MAC address ]
> ath0: authentication failed (reason 13) for [ base station MAC address ]
> ath0: authentication failed (reason 13) for [ base station MAC address ]
> ath0: authentication failed (reason 13) for [ base station MAC address ]
> ath0: authentication failed (reason 13) for [ base station MAC address ]
> 
> Here's what the ifconfig looks like:
> 
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         ether [ card mac address ]
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11a
> (OFDM/6Mbps)         status: no carrier
>         ssid [my ssid] 1:[my ssid]
>         channel -1 authmode OPEN powersavemode OFF powersavesleep 100
>         wepmode MIXED weptxkey 1
>         wepkey 1:128-bit wepkey 2:128-bit wepkey 3:128-bit wepkey
> 4:128-bit
> 
> I've verified and re-verified, via cut-and-paste from the router setup
> screen, that the WEP key is correct.
> 

Good news+bad news.  I just committed a fix to ifconfig to correctly handle
128-bit WEP keys.  I'm not sure how you thought you were setting your key
up but ifconfig was barfing on anything more than 104 bits.  FWIW ifconfig
wrongly indicated keys >5 bytes (40 bits) were 128-bit keys; I also fixed
that so ifconfig now indicates keys are 40-, 104-, or 128-bit according to
their length.  Beware also that wicontrol displays WEP keys longer than 104
bits zero-padded; I believe this is because of limitations in the RID API
for fetching keys.  Someone else may want to investigate that issue.

The bad news is that with 128-bit keys installed I'm getting decryption
errors at the AP.  Actually, I'm seeing errors for any length key so it's
likely a botch in the WEP frame construction in the driver.  I've run out
of time to look at this right now and will have to investigate later.

> Anyway, I can't get the ath(4) driver to talk to the router when it is
> running WEP.  I have been able to get it to talk 802.11g to the router
> without WEP enabled, though.
> 
> I tried setting the authmode to shared via ifconfig, but from looking at
> ieee80211_ioctl.c:
> 
># if 0
> 		case IEEE80211_IOC_AUTHMODE:
> 			sc->wi_authmode = ireq->i_val;
> 			break;
># endif
> 
> i.e. I get EINVAL back.
> 
> Is WEP supposed to work in -current?
> 

authmode is not relevant.  WEP worked at one time; I seem to have broken
it.  As I said above I will have to look at it later.

> In a separate issue, the ath(4) driver can't see the 802.11a side of the
> wireless router at all when it is running in 108Mbps "turbo" mode.  If I
> drop it down to 54Mbps, it sees it.  (Works fine in Windows.)
> 
> Is the ath(4) driver supposed to support the 108Mbps turbo mode?

I was able to associate with an Atheros AP with turbo mode enabled but
didn't get any higher throughput.  I'm investigating this.

FWIW I enabled turbo mode with:

ifconfig ath0 mediaopt turbo

I verified turbo mode was in use by disabling it on either station or AP
side and with things mismatched the station/AP couldn't see each other.
With turbo mode enabled on each side I was able to associate and
communicate as normal; but netperf throughput was identical to the
non-turbo setup.  I'm asking Atheros folks for clarification on this--I may
need to do some additional setup work to enable turbo operation.  This is
actually the first time I've tried turbo mode...

	Sam