MinSig

Both nodes Minsig
Try setting minsig on *both* nodes... I've seen this issue on my nodes as well.

A word of caution - before doing any getandverify, change all minsig values to 0 and make apply the changes after reboot or you could end up manually editing the /etc/wiana.settings file, as some versions of software report differently for minsig.

> I think I've figured out how to solve a problem I've been having, but I > can't figure out how to prevent it. > > I have a node that's way out on the edge of the mesh. It has one good > link to another node, but that's all. It can see a few other nodes, but > the signal is nowhere near good enough for a reliable link. I've set > the > minsig value in Wiana, and the automatic route blocking works fine. > > With one exception. > > One of the nodes that it's seeing a troublesome signal from is a > 2-radio > node. This node has a backhaul radio and a mesh radio. The backhaul > radio - the one on a different channel from the mesh - has the official > Wiana 1.x.y.z address. This means that the second radio is assigned a > random 10.x.y.z address. > > So far, so good. Now, when I look at the edge node, I see that the > 2-radio node is on the blocked list. Unfortunately, it's also showing > up > in reporter as being a mesh neighbour. This is leading to an unreliable > link, as the 2-radio node gives a 2-hop path to the gateway, whereas > the > good link is a 3-hop path. This leads to the node trying to establish a > route through the poor path, ergo catastrophic throughput and unhappy > customers. > > I can solve this by issuing the blocknode command on the 10.x.y.z > address of the 2-radio box. Unfortunately, that address seems to change > each time the box reboots. It's not that it reboots often; it's just > that I would like the mesh to self-manage in the ways that it's > designed > to. > > Given that it's actually the 10.x.y.z address that it's connecting to, > shouldn't it automatically block that node if the signal is poor?