You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the hostname is changed, e.g., by the hostname command, llmnrd will still use the old one. We can poll /proc/sys/kernel/hostname to get notified if the hostname is written, though; systemd does this as well.
See the attached patch for suggestions. It is more of a hack for now (and probably has to be restructured), but it works for us.
I see one issue in case the hostname was set via command line parameter -H and then the system host name gets changed, we'll still call hostname_change_handle(). If now the new hostname is longer than the one being set via command line, we'll overrun the buffer in the `strcpy()' call.
In any case I think this behavior could be unintuitive to the user (after all they explicitly set the hostname) and IMO the proper solution would be to not react on system hostname changes in case the LLMNR hostname was set via command line.
I'll adjust your patch accordingly if that's OK with you...
EDIT: Sorry, I didn't read your patch properly. Of course llmnrd_fd_hostname is only open()'ed in case the hostname is not set manually. So everything is fine with your patch and I'll apply it as such.
If the hostname is changed, e.g., by the
hostname
command, llmnrd will still use the old one. We can poll/proc/sys/kernel/hostname
to get notified if the hostname is written, though; systemd does this as well.See the attached patch for suggestions. It is more of a hack for now (and probably has to be restructured), but it works for us.
llmnrd-poll-hostname.patch.txt
The text was updated successfully, but these errors were encountered: