Is there a way to determine why olsrd is not sharing routing information with a neighbor. Case in point:
I see the neighbor's IP address and good LQ (~90%). But, the IP Address never resolves and the NLQ remains at 0. I am fairly sure the issue is due to a changed olsrd_secure_key on the neighbor. The question is how can I prove that, or, if that is not the issue, find other information from my side?
I have seen I can place olsrd into debug mode in it's conf file (DebugLevel >0) and that is supposed to send debugging info to stdout. But, if I do that and restart olsrd (/eytc/init.d/olsrd rtestart) I assume stdout is being redirected somewhere, but I can't find it.
Any ideas?
Thanks Darryl.
It is possible the distant device does not hear my node. But, since I see three different nodes, all fairly strong, it is unlikely. Even if my node has olsr_secure off by default, isn't it still possible the other end changed their config to turn it on?
But, the real question is still, what tools do I have to debug this. I tried logger and dmesg but neither show olsrd issues.
Services redirect standard output to /dev/null when started by the operating system scripts
OLSRD does have a debug flag but to be honest it doesn't give much, infact much more information is available via the OLSR HTTP gui in current OLSRD builds.
Until you have a good bidirectional link the state is somewhat in flux on a connection and its somewhat indeterminate, while it should eventually manage to get enough data until a bidirectional link is established its not guaranteed from what Ive experienced on some very marginal one way links. It is entirely possible you can hear them but they can't hear you due to local noise, possibly running an amplifier (which is considered a bad practice as they usually don't help at all in our experience) or that the remote node has the 'deaf channel' flaw and hasn't upgraded to B04 yet to get around the issue so that you can hear them but they can't hear you.
Honestly the only true way to know what the other side is doing is to talk to that admin, if they made custom changes they should/must NOT run under the default SSID or a regional default unless that entire region has agreed to that change (and backend changes are unsupported), however I do know of one user up in the Berkley area whom has in the past run under the default SSID's or older default SSID's with changed configs without respect for the impact it would have on the network. Ultimately since users have to have hardware we as devs never could lock out that sort of action, and it becomes an issue for the local hams to shun such behavior.
If you really wanted to debug deep you could do packet dumps with tcpdump and look at the packet flows see what is happening, a bit of knowledge on OLSRD packets is useful. At the very least you would hopefully see a name advertisement packet you could look at. Additionally there was another thread here that talked about opening a port and running tcpdump to look for identification packets that come in as an option to track down what node it is.
Here's a diagram I ran into that visually shows how there can be a 0% NLQ (doesn't hear you) alongside 100% LQ (you hear them). Conventional wisdom is that if there is a path for me to receive the signal and given comparable xmit power levels and antennas, then both sides should equally receive each other.
What happens with these relatively low power mW signals is that one side may have higher level of interfering signals (like at a tower site) to contend with--call this background noise. Thus, one side may not hear the other.
The line represents the point where the transmitter's signal is equal to the background noise and can no longer be received.
*Diagram complements of Don KE6BXT.