Smalltalk › Gemtalk › GLASS

Zinc on 3.1

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

dario trussardi

Re: IPv6 and IPv4 issues (was Zinc on 3.1)

Ciao Dale,

i'm not expert into internet configurations,

> Dario and Ken,
>
> We've gotten to the bottom of the problem and we have some bugs in our socket code related to IPv6 and IPv4 addresses ... As Ken observed, we are not listing all of the entries that we should.
>
> The primitive code used in both GsSocket class>>getHostAddressesByName: and GsSocket>>connectTo:on:timeoutMs: has the same bug. We have a bug fix, but it is in the primitive C code. The fix will be included in 3.1.0.3 when it becomes available.
>
> The only workaround that we know of is to either use on of the IPv4 addresses (acquired via a different means ... System class>>performOnServer: probably) or to enable IPv6 support on your machine.

my server where GLASS run have IPv6 enable.

The cat /proc/sys/net/ipv6/conf/all/disable_ipv6 answer 0

But it's not enough.

Questions:

A) i need to disable IPv6 on my server so as it manage only IPv4 ?

B) B1 i need a modem-router enabled to manage IPv6?

B2 and internet provider which support IPv6 ?

Thanks,

Dario

>
> Dale
>
> ----- Original Message -----
> | From: "Dale Henrichs" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, February 1, 2013 10:13:45 AM
> | Subject: Re: [GS/SS Beta] Zinc on 3.1
> |
> | Dario and Ken,
> |
> | I'm having one of our engineers look into the ipv4/ipv6 issues ...
> |
> | Dale
> |
> | ----- Original Message -----
> | | From: "Dario Trussardi" <[hidden email]>
> | | To: "GemStone Seaside beta discussion" <[hidden email]>
> | | Sent: Tuesday, January 29, 2013 2:52:42 AM
> | | Subject: Re: [GS/SS Beta] Zinc on 3.1
> | |
> | |
> | | Ciao,
> | |
> | |
> | | someone addressed the issue relative to the www.google.com IP
> | | resolution into GLASS 3.1.0.2?
> | |
> | |
> | | Any idea about it?
> | |
> | |
> | | Thanks,
> | |
> | |
> | | Dario
> | |
> | |
> | |
> | |
> | |
> | |
> | | Ciao,
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> | | On Jan 22, 2013, at 1:29 PM, Dale Henrichs wrote:
> | |
> | |
> | |
> | | | … and I needed a fix to DateAndTime>>asTimeStamp that's in a
> | | | recent
> | | | Squeak package but not in the Squeak.v3 package yet.
> | |
> | | Good catch ...
> | |
> | |
> | | Published as Squeak.v3-KenTreis.287.1 in case it's helpful for your
> | | merge.
> | |
> | |
> | |
> | |
> | | Typically I think these things go haywire because the process
> | | handling in zinc for multi-threaded processing is not very tolerant
> | | of errors ... I've seen a lot of infinite process forking loops get
> | | started (especially in the tests) when an error condition is hit
> | | ...
> | | perhaps the delay in the ensure block simply slowed down the
> | | inifinite forking loop enough to make it manageable ...
> | |
> | | While GemStone does not make it easier to debug the multi-process
> | | rats nest ... I think that there are only a handful of spots that
> | | need to be cleaned up (where the forks are) and make sure that
> | | certain types of errors short-circuit a fork that will lead right
> | | back to the original problem …
> | |
> | |
> | | I may have seen this too, some failing tests would lead to a temp
> | | object memory overflow. I didn't characterize it any further.
> | |
> | |
> | |
> | |
> | | I have yet to try the zinc stuff in 3.1.0.2, but it sounds like
> | | we've
> | | got come 3.1.0.2 specific sigsegv problems on the mac that will be
> | | easier for us to debug if we can reproduce the problems locally ...
> | | Have you been getting sigsegvs in 3.1.0.1 as well?
> | |
> | |
> | | Just in 3.1.0.2. I haven't seen any in 3.1.0.1.
> | |
> | |
> | |
> | |
> | |
> | | | I'm still getting some test failures/errors, but I think they're
> | | | mostly related to my development setup. One of them tries to
> | | | connect
> | | | to Google by name, but it ends up resolving as an IPv6 address
> | | | which
> | | | my network doesn't currently support. I looked quickly but didn't
> | | | see an easy way within SocketStream / SPort to request only IPv4
> | | | addresses.
> | |
> | | I think we only do IPv6 calls these days ... I'm not completely up
> | | to
> | | speed on how IPv4 networks are handled, but I think that you have
> | | to
> | | have IPv6 support enabled in the kernel for 3.x…
> | |
> | |
> | |
> | | Found a little more on this -- I think it may be partially in Sport
> | | and partially in GS. I have hacked around Sport for now, but the
> | | larger issue is inside a primitive invoked by
> | | GsSocket>>connectTo:on:. When debugging `GsSocket new connectTo: 80
> | | on: 'www.google.com'`, I see that the address list returned by
> | | two-arg primitive #25 only has one entry: Google's IPv6 address. As
> | | far as I can tell, the list should contain multiple entries, like
> | | what I get from the command line:
> | |
> | |
> | | $ host www.google.com
> | |
> | | www.google.com has address 74.125.141.99
> | | www.google.com has address 74.125.141.105
> | | www.google.com has address 74.125.141.104
> | | www.google.com has address 74.125.141.106
> | | www.google.com has address 74.125.141.147
> | | www.google.com has address 74.125.141.103
> | | www.google.com has IPv6 address 2607:f8b0:400e:c00::69
> | |
> | |
> | | I'm guessing that the primitive is preferring the IPv6 address, if
> | | present, at the expense of the IPv4 addresses.
> | |
> | |
> | |
> | |
> | | Ken
> | |
> | | +1 relative to the www.google.com IP resolution.
> | |
> | |
> | | I read this only now, my last email : HTTP request for
> | | 'maps.google.com' don't answer into GLASS
> | |
> | |
> | | is relative to the same problem.
> | |
> | |
> | | Dario
> | |
> | |
> | |
> | |
> | |
> | |
> | |
> |