On Fri, 2014-02-28 at 15:27 +0100, Thomas Hühn wrote:
> > Right, but if IEEE80211_TX_CTL_ASSIGN was set then it also isn't
> > cleared.
>
> So the standard conform behavior should be to re-use the same sequno in case of a software retry ?
Technically, I think that's probably what should happen. However, the
implementation of that is practically impossible since in many cases the
firmware may have assigned a sequence number. Drivers will typically not
assign that number back, if they even know it.
> I could re-assign the flag IEEE80211_TX_CTL_ASSIGN_SEQ when a software retry happens by add
> a test to function ieee80211_handle_filtered_frame. Something like:
> if (!ieee80211_is_data_qos(hdr->frame_control) || is_multicast_ether_addr(hdr->addr1)) {
> /* driver should assign sequence number */
> info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
> }
>
> Would this be right ?
No, clearly not, this isn't the same set of conditions. Even if it were,
though, I'd hate to duplicate them here since that just causes a
maintenance nightmare.
> > But now the frame might not have *any* sequence number assigned at all,
> > if e.g. the firmware assigns sequence numbers and they're not written
> > back to the frame. Thus I think you're losing the entire sequence number
> > assignment in this case.
> >
>
> If I re-assign the IEEE80211_TX_CTL_ASSIGN_SEQ flag for software retries, than drivers
> that assigned a sequence number in the first try, could probably assign a new one. Would that
> be ok ?
That's what we have. It's debatable and not necessarily
standard-conformant, but I don't think a little cleanup patch like yours
should be allowed to change it.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
