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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs


----- Forwarded Message -----
| From: "Alexander Kogan" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Sent: Monday, February 4, 2013 4:12:16 PM
| Subject: Re: [GS/SS Beta] IPv6 and IPv4 issues (was Zinc on 3.1)
|
| Dario.
| I'm not an expert on network configuration either but simple test for
| ipv6 connection would be to use ping6
| if you can connect to google using ipv6 protocol `ping6
| 2607:f8b0:400e:c00::68` (google's ipv6 address) then we might have
| problem we don't know about. If you can't likely something in your
| network router or ISP is not configured. In my tests ipv6 client
| socket from gemstone
| works just fine locally. You should be able to use old ipv4 address
| transparently to ipv6 so long you connect you socket using ipv4
| address.
| Util bug is fixed you will have to use 'host <server name>' to get
| list of addresses.
|
| Hope this helps
| Alex
|
| ----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Alexander Kogan" <[hidden email]>
| Sent: Monday, February 4, 2013 3:05:59 PM
| Subject: Fwd: [GS/SS Beta] IPv6 and IPv4 issues (was Zinc on 3.1)
|
| Alex,
|
| Can you help Dario? It's all mumbo jumbo to me:)
|
| Dale
|
| ----- Forwarded Message -----
| | From: "Dario Trussardi" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Monday, February 4, 2013 1:56:07 PM
| | Subject: Re: [GS/SS Beta] 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
| | > | |
| | > | |
| | > | |
| | > | |
| | > | |
| | > | |
| | > | |
| | > |
| |
|