Fwd: Unable to operate a rt2770 device at 5GHz in mesh mode

Fwd: Unable to operate a rt2770 device at 5GHz in mesh mode

[ferran]

Hello everyone,

I want to build a mesh network at 5GHz with raspberry-pi's connected
each to one rt2770 device.
Following this tutorial [1] I succeed to create a virtual mesh
interface(1), set the channel(2) (let's say 11 by now) and then join a
mesh network(3). I can see the probes with Wireshark, and when more than
one has joined the mesh, I can also see the stats of the peers(4), and
then leave the network (5).

    # 1
    iw dev wlan0 interface add mesh0 type mp

    # 2
    iw dev mesh0 set channel 11

    # 3
    iw dev mesh0 mesh join my_mesh_id

    # 4
    iw dev mesh0 station dump

    # 5
    iw dev mesh0 mesh leave

As I say, everything works at 2.4 channels. However, when setting the
channel to one of the 5GHz band, I receive an error when trying to join
a mesh network. I tested all the channels that the driver claims to
support, and indeed, no 5GHz channel works.

The results of executing the commands above as set(2), join(3), leave(5)
were these:
Channels 1,2,3,…,11 --> regular 2.4 GHz channels

    ## Testing channel 11 ##
       setting channel...
       joining mesh...
       leaving mesh...

Channels 12,13,14 and 36,38,40,44,…,165 --> rare 2.4GHz channels and
regular 5GHz's

    ## Testing channel 165 ##
       setting channel...
       joining mesh...
    command failed: Invalid argument (-22)
       leaving mesh...
    command failed: Transport endpoint is not connected (-107)

Channels 167, 169, 171, 208, 212, 216 --> disabled 5GHz channels or
inexistent channel number

    ## Testing channel 212 ##
       setting channel...
    command failed: Invalid argument (-22)
       joining mesh...
    command failed: Invalid argument (-22)
       leaving mesh...
    command failed: Transport endpoint is not connected (-107)

The output of "iw list" outputs something equivalent to:

  * Channels from 1 to 11

    24ff MHz [c] (20.0 dBm)
    # where "24ff" is the frequency and "c" is the channel

  * Channels 12,13,14 and 36 to 48 and 149 to 165

    ffff MHz [cc] (20.0 dBm) (passive scanning, no IBSS)
    # where "ffff" is the frequency and "cc" is the channel

  * Channels 52 to 165

    5fff MHz [ccc] (20.0 dBm) (passive scanning, no IBSS, radar detection)
    # where "5fff" is the frequency and "ccc" is the channel

  * Channels from 167 to 216

    ffff MHz [ccc] (disabled)
    # where "5fff" is the frequency and "ccc" is the channel

Which matches the three groups of the output of testing the channels
(same results from 12 to 165, radar detection does not affect the output).

Now, my target is to operate this WiFi devices in the 5 GHz band, so I
want to know why I can set the channel to 38, but not join a mesh on
this channel, that is, start to probing and listening the channel. Does
it have anything to do with regulation restrictions? I have succeeded at
connecting to an AP at 5 GHz in managed mode.

I will thank any light you can shed to this.
Thank you very much,

Ferran

Re: Fwd: Unable to operate a rt2770 device at 5GHz in mesh mode

[Bob Copeland]

On Tue, Mar 31, 2015 at 08:44:55PM +0200, ferran wrote:
>   * Channels 12,13,14 and 36 to 48 and 149 to 165
> 
>     ffff MHz [cc] (20.0 dBm) (passive scanning, no IBSS)
                                ^^^^^^^^^^^^^^^^^^^^^^^^^

In other words you cannot send beacons or other frames on this
channel.

> Does
> it have anything to do with regulation restrictions? I have succeeded at
> connecting to an AP at 5 GHz in managed mode.

Yes.

Once you start a mesh, it will create the mesh and start beaconing
immediately, so the regulatory domain of your device and/or CRDA may prevent
you from doing this.

In managed mode, the device is not beaconing so it doesn't have this
limitation, although it will not be able to send probe requests.

-- 
Bob Copeland %% http://bobcopeland.com/

Re: Fwd: Unable to operate a rt2770 device at 5GHz in mesh mode

[ferran]

Hey Bob,

Thank you for your fast reply. I did a little more research the day
after your reply and I succeeded on it.

The issue was that the kernel's regulatory domain isn't set by default.

# iw reg get
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (N/A, 20), (N/A)
    (2457 - 2482 @ 40), (N/A, 20), (N/A), NO-IR
    (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR
    (5170 - 5250 @ 80), (N/A, 20), (N/A), NO-IR
    (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
    (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
    (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
    (57240 - 63720 @ 2160), (N/A, 0), (N/A)

However, if I set it to a specific country, then it works.

# iw reg set ES
# iw reg get
country ES: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

>From the "rules" listed at the right, the one that was blocking the mesh
is "NO-IR", meaning "no initiating radiation"[1].

In short, by default Linux doesn't know where it is, so that it remains
conservative and doesn't let me start conversations.


Best regards,
Ferran

1:
https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules#beacon_hints

On 31/03/15 22:49, Bob Copeland wrote:
> On Tue, Mar 31, 2015 at 08:44:55PM +0200, ferran wrote:
>>   * Channels 12,13,14 and 36 to 48 and 149 to 165
>>
>>     ffff MHz [cc] (20.0 dBm) (passive scanning, no IBSS)
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> In other words you cannot send beacons or other frames on this
> channel.
>
>> Does
>> it have anything to do with regulation restrictions? I have succeeded at
>> connecting to an AP at 5 GHz in managed mode.
> Yes.
>
> Once you start a mesh, it will create the mesh and start beaconing
> immediately, so the regulatory domain of your device and/or CRDA may prevent
> you from doing this.
>
> In managed mode, the device is not beaconing so it doesn't have this
> limitation, although it will not be able to send probe requests.
>