From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:02:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCEB16A41F for ; Sat, 17 Dec 2005 11:02:05 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6760143D5F for ; Sat, 17 Dec 2005 11:02:04 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so792919wra for ; Sat, 17 Dec 2005 03:02:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DKd3/0EpJWsKNS0mSI+ng60qGLpYz4tfk3Q7rSWm1F69eKNN+FoGM9253Cl3HfpbYA0N7Hx8bqSNtvr18vJOnZZHC1uECv6KUEd1aucjtx5KgNjALsc9sce3p3PviWXrSdfw6AqW/1okQM7b5xSYz46OYHdpqhonRYoNgv3UaFU= Received: by 10.64.10.15 with SMTP id 15mr480711qbj; Sat, 17 Dec 2005 03:02:03 -0800 (PST) Received: by 10.65.22.9 with HTTP; Sat, 17 Dec 2005 03:02:03 -0800 (PST) Message-ID: Date: Sat, 17 Dec 2005 20:02:03 +0900 From: Eric Kjeldergaard To: Andy Bontoft In-Reply-To: <42FCDD7B.6040307@bontoft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42F47354.6000109@bontoft.net> <42F56A66.9080607@errno.com> <42FCDD7B.6040307@bontoft.net> Cc: freebsd-current@freebsd.org Subject: Re: ath problem 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: Sat, 17 Dec 2005 11:02:05 -0000 Welp, seems I'm having a similar problem to what is descibed here.=20 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: 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: 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@pci0:14:0: class=3D0x020000 card=3D0x1012185f chip=3D0x0013168c rev= =3D0x01 > hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR5212, AR5213 802.11a/b/g Wireless Adapter' > class =3D network > subclass =3D ethernet ath0@pci2:2:0: class=3D0x020000 card=3D0x831017ab chip=3D0x0012168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5211 802.11a/b/g Mini-PCI Wireless Adapter' class =3D network subclass =3D 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=3D8847 mtu 1= 500 > >> 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 > >> status: associated > >> ssid Z channel 9 bssid 00:0b:6b:35:cb:82 > >> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 5= 3 > >> 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=3D"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: [~] #ifconfig ath0 ssid Z mode 11b mediaopt hostap channel 6 up [~] #ifconfig ath0 ath0: flags=3D8843 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 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.=20 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: [~] #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.