|
Problems setting up heartbeat tunnel when computer re-starts.
![[us]](/s/countries/us.gif) Carmen Sandiego on Thursday, 13 August 2009 11:29:06
Ok here is the situation, I have a Win 2k3 r2 running Aiccu Windows GUI version 2006.07.23 with my tunnel set to heartbeat It is behind a NAT router (Tomato 1.25 running PPPoE WAN) with protocol 41 forwarded to its LAN address (static) I have these iptables commands added in the firewall of the tomato
iptables -t nat -A PREROUTING -i ppp0 -p 41 -j DNAT --to 10.0.1.2
iptables -t filter -A FORWARD -i ppp0 -p 41 -d 10.0.1.2 -j ACCEPT
Note I have syslog running reporting and everything being blocked by the firewall and nothing shows up as being block.
Now if I start the modem, router and all then start the computer it all comes up fine and stays up for days, now if my PPPoE session drop and comes back up with a new address it the IPv6 tunnel stops passing traffic even after letting aiccu send another heatbeat, if I restart aiccu the tunnel still wont pass traffic but if I close aiccu and let it sit for 30mins plus or minus and restart it will work for a few more days. Also If the server (running a working tunnel) restarts and the router hasn't dropped connection or changed IPs when the server comes back up the tunnel wont pass any traffic.
Anyone have any ideas what would cause this.
Also here is the end of a traceroute to my tunnel endpoint address when aiccu is running and should but is not passing traffic.
13 sixxs-asbnva-gw.customer.occaid.net (2001:4830:E6:7::2) 140 msec 140 msec 144 msec
14 sixxs-asbnva-gw.customer.occaid.net (2001:4830:E6:7::2) !H !H !H
The !H leads me to believe that the tunnel server didn't enable the interface on its end since if it did and was sending packets and them getting lost in-between they would just timeout.
Problems setting up heartbeat tunnel when computer re-starts.
now if my PPPoE session drop and comes back up with a new address it the IPv6 tunnel stops passing traffic even after letting aiccu send another heatbeat,
Tcpdump is what you want to start doing here to actually see what packets are being sent. See the "Problems Checklist" on the contact page.
Also, as the interface gets dropped, check that the iptable rules you made are still there when the interface comes up again.
if I restart aiccu the tunnel still wont pass traffic but if I close aiccu and let it sit for 30mins plus or minus and restart it will work for a few more days.
I bet some kind of NAT state is not properly updated.
The !H leads me to believe that the tunnel server didn't enable the interface on its end since if it did and was sending packets and them getting lost in-between they would just timeout.
Correct. When there are no valid heartbeat/AYIYA packets received the tunnel interface gets deconfigured on the PoP and you will get !H/!N (depends on the PoP, if I get time to finish the new sixxsd software then it will be standardized)
I see two proper solutions here:
1) upgrade that Tomato thing to an IPv6 edition (afaik they exist) or go for something like openwrt where it is based on which support IPv6 and have AICCU already out of the box. Then you can terminate the IPv6 tunnel on that host.
alternatively:
2) Use AYIYA. As that doesn't require hackery protocol forwards.
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Thursday, 13 August 2009 13:34:51
I tried AYIYA as well with "TAP-Win32 Adapter v8" installed. And the remote traceroute got the !H again (I ran it 60 seconds after I started aiccu)
Like I said it strange because if I reboot (normally a hard crash but shouldn't mater) the computer with aiccu on it the tunnel wont come back up even if the router has the same IP / hasn't dropped connection. Note a router reboot dose not solve this issue it seem just letting it sit for awhile 30mins + (seem to be random could be a lot longer then 30mins. Like if I just leave aiccu off the next day it will work fine even if the router still has the same IP / Non-droped connection and stay up for days the) Its almost like the POP is locking me out (lack of beter term) and I just have to let it reset.
This should be everything and including the kitchen sink... which ill need back =P.
Also as a test I fired up aiccu with the "TAP-Win32 Adapter v9" on another Win 2k3 with the same tunnel using AYIYA and had the same problem.
But If I switch to my uschi02 tunnel T13114 using heartbeat 6in4 it work but switching back to usqas01 T14485 using heartbeat 6in4 or AYIYA I get nothing.
C:\Program Files\Support Tools>ipconfig -all
Windows IP Configuration
Host Name . . . . . . . . . . . . : laptopserver
Primary Dns Suffix . . . . . . . : napshome.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : napshome.local
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom 440x 10/100 Integrated Controlle
r
Physical Address. . . . . . . . . : 00-11-43-61-C3-56
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.0.1.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 2001:4830:167f:0:211:43ff:fe61:c356
IP Address. . . . . . . . . . . . : fe80::211:43ff:fe61:c356%4
Default Gateway . . . . . . . . . : 10.0.1.6
DNS Servers . . . . . . . . . . . : 10.0.1.1
10.0.1.2
fec0:0:0:ffff::1%2
fec0:0:0:ffff::2%2
fec0:0:0:ffff::3%2
Primary WINS Server . . . . . . . : 10.0.1.2
Secondary WINS Server . . . . . . : 10.0.1.1
Ethernet adapter aiccu:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Win32 Adapter V8
Physical Address. . . . . . . . . : 00-FF-BA-0D-F3-E4
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IP Address. . . : 169.254.68.183
Subnet Mask . . . . . . . . . . . : 255.255.0.0
IP Address. . . . . . . . . . . . : 2001:4830:1600:112::2
IP Address. . . . . . . . . . . . : fe80::2ff:baff:fe0d:f3e4%17
Default Gateway . . . . . . . . . : 2001:4830:1600:112::1
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : FF-FF-FF-FF-FF-FF-FF-FF
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : fe80::ffff:ffff:fffd%5
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Disabled
Tunnel adapter Automatic Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Automatic Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : A9-FE-44-B7
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : fe80::5efe:169.254.68.183%2
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Disabled
Tunnel adapter Automatic Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Automatic Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 0A-00-01-02
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : fe80::5efe:10.0.1.2%2
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%2
fec0:0:0:ffff::2%2
fec0:0:0:ffff::3%2
NetBIOS over Tcpip. . . . . . . . : Disabled
Interface 17: aiccu
Addr Type DAD State Valid Life Pref. Life Address
--------- ---------- ------------ ------------ -----------------------------
Manual Preferred infinite infinite 2001:4830:1600:112::2
Link Preferred infinite infinite fe80::2ff:baff:fe0d:f3e4
Connection Name : aiccu
GUID : {BA0DF3E4-5685-4008-8F28-7582EE4CA499}
State : Connected
Metric : 0
Link MTU : 1380 bytes
True Link MTU : 1500 bytes
Current Hop Limit : 128
Reachable Time : 32s
Base Reachable Time : 30s
Retransmission Interval : 1s
DAD Transmits : 1
DNS Suffix :
Firewall : disabled
Site Prefix Length : 48 bits
Zone ID for Link : 17
Zone ID for Site : 1
Uses Neighbor Discovery : Yes
Sends Router Advertisements : No
Forwards Packets : Yes
Link-Layer Address : 00-ff-ba-0d-f3-e4
netsh interface ipv6>show interface 4
Querying active state...
-------------------------------------------------------------------------
Interface 4: Local Area Connection
Addr Type DAD State Valid Life Pref. Life Address
--------- ---------- ------------ ------------ -----------------------------
Public Preferred infinite infinite 2001:4830:167f:0:211:43ff:fe61:c
356
Link Preferred infinite infinite fe80::211:43ff:fe61:c356
Anycast 2001:4830:167f::
Connection Name : Local Area Connection
GUID : {36782379-D1E1-405E-B748-C8E2B0E21E1B}
State : Connected
Metric : 0
Link MTU : 1380 bytes
True Link MTU : 1500 bytes
Current Hop Limit : 128
Reachable Time : 42s
Base Reachable Time : 30s
Retransmission Interval : 1s
DAD Transmits : 1
DNS Suffix :
Firewall : disabled
Site Prefix Length : 48 bits
Zone ID for Link : 4
Zone ID for Admin : 5
Zone ID for Site : 2
Uses Neighbor Discovery : Yes
Sends Router Advertisements : Yes
Forwards Packets : Yes
Link-Layer Address : 00-11-43-61-c3-56
netsh interface ipv6>show routes
Querying active state...
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- ---- ------------------------ --- ---------------------
no Manual 0 2001:4830:1600:112::/64 17 aiccu
yes Manual 0 ::/0 17 2001:4830:1600:112::1
yes Manual 0 2001:4830:167f::/64 4 Local Area Connection
C:\Program Files\Support Tools>ping 2001:4830:1600:112::1
Pinging 2001:4830:1600:112::1 from 2001:4830:1600:112::2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2001:4830:1600:112::1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Program Files\Support Tools>c:\aiccu test
sock_getline() : "200 SixXS TIC Service on noc.sixxs.net ready (http://www.sixxs
.net)"
sock_printf() : "client TIC/draft-00 AICCU/2008.03.15-console-win32 WinNT/5.2.3
790-SP2"
sock_getline() : "200 Client Identity accepted"
sock_printf() : "get unixtime"
sock_getline() : "200 1250159838"
sock_printf() : "username BJ855-RIPE"
sock_getline() : "200 Choose your authentication challenge please"
sock_printf() : "challenge md5"
sock_getline() : "200 *************************"
sock_printf() : "authenticate md5 ******************************"
sock_getline() : "200 Succesfully logged in using md5 as BJ855-RIPE (Brandon Jac
kson) from 2001:7b8:3:4f:202:b3ff:fe46:bec"
sock_printf() : "tunnel show T14485"
sock_getline() : "201 Showing tunnel information for T14485"
sock_getline() : "TunnelId: T14485"
sock_getline() : "Type: ayiya"
sock_getline() : "IPv6 Endpoint: 2001:4830:1600:112::2"
sock_getline() : "IPv6 POP: 2001:4830:1600:112::1"
sock_getline() : "IPv6 PrefixLength: 64"
sock_getline() : "Tunnel MTU: 1380"
sock_getline() : "Tunnel Name: New Main"
sock_getline() : "POP Id: usqas01"
sock_getline() : "IPv4 Endpoint: ayiya"
sock_getline() : "IPv4 POP: 66.117.47.228"
sock_getline() : "UserState: enabled"
sock_getline() : "AdminState: enabled"
sock_getline() : "Password: *******************"
sock_getline() : "Heartbeat_Interval: 60"
sock_getline() : "202 Done"
Succesfully retrieved tunnel information for T14485
sock_printf() : "QUIT In My Garden"
Tunnel Information for T14485:
PoP Id : usqas01
IPv6 Local : 2001:4830:1600:112::2/64
IPv6 Remote : 2001:4830:1600:112::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
Name : New Main
Flag: HAS_IFHEAD not present
Flag: NEED_IFHEAD not present
[warning] Couldn't open registry key: SYSTEM\CurrentControlSet\Control\Class\{4D
36E972-E325-11CE-BFC1-08002BE10318}\0000\ComponentId (t2/2 vs 0/0 vs 1)
Found interface named 'aiccu', with guid {BA0DF3E4-5685-4008-8F28-7582EE4CA499},
using it
[tun-start] Trying \\.\Global\{BA0DF3E4-5685-4008-8F28-7582EE4CA499}.tap
Flag: HAS_IFHEAD not present
Flag: NEED_IFHEAD not present
[AYIYA-start] : Anything in Anything (draft-02)
[AYIYA-tun->tundev] : (Socket to TUN) started
heartbeat_socket() - IPv4 : 10.0.1.2
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (10.0.1.2)
### This should return so called 'echo replies'
### If it doesn't then check your firewall settings
### Your local endpoint should always be pingable
### It could also indicate problems with your IPv4 stack
Pinging 10.0.1.2 with 32 bytes of data:
Reply from 10.0.1.2: bytes=32 time<1ms TTL=64
Reply from 10.0.1.2: bytes=32 time<1ms TTL=64
Reply from 10.0.1.2: bytes=32 time<1ms TTL=64
Ping statistics for 10.0.1.2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
Did this work? [Y/n] y
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (66.117.47.228)
### These pings should reach the PoP and come back to you
### In case there are problems along the route between your
### host and the PoP this could not return replies
### Check your firewall settings if problems occur
Pinging 66.117.47.228 with 32 bytes of data:
Reply from 66.117.47.228: bytes=32 time=45ms TTL=52
Reply from 66.117.47.228: bytes=32 time=69ms TTL=52
Reply from 66.117.47.228: bytes=32 time=40ms TTL=52
Ping statistics for 66.117.47.228:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 69ms, Average = 51ms
######
Did this work? [Y/n] y
####### [3/8] Traceroute to the PoP (66.117.47.228) over IPv4
### This traceroute should reach the PoP
### In case this traceroute fails then you have no connectivity
### to the PoP and this is most probably the problem
Tracing route to iad0-sixxs.hotnic.net [66.117.47.228]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms car1-port1.ipv4.napshome.local [10.0.1.6]
2 10 ms 10 ms 9 ms h1.96.90.75.dynamic.ip.windstream.net [75.90.96.
1]
3 24 ms 23 ms 9 ms h56.122.90.75.static.ip.windstream.net [75.90.12
2.56]
4 17 ms 19 ms 19 ms h70.248.213.151.static.ip.windstream.net [151.21
3.248.70]
5 14 ms 13 ms 13 ms h96.254.213.151.static.ip.windstream.net [151.21
3.254.96]
6 13 ms 19 ms 18 ms te-3-2.car2.Atlanta2.Level3.net [4.71.254.13]
7 13 ms 52 ms 40 ms ae-71-52.ebr1.Atlanta2.Level3.net [4.68.103.60]
8 21 ms 17 ms 18 ms ae-63-60.ebr3.atlanta2.level3.net [4.69.138.4]
9 41 ms 50 ms 36 ms ae-2.ebr1.washington1.level3.net [4.69.132.86]
10 28 ms 55 ms 49 ms ae-91-91.csw4.Washington1.Level3.net [4.69.134.1
42]
11 28 ms 28 ms 27 ms ae-43-99.car3.Washington1.Level3.net [4.68.17.19
7]
12 28 ms 28 ms 29 ms CARPATHIA-H.car3.Washington1.Level3.net [4.79.16
9.26]
13 30 ms 39 ms 39 ms 209.222.144.164
14 29 ms 36 ms 28 ms iad0-sixxs.hotnic.net [66.117.47.228]
Trace complete.
######
Did this work? [Y/n] y
###### [4/8] Checking if we can ping IPv6 localhost (::1)
### This confirms if your IPv6 is working
### If ::1 doesn't reply then something is wrong with your IPv6 stack
Pinging ::1 from ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Ping statistics for ::1:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
Did this work? [Y/n] y
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1600:112:
:2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
Pinging 2001:4830:1600:112::2 from 2001:4830:1600:112::2 with 32 bytes of data:
Reply from 2001:4830:1600:112::2: time<1ms
Reply from 2001:4830:1600:112::2: time<1ms
Reply from 2001:4830:1600:112::2: time<1ms
Ping statistics for 2001:4830:1600:112::2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
Did this work? [Y/n] y
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1600:112:
:1)
### This confirms the reachability of the other side of the tunnel
### If it doesn't reply then check your interface and routing tables
### Don't forget to check your firewall (both IPv4 and IPv6) of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
Pinging 2001:4830:1600:112::1 from 2001:4830:1600:112::2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2001:4830:1600:112::1:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),
######
Did this work? [Y/n] y
###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net)
### This confirms that you can reach the central machine of SixXS
### If that one is reachable you should be able to reach most IPv6 destinations
### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connecti
on
### If your browser supports IPv6 and uses it of course.
'tracert6' is not recognized as an internal or external command,
operable program or batch file.
######
Did this work? [Y/n] y
###### [8/8] Traceroute6 to (www.kame.net)
### This confirms that you can reach a Japanese IPv6 destination
### If that one is reachable you should be able to reach most IPv6 destinations
### You should also check http://www.kame.net which should display
### a animated kame (turtle), of course only when your browser supports and uses
IPv6
'tracert6' is not recognized as an internal or external command,
operable program or batch file.
######
Did this work? [Y/n] y
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
Problems setting up heartbeat tunnel when computer re-starts.
You tried this for 1 minute and then swapped the tunnel back to heartbeat.
PoPs only synchronize every 30 minutes, not the very instant that you change them. As such, when changing the type of tunnel, you will have to wait for that synchronization to happen.
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Thursday, 13 August 2009 13:54:34
Did not know that. Also that would seem to correspond to the borked tunnel getting reset and being able to work again since it seem to work after 30+- mins of no heartbeats.
Also since I can connect to my other tunnels when this happens just not the one "locked out" (p.s. this happened when I was on uschi02 aswell and I could switch to others just fine just like I can now, all with 6in4) I would start to conclude that it some how with the tunnel servers. Since rebooting everything (Modem, router computer with a new WAN IP, that was before messing with AYIYA setting) Will allow other tunnels continue to work except that single one that's getting "locked out" or hung. Is there a lockout system on the tunnel servers?
Problems setting up heartbeat tunnel when computer re-starts.
If you send random nonsense to the PoPs they will start ignoring it.
For the rest of your assumptions, provide the requested data as listed on the contact page.
Especially tcpdumps.
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Thursday, 13 August 2009 14:47:59
Here is 3 wireshark dumps http://home.windstream.net/bostang/wireshark-caps.zip
usqas01-6in4-66-117-47-228.pcap Is for tunnel T14485 the one not working
usdal01-6in4-209-197-16-66.pcap Is for tunnel T18582 works.
uschi02-6in4-216-14-98-22.pcap Is for tunnel T13114 works.
All are 6in4 all the caps include traffic to/from the PoPs IP.
The only thing I'm changing is the tunnel ID in the aiccu.conf file and restarting aiccu.
I Think everything thing else was included in the other post.
Problems setting up heartbeat tunnel when computer re-starts.
usqas01-6in4-66-117-47-228.pcap Is for tunnel T14485 the one not working
What is the PCAP supposed to contain? Apparently you are sending random data to random destinations. But what is it supposed to be? Sending traffic to 6to4 destinations is a really bad idea as you never know if that is working and coming back.
Also, why are you not simply doing something simple like pinging the endpoint on the PoP side?
Nevertheless, the PoP reports the following:
Last Beat : 2009-08-13 17:38:05 (4002 seconds ago)
(time in UCT)
As such no valid heartbeat packets have been received for over an hour.
Without valid heartbeat packets a heartbeat interface won't be up.
Lastly, swapping between AYIYA and heartbeat all the time, will not resolve your problem either.
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Friday, 14 August 2009 00:01:20
Some of that traffic was coming from a utorrent client on the network that's not what I was looking at for connectivity. On that one you can see the 3 heartbeats being sent and ping from 2001:4830:1600:112::2 to sixxs.com (2001:838:1:1:210:dcff:fe20:7c7c) which go unanswered/get lost (did the same test on the rest of the tunnels on it worked) I forgot to ping the ::1 in that packet cap but every other time on that tunnel the ::1 doesn't respond.
Now it came back up afgter I left it off for 12hrs while I slept and with no changes (no router reboots and the same IP/session no firewall changes). But for a test I restarted the computer with aiccu and again the pop wont respond, how can a simple restart cause this. Next time I get it working as a test ill close aiccu for about 4-5mins (about the time it takes for the server to restart) and start it back up and see what happens.
Also dose the POP report my IPv4 to the website (Your IPv4 Heartbeat, currently xxx.xxx.xxx.xxx) or dose the TIC server because when its not working that address will change to the current one if it changes.
The only reason I switched to AYIYA was to trouble shoot not knowing it took 30mins to update, but this problem has been happening for a couple months with out switching anything and it just magicly fixes it self after letting the POP "cooldown".
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Friday, 14 August 2009 14:31:37
Tag [/code] is not closed
Problems setting up heartbeat tunnel when computer re-starts.
usqas01 T14485 - Still dose not work, switched it to AYIYA about 3-4hrs ago and just now tried it and still no response from the other side. Aiccu log, pings, ipconfig and netsh's show routes command.
Switching back and forth between tunnel types is really not going to enable us to figure out if there is something wrong on the PoP side, if at all there is something wrong.
The PoP indicates though:
Last Beat : 2009-08-14 16:04:56 (5924 seconds ago)
But indeed, as you are stopping/starting it all the time, it indeed will never properly come up and we'll also never be able to look at the PoP state when it is supposed to be up....
And I would not be surprised if because of the many changes and different configurations you are making there are all kinds of non-matching configurations actually running on your machine. Several examples can be seen above already where you are using another tunnel, but a subnet from the first, which really won't work.
For some reason your DNS resolver seems to override the real DNS and displays sixxs-tunnel-gw-uschi02.ipv6.napshome.local for 2001:4978:f:7::1 which really is gw-8.chi-02.us.sixxs.net. I have no idea how you get that on a Windows box, but it just indicates that there your configuration is non-standard.
AICCU is in no way capable of cleaning them up. As it cannot know what is intentional, and what is not.
sock_getline() : "Tunnel MTU: 1380"
Why is your MTU 1380, that seems like a weird number to me. You do realize that AYIYA has more overhead than a normal proto-41 tunnel? Why did you configure that?
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Friday, 14 August 2009 16:20:18
Ok Ill start the usqas01 tunnel and leave it running for you with it set to AYIYA. (Its working for the moment, more info at the end of the post)
As for the other subnet being there I just didn't remove it but it doesn't cause issue considering I'm pinging from the Tunnels ::2 which works on the 2 tunnels that the subnet is not assigned, of course the rest of the computers cant connect to anything via IPv6 but that's not where I'm testing from.
As for the RDNS I just added a RDNS Listing in my 2k3 DNS server for thoses ipv6 address again doesn't effect functionality just the name that shows.
As for MTU of 1380 my DSL's PPPoE MTU is 1454, so 1454 - 72(AYIYA overhead) = 1382 so a IPv6 MTU 1380 work (could have used 1382) but the tunnel on the 2k3 is set for 1380 and so is the subnet on the other interface, normally I used 6in4 with a IPv6 MTU of 1434 1454 - 20 (6in4 overhead) = 1434 and it works fine.
Ok the usqas01 T14485 tunnel came up this time I noticed that something has changed now that it works
sock_getline() : "200 Succesfully logged in using md5 as BJ855-RIPE (Brandon Jackson) from 2001:7b8:3:4f:202:b3ff:fe46:bec" as you can see the IPv6 address now matches what the other 2 tunnels had again I'm not sure if this really mean anything but Ill keep an eye on it when its not working.
Also wasn't their a bug with aiccu that involved Win 2k3 and a routing or forwarding issue with AYIYA, because right now I cant get the subnet to route and pretty sure that's why I want with 6in4 in the first place.
Oh and as for the fourm software I knows it custom I understand why I was just a little frustrated =P I spent about 30min gathering all that data and it just went poof (Ill make sure to use notepad first and copy from it from now on).
Problems setting up heartbeat tunnel when computer re-starts.
Also wasn't their a bug with aiccu that involved Win 2k3 and a routing or forwarding issue with AYIYA, because right now I cant get the subnet to route and pretty sure that's why I want with 6in4 in the first place.
Due to the nature of TUN/Tap on windows routing, well actually forwarding, packets fails, unless a complete ND setup is emulated.
Oh and as for the fourm software I knows it custom I understand why I was just a little frustrated =P I spent about 30min gathering all that data and it just went poof (Ill make sure to use notepad first and copy from it from now on).
In the cases that it happens, SixXS Staff can always fix the post.
There used to be an edit option, but we had to disable that due to some people modifying their posted messages, which would then state something completely different from what they first posted.
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Friday, 14 August 2009 16:59:35Due to the nature of TUN/Tap on windows routing, well actually forwarding, packets fails, unless a complete ND setup is emulated.
Alright I'm gonna let this tunnel stay up for a little while then ill shut it down and switch it back to 6in4 heartbeat, and see what I get since no real point of the tunnel being up if the subnet is dead.
There used to be an edit option, but we had to disable that due to some people modifying their posted messages, which would then state something completely different from what they first posted.
Diffidently understand. Maybe a Edit within 3-4mins to fix something then lock, Iv seen some forum use something like that. Just a suggestion. Oh and the Preview would be nice ;-)
Problems setting up heartbeat tunnel when computer re-starts.
Carmen Sandiego on Friday, 14 August 2009 13:48:26
BTW I hate this damn forum software had a huge post of info (ipconfig's, pings, netsh routes info and aiccu logs) and because 1 little tag wasn't closed I lost the whole post (just a little rant). so here is round 2, with most likely less info.
Packet Caps from this Testing session are here http://home.windstream.net/bostang/wireshark-caps-2.zip
usqas01 T14485 - Has been set for ayiya for over 3 hours before trying it, and still dosn't work, aiccu setup the TUN-Tap with the correct address and routes. One thing I noticed in the AICCU start up log the "sock_getline() : "200 Succesfully logged in using md5 as BJ855-RIPE (Brandon Jackson) from X:X:X:X:X:X:X:X"" line for this POP was different then the other 2 this one had 2001:960:800::2 and uschi02 and usdal01 had 2001:7b8:3:4f:202:b3ff:fe46:bec other then that everything else looked the same except for address and pop info.
usdal01 T18582 - Was set for ayiya for only a 1 minuet and it worked the first time I tried it, everything look identical to usqas01 except for the line in the aiccu log and addresses which were correct for this tunnel.
uschi02 T13114 - Is set for 6in4 also worked without issue (did notice a little packet loss but no big deal).
Again there was logs and info from all the tunnels but it got lost when I tired to post, Ill try and do another batch of test and get them when I can.
Problems setting up heartbeat tunnel when computer re-starts.
BTW I hate this damn forum software had a huge post of info (ipconfig's, pings, netsh routes info and aiccu logs) and because 1 little tag wasn't closed I lost the whole post (just a little rant). so here is round 2, with most likely less info.
You forgot the [ desc ] part. Fixed.
Also, the reason we have our own forum software is due to one very important things: Security; every other forum tool is leaking with security bugs, we really do not want to take the risk that because some remote person doesn't know how to program that it compromises our services.
Next to that there are of course also integration and other required features like RSS/ATOM feeds and many many other details that other tools don't cover, but this one does.
We'll one day implement a 'preview' option again, that will at least partially resolve the tag issue; and maybe some other people might actually read what they write in that case, as those big orange boxes don't seem to be noticed by anyone, nor the prefilled text for that matter; maybe we should add some minor insults in there would at least make it a bit comical that people demonstrate that they can't read.
|
![[ch]](/s/countries/ch.gif)
on Thursday, 13 August 2009 12:07:58
Posting is only allowed when you are