This is a discussion on Re: Samba 4 and IPv6 - Samba ; Hi Tridge, email@example.com wrote: > Hi David, > > (I have replied CCing the samba-technical list, as others may be > interested. I hope you don't mind) > > > Did you manage to make any more progress with Samba ...
> Hi David,
> (I have replied CCing the samba-technical list, as others may be
> interested. I hope you don't mind)
> > Did you manage to make any more progress with Samba 4 and IPv6?
> yes, I stayed up late working on it last night. I attach my current
> patch. Note that it ended up being very different from the approach
> you took. Instead of having new ipv6 routines in socket_ip.c, I am now
> teaching all the IP code to know about both v4 and v6. I have also
> continued the trend to using char* to represent IPs, and have moved to
> using the more modern getnameinfo(), getaddrinfo() etc calls.
This looks great. My patch was a bit of a hack so your approach is better.
Did you consider moving to sockaddr_storage? Jeremy did this in Samba
3.2. Sockaddr_storage makes it easier to write protocol independent
code. This way you don't need to teach much of the code to know about
both v4 and v6 just use sockaddr_storage.
Jeremy mapped sockaddr_storage to whatever was available on platforms
that did not have the IPv6 socket API.
I know you did not like this idea, but I still like using getnameinfo()
to return textual IP addresses. The reason is that it is protocol
independent. The flag NI_NUMERICHOST ensures that no DNS lookups take
place. This gets rid of a lot of inet_ntop() calls that have to
explicitly specify the address family. It is a little slower though...
> The other major change is the "late binding" of the socket functions
> to either v4 or v6. When you call socket_create() on an IP socket it
> doesn't create the socket immediately. It waits until you do a listen,
> or a connect or similar, and uses the address arguments passed to
> those to work out whether you really need v4 or v6. If however you
> pass an explicit "ipv4" to socket_create() then it will force it to
> ipv4. That is used by the nbt code. All the other code just asks for
> "ip" and it works out the right address family when you first use the
> There are still a couple of kinks in the patch below that I need to
> work out, but I think the general approach will work well.
> Cheers, Tridge
I'll try this patch out either tomorrow or when I am on holiday!