> Based on that information, I have removed the "Yes (under development)"
> note from the driver page since it doesn't really support it... In fact,
> I'm surprised it works even with that hack since hostapd usually polls
> the station with nullfunc frames and waits for an ack.
Reading the mail from Ivo (http://sourceforge.net/mailarchive/message.php?msg_id=200808082059.11968.IvDoorn%40gmail.com)
I gather that the ACK in question is not from the peer but from the local
hardware indicating that the frame was actually sent and not lost due to
some local error.
--
Regards
Joerg
Hi Joerg,
On Thu, Apr 30, 2009 at 14:41, Joerg Pommnitz <[email protected]> wrote:
>
>> Based on that information, I have removed the "Yes (under development)"
>> note from the driver page since it doesn't really support it... In fact,
>> I'm surprised it works even with that hack since hostapd usually polls
>> the station with nullfunc frames and waits for an ack.
>
> Reading the mail from Ivo (http://sourceforge.net/mailarchive/message.php?msg_id=200808082059.11968.IvDoorn%40gmail.com)
> I gather that the ACK in question is not from the peer but from the local
> hardware indicating that the frame was actually sent and not lost due to
> some local error.
> --
> Regards
> Joerg
According to Ivo, we cannot be totally sure that the device has sent
the frame into the air, so no actual ACK is reported back to mac80211.
The hostapd hack works, as long as the stations are not very far from
the AP, and thus not 'too many retries' need to be sent.
AFAIK, this is not optimal at all, so I don't go around and say 'it
works'. It may or may not work in your case.
If possible, test and report back your findings.
Luis Correia
rt2x00 project admin
On Thu, 2009-04-30 at 06:41 -0700, Joerg Pommnitz wrote:
> > Based on that information, I have removed the "Yes (under development)"
> > note from the driver page since it doesn't really support it... In fact,
> > I'm surprised it works even with that hack since hostapd usually polls
> > the station with nullfunc frames and waits for an ack.
>
> Reading the mail from Ivo (http://sourceforge.net/mailarchive/message.php?msg_id=200808082059.11968.IvDoorn%40gmail.com)
> I gather that the ACK in question is not from the peer but from the local
> hardware indicating that the frame was actually sent and not lost due to
> some local error.
No, the ACK in question is this one:
local remote
--- nullfunc frame --->
<------- ACK ----------
Apparently rt73usb is incapable of telling the driver that it got this
ACK frame, and as such hostapd will not be informed about that, and then
it will expire the station if it's otherwise idle.
johannes