MU-MIMO isn't working... any ideas why?

[Uri]

Hi guys,
I am trying to measure MU-MIMO behavior using 3 Linksys EA8500 routers, but it isn't working. I had the same setup using 3 Asus AC87U routers with the same result.

The setup is the following:

• One EA8500 router is configured as a wireless bridge (Bridge_1) with a machine (M_1) connected to it via ethernet cable.
• A second EA8500 router is configured as a wireless bridge (Bridge_2) with a machine (M_2) connected to it via ethernet cable.
• The third EA8500 router (AP) configured as a router. I have machine (M_3) connected to it via ethernet cable.

A simple python script on M_3 is reading a 2GB file in 4KB chunks and send them to both M_1 and M_2 over UDP, while I sniff the network using OS X sniffer. The files are received on M_1 and M_2, but it isn't doing MU-MIMO.

The result is the linked .wcap file (I don't really know the difference between it and .pcap, but wireshark opens it with no problem) which shows that the AP is doing a Single User Sounding procedure: it sends a Null Data Packet Announcement (NDPA) to M_1, get an answer, and send another packet to M_2 to get a second answer. (you can use this filter in wireshark to see it: (wlan.fc.subtype == 14) || (wlan.fc.subtype == 5) )

In MU-MIMO he is supposed to send just one NDPA to both M_1 and M_2, get immediate response from M_1, and poll M_2 for its channel measurement (aka V-matrix or Compressed Beamforming Report).

I actually did the same thing with Asus AC87U routers with exactly the same behavior. I was confirmed by Asus supervisor that they don't support MU-MIMO between AP and Bridge (after they initially confirmed to me that it is working).

Does anyone have any idea what might be the problem or what might be the issue? I would really appreciate any help!

Rock On!
Uri

The .wcap can be found here: https://drive.google.com/open?id=0B7X38eaciUXGbkh6NE9yR19CVWs

 

[L&LD]

For MU-MIMO to 'work', you need more than two clients with at least one less antennae / streams (combined) than the router supports. With identical routers, MU-MIMO is effectively not on unless you can control the streams in use per router.

 

[Uri]

First of all - thanks for your feedback.
I know that given clients which have the same throughput capacity (and number of stream) as the AP, there will be no throughput benefit of using MU-MIMO in comparison to using SU-MIMO - But I didn't consider that the AP might avoid MU-MIMO in such a scenario...

Given that I can't force the AP to do MU-MIMO, can you think of a way to make the AP use MU-MIMO, given that I have any number of routers which act as bridges? I still suspect that Linksys simply didn't implement a MU-MIMO client in the wireless bridge mode...

Regular clients are harder to come by and are a lot harder to handle (the cheapest option will be using Xiaomi Mi 4i cellphones, but I will have to invest time in learning how to run a python script on it and it will be harder to make rapid changes).

Thanks again for your help,
Uri

 

[sfx2000]

Downloading the WCAP now, let me review and I'll respond...

 

[Uri]

Thanks @sfx2000 ! you can take a look at @L&LD reply as well.

 

[sfx2000]

Looks like a couple of things...

1) Linksys firmware, at least in AP mode, MU-Beamformee is false, so this may affect the sounding reports
2) Look at the action message, and again, the client STA is indicating that it is not beamformed..

So... it looks like the AP is looking at the sounding reports, and making the decision to

a) not TxBF
b) since TxBF isn't done, no MU

So while you might have multiple MU capable devices, at the same time, both clients STA's are 4*4:4, and the AP may be deciding it's better to burst the bits over SU in MCS9, rather than split it up with 1 or 2 SS to B1 and same to B2...

Doesn't help that the Apple BCM4360 driver pretty much burps heavily on AC specific frames (hence the corrupted packets you see on the responses - this is a known issue with that driver (over the air is fine, it's the logging task that has problems)

 

[sfx2000]

1) Linksys firmware, at least in AP mode, MU-Beamformee is false, so this may affect the sounding reports
2) Look at the action message, and again, the client STA is indicating that it is not beamformed..

So the assumption is that the default for the Wireless bridges is that they may be same as the AP...

Couple of things you might check for the wireless bridges - log in to the web gui, go to advanced-wireless.html, and check settings there, might be some options to tinker with...

Linksys, on their smartwifi does have some additional detail in the sysinfo.cgi output with the driver config dumps, worth reviewing (note, don't post output here as it also shows credentials and unit specific info)...

http://<ip of the device>/sysinfo.cgi

 

[sfx2000]

@Uri - can you do me a small favor and capture a 2.4GHz trace from the E8500 in the default config (mode mixed, not "B/g/n only") - I'm doing some digging on a different linksys device, and having a trace from a QCA-based device would be useful to compare against the marvell device I'm investigating...

 

[sfx2000]

Here's the specific item from the AP I was mentioning...

  Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1)
  Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191)
  Tag length: 12
  VHT Capabilities Info: 0x338b7832
  .... .... .... .... .... .... .... ..10 = Maximum MPDU Length: 11 454 (0x00000002)
  .... .... .... .... .... .... .... 00.. = Supported Channel Width Set: Neither 160MHz nor 80+80 supported (0x00000000)
  .... .... .... .... .... .... ...1 .... = Rx LDPC: Supported
  .... .... .... .... .... .... ..1. .... = Short GI for 80MHz: Supported
  .... .... .... .... .... .... .0.. .... = Short GI for 160MHz and 80+80MHz: Not supported
  .... .... .... .... .... .... 0... .... = Tx STBC: Not supported
  .... .... .... .... .... .000 .... .... = Rx STBC: None (0x00000000)
  .... .... .... .... .... 1... .... .... = SU Beam-former Capable: Supported
  .... .... .... .... ...1 .... .... .... = SU Beam-formee Capable: Supported
  .... .... .... .... 011. .... .... .... = Compressed Steering Number of Beamformer Antennas Supported: 4 (0x00000003)
  .... .... .... .011 .... .... .... .... = Number of Sounding Dimensions: 4 (0x00000003)
  .... .... .... 1... .... .... .... .... = MU Beam-former Capable: Supported
[B]  .... .... ...0 .... .... .... .... .... = MU Beam-formee Capable: Not supported[/B]
  .... .... ..0. .... .... .... .... .... = VHT TXOP PS: Not supported
  .... .... .0.. .... .... .... .... .... = +HTC-VHT Capable (VHT variant HT Control field): Not supported
  .... ..11 1... .... .... .... .... .... = Max A-MPDU Length: 1 048 575 (0x00000007)
  .... 00.. .... .... .... .... .... .... = VHT Link Adaptation: No Feedback (0x00000000)
  ...1 .... .... .... .... .... .... .... = Rx Antenna Pattern Consistency: Supported
  ..1. .... .... .... .... .... .... .... = Tx Antenna Pattern Consistency: Supported
  00.. .... .... .... .... .... .... .... = Reserved: False

 

[sfx2000]

@Uri - can you do me a small favor and capture a 2.4GHz trace from the E8500 in the default config (mode mixed, not "B/g/n only") - I'm doing some digging on a different linksys device, and having a trace from a QCA-based device would be useful to compare against the marvell device I'm investigating...

Here's a marvell beacon (WRT1900acV2) -- notice the MU-Beamformer/Beamformee AVP's are both set to true on that device (default)

https://db.tt/shMBlCRg

sfx

 

[Uri]

Here's a marvell beacon (WRT1900acV2) -- notice the MU-Beamformer/Beamformee AVP's are both set to true on that device (default)

https://db.tt/shMBlCRg

sfx

@sfx2000 Thanks!

• I will upload a 2.4 trace tomorrow, as soon as I get to the office.
• I am not sure I followed what you said about the apple BCM4360... will I be better off sniffing using a dell desktop with a decent NIC (I don't remember the kind)? if so, do you suggest Wireshark, Airmagnet or a different tool?
• Thanks for pointing out the AP is beamformer but not beamformee. what is it about the Action message that indicates the same thing?
• I will try http://<ip of the device>/sysinfo.cgi tomorrow at the office and keep you updated

Thanks a lot!
Uri

 

[thiggins]

While intellectually interesting, this is a wild goose chase.
There is no reason for MU routers to use MU when communicating to other MU routers. Nothing whatsoever to be gained, as you said at the top of the thread.

 

[Uri]

I have reached a senior tech support engineer in Linksys who confirmed that their routers can't perform as a MU-MIMO client...

@sfx2000 I wasn't able to make the system work using the 2.4Ghz for bridge (and it isn't connected to the internet so I can't just download something using my cellphone and sniff with my Mac) - I will fix it tomorrow and upload the trace you have asked for.

Thanks a bunch for your help!

 

[sfx2000]

I have reached a senior tech support engineer in Linksys who confirmed that their routers can't perform as a MU-MIMO client...

@sfx2000 I wasn't able to make the system work using the 2.4Ghz for bridge (and it isn't connected to the internet so I can't just download something using my cellphone and sniff with my Mac) - I will fix it tomorrow and upload the trace you have asked for.

Thanks for the update - it's what I suspected based on the traces... MU is complicated enough, so the drivers are probably optimized for the device working as an AP, not as a client STA...

with regards to the 2.4GHz trace - not a big deal - just looking for a Beacon capture on a QCA device in 2.4GHz with TurboQAM enabled to see what they're doing there - I suspect they're doing similar to BRCM, and different that MRVL (the BRCM approach is better interop than what MRVL is doing in 2.4GHz with Turbo..)

 

[sfx2000]

There is no reason for MU routers to use MU when communicating to other MU routers. Nothing whatsoever to be gained, as you said at the top of the thread.

Was perhaps a valid science project - the other two EA8500's are set up as bridges, so they are client STA's to the primary AP. Being that there is a distinct lack on MU clients as of Nov 2015, I probably would have tried this as well if I wanted to get proof on the wire..

That being said, the decision logic on the MU scheduler needs to take into consideration of the client conditions, based on the sounding data sent by the clients for TxBF (first), and then consider the opportunity to either burst SU frames or take the time to build the MU frames...

Even if the EA8500's in client mode supported MU, it's likely the AP would have sent the frames in SU...

Every AP tracks the client STA's based on HT/VHT/ERP capabilities, along with the implicit 802.11b caps, based on the initial Association handshake, so the AP knows which client is capable of what - legacy, 11n, 11ac, 11g, and the connection capabilities of each client (and, FWIW, in 11n or later, adjacent networks)). The AP works to find common ground across all client STA's within it's ability to do so...

 

[sfx2000]

I wasn't able to make the system work using the 2.4Ghz for bridge (and it isn't connected to the internet so I can't just download something using my cellphone and sniff with my Mac) - I will fix it tomorrow and upload the trace you have asked for.

Just need the beacon frame with the AP in default mode...

 

[Uri]

Yes - it is a scientific project I am investigating the behavior of client-grouping in MU-MIMO, and how the V-matrices affect it in real life. for that purpose - I need a running environment of MU-MIMO...

But @sfx2000, given the beacon you have showed, it seems like the WRT1900acV2 is capable of playing both sides of the MU-MIMO, both the Tx and the Rx, and exactly what i need.
Is it so out of the box, or did you mess around with it (dd-wrt, tomato, anything requiring a screwdriver, etc...)? do you know if it has a wirless bridge / client mode? is it hard to get one (it seems there's a lot of mix up between V1 and V2)

Uri

 

[sfx2000]

The WRT1900 series do not support MU-MIMO

 

[Uri]

A trace of 2.4Ghz of the Linksys EA8500 can be found here:
https://drive.google.com/file/d/0B7X38eaciUXGRWlEYjNKaUx3NEE/view?usp=sharing
There's a lot of noise, but I think packet #2 (MAC ending with 82:9c) is the beacon from the router.
If you need anything else - let me know.

 

[sfx2000]

There's a lot of noise, but I think packet #2 (MAC ending with 82:9c) is the beacon from the router.
If you need anything else - let me know.

Thanks - you can pull that link down (probably should since it has the school's traffic in that capture)

the relevant item was very useful - see here - https://db.tt/433kay8L