Re: Strange performance issue when using two devices at once

[Marlon Smith <marlon.smith10@gmail.com>]

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