FS#63858 - [samba] ping by NetBIOS name fails if nmblookup gives multiple IPs for host

Attached to Project: Arch Linux
Opened by viktor (dviktor) - Friday, 20 September 2019, 11:05 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 24 April 2022, 15:19 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jelle van der Waa (jelly)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Preface:
The same problem has been addressed here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825380) and here (https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1802628), but these bugs were closed "by accident" without actually resolving original problem. Also here is the discussion on Arch Linux forum (https://bbs.archlinux.org/viewtopic.php?id=245628).
I've set up samba according to wiki article, as it can be seen from configs below.

Description:

I have samba + winbind installed and configured as client, here is smb.conf on my desktop:
[global]
workgroup = BIOKINET
netbios name = desolve-lab
server string = desolve-lab SMB client
hosts allow = 172.16. 127.0.0.1
load printers = no
log file = /var/log/samba/%m.log
max log size = 100
log level = 2
dns proxy = no
security = user
map to guest = Bad User
wins server = 172.16.0.1

smb, nmb and winbind daemons are running fine. wins is appended to the nsswitch.conf:
[viktor@desolve-lab ~]$ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files mymachines systemd
group: files mymachines systemd
shadow: files

publickey: files

hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns wins
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

nmblookup works great and I have NetBIOS resolution (apocalypse is another Arch Linux SMB server; perch is Windows Server 2003 machine with OpenVPN client running on it):
[14:01 viktor@desolve-lab ~]$ nmblookup apocalypse
added interface enp3s0 ip=fdc0:3f33:18b5::9ce bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface enp3s0 ip=fdc0:3f33:18b5:0:97bb:ebcb:32e5:7af3 bcast= netmask=ffff:ffff:ffff:ffff::
added interface enp3s0 ip=172.16.140.49 bcast=172.16.255.255 netmask=255.255.0.0
Got a positive name query response from 172.16.140.43 ( 172.16.140.43 )
172.16.140.43 apocalypse<00>
[14:02 viktor@desolve-lab ~]$ nmblookup perch
added interface enp3s0 ip=fdc0:3f33:18b5::9ce bcast= netmask=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
added interface enp3s0 ip=fdc0:3f33:18b5:0:97bb:ebcb:32e5:7af3 bcast= netmask=ffff:ffff:ffff:ffff::
added interface enp3s0 ip=172.16.140.49 bcast=172.16.255.255 netmask=255.255.0.0
Got a positive name query response from 172.16.140.48 ( 172.16.140.48 10.177.77.209 )
172.16.140.48 perch<00>
10.177.77.209 perch<00>

However, ping works only for hosts with exactly one IP address assigned. For all other hosts it says "System error":
[14:04 viktor@desolve-lab ~]$ ping -c 3 apocalypse
PING apocalypse (172.16.140.43) 56(84) bytes of data.
64 bytes from 172.16.140.43 (172.16.140.43): icmp_seq=1 ttl=64 time=0.341 ms
64 bytes from 172.16.140.43 (172.16.140.43): icmp_seq=2 ttl=64 time=0.211 ms
64 bytes from 172.16.140.43 (172.16.140.43): icmp_seq=3 ttl=64 time=0.217 ms

--- apocalypse ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 0.211/0.256/0.341/0.059 ms
[14:04 viktor@desolve-lab ~]$ ping -c 3 perch
ping: perch: System error

Expected results:
ping can reach machine with several IPs assigned

Actual results:
for machines with several IPs assigned ping says "System error" instead of proper working
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Sunday, 24 April 2022, 15:19 GMT
Reason for closing:  No response
Comment by viktor (dviktor) - Friday, 11 September 2020, 19:48 GMT
Still observing the same behavior on Samba 4.12.6
Comment by Tobias Powalowski (tpowa) - Monday, 28 March 2022, 08:06 GMT
Still an issue?

Loading...