Date: Sun, 24 Jul 2005 21:36:55 +0200 From: Michal Mertl <mime@traveller.cz> To: Sam Leffler <sam@errno.com> Cc: freebsd-current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger Message-ID: <1122233815.13679.3.camel@genius1.i.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1122233815.13679.3.camel>