Sorry for answering to that old thread, but it seems to be the same problem here. Aiccu usually work well on my laptop, but sometimes (like now) it simply says: "Couldn't retrieve first tunnel for the above reason, aborting" with *no* reason given above. (No matter how I set daemonize.) Even setting "verbose true" does not give any other informations. According to wireshark aiccu tries to talk to the tic server, which immediately hangs up, allowing no communication. I don't think I was "hammering" the server in any unusual way, hence I'm not sure why the server refuses to talk to me. It would be great if the server could send some useful error message. The client should probably handle that case somehow, possibly by giving some appropriate message at least something like "Server refuses to talk". (I use the current Ubuntu package of aiccu, if that might be important.)

Please provide a *lot* more details. You might want to enable 'verbose' mode and disable 'daemon' mode from the config file. Next to that 'aiccu test' is your friend. For the rest, as mentioned in the big orange box: read the "reporting problems" section of the contact page and.... provide more details.

The state of this ticket has been changed to user

I have the same error as described above (also if a activate verbose und deactivate daemonize): # aiccu test Couldn't retrieve first tunnel for the above reason, aborting my tunnel_id is T10731, my PoP is deham01, the PoP IPv4 is 212.224.0.188. a traceroute to the PoP's v4: traceroute to 212.224.0.188 (212.224.0.188), 30 hops max, 40 byte packets 1 192.168.178.1 1.733 ms 0.509 ms 0.561 ms 2 213.148.133.204 29.923 ms 44.245 ms 30.979 ms 3 87.234.11.133 22.052 ms 248.579 ms 30.697 ms 4 213.148.134.17 78.905 ms 76.325 ms 72.874 ms 5 213.148.134.125 38.854 ms 38.461 ms 78.239 ms 6 80.81.192.14 40.339 ms 40.080 ms 43.642 ms 7 87.86.77.65 55.225 ms 99.561 ms 55.118 ms 8 87.86.71.241 56.414 ms 57.247 ms 54.881 ms 9 212.224.4.89 56.333 ms 102.851 ms 56.659 ms 10 212.224.0.188 56.882 ms 55.844 ms 58.042 ms I use the aiccu client of the etch-backports repository, but also tried a fresh downloaded source version. same error. A "uname -a": Linux uni5 2.6.18-5-xen-686 #1 SMP Wed Dec 19 01:15:37 UTC 2007 i686 GNU/Linux

my aiccu.conf: # Under control from debconf, please use 'dpkg-reconfigure aiccu' to reconfigure username user password pass protocol tic server tic.sixxs.net tunnel_id T10731 # AICCU Configuration # Login information (defaults: none) #username <your nichandle/username> #password <your password> # Protocol and server to use for setting up the tunnel (defaults: none) #protocol <tic|tsp|l2tp> #server <server to use> # Interface names to use (default: aiccu) # ipv6_interface is the name of the interface that will be used as a tunnel interface. # On *BSD the ipv6_interface should be set to gifX (eg gif0) for proto-41 tunnels # or tunX (eg tun0) for AYIYA tunnels. ipv6_interface sixxs # The tunnel_id to use (default: none) # (only required when there are multiple tunnels in the list) #tunnel_id Txxxx # Be verbose? (default: false) verbose true # Daemonize? (default: true) # Set to false if you want to see any output # When true output goes to syslog # # WARNING: never run AICCU from DaemonTools or a similar automated # 'restart' tool/script. When AICCU does not start, it has a reason # not to start which it gives on either the stdout or in the (sys)log # file. The TIC server *will* automatically disable accounts which # are detected to run in this mode. # daemonize false # Automatic Login and Tunnel activation? automatic true # Require TLS? # When set to true, if TLS is not supported on the server # the TIC transaction will fail. # When set to false, it will try a starttls, when that is # not supported it will continue. # In any case if AICCU is build with TLS support it will # try to do a 'starttls' to the TIC server to see if that # is supported. requiretls false # PID File #pidfile /var/run/aiccu.pid # Add a default route (default: true) #defaultroute true # Script to run after setting up the interfaces (default: none) #setupscript /usr/local/etc/aiccu-subnets.sh # Make heartbeats (default true) # In general you don't want to turn this off # Of course only applies to AYIYA and heartbeat tunnels not to static ones #makebeats true # Don't configure anything (default: false) #noconfigure true # Behind NAT (default: false) # Notify the user that a NAT-kind network is detected behindnat true # Local IPv4 Override (default: none) # Overrides the IPv4 parameter received from TIC # This allows one to configure a NAT into "DMZ" mode and then # forwarding the proto-41 packets to an internal host. # # This is only needed for static proto-41 tunnels! # AYIYA and heartbeat tunnels don't require this. #local_ipv4_override

It does work now... Thank you.

everything...complete IPv6 connectivity...

Some additional information, no need for action: I had the same issue today (only the message "Couldn't retrieve first tunnel for the above reason, aborting", but no "above reason" was given). My system is a PPC Gentoo Linux. I started debugging it and I reached this call to "sock_getline" which failed without a debug log entry. /* Fetch the welcome */ if (sock_getline(tic->sock, tic_buf, sizeof(tic_buf), &tic_filled, buf, sizeof(buf)) == -1) { return false; } I suspect something goes wrong in "sock_getline" without providing a debug message. I was not able to find what is going wrong, because all of the sudden it worked again (like other users reported here). I will continue debugging it when it happens again.