Hi Johannes,
>> As far as I can see, software-retry frames get in status.c the flag
>> IEEE80211_TX_INTFL_RETRANSMISSION
>> assigned (in function ieee80211_handle_filtered_frame). And this flag
>> prevents in function
>> invoke_tx_handlers() the call of ieee80211_tx_h_sequence(), so there
>> is not new seqno assigned in case of a software-retry within tx.c.
>
> 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 ?
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 ?
>> But in case of a software retry there is info->control set to zero.
>> After I would move IEEE80211_TX_CTL_ASSIGN_SEQ into
>> info->control.flags this flag is zero.
>> Hence also drivers do not assign a new sequence number.
>
> 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 ?
Greetings Thomas
> 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
