From owner-freebsd-current@FreeBSD.ORG Sun Jul 24 19:37:07 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 E205516A41F for ; Sun, 24 Jul 2005 19:37:07 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3585443D48 for ; Sun, 24 Jul 2005 19:37:06 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j6OJav96098297; Sun, 24 Jul 2005 21:36:58 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Sam Leffler In-Reply-To: <42E30073.1080202@errno.com> References: <20050719094905.F15510@fledge.watson.org> <1121771151.764.42.camel@genius1.i.cz> <42DDD710.4030503@errno.com> <1121855884.796.8.camel@genius1.i.cz> <42DE648B.1060402@errno.com> <1121881805.929.38.camel@genius1.i.cz> <1121987685.61017.31.camel@genius1.i.cz> <42E30073.1080202@errno.com> Content-Type: text/plain Date: Sun, 24 Jul 2005 21:36:55 +0200 Message-Id: <1122233815.13679.3.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger 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: Sun, 24 Jul 2005 19:37:08 -0000 Sam Leffler wrote: > Michal Mertl wrote: > > I can confirm that the atheros based client really connects much worse > > than an IPW based one. When I restart the atheros AP, the ipw card > > connects immediately after the AP is back but the atheros client either > > never connects or it will take long time (I didn't wait long enough). It > > connects immediately after I issue ifconfig down/up on it. > > Once a station has failed to associate with an ap it marks it "bad" and > won't try again for a while. I need to bring in some improvements from > another tree that improve this area of the code; we wait too long to > re-enable going back to an ap. Marking the interface down-then-up > clears this state so you can immediately re-associate. The ipw firmware > does not use this code so it behaves differently. I see. This should't in reality be much of a problem anyway. > > > > More interesting finding that I have is about the bridging issue. I > > wasn't able to find which debug setting (via dev.ath.0.debug or > > net.wlan.0.debug) will show me any usefull information. Anyways it now > > seems to me that I was wrong saying that it works at all. The AP bridges > > the packets only when there is another IP communication between the AP > > host and one of the clients. It seems to me that the bridged packets are > > queued somewhere and sent only when there are some non bridged. > > I don't recall what "the bridging issue" was but use 80211debug and > athdebug to manipulate these sysctls using mnemonics--80211debug -? will > list the controls. Code is in tools/tools/ath. At some point these > tools probably should be integrated with another program and not stay > hidden in the tools directory I see, thank you. I hope I'll be able to submit better problem reports then. > . > > Test conditions - I have 192.168.1.1 on the AP, .2 on the IPW notebook > > and .3 on the atheros client. The settings of ath0 on AP are: "mode 11b > > mediaopt hostap channel 1 ssid test_ap_xx". The settings on clients are > > almost the same except there I don't issue any mediaopt. I hope I'm not > > doing anything extra stupid :-). The nodes are just several centimeters > > apart from each other and I only have tiny antennas. When the only IP > > communication is the ping from 192.168.1.2 to .3 (between the clients) I > > don't get any answer. When I ping at the same time from between any of > > the clients and the AP it works. When I let the first ping run for > > several seconds and then start the second one I get all the answers at > > the same time. > > I'm guessing this was the problem where frames bridged internal to the > net80211 layer were not dispatched immediately. If so we both know this > was fixed. Yes, it was. Thank you Michal