Re: 11n in adhoc mode
Hm, you may be right; but I disabled HT protection entirely and stuck it on a very quiet channel. It's possible both ends were colliding with each other though. I did add some HT update code to the adhoc beacon processing, though. It's just not entirely clear how to handle that given the nature of IBSS - ie, every peer may have some different idea of what the protection mode is. It's possible that it should be learnt once when you join the BSS, much like how the adhoc scan pick code checks for a few things matching before it joins that BSS. Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: 11n in adhoc mode
> -- > > Message: 1 > Date: Tue, 11 Dec 2012 01:19:51 -0800 > From: Adrian Chadd > To: Johann Hugo > Cc: freebsd-wireless@freebsd.org > Subject: Re: 11n in adhoc mode > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > .. so now I have 11n IBSS working, but the performance is pretty > shocking. I bet there's some timers that are just not programmed > correctly. > I see massive numbers of long retries and CRC errors. Are protection modes set correctly on both ends? This happens when each end uses different prot mode. > * Then some ancillary stuff - mostly processing beacon frames from > peers and handling HT IE changes correctly. Because this is an adhoc mode issue, this may not apply. But, this is what I have been seeing. Yet another ancillary stuff. Currently, protection mode is updated though ieee80211_htprot_update() (finally iv_update_beacon() is called), and it is called only in hostap mode. When occupancy changes, an ap updates beacon and tells driver to updated the prot mode. Even though, other ends receives updated beacon, ieee80211 stack doesn't tell driver to update the mode (other than in ap mode). As the result, those nics run on different prot modes. When operating with mismatched mode, retry and crc error counts skyrocket. I think we need to add ic_update_prot(). AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: 11n in adhoc mode
.. so now I have 11n IBSS working, but the performance is pretty shocking. I bet there's some timers that are just not programmed correctly. I see massive numbers of long retries and CRC errors. In any case, there are a few odd things out: * ieee80211_ies_expand() doesn't parse HTINFO, only HTCAP. I don't know why - Bernhard, any ideas? * Taught ieee80211_sta_join() about the HT setup, so it sets up HT information based on the probe response. * The problem here is that the STA code sets up the HT information based on the association response, rather than the probe response; but there's no association request/response with IBSS. So if you don't capture it during probe response, you're short of luck; * .. and when doing an initial scan, the probe response goes to the scan module; it doesn't make it through to the normal probe response code that follows and thus it can't possibly be used to upgrade things. * Then some ancillary stuff - mostly processing beacon frames from peers and handling HT IE changes correctly. So with this, I have what looks like a working 802.11n IBSS - at least there are MCS rates negotiated on both sides. I don't like it one bit though; I'd like to sit down with Bernhard and anyone else who knows net80211 well enough to see whether things are "right". But.. it seems quite plausible to make work now. I don't think I have the time / brain cycles to debug some of the more stranger behaviour (and I can't ignore that the driver/HAL is missing a whole heap of 11n chipset IBSS fixes, let along the IBSS data path needing some TX and RX AMPDU fixes) but I'll definitely see if I can just get the basics up and running. Thanks, Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
