I've tried this with two N2M Loco to no avail.

What I've tried:

• setting plink_action to block on both ends - not working
• setting plink_action to `block on one device and restarting the other - not working

They're happily showing off their plink_action, but don't act accordingly. Is this maybe only relevant with mesh_fwding enabled?

Node A

Station de:a4:dc:90:8b:85 (on mesh0)
    inactive time:  80 ms
    rx bytes:   1451025953
    rx packets: 10715485
    tx bytes:   726
    tx packets: 8
    tx retries: 1
    tx failed:  0
    signal:     -37 [-38, -41] dBm
    signal avg: -37 [-39, -42] dBm
    Toffset:    -54457778566 us
    tx bitrate: 57.8 MBit/s MCS 11 short GI
    rx bitrate: 58.5 MBit/s MCS 6
    mesh llid:  8640
    mesh plid:  20058
    mesh plink: BLOCKED
    mesh local PS mode: UNKNOWN
    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
    connected time: 54546 seconds

Node B

Station de:a4:dc:90:8b:92 (on mesh0)
    inactive time:  70 ms
    rx bytes:   153495
    rx packets: 2274
    tx bytes:   73387
    tx packets: 688
    tx retries: 53
    tx failed:  137
    signal:     -36 [-39, -40] dBm
    signal avg: -36 [-38, -40] dBm
    Toffset:    54457779237 us
    tx bitrate: 1.0 MBit/s
    rx bitrate: 1.0 MBit/s
    expected throughput:    0.640Mbps
    mesh llid:  34780
    mesh plid:  0
    mesh plink: OPN_SNT
    mesh local PS mode: UNKNOWN
    mesh peer PS mode:  UNKNOWN
    mesh non-peer PS mode:  ACTIVE
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 133 seconds

In what why are they not "acting" accordingly? What would you expect?

I'd expect them to stop meshing, not providing L2 connectivity any more.

Well, the plink action is BLOCKED (or OPN_SNT) and not ACTIVE so they're not meshing.

Indeed, I was confused by the status page maybe.

Hey

I have implemented a mesh backhaul on 5 Dlink routers with 802.11s mesh protocol and everything work out perfect however the throughput measurements performed with iperf tool indicates much lower throuhput (maximum around 18 Mbps) between routers on mesh setup in comparison with that of normal access point client scenario (non mesh setup around 90 Mbps) . can ayone explain this difference?

in the mesh setup when the "iw dev mesh-interface station" is executed the expected throughput is around 26 Mbps but in iperf its around 18Mbps. can anyone also clarify why this is the case and which throuput is the real throughput ?

Any guide and explanation would be greatly appreciated
Thanks in advace

@RaminnimaR In case you have "mesh plink: BLOCKED", you shoud expect a throughput of 0, since packets are blocked hopefully.
If you just experience a slower throughput: it's hard to call that a "partly success"... it is just a bug in my eyes.

Thanks for your response

Actually the mesh plink is shown as established (ESTAB), I just cant get better throughput than 18 Mbps. As I am writing a report in which the throughput results shall be included now I wanna know if should document the results of the expected throughput in the "iw" command or the throughput results of the iperf tool . As you may know they are never the same and I dont understand why.

As you may know they are never the same and I dont understand why.

i am not sure what the iw response for blocked plinks is, but if you can cat any iperf "above 0" it is definitly a bug and the "block" does not work.

BTW: Please make sure that the packets for your iperf testing really go via this link of the mesh and not "via different hops", since this is NOT about blocking nodes from the batman mesh.

To use the blocking feature in the latest stable release the package iw-full is required.

As far as I understand the reason you want to support it is to block sub-optimal links, don't you? Has anyone tested whether it makes a difference?

I don't expect a big improvement. We don't use HWMP which might make bad routing decisions. E.g. Batman decides on which link to use and if a specific link is sub-optimal the only traffic it sees are OGMs, doesn't it? And in case the optimal link's node goes offline, we don't want the mesh to break (that's why we use mesh after all).
If the OGMs really make a difference we would need to write a daemon that sets the plink-actions dynamically or better patch Batman (V) to set plink-actions using netlink.