Just to add another DNS related bit: with 7.7rc4 I have intermittent problems with Amazon Echo Show 8. Other echos (dot and echo plus) work fine.
The problem is alexa randomly stops working, saying something like “I can’t connect”.
Some times it fails soon after boot, other times works fine after boot but loose connection some time (hours) later.
If I switch to ISP router DNS evertything works fine (as it did with 7.5).
This is exactly what Siri does. Often 1-10 minutes later it will work fine again. I hadn’t chalked it and the steaming issues/random dns issues when loading remote resources to an update since it’s so intermittent.
Maybe we can try to use a simple bash script, but the main question is how to build the list of the hosts.
external=1.1.1.1
while read host; do
if [ ! -z "$host" ]; then
local_reply=$(dig $host +short | sort)
external_reply=$(dig @$external $host +short | sort)
diff <(echo $local_reply) <(echo $external_reply)
if [[ $? -ne 0 ]]; then
echo "`date` - different - $host"
echo "local reply: $local_reply"
echo "external reply: $external_reply"
echo
else
echo "`date` - same - $host"
fi
fi
done <dns.names
I just created dns.names file from /ip/dns/cache print output. If we have a suspicious replies in the cache, we can try to perform a test.
Also, we may consider to adopt the script to show the error only in case of an empty reply.
It is probably no good to try to build test cases ourselves. That is why I was looking at the “unbound” test code as it appears to have many test cases and it has probably arisen from the many quirks that they have hit when developing “unbound”.
When we could just run those tests against an arbitrary resolver (only via the network to a specified IP) it would be great. We could test the MikroTik resolver and maybe find a snag that they have also encountered during development.
But frankly, I think it would be better when MikroTik just used unbound. It can do everything that their resolver can do (maybe sometimes in a bit of a different way, e.g. it handles forwarding cleanly using “forward zones” instead of those ugly regexps), plus it can do things that are on the wishlist, like DNSSEC.
The only problem could be that the default binary is 1MB in size and it may not fit in the smips routers. But they are EOL for v7 anyway.
Even the brand new 100G switch CRS504 has just 16MB of storage so that limitation is not going away any time soon. This is a decision MikroTik has made and the price is them having to build everything from scratch because the standard approaches will not fit.
16MB is bad but the SMIPS devices are much worse, as they do not have enough RAM either so the new version has to fit in the flash alongside the old one during update.
Still, a 16MB flash device with an ARM CPU will not be a joy forever either. E.g. a hAP ac2 has only 1.4MB of space left in the flash on a v7.7rc install.
I think one of the reasons is that the interface technology for those flash chips changes at the 16MB mark. To have more, you either need to have a 16MB chip (to boot) plus some extra chip for more storage, or you would need to use different technology SoC that allows larger boot flash chips and probably costs more. Also, having two chips may mean that you need so many lines dedicated to interfacing the memory that you may not have enough left for other control purposes.
Still, going with that 16MB flash on so many devices certainly paints them in a corner.
It MAY costs more, but I don’t think so. Why? Because of what we saw with the hAP AC3: it went from 16MB to 1GB - but it no longer can take 300k writes/cell, since it uses a different kind of flash. But it comes with 128MB - almost 10x more.
Yes, the SOC documentation states that it uses no more than 16MB SLC, but TLC can go up… 1GiB. If I’m not mistaken. I’m all for it, just uses wear leveling and call it a day.
And even if costs more: we are talking about 1GB, not 1TB. What would it be? US$ 2 more?
In the MIPSBE days (2011, 750, 750r2 etc) even the cheap devices came with 128MB. But it was a different SoC. I did not read all datasheets (they may not even all be available) but apparently something changed when MMIPS was introduced, and it remained when ARM became the norm.
had problems in updating procedures because of that. had to do some resets and netinstalls for, TBH, no good reason if there were say 64MB at least of flash to have room for the update-npk
The bridge HW offloading does not work on hap ax3 and there is also no Host tab in the Switch menu, although according to the Switch Chip Features table the Port Switch and the Host Table should work on IPQ-PPE.
Unless RAM disk for downloading upgrade npk files becomes a norm on all devices, minimum usable flash size is 128MB on devices with ac/ax radios (i.e. all wifi devices). I guess 64MB would be enough for wired-only devices (many people would not be happy about that, running containers seems to be the next fashion).
On my Audience (128MB flash, 256MB RAM) running v7.6 and wifiwave2 driver, flash usage is 53MB. 7.2rc4 npk size is 27MB (13MB for base package and 14MB for wifiwave2 package). I haven't manually downloaded any newer version, but I expect file sizes to be similar (if not larger) in recent versions. RAM utilization is lurking around 160MB, so it would be possible to fit upgrade packages in RAM disk.
I did try to partition flash disk to two 64MB partitions. It was running fine, but upgrades obviously failed due to lack of flash space on 64MB partition.
It is stored in the RAMdisk which is available in all devices that have 16MB flash and 128MB or more of RAM (and from very recently can now also be enabled on devices with more flash, THANKS!).
So that includes almost all new devices. The SMIPS routers (hAP lite and hAP mini) do not even have enough RAM for a RAMdisk, so they can store it only in flash.