meteohub.de

After installing a local caching DNS resolver (unbound) on my local network, I came to realize that MeteoBridge is among the top 5 systems on my home network in terms of generated DNS requests. For my configuration (sending data to 11-plus weather sites), my TL-MR3020 (v1) generates more than 1 DNS request every 2 seconds, and the vast majority of these are repetitive, yet the hosts have non-zero TTL (time to live).

This is a typical side effect of an application using stock libc - every application call to send data to a host will result in a call to the DNS server, because libc doesn't cache responses or pay any attention to the TTL for a given address resolution.

After much consideration, it turns out that it is relatively easy to solve this - by enabling the dnsmasq caching DNS server that is already installed on the OpenWrt platform that MeteoBridge runs on top of. In fact, if you are using the WiFi capability of the TL-MR3020, AND your WiFi SSID name starts with "MB", you will already have dnsmasq running on your MeteoBridge, although I doubt it is providing any benefit until you configure it properly, which I have figured out. I have also figured out how to stop the setup.sh startup script from shutting down dnsmasq so that it remains available for MeteoBridge to use even if you're not using WiFi as an Access Point.

Before I explain how I do all this, I'm going to ask (by way of this message) the MeteoBridge staff if it is OK for me to explain it. My changes are exclusively done through the OpenWrt interface and the provided hook into rc.local, and once completed the memory footprint of running apps is increased by less than 1MB, leaving plenty of room for all the MeteoBridge stuff to run (while also significantly reducing network traffic and name resolution delays).

So, MeteoBridge folks - is it permissible for me to share how to get dnsmasq running, so as to reduce (significantly) the unnecessary DNS overhead that MeteoBridge is generating?

You can do as you like, the system is open on root level to give you full freedom. But please understand that you are out of support when you modify on system level. I personally do not recommend to change things you because of a more theoretical issue, but if you have to do it for some reason, go ahead.
As Meteobridge is extremely low on RAM we decided not to use the dnsmasq, so be prepared for side effect problems.

Thanks.

It has actually been running much more reliably using dnsmasq than it was when it was depending upon external name servers, with far fewer timeouts listed in the Live Data log. And while it still may be a theoretical issue, to have this one little tiny thing be responsible for more than 50% of the DNS traffic going out to my ISP's name servers seems a little bit extreme, since I have over 85 other active devices on my home network...

The good news is that I can revert to "stock" configuration by simply commenting out a few lines in the Startup script (=rc.local), so I don't worry too much about being out of compliance. And the memory footprint increase is just a few hundred kB vs. not using dnsmasq (and I could probably reduce it if I could configure a smaller cache size without resorting to hacking the actual NVRAM image).

That said, I've ordered a M3020_v3 to replace my current v1 with, so the memory constraint concerns should go away once I get there. Did perchance you already enable dnsmasq on the v3?

Bottom line, though, is do you mind if I share the instructions on this forum, or would you prefer I just leave it to smart people to figure out for themselves (it's not that hard).

Thanks for everything you do - I really *love* having the MeteoBridge and all the capabilities you have built into over the years...

When someone messes up the "rc.local", the system will no longer boot! Are you ready to handle the support requests of users having bricked their system by that? I don't want to do that.

OK, then - that's why I asked you first, before posting the How To...

Enhancement Request: Allow users to safely configure and enable OpenWrt's dnsmasq with a minimal cache (needs less than the default 150 name slots).

NOTE: dnsmasq will be left running on standard TL-M3020 MeteoBridge installations if the user configures to use WiFi bridged to Ethernet (e.g. AP mode), and a WiFi SSID name that begins with "MB", even without using OpenWrt Expert Mode. Unfortunately, this will only consume memory and possibly break connectivity because the default dnsmasq configuration is incomplete.

Can you please check if LAN to WLAN bridging does still work with dnsmasq enabled?
I don't remember exactly but I think there also was a functional reason that made me to disable that service.

It will be a while before I can test it.

But the code currently Does NOT stop dnsmasq if /etc/config/wireless.mode == 'ap' AND /etc/config/wireless.ssid.startsWith('MB)
That said, I'm not sure why you would want dnsmasq if acting as an access point for a SSID named 'MB*'

I think I already spent too much time into this discussion which is more about who is right than oriented to any real problem.