Ok, what should be my next step given that socat is returning nil? Is there anything else needed on the command line to make hints work? Here’s what I’ve found thus far:
hints get
[string “init”]:198: [string “hints get”]:1: ‘=’ expected near ‘get’
hints get [‘localhost’]
[string “init”]:198: [string “hints get [‘localhost’]”]:1: ‘=’ expected near ‘get’
The messages seem to suggest that an ip:port is desired, but per your earlier post this should be reading sockets, not ip addresses?
No, that’s just a confusing error message. The config language is lua 5.1, implemented by luajit. In short, you can set additional hints e.g. by hints['foo'] = '1.2.3.4' and read them by hints['foo'].
What does nil mean in this context… no hints loaded? What do I do next to track down the cause? Are others reporting a similar issue, or is there something I should check in my configuration that may be causing this?
So, I think the cause of this all is that the meaning of hints.config('foo') is to clear up any hints and load a hosts-like file. As knot-resolver documentation didn’t mention this important point, it was easy to get caught by that. Any idea how that second hints.config line got in? I don’t see it in the Omnia scripts generating the config, but maybe I’m missing something.
By “second hints.config line”, I think you are referencing the line above the policy:add statement near end of file:
hints.config(‘/tmp/hosts/dhcp’)
I’ve not looked at the autogenerate scripts, so I can’t explain that. I have been reviewing my Omnia config via LuCI, and thus far have not found any filed containing /tmp/hosts/dhcp. Will keep looking, but am posting this in the hope that someone involved in assembling the scripts for Omnia might know.
In case it’s useful, the contents of /tmp/hosts/dhcp on my Omnia is:
auto-generated config file from /etc/config/dhcp
x.x.x.1 nxnet
While /etc/config/dhcp does contain the full list of static dhcp assignments that I configured in LuCI, /tmp/hosts/dhcp only contains the above resolution for the router (dns/dhcp server) itself. Again, I’m not familiar with the code, but offhand I’m unclear how that self-reference would cause 6 servers named “up-0X.local” to fail to resolve. All other servers are resolving by name.
@vcunat Is there a config setting to cause kresd to log all requests to syslog/messages? Is this done by setting “verbose”?
The online Knot docs indicate that persistent config files can be created in /tmp/run/kresd (dir does not exist on Omnia, so would be created). Does anyone know if this still works on Omnia given the three different packages used for dns/dhcp?
@vcunat I re-read the thread that you referenced. If you are referring to my question about manual updates to the autogenerated file, I never got an answer nor pursued that further. Correction to my earlier version of this post, I did find one change made in response to the posting:
/etc/init.d/kresd
Add those two lines:
in section init_header, after line echo " ‘policy’" >> $CONFIGFILE
echo " , ‘hints’" >> $CONFIGFILE
in section load_uci_config_common, after line set_param_func “cache.clear” “”
set_param_func “hints.config” “‘/tmp/hosts/dhcp’”
Specifically change #2 was still implemented on my Omnia. Change #1 existed in the original version of my file, although prior to rather than after the line indicated. I did not make change #1 - left that part of the config as original. Am testing backout of change #2.
The verbose mode makes kresd print more information into the standard error output. I don’t know where Omnia puts that.
Yes, I meant change #2, as that’s apparently what adds hints.config('/tmp/hosts/dhcp') call near the end of the config file, which is what erases all the hints added above that point.
@nijel I’m applying your recommendation. The killall kresd didn’t work, so I used /etc/init.d/kresd stop. Resolved error I’d previously posted in this reply - likely tired eyes and sloppy typing on my part. Running kresd at console now. Will report back on results.
Problem solved. I fixed my typo in the kresd.config file, though would have expected that to cause resolve failure for all servers if that was causal. Then I found I was able to resolve the up-NN machines from my laptop, starting about a half hour ago. The laptop had been having the same resolution problem prior to that. Desktop, however, was still failing to resolve those 6 servers after the laptop started working. Compared the network configurations of the Mac Air vs iMac. Air was static assigned DHCP. iMac was manual assignment with the same values (different ip address!!). I noticed the Default Router field was assigned by DHCP on the Air, but was not available on the iMac manual config for assignment, thus was blank on the iMac. Switched the iMac to static DHCP just like the Air. I can now resolve the up-NN 6 hosts, and still can resolve all of the others that were working before from iMac and other machines.
Footnote: the iMac was rebooted earlier this morning due to network failure on that machine. Reboot does not explain things now working b/c the reboot was hours ago; and the resolution failures continued up to just recently, post reboot. This, along with other issues I’ve experienced with the iMac, however, is causing me to doubt the stability of Mac OS.
Footnote 2: I’d briefly reported resolution failures after restarting kresd in normal mode via /etc/init.d/kresd start. After further restarts and testing, I believe that I tested too quickly on the iMac. All appears to be working at this point.
