The problem is if I change the rt2800 driver to set 0 if it gets 1,
etc., that will break all existing user-space programs.
And also with the current lower limit, I cannot disable transmission
retries. The minimal transmit attempts value is 2 (retry is 1).
Robert
2015. 06. 3, szerda keltezéssel 15.05-kor Johannes Berg ezt írta:
> On Wed, 2015-06-03 at 14:46 +0200, Robert Hodaszi wrote:
> > From: Robert Hodaszi <robert.hodaszi@xxxxxxxx>
> >
> > To disable the transmit retries on RT28xx driver, the retry limit should
> > be set to 0. The current lower limit (1) prevents it.
>
> So actually - we have the same limit in nl80211... we should change both
> at the same time.
>
> However, I'm withdrawing my earlier comment. The dot11ShortRetryLimit
> and dot11LongRetryLimit counters (which correspond to this) are defined
> to have a range 1..255, and semantically are actually the number of
> permissible transmission *attempts* (see their definition in
> 802.11-2012).
>
> As a consequence, I'd say the driver is doing things wrong here and this
> part is actually correct.
>
> You could argue that this is userspace API that must never change,
> but ... dunno. If you feel strongly about this I guess we could accept 0
> and translate it to 1 in cfg80211 to get the correct semantics, but
> you'd still have the driver bug then. I don't think we should accept 0
> and pass it to the driver, since it need not expect such a value based
> on the 802.11 spec.
>
> johannes
>
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
