Date: Sat, 23 Jul 2005 19:44:03 -0700 From: Sam Leffler <sam@errno.com> To: Michal Mertl <mime@traveller.cz> Cc: freebsd-current@freebsd.org Subject: Re: Recent fragility with if_wi, 802.11 adhoc/wep, and Tiger Message-ID: <42E30073.1080202@errno.com> In-Reply-To: <1121987685.61017.31.camel@genius1.i.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Michal Mertl wrote: > Michal Mertl wrote: > >>Sam Leffler wrote: >> >>>Michal Mertl wrote: >>> >>>>I run an ath card in hostap mode and several wireless clients connect to >>>>it and are on the same IP network. The ping from one client to another >>>>is slow yet both ping the AP fine. I think that in this situation the >>>>bridging is done by ath (in HAL?) and configured by 'ifconfig apbridge'. >>> >>>The bridging is done in the net80211 layer, not "in the card". I will >>>test, thank you. >> >>Thanks for the correction. >> >>And thank you for looking into it. > > > Some new findings: > > 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. > > 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. > > 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. > > This is probably complete nonsense but I think that what I'm > experiencing looks as if the bridged packets weren't generating > interrupts or something. The frames were queued for transmit but the driver was never told to send them; hence the random delay. > > I've got serial consoles hooked to the machines and am able to sprinkle > some debug prints somewhere if required. > > > Michal > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42E30073.1080202>