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. Actual results: syslog messages like May 8 15:19:48 server smbd[442]: [2009/05/08 15:19:48, 0] lib/util_sock.c:matchname(1749) May 8 15:19:48 server smbd[442]: matchname: host name/address mismatch: ::ffff:192.168.1.2 != client.example.com Expected results: No such messages. client.example.com has IPv4 address 192.168.1.2. Address and name should match. Build/Platform: 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.