ns: sa_set: ... (Invalid argument) messages during startup

[borosai]

Hello. I'm attempting to configure baresip v1.1.0 on my OpenBSD-current system. The last time I used baresip was a few years ago, and I don't recall seeing the following messages (or something similar) printed while starting up the program.

ns: sa_set: 10.0.0.1 # resolvd: em0 (Invalid argument)
ns: sa_set: fd00:10::1 # resolvd: em0 (Invalid argument)

Earlier this year, OpenBSD introduced resolvd(8) [1], and as a result, the nameserver entries in /etc/resolv.conf are now formatted by resolvd as follows:

nameserver 10.0.0.1 # resolvd: em0
nameserver fd00:10::1 # resolvd: em0

I wasn't able to confirm this on my own, so I just wanted to check if the addition of "# resolvd: em0" to the nameserver entries is possibly causing this message/issue.

[1] https://man.openbsd.org/resolvd

[sreimers]

Can you try the git version: https://github.com/baresip/baresip/wiki/Install:-GIT-Version

[borosai]

Sure, I can give it a shot.

By the way, is there a specific change after v1.1.0 that I would be testing? I'm just wondering if it would be simpler to patch the OpenBSD port (locally, for testing), or to apply OpenBSD's patches to my own build using your instructions.

[sreimers]

You can try make HAVE_RESOLV=1 for libre stable.

[borosai]

I modified and built OpenBSD's re port with your recommendation, and after rebuilding baresip as well, the messages still appear. I looked at the rest of the baresip port [1], and noticed that HAVE_RESOLV appears to be set already (Makefile.inc), but I haven't worked much with ports so I may be wrong. If you want, I could ask about this package on the OpenBSD ports mailing list, and get back to you with more accurate information.

Also, I was looking at re's source code to try to understand what's going on, and the parse_resolv_conf function in /src/dns/ns.c appears to be the default method, correct? If it is indeed having issues parsing the new nameserver lines, would modifying that to ignore everything after the address (second field) be an option?

[1] https://cvsweb.openbsd.org/ports/telephony/baresip/

[borosai]

I was curious, so I decided to do some additional testing. I changed the regex string on line 64 in /src/dns/ns.c from "nameserver [^\n]+" to "nameserver [^ ]+", like the strings for domain and search parsing. Could this introduce any issues I haven't considered?

Anyway, after building the patched re package, and running baresip, the messages are gone and /netstat displays the following (shortened version):

/netstat
...
DNS Servers from System: (2)
   0: 10.0.0.1:53
   1: [fd00:10::1]:53

Do the square brackets around the IPv6 address have any significance?

Using the unmodified re package, I get the following instead:

/netstat
...
ns: sa_set: 10.0.0.1 # resolvd: em0 (Invalid argument)
ns: sa_set: fd00:10::1 # resolvd: em0 (Invalid argument)
 DNS Servers from System: (0)

Again, I'm not sure if this is the best option, but it seems to work. Would you recommend another solution?

[alfredh]

the most flexible solution is probably to ignore the comment in the parsing:

$ cat /etc/resolv.conf 
domain getinternet.no
search getinternet.no
nameserver 10.0.1.1
nameserver 10.0.1.2      # here is a comment

[sreimers]

Yes I think we should improve the parse_resolv_conf for comments, but I still wonder why HAVE_RESOLV is not used, it should be the preferred method. @borosai could you test the GIT Version? I will move the issue to https://github.com/baresip/re

[borosai]

I will try to test the Git version this weekend, but it may take a bit longer. Regardless, improving the way comments are handled seems like a positive change.

[borosai]

I just finished testing the Git versions of baresip, re, and rem. Unfortunately I'm still seeing the same messages.

If you're up to it, I can only recommend visiting the CVS link I posted above, where you can look for any changes introduced in the OpenBSD port (Makefiles, patches, etc.) that could be affecting the expected behavior. I don't know what to look for, so I wouldn't be much help with that.

[sreimers]

Sorry fo the delay. What compiler do you use? I just realized OpenBSD has a modificated/old gcc as system compiler:

man gcc-local

gcc does not search under /usr/local for include files nor for libraries: as a system compiler, it only searches the system paths by default.

You can try:

gmake CC=clang

[borosai]

No problem. OpenBSD switched the system compiler to clang back in 2017.

$ clang --version
OpenBSD clang version 13.0.0