On an IPv6-enabled Linux samba server, smbd clutters syslog (and client log files) with nuisance messages:
Steps to reproduce:
Run samba server on IPv6-enabled machine and connect to shares from clients.
syslog messages like
May 8 15:19:48 server smbd: [2009/05/08 15:19:48, 0] lib/util_sock.c:matchname(1749)
May 8 15:19:48 server smbd: matchname: host name/address mismatch: ::ffff:192.168.1.2 != client.example.com
No such messages. client.example.com has IPv4 address 192.168.1.2. Address and name should match.
samba 3.3.4 on Fedora 9/x86
Also observed on:
samba 3.2.x on Fedora 9/x86
Created attachment 4157 [details]
Proposed fix for IPv6-related name/address mismatch
Here is a proposed patch for the host name/address mismatch messages. It fixes the matchname function to work properly with IPv4-mapped IPv6 addresses. (This might fix other problems, too.) If the sockaddr argument belongs to family AF_INET6, and if it represents an IPv4-mapped address, then getaddrinfo is called with additional flags AI_V4MAPPED|AI_ALL. The result list then also contains the hosts IPv4 addresses in mapped form, so the comparison with sockaddr can be done properly (apples to apples ;))
Unfortunately, for this to work, interpret_string_addr_internal() needs to get an additional argument (the address family). That should be acceptable as it is a local function only, so all its callers are in the same file. Alternatively, one could call getaddrinfo directly from within matchname, at the cost of code duplication.
+1 on the patch in comment 1
Version-Tested: 3.3.7 (on CentOS 4)
Without this patch, hostname-based whitelists fail to function properly on systems that support IPv6 but are deployed on IPv4-only networks (which describes most systems I've come in contact with). With the patch, which looks reasonable to me, hostname-based whitelists work as expected.
This is a regression from samba 3.0.x, where this worked correctly.
This bug is still present in samba-3.5.10-125.el6.i686 on CentOS 6. Please could we have it fixed?
This is not an issue with recent versions, I think, if you see this issue with 4.12 or newer, feel free to reopen this bug.