Re: ath problem

Welp, seems I'm having a similar problem to what is descibed here. 
I'll give similar information.  I'm quite sure I was able to make my
card do hostap in the 5.3 days.

> >> I'm unable to get a wireless access point to work properly and for
> >> the life of me I can't work out why. I've spent the past few evenings
> >> trawling the mailing list archives without much success. I'm hoping
> >> someone can point me in the right direction.
> >> It's an Atheros 5212 (Wistron cm9 miniPCI) in a soekris 4801 box.
> >
> >
> > 5212 Wistron cm9 means nothing; dmesg|grep ath will get you the
> > mac+phy revs that identify your part.
>
> ap# dmesg| grep ath
> ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
> ath0: <Atheros 5212> mem 0xa0010000-0xa001ffff irq 11 at device 14.0 on
> pci0
> ath0: Ethernet address: 00:0b:6b:35:cb:82
> ath0: mac 5.9 phy 4.3 radio 3.6

ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
ath0: <Atheros 5211> mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
ath0: Ethernet address: 00:05:4e:42:8b:2d
ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3

> pciconf provides this information
> ath0_at_pci0:14:0: class=0x020000 card=0x1012185f chip=0x0013168c rev=0x01
> hdr=0x00
>     vendor   = 'Atheros Communications Inc.'
>     device   = 'AR5212, AR5213 802.11a/b/g Wireless Adapter'
>     class    = network
>     subclass = ethernet

 ath0_at_pci2:2:0:  class=0x020000 card=0x831017ab chip=0x0012168c
rev=0x01 hdr=0x00
    vendor   = 'Atheros Communications Inc.'
    device   = 'AR5211 802.11a/b/g Mini-PCI Wireless Adapter'
    class    = network
    subclass = ethernet

> >> A test client (WinXP SP2) can associate and on occasion obtains an
> >> address from the DHCP server on the ether side of the AP. Most of the
> >> time it is unable to obtain an address however, and even when it does
> >> after a few seconds it changes to the default not connected address
> >> of the 169.254/16 network.
> >> Initially I was trying to configure hostap for wpa+802.1x (EAP_TLS),
> >> the 802.1x worked fine and the XP laptop received its address, again
> >> after a few seconds the address would revert to the 169.254/16
> >> network. To try and identify the issue I switched to a simple wep
> >> mode (without hostap), but I have the same issue. The athstats tool
> >> reports a lot of failures.
> >> I haven't attached pages and pages of debug output as I'm not sure
> >> what would be required and don't want to flood the list. I have just
> >> attached a few of the basic things, but if more information is
> >> required I can obviously supply it.
> >> Thanks for your time
> >> andy
> >> btw - the same laptop works perfectly with an identical config
> >> (except the SSID is different) on second 'off the shelf' AP.
> >>
> >> ap# ifconfig ath0
> >> ath0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >>        inet6 fe80::20b:6bff:fe35:cb82%ath0 prefixlen 64 scopeid 0x4
> >>        inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255
> >>        ether 00:0b:6b:35:cb:82
> >>        media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
> >>        status: associated
> >>        ssid Z channel 9 bssid 00:0b:6b:35:cb:82
> >>        authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 53
> >>        protmode CTS dtimperiod 1 bintval 100
> >
> >
> > Run open and simplify your config until you figure out what's wrong.
> > Channels 1, 6, and 11 are usually the best for signal w/ 6 preferred.
> > Not sure why your ap is using 9.
>
> I set it to run on channel nine as at any given time I can see between
> seven and fifteen wireless networks, with on average half of them
> running on channel eleven. I run the 'off the shelf' ap I mentioned on
> channel six and as they're about two foot apart I thought picking an
> unused channel might be reasonable - incorrectly it seems.
>
> I have configured it as a completely open ap, and the problem is the same.
> The interface entry from my /etc/rc.conf is...
>     ifconfig_ath0="ssid Z mode 11g mediaopt hostap channel 6 up"

So then, I have a palmos client trying to connect as a client (using
autoscans to see if it is detected, though I have tried to set it up
manually as well) to my freebsd machine which is configured as
follows:

<root_at_uninfectable> [~] #ifconfig ath0 ssid Z mode 11b mediaopt hostap
channel 6 up
<root_at_uninfectable> [~] #ifconfig ath0
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:05:4e:42:8b:2d
        media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b <hostap>
        status: associated
        ssid Z channel 6 bssid 00:05:4e:42:8b:2d
        authmode OPEN privacy ON deftxkey UNDEF txpowmax 34 dtimperiod 1
        bintval 100

I've tried this with and without an IP with the same results. 
Everything in there looks right to me.  I'm using compiled-into-kernel
ath_hal, ath, and ath_rate_sample.

> > You don't indicate if the client is using 11g or 11b; based on the
> > statistics I'm guessing 11g.

For mine it is an 11b setup.

> > You probably need to setup a 3rd machine and sniff the traffic to see
> > what's going on.  Windows has some serious timing requirements in
> > their system and if you enable debugging on the ap you may slow things
> > down enough that the client will time out.
> >
> >     Sam
> >
> >>
> >> ap# sysctl net.link.ether.bridge
> >> net.link.ether.bridge_cfg: "ath0,sis0"
> >> net.link.ether.bridge_ipfw: 0
> >> net.link.ether.bridge_ipf: 0
> >> net.link.ether.bridge.config: "ath0,sis0"
> >> net.link.ether.bridge.enable: 1
> >> net.link.ether.bridge.predict: 0
> >> net.link.ether.bridge.dropped: 0
> >> net.link.ether.bridge.packets: 0
> >> net.link.ether.bridge.ipfw_collisions: 0
> >> net.link.ether.bridge.ipfw_drop: 0
> >> net.link.ether.bridge.copy: 0
> >> net.link.ether.bridge.ipfw: 0
> >> net.link.ether.bridge.ipf: 0
> >> net.link.ether.bridge.debug: 2
> >> net.link.ether.bridge.version: 031224
> >>
> >> ap# ./athstats
> >> 1666 tx management frames
> >> 5 tx frames discarded prior to association
> >> 996 tx failed 'cuz too many retries
> >> 11502 long on-chip tx retries
> >> 221 tx frames with no ack marked
> >> 204 tx frames with short preamble
> >> 57002 rx failed 'cuz of bad CRC
> >> 136258 rx failed 'cuz of PHY err
> >>    122418 OFDM timing
> >>    13840 CCK timing
> >> 28961 beacons transmitted
> >> 165 periodic calibrations
> >> 4 rfgain value change
> >> 4489 rate control checks
> >> 5 rate control dropped xmit rate
> >
> >
> > This is odd; are you using ath_rate_sample?  If there is noise causing
> > the rate control code to drop the tx rate then
> >
> >> rssi of last ack: 19
> >> avg recv rssi: 33
> >> 59 switched default/rx antenna
> >> Antenna profile:
> >> [1] tx      472 rx     3037
> >> [2] tx      414 rx       29

In case this is useful:
<root_at_uninfectable> [~] #athstats
48 tx management frames
28 tx frames discarded prior to association
8 tx failed 'cuz too many retries
96 long on-chip tx retries
17 tx frames with no ack marked
112 rx failed 'cuz of bad CRC
42334 beacons transmitted
139 periodic calibrations
rssi of last ack: 4
Antenna profile:
[0] tx       39 rx        0
[1] tx        0 rx      405

That's all the information I can think of.  I'm quite sure this used
to work with an ifconfig incantation (almost) exactly like that.  In
fact, I often copied and pasted the one from the man page and it
worked.  It seems that it doesn't now.  Is there some change that
occurred that I should be aware of and missed?

Thanks in advance for your time and expertise,

Eric Kjeldergaard

--
If I write a signature, my emails will appear more personalised.