Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1580400246.26012.88.camel@gmail.com>
Subject: Re: Strange performance issue when using two devices at once
From:   Marlon Smith <marlon.smith10@gmail.com>
To:     Felix Fietkau <nbd@nbd.name>, Ben Greear <greearb@candelatech.com>,
        linux-wireless@vger.kernel.org
Date:   Thu, 30 Jan 2020 11:04:06 -0500
In-Reply-To: <0c80b739-b190-1a33-47d1-a04692a948c7@nbd.name>
References: <1580323191.26012.48.camel@gmail.com>
         <2e80a485-892d-3b29-19c7-38a9caa14f4b@candelatech.com>
         <1580325769.26012.54.camel@gmail.com>
         <6bcff97c-3b9b-7fa9-5101-80aca367ff84@candelatech.com>
         <1580327314.26012.59.camel@gmail.com>
         <c8788984-3de0-b41c-e2a1-66b67d0674a6@candelatech.com>
         <1580395439.26012.75.camel@gmail.com>
         <0c80b739-b190-1a33-47d1-a04692a948c7@nbd.name>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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