You are here

squelch?

8 posts / 0 new
Last post
KE2N
KE2N's picture
squelch?

This topic has been discussed before I think. If there is already an answer just point me there.

We have a spot in our mesh where a node sees its intended links at -65 dBm and a handful of other stations at -88 or less.  Assuming we want to keep all the nodes on the same SSID, is there a way we can prevent this node from having any comms with the really weak stations?  Just ignore them.  This would be analogous to setting the squelch in a conventional radio to avoid really weak and scratchy FM signals.   The reason is to avoid needlessly loading the node (and the channel) with lots of pointless/useless retries and other overhead work.

Ken

 

K5DLQ
K5DLQ's picture
I think you want the

I think you want the "blacklist" feature:   https://github.com/aredn/aredn_ar71xx/issues/211

 

KE2N
KE2N's picture
ok +1

OK - that is not signal-based but it would sure do the job.

I tried putting in option macfilter and maclist per some instructions for openwrt and - while it did not complain about that - it did not work either.  So I guess that option is not supported (or checked for) by AREDN mesh.  How hard is that to do?  I am happy to try it out.

 

AE6XE
AE6XE's picture
Such a squelch feature is

Such a squelch feature is possible, this is essentially what the ANI (Adaptive Noise Interference) capability in the ath9k driver is doing and what happens with the "deaf node" scenario -- squelching out neighbors.    Figuring out how to do this is the challenge.  I looked though the user command options, and there does not appear to be any way to affect ANI to do this on purpose, it looks to be at the wireless driver code level only.   

Joe AE6XE

nc8q
nc8q's picture
prevent node from having comms with the really weak stations

Hi, Ken:

Use a different channel or ask the weak station(s) to use a different channel.
This would be analogous to setting the frequency/channel in a conventional radio to avoid interfering with other stations.
This may also analogous to establishing a VLAN to reduce unnecessary traffic and broadcasts on a channel.

Our local network has twenty-five (25) active nodes on 2397 MHz. (+15 nodes not on 2.4 GHz.)
In order for any acceptable networking to occur, they found it necessary to set multiple different SSIDs on those nodes.
In one instance of changing SSIDs the latency was decreased by a ratio of 700:1.
Obviously, channel contention remains. However, point-to-point linking between LANs is now avoided on 2397 MHz.

Chuck

KE2N
KE2N's picture
yes we had different SSID's

yes we had different SSID's and a DtD link, which worked fine. But that required a 100-meter long underground cable. That link has effectively been lost, so I was looking for a way to restore functionally-similar operation that did not involve moving to part-15 channels.

I still would like to try the black list feature.  I see that it is a standard feature in OpenWRT so its roots must be buried somewhere in AREDN.

AE6XE
AE6XE's picture
Ken, this is an iptable

Ken, this is an iptable command to put in the custom rules file to drop packets from a given MAC address.  Might be able to google to find examples of this command, but be sure to put in both the INPUT and FORWARD tables.

Changing the SSID should only improve the situation if it fundamentally changed the routing path traffic was taking though all the nodes.   Like a far out node that keeps trying to reach a service clogging up the channel.  We're just cutting it off.   But if that node has another path on another SSID, it can still clog up the channel just the same.   

Regardless, the devices continue to share the channel and still talk with  management control frames -- beacons, RTS/CTS, and more -- are not SSID unique -- the purpose is to communicate across all devices/SSIDs to manage the channel use.   Changing SSIDs and dropping packets from MAC addresses should have a similar effect.   

Joe AE6XE

nc8q
nc8q's picture
did not involve moving to part-15 channels.

Hi, Ken:

 Sorry, I should have made some channel suggestions!
I did not mean to suggest moving to shared Part 15 channels in 2400<>2485 MHz.
Try some channels around 3380<>3495 and/or 5835<>5920 MHz.

Chuck
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer