On Wed, 2020-01-29 at 12:01 -0800, Ben Greear wrote: > On 1/29/20 11:48 AM, Marlon Smith wrote: > > > > On Wed, 2020-01-29 at 11:27 -0800, Ben Greear wrote: > > > > > > On 1/29/20 11:22 AM, Marlon Smith wrote: > > > > > > > > > > > > On Wed, 2020-01-29 at 10:42 -0800, Ben Greear wrote: > > > > > > > > > > > > > > > On 1/29/20 10:39 AM, Marlon Smith wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > I have two RT5370 devices connected to the same access > > > > > > point. > > > > > > Both > > > > > > devices are very slow, but the instant I disconnect one > > > > > > device, > > > > > > the > > > > > > other speeds up by a factor of 10. > > > > > Out of curiosity, are both of the RT5370 used on the same > > > > > client > > > > > device? > > > > > > > > > > > > > > > > > > Did you check that they have unique MAC addresses? > > > > > > Thanks, > > > > > Ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The really strange part is that one device will perform > > > > > > slowly > > > > > > even > > > > > > if > > > > > > the other device is basically idle! I've confirmed this > > > > > > with a > > > > > > packet > > > > > > sniffer. > > > > > > > > > > > > I've been trying to do some debugging, and I've found that > > > > > > when > > > > > > both > > > > > > devices are connected to the access point, they report a > > > > > > large > > > > > > number > > > > > > of duplicate frames. I added some debug output > > > > > > in ieee80211_rx_h_check_dup() to confirm that this only > > > > > > happens > > > > > > while > > > > > > both devices are connected. The packet sniffer also shows a > > > > > > large > > > > > > number of retries while this is occurring. > > > > > > > > > > > > Using backports 5.3-rc4 for this, but also tested on 4.14- > > > > > > rc2. > > > > > > > > > > > > I did post about this previously on this mailing list > > > > > > (RT5370 > > > > > > performance issues), but I thought I'd post again with this > > > > > > new > > > > > > information and more descriptive title. I'm a little bit > > > > > > stuck > > > > > > on > > > > > > this > > > > > > for a while now, so any ideas are much appreciated. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Marlon > > > > > > > > > > They are on separate devices, although the mac addresses are > > > > close. > > > > 70:F1:1C:2E:AF:B4 and > > > > 70:F1:1C:2E:AF:B6. > > > > > > > > However, I have a third device 70:F1:1C:2E:AF:BB which performs > > > > well > > > > and does not affect the performance of the other two. > > > > > > > Have you tried a different AP? > > > > > > And also tried using the exact same MAC addresses configured on a > > > different > > > radio (like ath9k)? > > > > > > Thanks, > > > Ben > > > > > > > > I have tried a different access point in a different environment > > but no > > luck. I'll see if I can configure my laptop to use one of the > > problematic devices' mac address. > It might be tricky to determine, but if you can notice whether one of > your station devices > is (block-)acking the other's frames, that would be a good clue that > it is a station > side bug. A carefully inspected sniff, especially if you can put > sniffer near one station > and far from the other and so use RSSI as a sorting factor, should > allow you to determine > this. > > Thanks, > Ben > > 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.
