On Thu, 2020-01-30 at 16:32 +0100, Felix Fietkau wrote: > On 2020-01-30 15:43, Marlon Smith wrote: > > > > So I did a few tests and got some pretty interesting results. > > > > With the two devices connected to the access point and performing > > slowly, I changed the MAC address of one of the devices (Just from > > a B6 > > to a BA). Immediately, both devices began working properly! > > > > Back to the original MAC address, I looked at my sniffer, and I do > > not > > see any evidence of one device acking another device's frames. With > > one > > device sitting idle and the other transferring data, I see high > > numbers > > of retransmitted frames, and then an eventual ack from the correct > > device, but very little activity from the idle device. While this > > is > > happening, the device driver indicates that it is dropping lots of > > duplicate received packets. > Here's the cause and an approach for fixing it: > > The MAC_BSSID_DW1 register configures the Multi-BSSID mode. It can be > configured for 1, 2, 4 or 8 BSSIDs. This controls what MAC addresses > the > chip will respond to. The driver always sets it up for 8 BSSIDs. > > The problem here is that the chip has a hardcoded pattern for how > those > BSSIDs are allocated: > Depending on the number of BSSIDs, the lower 1, 2 or 3 bits are used > to > encode the BSS index. This means that when 8 BSSIDs are enabled, the > lower 3 bits are effectively masked out on the MAC address filter > that > decides which frames to ACK. Because your MAC addresses are so close > together, both devices try to ACK the same frames at the same time. > This > will not be visible in a sniffer, since they will be transmitting at > the > same time. > > I'd say the first step in fixing this is to make the driver set > MAC_BSSID_DW1_BSS_ID_MASK based on the MAC addresses of configured > virtual interfaces. For older chips, this MAC address pattern cannot > be > fixed. > > However, on at least RT3883, RT3352 and RT5350 (and thus most likely > also RT5370), you can set BIT 21 in that register, which changes the > pattern. With that bit set, the second interface only sets the local > bit > of the MAC address, and from the third interface on it adds (idx- > 1)<<2 > to the first byte. That gets rid of the MAC address conflicts. > > Hopefully someone familiar with the rt2x00 code will read this and > write > some patches :) > > - Felix Felix, this was exactly it. I set that bit and the problem disappeared. Thank you so much! Ben, your help was very much appreciated as well. Your suggestions really helped narrow things down. Is there a way I can help others who might come across this problem in the future? Would filing a bug report help anyone out, even if just to document this issue? Thanks again both of you, you saved me countless hours of time here. Marlon
