[Samba] Bug 6870 resurfaced in Samba 4.2.10

[Rebecca Gellman]

Hi, 

ifconfig doesn't show IPv6 addresses because IPv6 is disabled on all
interfaces (via sysctl). While it's in this state, it is not possible to
configure an IPv6 address (both ip and ifconfig return errors). 

As can be seen in the strace, the IPv6 socket fails and samba gives up,
rather than checking the IPv4 socket. Even if IPv6 addresses were
available, this behaviour is wrong. 

Regards 

Rebecca Gellman 

On 2016-10-14 07:40, L.P.H. van Belle via samba wrote: 

> Hai, 
> 
> Did you check if ifconfig still shows ipv6 adresses. ( even ::1 ) 
> 
> Can you check that. 
> 
> I have several with ipv6 on and severel only ipv4. 
> As of 4.1.17+ i didnt see this happing here. Now on 4.4.5 
> I think you have forgotten something. 
> 
> Greetz, 
> 
> Louis
> 
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Rebecca Gellman
>> via samba
>> Verzonden: donderdag 13 oktober 2016 17:07
>> Aan: samba at lists.samba.org
>> Onderwerp: [Samba] Bug 6870 resurfaced in Samba 4.2.10
>> 
>> According to this bugzilla entry, bug 6870 has been fixed as of at least
>> version 3.5:
>> 
>> https://bugzilla.samba.org/show_bug.cgi?id=6870
>> 
>> However, I assert that it is present in 4.2.10, which ships with Debian
>> Jessie.
>> 
>> On my home network (IPv4 and IPv6), a box with Samba 4.2.10 with IPv6
>> disabled (via sysctl), will fail to contact a DC because the IPv6
>> connect fails immediately before the v4 connect has a chance to succeed.
>> 
>> I determined this by strace'ing the "net ads workgroup" command, which
>> resulted in the following:
>> 
>> 11:41:52 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 11 <0.000027>
>> 11:41:52 fcntl(11, F_GETFL) = 0x2 (flags O_RDWR) <0.000015>
>> 11:41:52 fcntl(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0 <0.000016>
>> 11:41:52 fcntl(11, F_GETFD) = 0 <0.000015>
>> 11:41:52 fcntl(11, F_SETFD, FD_CLOEXEC) = 0 <0.000016>
>> 11:41:52 connect(11, {sa_family=AF_INET, sin_port=htons(389),
>> sin_addr=inet_addr("192.168.81.132")}, 16) = 0 <0.000050>
>> 11:41:52 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 12 <0.000025>
>> 11:41:52 fcntl(12, F_GETFL) = 0x2 (flags O_RDWR) <0.000016>
>> 11:41:52 fcntl(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0 <0.000015>
>> 11:41:52 fcntl(12, F_GETFD) = 0 <0.000016>
>> 11:41:52 fcntl(12, F_SETFD, FD_CLOEXEC) = 0 <0.000015>
>> 11:41:52 setsockopt(12, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0 <0.000018>
>> 11:41:52 connect(12, {sa_family=AF_INET6, sin6_port=htons(389),
>> inet_pton(AF_INET6, "2001:8b0:1627:1::2", &sin6_addr), sin6_flowinfo=0,
>> sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
>> <0.000032>
>> 11:41:52 close(12) = 0 <0.000028>
>> 11:41:52 close(11) = 0 <0.000024>
>> 11:41:52 close(10) = 0 <0.000020>
>> 11:41:52 fcntl(8, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=288,
>> len=1}) = 0 <0.000021>
>> 11:41:52 fcntl(8, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=288,
>> len=1}) = 0 <0.000018>
>> 11:41:52 fcntl(9, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=48,
>> len=1}) = 0 <0.000019>
>> 11:41:52 fcntl(9, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=48,
>> len=1}) = 0 <0.000032>
>> 11:41:52 fcntl(9, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=48,
>> len=1}) = 0 <0.000019>
>> 11:41:52 fcntl(9, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=48,
>> len=1}) = 0 <0.000017>
>> 11:41:52 write(2, "ads_connect: No logon servers\n", 30ads_connect: No
>> logon servers
>> 
>> As you can see, sockets 11 and 12 are setup to contact the DC, 11 to v4,
>> and 12 to v6. connect() on socket 11 is successful (returns 0), but
>> connect() on socket 12 returns -1 due to "Network unreachable" - this is
>> correct as the box in question does not have IPv6.
>> 
>> The attempt is abandoned (implied by the immediate closing of sockets 11
>> and 12, and the writing of "No logon servers" to stderr) before any
>> attempt is made to talk on socket 11 (v4).
>> 
>> After futzing the box to have an IPv6 address with appropriate routing,
>> the attempt succeeds as expected. However, for reasons (too long to go
>> into here) this is not a solution, only a means of proving the problem.
>> 
>> Since most DCs publish v6 records of some kind in DNS in an AD setup
>> these days, it would seem that this behaviour could do with urgently
>> fixing.
>> 
>> Any comments from the samba bods, or should I forward this on to
>> samba-technical ?
>> 
>> Thanks
>> 
>> -- Rebecca Gellman
>> 
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba