On Tue, 2014-02-25 at 14:31 +0100, Thomas Hühn wrote: > > I'm not convinced this patch is correct, so you need to convince me. > > What happens to software-retry frames? They probably *shouldn't* get a > > new seqno, but if the driver doesn't modify the SKB (say because > > hardware/firmware assigns it) then this is certainly not right. > > 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. > 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. 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
