OLSR services limit with large number of defined services prevents name and services propagation (ie. IP address only)

[nathantcampbell]

Hi,

Issue: Over a certain size of advertised services (for me it's anything over 688 bytes for the /etc/config/services file), propagation of the node's hostname as well as all advertised services do not propagate to mesh network neighbors or beyond. Easy identification of the issue is current neighbors show your node as an IP address only, with no listed services even though you have services published on that node.

Example of what broken state looks like .

I have confirmed this as an issue on both the stable and current nightly (762-54589ff) releases. I believe it is unrelated to the other mechanism by which your hostname won't propagate, as simply sliming down the published services puts the node into a working state again. For reproduction and confirmation, I've attached two support downloads from my config both in a working and non-working state. The only difference between these configs is I've added one additional character to the last advertised service label which seems to put the publication over a size limit thus breaking propagation via OLSR.

Full explanation of troubleshooting with screenshot examples of working and non-working state here.

supportdata-AI7NC-QTH-hAP-202201072307_NotWorking.zip
supportdata-AI7NC-QTH-hAP-202201072308_Working.zip

Nathan, AI7NC

[aanon4]

So while the code which distribute service information on the Mesh has a maximum buffer size of 10K, the OLSR packet size is limited to the MTU (for tunnels this is something like 1480 I think) and service information is not currently split into multiple packets. With various other bits of information being included (see the olsrd_nameservice plugin section of /var/etc/olsrd.conf on your node) you're hitting this MTU limit. The current code simply throws away the service message if it's too big to send.

Fortunately for us, the receiving code is quite capable of handling multiple incoming service messages, each containing only some of the data, so we just need to rewrite the sending code to split large messages up. I can do this, but would need you to be able to test some custom builds. Possible?

[nathantcampbell]

Well that's all exactly what I thought was happening. I had figured the service info was being included with the DNS and that together was bumping up against a threshold.

Yes, I can help test. I'll likely keep my config as is for the present, making it easy to test with the same conditions as before.

[aanon4]

Any chance at all you can test this without tunnels (which you are using I see)? A custom build cannot download the extra you normally install for tunnels. Also, what specific device do you want to test this on so I can send you the relevant binary?

[nathantcampbell]

Yeah, I have an RF connection to our network through a neighbor at the moment; so I can do it in absence of tunnels.

[aanon4]

Excellent. Just let me know what device you want to run the test code on and I'll send you a build later today. I guess I also need an email address for you.

[nathantcampbell]

I'm using a Microtik HAP AC Lite. Email ai7nc1@gmail.com

[aanon4]

Emailed you a test build.

[nathantcampbell]

"KN6PLV_test2-main-54589ff" dev firmware has addressed the issue. I'm going to monitor for a day to ensure there are no downstream issues in the Willamette Valley Mesh network.

[aanon4]

Associated pull request to fix the issue: aredn/aredn_packages#7

[nathantcampbell]

Confirmed no downstream issue with the fix. Good to pull to nightly.

[ae6xe]

confirmed on hap ac lite -- added ~30 service advertisements. The URL links alone added up to over 1750 bytes. No issues.

[ae6xe]

PR committed into repo: aredn/aredn_packages@740fdf9