search

o11s / open80211s

open80211s
Other
242 stars 55 forks source link

mesh_rssi_threshold Functionality #70

Closed darkdrgn2k closed 6 years ago

darkdrgn2k commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 https://github.com/o11s/open80211s/issues/70, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewisE1TQtDBY3Kw2ucbg6d6f8nVedks5s-3eVgaJpZM4Q8Y-A .

darkdrgn2k commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 https://github.com/o11s/open80211s/issues/70#issuecomment-352151661, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewj8q7ogKEvf56-U-sCmEH7ZfEipzks5tAyEogaJpZM4Q8Y-A .

darkdrgn2k commented 6 years ago

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 commented 6 years ago

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 https://github.com/o11s/open80211s/issues/70#issuecomment-352193603, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewsQv__97pRFZDL9rs0R63K3f5to_ks5tA-8XgaJpZM4Q8Y-A .

darkdrgn2k commented 6 years ago

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 commented 6 years ago

On Sun, Dec 17, 2017 at 2:19 AM, darkdrgn2k notifications@github.com 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 https://github.com/o11s/open80211s/issues/70#issuecomment-352201044, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewp_eC1YQRHZ6cGIM-c2a7oglMc32ks5tBAmmgaJpZM4Q8Y-A .

darkdrgn2k commented 6 years ago

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