use dns servers from udhcpc
sheridans opened this issue · 10 comments
Have this working fine specifying public dns servers via udhcpd.conf via options, however it would be useful to be able to update the dns servers in resolv.conf on the host with those from udhcpc on the bhyve client, as it break local dns resolution (especially with local histnames, vlans, etc).
For example when udhcpc runs, it creates a (local) file in bhyve located at /tmp/resolv.conf. There doesn't seem anyway to get this to the host. If there was a way of linking /etc/resolv.conf on the host to say (writable) /media/etc/resolv.conf on the vm as you can link the wpa_supplicant.conf that may help?
Sorry if I have missed something and there is a way to do this.
Hi @sheridans: I am not sure if I see you meant here. The /etc/resolv.conf file would always be re-generated by resolvconf(8) when dhclient(8) gets an IP address via wifibox0 on the host. The resolv.conf file that is generated by udhcpc could be exported to the host through /media/etc for sure, but what would you do with that file? Note that wpa_supplicant.conf(5) is a separate file that lives under $LOCALBASE/etc/wifibox/wpa_supplicant and it is not that same as /etc/wpa_supplicant.conf -- they only share the same format.
I'm guessing I set it up wrong, i actually created a link to the /etc/wpa_supplicant.conf as opposed to copying it:
$ cd /usr/local/etc/wifibox/wpa_supplicant
$ doas mv wpa_supplicant.conf wpa_supplicant.bak
$ doas ln /etc/wpa_supplicant.conf ./
With regards to handling /etc/resolv.conf maybe there is away to modify the dns in udhcpd.conf file from the default.script of udhcpc that runs after it gets an address? But that would require rw access. Failing that I could use a script to replace /etc/resolv.conf with that exposed to the host by the vm (as you mentioned).
dhclient wifibox0 && cp /usr/local/etc/wifibox/appliance/resolv.conf /etc/resolv.conf
Seems kind messy to but would work around ¯_(ツ)_/¯
Not sure best approach round this, add dns resolver to bhyve image and point dns to that? Extra overhead with that option
Did I understand it well that you have a DHCP server on the wireless network that forwards some special configuration for the clients? And the problem is that this set of information is lost somewhere between udhcpc and udhcpd?
Ideally, the FreeBSD host (the client of the client) should get all the extra data from the DHCP server in the guest, which is then relayed to /etc/resolv.conf. I think a potential solution for the problem could be to implement a 1:1 NAT or networking bridging, perhaps. Otherwise I can imagine only various workarounds as you also suggested. Let me think about this.
In my case it's not dhcp options causing an issue, simply name resolution. For example at work we have hostnames which only resolve internally so using public dns servers causes a problem. Having to manually edit /etc/resolv.conf to manually point to local dns resolvers is a bit of a pain.
It wouldn't be an issue with a static desktop that never moves as you could just set the opt dns 192.168.1.1 in udhcpd for example as it would never change. With a laptop that's carried between various places with local dns servers requires constantly editing /etc/resolv.conf hence if there was a way to export the '/tmp/resolv.conf' from the alpine guest to the main host would at least be able to script copy that over the hosts /etc/resolv.conf
hopefully this makes sense
Okay, I will see what I can do to support this use case.
@sheridans I have added support for propagating the DNS information between udhcpc and udhcpd. You can test it by installing the net/wifibox-alpine port from the development tree: https://github.com/pgj/freebsd-wifibox-port/tree/1302885fa7ae2c8e078766b305004beacd245f61 . Let me know how it works for you.
I did not receive any answer on this, so I assume my proposal is acceptable. Therefore I am closing this ticket. Please re-open if there is anything to follow up.
Hadn't got around to trying it, thanks for the follow up, will let you know how it goes.
Sorry for late reply, works perfectly after testing on multiple systems - thank you!
That is great to hear, you are welcome. Thanks for the feedback.