Neighbor filter - black list #47
Comments
|
You might expand this to let the sysop create a Black or White List. The Black List would keep certain nodes out while the White List would only allow certain nodes in. I would also think that a White List would also be the same list needed for Issue 212 - Enabling only certain nodes for an event. Enabling this feature could be dicey on a remote node. I would suggest a No List condition as the default option until specifically configured by the sysop. A confirmation question 'Are You Sure` would be in order before the configuration is applied. The White List option harkens back to the NetRom days on packet when band openings would create short lived paths that were unusable for networking. They would disappear long before the routing algorithm knew they were gone. |
|
Does this enhancement cover the white list functionality you are thinking of?: |
|
I think Issue 212 is just another name for a White List. So, the answer is yes. How you want to call it would be different. I think White List/Black List would be more intuitive than Black List/Event Mode. Just my $0.02. |
|
Sorry about that... Anyway K2EN says the black list is a standard feature in OpenWRT so its roots must be buried somewhere in AREDN. |
|
OpenWRT has a generic iptable rule builder to create a wide range of custom firewall rules. In AREDN the rules can be added manually to the custom firewall rule table today. However, in the spirit of AREDN, we'd probably have UI sections for specific use cases, e.g. a UI place to enter a list of MAC addresses to block, so that we can ensure the mesh node continues to operate properly and not break something else. |
|
I think the best place to do this is via OLSR, not iptables. Done via olsr, the node(s) in question will never make it to the routing table. Thus, they don't have to filtered out downstream. Besides (I may be wrong here), once a node is in the OLSR table, it will still get propagated to other nodes. And, they will have to be filtered by iptables. Some OLSR configuration statements to try: Blacklist (per interface) Whitelist (per interface) Just a thought in the "more than one way to skin a cat" category. |
|
Didn't we get strong objections around the White List concept at the recent
AREDN SoCal meet-up?
…On Thu, Feb 7, 2019 at 12:56 PM Mark ***@***.***> wrote:
I think the best place to do this is via OLSR, not iptables. Done via
olsr, the node(s) in question will never make it to the routing table.
Thus, they don't have to filtered out downstream. Besides (I may be wrong
here), once a node is in the OLSR table, it will still get propagated to
other nodes. And, they will have to be filtered by iptables.
Some OLSR configuration statements to try:
Blacklist (per interface)
LinkQualityMult 10.1.2.3 .1
where 10.1.2.3 is the ip address to be blacklisted
.1 is a multiplication value applied to the actual LQ coming in. Thus, an
incoming LQ of 80% would be dropped down to 8% and used in subsequent OLSR
calculations. If you set the multiplicatoion factor to 0, you have now
fully blocked that ip address.
Whitelist (per interface)
LinkQualityMult Default 0
Here you set anything coming in to 0, no quality. Then you use
LinkQualityMult to enable those ip addresses you wish to accept.
Just a thought in the "more than one way to skin a cat" category.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<https://github.com/aredn/aredn_ar71xx/issues/211#issuecomment-461592637>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AiQlhW6SAYL5plPU0rmAhBeANye8W8CWks5vLJMPgaJpZM4XFNFa>
.
|
|
Yes. Users were strongly against it
Thanks,
Darryl
… On Feb 7, 2019, at 3:31 PM, Andre Hansen ***@***.***> wrote:
Didn't we get strong objections around the White List concept at the recent
AREDN SoCal meet-up?
On Thu, Feb 7, 2019 at 12:56 PM Mark ***@***.***> wrote:
> I think the best place to do this is via OLSR, not iptables. Done via
> olsr, the node(s) in question will never make it to the routing table.
> Thus, they don't have to filtered out downstream. Besides (I may be wrong
> here), once a node is in the OLSR table, it will still get propagated to
> other nodes. And, they will have to be filtered by iptables.
>
> Some OLSR configuration statements to try:
>
> Blacklist (per interface)
> LinkQualityMult 10.1.2.3 .1
> where 10.1.2.3 is the ip address to be blacklisted
> .1 is a multiplication value applied to the actual LQ coming in. Thus, an
> incoming LQ of 80% would be dropped down to 8% and used in subsequent OLSR
> calculations. If you set the multiplicatoion factor to 0, you have now
> fully blocked that ip address.
>
> Whitelist (per interface)
> LinkQualityMult Default 0
> Here you set anything coming in to 0, no quality. Then you use
> LinkQualityMult to enable those ip addresses you wish to accept.
>
> Just a thought in the "more than one way to skin a cat" category.
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <https://github.com/aredn/aredn_ar71xx/issues/211#issuecomment-461592637>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AiQlhW6SAYL5plPU0rmAhBeANye8W8CWks5vLJMPgaJpZM4XFNFa>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
move conversation related to white list rules to here: https://github.com/aredn/aredn_ar71xx/issues/212 |
The text was updated successfully, but these errors were encountered: