From owner-freebsd-current@FreeBSD.ORG Wed Jul 27 05:21:52 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 3E01F16A41F for ; Wed, 27 Jul 2005 05:21:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FDF243D49 for ; Wed, 27 Jul 2005 05:21:51 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6R5Lpms070228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2005 22:21:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E71A11.2060706@errno.com> Date: Tue, 26 Jul 2005 22:22:25 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Mertl References: <1122322318.1042.12.camel@genius1.i.cz> <42E58A03.8010007@errno.com> <1122364309.31546.34.camel@genius1.i.cz> <42E664E6.6000606@errno.com> <1122397256.1067.15.camel@genius1.i.cz> In-Reply-To: <1122397256.1067.15.camel@genius1.i.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: hostap recently broken 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: Wed, 27 Jul 2005 05:21:52 -0000 Michal Mertl wrote: > Sam Leffler píše v út 26. 07. 2005 v 09:29 -0700: > >>Michal Mertl wrote: >> >>>Sam Leffler wrote: >>> >>> >>>>Michal Mertl wrote: >>>> >>>> >>>>>Hello, >>>>> >>>>>I've just found out that something very recently broke hostap on FreeBSD >>>>>CURRENT. The client associates and gets the MAC address of the AP. When >>>>>I run tcpdump on the AP I see the pings from the client getting in but >>>>>the AP doesn't reply. The ARP protocol works but nothing else does. >>>>> >>>>>Source checked on 2005-07-22 16:00 UTC works fine. >>>>> >>>>>The AP card is atheros but just reverting the last changes to the driver >>>>>doesn't help. >>>> >>>>I just tried with CURRENT (from last night). 5212 card setup with TKIP >>>>for PTK and GTK. ap operating in 11g. Powerbook running Tiger >>>>associated and operated fine. 29Mb/s for upstream tcp netperf (sta and >>>>ap in close proximity--rssi 41). >>>> >>>>I appreciate you testing stuff but please try to diagnose your problems >>>>a bit harder and then provide more useful info like the h/w revs and the >>>>exact steps you use to setup a non-working system. >>> >>> >>>Sorry, I had the exact same HW setup as before which I described in my >>>email about the problem with bridging. >>> >>>I've got several Atheros 5212 cards (mac 5.9 phy 4.3 radio 3.6) and also >>>IPW notebook all running CURRENT, the notebook and the client several >>>days old (from before 2005-07-22 16:00 UTC). >>> >>>The most basic setup - 'ifconfig ath0 192.168.0.1 mediaopt hostap ssid >>>aaa' on the AP and 'ifconfig ath0 192.168.0.2 ssid aaa' worked like a >>>charm before the date and not after. With the newer kernel on the AP the >>>cards associate and as I've just found I can communicate between the >>>stations on the AP. Ping to the AP doesn't work even when I get the MAC >>>address of the AP via ARP. Adhoc connection works. >> >>I am unclear still on what happens. I believe you are saying: >> >>ping 192.168.0.1 >> >>from the station to the ap fails. If so what does 80211stats show on >>the ap when this happens (do releveant error stats go up)? If you do > > > ./80211stats -a > 00:0b:6b:35:dc:d4: > rx_mgmt 1 > tx_data 107 tx_bytes 9788 > > 00:0b:6b:35:dc:f0: > rx_data 107 rx_mgmt 1 rx_bytes 10430 > tx_data 6 tx_mgmt 2 tx_bytes 36 > tx_assoc 1 tx_auth 1 Er, 80211stats (no -a) yields very different info that this. I should probably nuke the -a stuff after enhancing ifconfig ath0 list sta (or better move stuff elsewhere). > > > ./athstats > 8 tx management frames > 3 tx frames discarded prior to association > 93 tx failed 'cuz too many retries > 930 long on-chip tx retries > 1 tx frames with no ack marked > 8148 beacons transmitted > 27 periodic calibrations > 834 rate control checks > rssi of last ack: 48 > avg recv rssi: 49 > 1 switched default/rx antenna > Antenna profile: > [1] tx 8 rx 97 > [2] tx 1 rx 0 > > > These are shortly after reboot after several minutes of inactivity and > now ping running 150 sec. > > After some 20 secs: > > ./athstats > 8 tx management frames > 3 tx frames discarded prior to association > 181 tx failed 'cuz too many retries > 1810 long on-chip tx retries > 1 tx frames with no ack marked > 9021 beacons transmitted > 30 periodic calibrations > 923 rate control checks > rssi of last ack: 48 > avg recv rssi: 44 > 1 switched default/rx antenna > Antenna profile: > [1] tx 8 rx 185 > [2] tx 1 rx 0 > > ./80211stats -a > 00:0b:6b:35:dc:d4: > rx_mgmt 1 > tx_data 183 tx_bytes 16780 > > 00:0b:6b:35:dc:f0: > rx_data 183 rx_mgmt 1 rx_bytes 17878 > tx_data 6 tx_mgmt 2 tx_bytes 36 > tx_assoc 1 tx_auth 1 > > > >>80211debug +input > > > >>on the ap do you get any log msgs about discarded frames? > > > Nothing is displayed. > > >>You also seem to say the sta resolves the ip w/ arp. Is the same true >>for the ap (i.e. that it resolves the ip address of the sta)? I'm >>assuming you are NOT running firewall rules do not have crypto setup and >>have not fiddled with parameters like apbridge (you didn't provide >>ifconfig output for each side). > > > No, I set the cards only with the commands provided. There's no > firewall. > > AP: > > ath0: flags=8843 mtu 1500 > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:0b:6b:35:dc:d4 > media: IEEE 802.11 Wireless Ethernet autoselect > (autoselect ) > status: associated > ssid aaa channel 36 bssid 00:0b:6b:35:dc:d4 > authmode OPEN privacy OFF txpowmax 52 dtimperiod 1 bintval 100 > > > STA: > > ath0: flags=8843 mtu 1500 > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:0b:6b:35:dc:f0 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) > status: associated > ssid aaa channel 36 bssid 00:0b:6b:35:dc:d4 > authmode OPEN privacy OFF txpowmax 53 bintval 100 > > > >>I rarely test direct communication between sta+ap; usually I bridge to a >>wired net and communicate with stations on the wired net (it's always >>what I'm doing when I report netperf numbers). Does bridged >>communication to a sta on another network work? > > > I've just set up bridging on ath and wired ethernet and pinged a station > on it. This works. > > I changed the IP addresses and did 'sysctl > net.link.ether.bridge.config="ath0 fxp0"' and 'sysctl > net.link.ether.bridge.enable=1'. > > ifconfig of the AP: > > fxp0: flags=8943 mtu > 1500 > options=b > inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 > ether 00:0e:0c:68:71:6a > media: Ethernet autoselect (100baseTX) > status: active > ath0: flags=8943 mtu > 1500 > ether 00:0b:6b:35:dc:d4 > media: IEEE 802.11 Wireless Ethernet autoselect > (autoselect ) > status: associated > ssid aaa channel 36 bssid 00:0b:6b:35:dc:d4 > authmode OPEN privacy OFF txpowmax 52 dtimperiod 1 bintval 100 > > I still can't ping 10.0.0.1 from the STA (which is now 10.0.0.3). > > > Thank you for your help. I won't be able to continue testing for several > hours, sorry. > > The ath cards I have have two antenna connectors. Does it matter which > one I use? I see that sysctl dev.ath shows different txantenna than > rxantenna but I only have one antenna connected (and don't really know > what is the number of the connector). It shouldn't matter as these cards do fast diversity and the driver+hw will lock to the tx antenna that's working best. There are some hacks in xmit'ing beacons to spray frames which may work better with two antennae hooked up; not sure. If you want to futz with things there are sysctl's to force the tx/rx antenna (can't recall which or both). Sam