mesh_rssi_threshold Functionality

[darkdrgn2k]

Does mesh_rssi_threshold prevent links with low dBm values, or does it simply not route packets over that links?

I set it to -30 however the links with -50 and -70 both show in station dump.

[chunyeow]

What is the state of stations shown in station dump? As long as they are not in established state, then this is correct.

…

On Sun, Dec 10, 2017 at 2:17 PM, darkdrgn2k ***@***.***> wrote: Does mesh_rssi_threshold prevent links with low dBm values, or does it simply not route packets over that links? I set it to -30 however the links with -50 and -70 both show in station dump. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewisE1TQtDBY3Kw2ucbg6d6f8nVedks5s-3eVgaJpZM4Q8Y-A> .

[darkdrgn2k]

yes seems established

 iw dev wlan0 set mesh_param mesh_rssi_threshold -70

Station 8c:88:2b:00:00:4a (on wlan0)
        inactive time:  172 ms
        rx bytes:       6602425
        rx packets:     101132
        tx bytes:       3706042
        tx packets:     24597
        tx retries:     132134
        tx failed:      14820
        signal:         -74 [-74] dBm
        signal avg:     -75 [-75] dBm
        Toffset:        -540333624 us
        tx bitrate:     1.0 MBit/s
        rx bitrate:     6.5 MBit/s MCS 0
        expected throughput:    0.366Mbps
        mesh llid:      41224
        mesh plid:      12402
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no

[chunyeow]

Do you use wpa_supp or authsae to do the peering? Can you check whether this is override by reading back the threshold value, using iw wlan0 get mesh_param.

…

On Sat, Dec 16, 2017 at 9:47 AM, darkdrgn2k ***@***.***> wrote: yes seems established iw dev wlan0 set mesh_param mesh_rssi_threshold -70 Station 8c:88:2b:00:00:4a (on wlan0) inactive time: 172 ms rx bytes: 6602425 rx packets: 101132 tx bytes: 3706042 tx packets: 24597 tx retries: 132134 tx failed: 14820 signal: -74 [-74] dBm signal avg: -75 [-75] dBm Toffset: -540333624 us tx bitrate: 1.0 MBit/s rx bitrate: 6.5 MBit/s MCS 0 expected throughput: 0.366Mbps mesh llid: 41224 mesh plid: 12402 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewj8q7ogKEvf56-U-sCmEH7ZfEipzks5tAyEogaJpZM4Q8Y-A> .

[darkdrgn2k]

so i did some testing
NEW connections will not be established when the threshold is set and sit at "LISTEN"

OLD connections are not dropped even after several hours

is this by design?

No encryption open air and settings are still set.

[chunyeow]

On Dec 17, 2017 12:25 AM, "darkdrgn2k" <notifications@github.com> wrote: so i did some testing NEW connections will not be established when the threshold is set and sit at "LISTEN" Yes, this is the behavior OLD connections are not dropped even after several hours is this by design? OLD means before you set the threshold? If yes, the peering will still happen and after you set threshold, the previous established peers will still in established state No encryption open air and settings are still set. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewsQv__97pRFZDL9rs0R63K3f5to_ks5tA-8XgaJpZM4Q8Y-A> .

[darkdrgn2k]

Awesome thank you that explains the behavior i am seeing, seems like its all by design.
So a connection established BEFORE threshold is set will NOT be blocked

What about a connection that is set AFTER but then at a later point falls below the threshold?

[chunyeow]

On Sun, Dec 17, 2017 at 2:19 AM, darkdrgn2k ***@***.***> wrote: Awesome thank you that explains the behavior i am seeing, seems like its all by design. So a connection established BEFORE threshold is set will NOT be blocked What about a connection that is set AFTER but then at a later point falls below the threshold?

This user won't be blocked. The threshold need to set before peering happens (initial stage of your node seeing another peer broadcasting its beacon) to make it work. If you want to block this user, you need to use "plink_action" to block the specific MAC. But then you probably need to get the reading of RSSI before blocking it.

…

--- Chun-Yeow

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewp_eC1YQRHZ6cGIM-c2a7oglMc32ks5tBAmmgaJpZM4Q8Y-A> .

[darkdrgn2k]

Awsome thank you for the explanation. It is all working as designed then.

I also am working on a script to keep en eye out for the signal and block connections that fall bellow the threshold while opening one's that go above. I just didn't want to reinvent the wheel.

The threshold in o11s is a def useful thank you