All OSX platforms (running 10.6.7, client and server) I have tried this on eventually cause a system hang in the same manner.
I had the same problem running gw6c.
I am currently running gogoc-1_2-RELEASE, after fixing several bugs as documented in my other posting, which precluded it functioning at all. The reason it works for others is that the tunnel broker I am using is running version 2.0.1, and the bugs present themselves in this situation. Something to be said for testing software....
Establishing connection to server broker.aarnet.net.au using reliable UDP.
Using TSP protocol version 2.0.2.Retrieving TSP capabilities from Server.
TSP version not supported by server: 2.0.2.
Failed to retrieve TSP capabilities.
Establishing connection to server broker.aarnet.net.au using reliable UDP.Using TSP protocol version 2.0.1.
Retrieving TSP capabilities from Server.
I am posting this in case anyone else is experiencing this with OSX, and I hope to eventually resolve this issue, or my gogo hardware will show up, and I will lose interest in pursuing this.
Just happened again.
I had a "top" running, and the gogoc process was "stuck". I hit ^C and GDB showed me that it was in select(). I stepped thru the select return and processing the EINTR or EAGAIN or whatever it was and it then went into a loop where select() returned 0 immediately. I continued it, but the "top" listing still showed "stuck".
"netstat -m" showed lots of mbufs available.
"ifconfig $anything" immediately got stuck.
A "tcpdump" I had been running was stuck.
"dmesg" still worked, and it showed:
mld6_input: src :: is not link-local (grp=ff02::0001:ff00:0001)
<something about the nfs server not responding>
I tried to kill the gogoc process (kill -9) and it wedged. Shortly thereafter, pretty much everything wedged, and I had to power cycle again.
So I surmise that there is a bug in IPv6 in OSX which leaves some network based resource locked. I do not really know what the source is for OSX networking, I have no idea what locking is used in the kernel to deal with concurrency in the networking bits, but it seems as if something gets locked and is left locked, and everything piles up behind.
The version error you see is not an error incompatibility of versions between the server and client. What should happen is that the client should reconnect using an older version of TSP, which it looks like it does.
Why it gets stuck I do not know. One way of testing things out is to take the commands from the configuration script and run them manually to see what happens. Although it seems that you don't make that far if I understand it correctly.
The client successfully drops back to version 2.0.1 and I connect and IPv6 is up and running quite well for a random period of time.
Subsequently, OSX wedges.
The issue of the 2.0.2 and 2.0.1 I raised as an explanation as to why others are not reporting a complete failure to connect with the gogoc client. I had to fix various bugs in the client associated with the fact that although it will fall back, it has apparently never been tested, as it crashes immediately, with obvious and trivially fixed bugs.
I am currently in the process of installing FreeBSD 8.2 in a VMware virtual machine, and I will run the client there. I can no longer afford the disruption of having to hard-reset the machine running gogoc.
Hopefully, this will provide a work-around, but even if FreeBSD wedges, hard-reset of the VMware machine is much less disruptive.