The kernel test robot highlighted a bug in the patch. So for now do not apply this one. I'm currently testing the injection behavior of some new devices I have, since my current ones are getting old, and I'll send updated patches within a week or two if all goes well. On Sun, 28 Jun 2020 20:59:56 +0200 Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sun, 2020-06-28 at 22:05 +0400, Mathy Vanhoef wrote: > > The sequence number of injected frames is being overwritten by the > > function ieee80211_tx_h_sequence when the following two conditions > > are met: > > > > 1. The frame is injected on a virtual interface, and a second > > virtual interface on this device is operating in managed/AP/.. mode. > > > > 2. The sender MAC address of the injected frame matches the MAC > > address of the second interface operating in managed/AP/.. mode. > > > > In some cases this may be desired, for instance when hostap is > > configured to send certain frames using a monitor interface, in > > which case the user-space will not assign a sequence number and > > instead injects frames with a sequence number of zero. > > Yeah, this is where that used to be used. I'm thinking we should > "break" this stuff eventually, tell people to use modern hostapd > versions, and see who cares ... because all this "cooked monitor" > etc. is all quite ugly. > > > However, in case the user-space does assign a non-zero sequence > > number, this number should not be overwritten by the kernel. This > > patch adds a check to see if injected frames have already been > > assigned a non-zero sequence number, and if so, this sequence > > number will not be overwritten by the kernel. > > Seems reasonable, but I have to wonder what you're up to now ;-) > > Anyway, I'll apply this unless I find some tests fail or something, > but I'll be going on vacation soon, so it'll be a while (since it's > for the -next tree as a feature). > > johannes >
