sqConnectToAddressSize: Address family not supported by protocol

> Name-resolution does not seem to be the issue.  NetNameResolver
> produces a SocketAddress whose printString pretty much matches what I
> get using "host" on the linux command-line.
>
> The issue is that Squeak is unable to use its own SocketAddress
> representation to make the connection.  And it reports this error from
> the VM:
>
>    sqConnectToAddressSize: Address family not supported by protocol
>
> Does anyone know what that means?

> On Fri, Sep 20, 2013 at 9:21 PM, tim Rowledge <[hidden email]> wrote:
>> All I can think of for now is to try some non-squeak resolver type tools and at least get evidence as to whether it's them or us.
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful random insult:- Has an inferiority complex, but not a very good one.
>>
>>
>>
>

>
> On 21-09-2013, at 10:14 AM, Chris Muller <[hidden email]> wrote:
>
>>   sqConnectToAddressSize: Address family not supported by protocol
>
> Googling the error message suggests it's a pretty common issue. The explanations seem to veer all over the place but the simplest one (ie one I can understand…) is
> http://help.directadmin.com/item.php?id=474
> It seems as if it is a widely caused library error, but we're well outside my OS comfort zone already.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
>
>
>

> Am 21.09.2013 um 22:04 schrieb Chris Muller <[hidden email]>:
>
>> Using curl for http get produces nearly the opposite results as using squeak.
>>
>> Connected to GF:
>>  curl --ipv6 --get www.yahoo.com
>>          ("...a bunch of http...")
>>
>> Connected to Surewest:
>>   curl --ipv6 --get www.yahoo.com
>>          "curl: (7) Failed to connect to 2001:4998:f011:1fe::3000:
>> Network is unreachable"
>>
>
>
> are you positive that IPv6 is enables in your image?
>
>> On 21 September 2013 18:14, Chris Muller <[hidden email]> wrote:
>>> Name-resolution does not seem to be the issue.  NetNameResolver
>>> produces a SocketAddress whose printString pretty much matches what I
>>> get using "host" on the linux command-line.
>>>
>>> The issue is that Squeak is unable to use its own SocketAddress
>>> representation to make the connection.  And it reports this error from
>>> the VM:
>>>
>>>  sqConnectToAddressSize: Address family not supported by protocol
>>>
>>> Does anyone know what that means?
>>
>> Well, the error is quite clear, or would be if the error told us which
>> "address family" and "protocol" were involved. What does strace tell
>> you?
>>
>
> protocol would ipv6 in this case but af might be inet, but should be inet6, iirc.
>
> Best
> -tobias

> On 2013-09-21, at 23:55, Tobias Pape <[hidden email]> wrote:
>
>> Am 21.09.2013 um 22:04 schrieb Chris Muller <[hidden email]>:
>>
>>> Using curl for http get produces nearly the opposite results as using squeak.
>>>
>>> Connected to GF:
>>>  curl --ipv6 --get www.yahoo.com
>>>          ("...a bunch of http...")
>>>
>>> Connected to Surewest:
>>>   curl --ipv6 --get www.yahoo.com
>>>          "curl: (7) Failed to connect to 2001:4998:f011:1fe::3000:
>>> Network is unreachable"
>>>
>>
>>
>> are you positive that IPv6 is enables in your image?
>>
>>> On 21 September 2013 18:14, Chris Muller <[hidden email]> wrote:
>>>> Name-resolution does not seem to be the issue.  NetNameResolver
>>>> produces a SocketAddress whose printString pretty much matches what I
>>>> get using "host" on the linux command-line.
>>>>
>>>> The issue is that Squeak is unable to use its own SocketAddress
>>>> representation to make the connection.  And it reports this error from
>>>> the VM:
>>>>
>>>>  sqConnectToAddressSize: Address family not supported by protocol
>>>>
>>>> Does anyone know what that means?
>>>
>>> Well, the error is quite clear, or would be if the error told us which
>>> "address family" and "protocol" were involved. What does strace tell
>>> you?
>>>
>>
>> protocol would ipv6 in this case but af might be inet, but should be inet6, iirc.
>>
>> Best
>>       -tobias
>
> Definitely looks like an IPv6 issue, which should work in theory if the VM has the new Socket plugin, but has not been extensively tested.
>
> You could try with Etoys from squeakland.org which used to handle IPv6 just fine, at least under Linux. It was not tested much on other OS either.
>
> Would be nice to get this ironed out (though there is the option of disabling IPv6 in your OS).
>
> - Bert -
>
>
>

> On 2013-09-23, at 21:01, Chris Muller <[hidden email]> wrote:
>
>> A tier-2 support specialist from Google just left.  No one was sure
>> what the precise cause of the issue was, but by changing my IPv6
>> Method (in Ubuntu's connection editor) from "Automatic" to "Ignore",
>> and then back to "Automatic", followed by a reboot of the router,
>> seems to have cleared the issue up.  Everything seems to be working
>> fine even with Squeak's IPv6 turned on.
>>
>> Thank you all for the suggestions, I'm glad it was my problem and not Squeak.
>
>
> So does your Squeak use IPv6 now? Or does it work because it falls back on IPv4?
>
> - Bert -
>
>
>

> Chris, if you go here - http://www.kame.net/ - do you see a dancing
> turtle? (If you do, you have full IPv6 connectivity to that machine.)
>
> frank
>
> On 21 September 2013 18:48, tim Rowledge <[hidden email]> wrote:
>>
>> On 21-09-2013, at 10:14 AM, Chris Muller <[hidden email]> wrote:
>>
>>>   sqConnectToAddressSize: Address family not supported by protocol
>>
>> Googling the error message suggests it's a pretty common issue. The explanations seem to veer all over the place but the simplest one (ie one I can understand…) is
>> http://help.directadmin.com/item.php?id=474
>> It seems as if it is a widely caused library error, but we're well outside my OS comfort zone already.
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
>>
>>
>>
>

> Oops, just saw your second note Frank--
>     No, the turtle doesn't dance.
>
> But I'm back to using my old ISP again because GF started flaking out
> again with the same issues.
>
> So is it possible THAT is why it's "working" with my old ISP?  Because
> my connection with them is not even IPv6 "capable" and so Squeak was
> never attempting to use IPv6 even though the preference was enabled?
> (Whew!)
>
> On Sat, Sep 21, 2013 at 1:38 PM, Frank Shearar <[hidden email]> wrote:
>> Chris, if you go here - http://www.kame.net/ - do you see a dancing
>> turtle? (If you do, you have full IPv6 connectivity to that machine.)
>>
>> frank
>>
>> On 21 September 2013 18:48, tim Rowledge <[hidden email]> wrote:
>>>
>>> On 21-09-2013, at 10:14 AM, Chris Muller <[hidden email]> wrote:
>>>
>>>>   sqConnectToAddressSize: Address family not supported by protocol
>>>
>>> Googling the error message suggests it's a pretty common issue. The explanations seem to veer all over the place but the simplest one (ie one I can understand…) is
>>> http://help.directadmin.com/item.php?id=474
>>> It seems as if it is a widely caused library error, but we're well outside my OS comfort zone already.
>>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>> Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
>>>
>>>
>>>
>>
>

> It's actually harder to tell than that. If you say "connect to
> www.kame.net" you'll issue some kind of DNS request. IPv6 addresses
> are stored in AAAA records and IPv4 addresses in A records, so if you
> ask for both you could end up connecting using either IPv6 or IPv4,
> depending on how the socket code's written.
>
> For instance you could write the socket connection logic to say
> 'resolve for AAAA and A, and iterate over the AAAA records trying to
> connect to each IPv6 address in turn, falling back to the A records,
> and bailing as a last resort'. I have no idea how Squeak's network
> code will do this. Running strace would tell you the OS level calls
> Squeak made, which should shed some light on the problem.
>
> Just yesterday I ran into a problem at work where 'localhost' meant
> 127.0.0.1 on my machine, and ::1 on a build slave. That wasn't fun to
> understand.
>
> frank

>
> On 2013-09-24, at 11:03, Frank Shearar <[hidden email]> wrote:
>
>> It's actually harder to tell than that. If you say "connect to
>> www.kame.net" you'll issue some kind of DNS request. IPv6 addresses
>> are stored in AAAA records and IPv4 addresses in A records, so if you
>> ask for both you could end up connecting using either IPv6 or IPv4,
>> depending on how the socket code's written.
>>
>> For instance you could write the socket connection logic to say
>> 'resolve for AAAA and A, and iterate over the AAAA records trying to
>> connect to each IPv6 address in turn, falling back to the A records,
>> and bailing as a last resort'. I have no idea how Squeak's network
>> code will do this. Running strace would tell you the OS level calls
>> Squeak made, which should shed some light on the problem.
>>
>> Just yesterday I ran into a problem at work where 'localhost' meant
>> 127.0.0.1 on my machine, and ::1 on a build slave. That wasn't fun to
>> understand.
>>
>> frank
>
>
> The old socket plugin code uses gethostbyname() and returns the first of the list of answers, without even checking that the answer is, in fact, an IPv4 address.
>
> The new socket plugin code uses getaddrinfo() and answers the full list of addresses, so the image can figure out which one it prefers.
>
> Both old and new is still supported in the plugin so it's up to the image to use either.
>
> NetNameResolver addressesForName: 'www.google.com'
> ==> an OrderedCollection(
>         173.194.44.51(muc03s08-in-f19.1e100.net),0(0)-inet4-stream-tcp
>         173.194.44.48(muc03s08-in-f16.1e100.net),0(0)-inet4-stream-tcp
>         173.194.44.49(muc03s08-in-f17.1e100.net),0(0)-inet4-stream-tcp
>         173.194.44.52(muc03s08-in-f20.1e100.net),0(0)-inet4-stream-tcp
>         173.194.44.50(muc03s08-in-f18.1e100.net),0(0)-inet4-stream-tcp
>         2a00:1450:4016:803::1011(muc03s08-in-x11.1e100.net),0(0)-inet6-stream-tcp)
>
> If you use "NetNameResolver addressForName: ..." then it will either use the old code (if forced by preference) or answer the first of the addresses.
>
> I myself cannot easily test IPv6 as it's not natively supported by my ISP, yet.
>
> If it did, then both of these should work equally:
>
>         HTTPSocket httpGetDocument: 'ipv4.whatismyv6.com'
>         HTTPSocket httpGetDocument: 'ipv6.whatismyv6.com'
>
>
> - Bert -
>
>
>