|
No heartbeat detected?
![[us]](/s/countries/us.gif) Shadow Hawkins on Monday, 23 January 2012 07:51:08
I have a heartbeat type tunnel; my tunnel works fine in general.
I do have a problem/question: On my sixxs page that shows me the details of my connection, I'm seeing "Heartbeat, currently unknown".
From the HeartBeat FAQ (https://www.sixxs.net/tools/heartbeat/), it tells me that after 5 min, the tunnel will be disabled by the POP.
I'm not seeing anything acknowledging my heartbeat working, but my tunnel remains up.
I'm also not earning any ISK (even though my tunnel has been up for a few years now).
I sync my time using NTP, and use AICCU to configure the tunnels; I'm not quite sure why the heartbeat doesn't seem to be working - and hasn't been working for a very long time. My tunnel still seems to work; I just want to know if I'm doing something wrong...
Any ideas?
No heartbeat detected?
I'm seeing "Heartbeat, currently unknown".
This merely means that at the time of your query the website was unable to ask the PoP where your tunnel is currently terminated.
I'm not seeing anything acknowledging my heartbeat working, but my tunnel remains up.
If your tunnel works, as in you can ping the remote end of the PoP (<tunnel>::1) and you can generally reach the remote sites, then well, it works.
I'm also not earning any ISK (even though my tunnel has been up for a few years now).
That is very likely because your tunnel does not ping properly throughout the day, see the FAQ.
I'm not quite sure why the heartbeat doesn't seem to be working
The heartbeat obviously is working otherwise a heartbeat tunnel does not get configured as up and your connectivity would not workj.
No heartbeat detected?
![[dk]](/s/countries/dk.gif) Shadow Hawkins on Monday, 23 January 2012 14:59:20I'm seeing "Heartbeat, currently unknown".
This merely means that at the time of your query the website was unable to ask the PoP where your tunnel is currently terminated.
No heartbeat detected?
Depending on the front-ends one goes through one will or will not get a response. One of the many reasons why we are moving to sixxsd v4.
No heartbeat detected?
Shadow Hawkins on Monday, 23 January 2012 17:44:16If your tunnel works, as in you can ping the remote end of the PoP (<tunnel>::1) and you can generally reach the remote sites, then well, it works.
Well, I look at my tunnel information, and I have the PoP IPV6 address (ie. <tunnel>::1). (obviously, I'm obscuring the actual IP)
So, I ping6 it:
ping6 <tunnel>::1
^C
--- <tunnel>::1 ping6 statistics ---
16 packets transmitted, 0 packets received, 100.0% packet loss
Yet... the tunnel remains up. I have no problem with ipv6.google.com, comcast6.net reports I'm using IPv6, sixxs reports I'm using IPv6, etc.
That is very likely because your tunnel does not ping properly throughout the day, see the FAQ.
Exactly what am I supposed to look for? I've searched for 'heartbeat', and nothing seems to apply, other than the heartbeat FAQ I quoted in my original post... I know my /etc/aiccu.conf leaves the "heartbeat" setting as the default...
No heartbeat detected?
Shadow Hawkins on Monday, 23 January 2012 17:52:06
OK, this may be helpful... gives me a place to look deeper.
The previous ping was from a host that routes through the machine running aiccu. I tried the actual host running aiccu, and received "Network is unreachable." (ditto for other ipv6 hosts).
Hmmm.... I was reporting that the other hosts were working from memory, as I hadn't pinged them in my post of a few minutes ago.
So, I restarted aiccu. Now I can ping the PoP IPv6 address.
So it seems the tunnel really was down this morning... which is actually the whole reason I noticed the heartbeat wasn't working - my tunnel wasn't stable yesterday, so I was investigating... and discovered the heartbeat wasn't being reported as active.
I'll have to dig into the FAQ's to see what I can find; maybe my firewall blocks the heartbeat... I'll have to investigate.
No heartbeat detected?
16 packets transmitted, 0 packets received, 100.0% packet loss Yet... the tunnel remains up. I have no problem with ipv6.google.com, comcast6.net reports I'm using IPv6, sixxs reports I'm using IPv6, etc.
It would be extremely useful if you would provide routing tables and other such nice details as requested by that big yellow/orange box.
Exactly what am I supposed to look for?
The one with "Tunnel endpoint didn't ping" in the title would be a great start. Next to of course "My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker".
No heartbeat detected?
Shadow Hawkins on Monday, 23 January 2012 20:06:37It would be extremely useful if you would provide routing tables and other such nice details as requested by that big yellow/orange box.
I was unable to find a big yellow/orange box listing anything; I did see a list on the 'contact' page, but it's not in yellow/orange. It'll have to do...
Aiccu test: (nothing interesting as far as I can tell...)
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (24.10.222.127)
### 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
PING 24.10.222.127 (24.10.222.127) 56(84) bytes of data.
64 bytes from 24.10.222.127: icmp_req=1 ttl=64 time=0.097 ms
64 bytes from 24.10.222.127: icmp_req=2 ttl=64 time=0.041 ms
64 bytes from 24.10.222.127: icmp_req=3 ttl=64 time=0.047 ms
--- 24.10.222.127 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.041/0.061/0.097/0.026 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (209.197.5.66)
### 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
PING 209.197.5.66 (209.197.5.66) 56(84) bytes of data.
64 bytes from 209.197.5.66: icmp_req=1 ttl=54 time=71.8 ms
64 bytes from 209.197.5.66: icmp_req=2 ttl=54 time=76.3 ms
64 bytes from 209.197.5.66: icmp_req=3 ttl=54 time=73.2 ms
--- 209.197.5.66 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 71.838/73.782/76.301/1.892 ms
######
####### [3/8] Traceroute to the PoP (209.197.5.66) 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
traceroute to 209.197.5.66 (209.197.5.66), 30 hops max, 60 byte packets
1 24.10.216.1 (24.10.216.1) 27.789 ms 28.599 ms 31.476 ms
2 te-7-1-ur08.saltlakecity.ut.utah.comcast.net (68.85.39.125) 17.146 ms 17.150 ms 17.220 ms
3 te-3-1-ar02.saltlakecity.ut.utah.comcast.net (68.86.199.157) 16.098 ms 17.088 ms 17.160 ms
4 te-0-1-0-1-cr01.denver.co.ibone.comcast.net (68.86.94.113) 43.619 ms 43.626 ms 43.611 ms
5 pos-0-13-0-0-cr01.seattle.wa.ibone.comcast.net (68.86.86.214) 45.103 ms 46.058 ms 46.058 ms
6 pos-0-1-0-0-pe01.seattle.wa.ibone.comcast.net (68.86.85.38) 42.493 ms 38.218 ms 38.169 ms
7 75.149.231.130 (75.149.231.130) 38.149 ms 38.196 ms 38.181 ms
8 unknown.hwng.net (209.197.0.253) 62.849 ms 71.478 ms 70.068 ms
9 e2-1.r1.ph.hwng.net (209.197.0.22) 72.759 ms unknown.hwng.net (209.197.0.45) 74.080 ms 78.726 ms
10 1-4.r2.ph.hwng.net (69.16.191.74) 81.646 ms 84.252 ms 82.624 ms
11 usphx01.sixxs.net (209.197.5.66) 79.672 ms 79.581 ms 80.542 ms
######
###### [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
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.060 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.081 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.060/0.068/0.081/0.011 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:1938:81:a5::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:1938:81:a5::2(2001:1938:81:a5::2) 56 data bytes
64 bytes from 2001:1938:81:a5::2: icmp_seq=1 ttl=64 time=0.075 ms
64 bytes from 2001:1938:81:a5::2: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 2001:1938:81:a5::2: icmp_seq=3 ttl=64 time=0.099 ms
--- 2001:1938:81:a5::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.075/0.088/0.099/0.012 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:1938:81:a5::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 of course
### If the previous test was successful then this could be both
### a firewalling and a routing/interface problem
PING 2001:1938:81:a5::1(2001:1938:81:a5::1) 56 data bytes
64 bytes from 2001:1938:81:a5::1: icmp_seq=1 ttl=64 time=76.9 ms
64 bytes from 2001:1938:81:a5::1: icmp_seq=2 ttl=64 time=73.7 ms
64 bytes from 2001:1938:81:a5::1: icmp_seq=3 ttl=64 time=72.3 ms
--- 2001:1938:81:a5::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 72.376/74.339/76.906/1.898 ms
######
###### [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 connection
### If your browser supports IPv6 and uses it of course.
traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:1938:81:a5::2, 30 hops max, 24 byte packets
1 gw-166.phx-01.us.sixxs.net (2001:1938:81:a5::1) 74.412 ms 75.586 ms 72.158 ms
2 2001:4de0:1000:a4::1 (2001:4de0:1000:a4::1) 97.217 ms 76.52 ms 74.958 ms
3 1-3.ipv6.r1.ph.hwng.net (2001:4de0:1000:27::2) 72.766 ms 73.313 ms 74.679 ms
4 2-4.ipv6.r1.la.hwng.net (2001:4de0:1000:40::1) 92.076 ms 82.946 ms 91.731 ms
5 3-4.ipv6.r1.ch.hwng.net (2001:4de0:1000:17::1) 135.88 ms 132.194 ms 143.07 ms
6 1-4.ipv6.r1.ny.hwng.net (2001:4de0:1000:13::1) 163.725 ms 153.659 ms 153.998 ms
7 8-1.ipv6.r1.dc.hwng.net (2001:4de0:1000:12::2) 160.303 ms 167.786 ms 162.19 ms
8 2-3.ipv6.r2.dc.hwng.net (2001:4de0:1000:9::2) 163.695 ms 160.097 ms 164.558 ms
9 5-4.ipv6.r2.am.hwng.net (2001:4de0:1000:5::1) 255.604 ms 269.993 ms 257.507 ms
10 1-3.ipv6.r2.am.hwng.net (2001:4de0:1000:1::2) 254.402 ms 251.368 ms 252.099 ms
11 ams-ix.ipv6.concepts.nl (2001:7f8:1::a501:2871:1) 259.071 ms 254.372 ms 254.804 ms
12 2001:838:5:a::2 (2001:838:5:a::2) 260.289 ms 260.812 ms 263.003 ms
13 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 261.966 ms 257.141 ms 255.88 ms
######
###### [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
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2001:1938:81:a5::2, 30 hops max, 24 byte packets
1 gw-166.phx-01.us.sixxs.net (2001:1938:81:a5::1) 74.624 ms 75.905 ms 74.641 ms
2 2001:4de0:1000:a4::1 (2001:4de0:1000:a4::1) 179.384 ms 76.659 ms 74.289 ms
3 1-3.ipv6.r1.ph.hwng.net (2001:4de0:1000:27::2) 82.522 ms 75.788 ms 74.728 ms
4 2001:478:186::20 (2001:478:186::20) 88.81 ms 78.291 ms 76.037 ms
5 10gigabitethernet2-2.core1.lax1.he.net (2001:470:0:159::1) 87.361 ms 85.549 ms 98.794 ms
6 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 95.566 ms 99.467 ms 100.547 ms
7 10gigabitethernet1-1.core1.sjc2.he.net (2001:470:0:31::2) 93.614 ms 97.296 ms 94.836 ms
8 xe-0.equinix.snjsca04.us.bb.gin.ntt.net (2001:504:0:1::2914:1) 104.142 ms 102.366 ms 103.788 ms
9 as-1.r21.osakjp01.jp.bb.gin.ntt.net (2001:218:0:2000::aa) 218.856 ms 217.758 ms 217.281 ms
10 ae-2.r22.osakjp01.jp.bb.gin.ntt.net (2001:218:0:2000::1b6) 217.012 ms 213.457 ms 244.476 ms
11 ae-5.r24.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::1de) 212.78 ms 210.796 ms 379.658 ms
12 po-1.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:0:6000::10e) 220.668 ms 222.164 ms 219.772 ms
13 ge-8-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:2000:5000::82) 238.701 ms 240.107 ms 445.057 ms
14 ve44.foundry6.otemachi.wide.ad.jp (2001:200:0:10::141) 212.842 ms 244.52 ms 213.209 ms
15 ve42.foundry4.nezu.wide.ad.jp (2001:200:0:11::66) 216.402 ms 213.484 ms 229.83 ms
16 cloud-net1.wide.ad.jp (2001:200:0:1c0a:218:8bff:fe43:d1d0) 213.02 ms 213.957 ms 215.537 ms
17 2001:200:dff:fff1:216:3eff:feb1:44d7 (2001:200:dff:fff1:216:3eff:feb1:44d7) 226.469 ms 226.732 ms 227.023 ms
######
###### 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.
Aiccu Version: AICCU 2007.01.15-console-linux by Jeroen Massar
(Debian (sid) package - aiccu 20070115-14)
My email: ttelford@pariahzero.net
#aiccu tunnels output: T23442 2001:1938:81:a5::2 heartbeat usphx01
Provide details of the setup, type of connections, where NATs are located:
Setup: Internet -> Cable Modem -> Linux PC (running aiccu)
The Linux box is directly connected to the Internet. It runs AICCU & a firewall. (The Linux box does run NAT to provide Internet to hosts on my home network; but AICCU is connecting directly).
OS Type: Debian (sid) - Linux 3.2.0-1-amd64 #1 SMP Thu Jan 19 09:46:46 UTC 2012 x86_64 GNU/Linux
Interface information:
eth0: - internal network; provides NAT IPv4 to the 'inside' - I doubt this part is causing issues...
eth1: - external network, connected to the cable modem
sixxs: - aiccu tunnel
`ip tunnel show sixxs` output:
ipv6/ip remote 209.197.5.66 local 24.10.222.127 ttl 64 6rd-prefix 2002::/16
IPv4 Routing Table: (ip route show)
default via 24.10.216.1 dev eth1
24.10.216.0/21 dev eth1 proto kernel scope link src 24.10.222.127
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
224.0.0.0/4 dev eth0 scope link
IPv6 Routing Table (ip -6 route show)
2001:1938:81:a5::/64 via :: dev sixxs proto kernel metric 256
2001:1938:240:1000::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 via :: dev sixxs proto kernel metric 256
default via 2001:1938:81:a5::1 dev sixxs metric 1024
IPv4 Firewall Tables: I use shorewall; iptables -L is very, very long, but I'll give the overall idea:
Targets
firewall - the box running AICCU
net: eth1, ipv4 connected to the cable modem
sixxs: aiccu-created tun interface
POLICY:
DROP net -> firewall
ACCEPT firewall -> net
DROP sixxs -> firewall (drops IPv4 coming through the sixxs tunnel, as it's supposed to be ipv6, right?)
DROP net -> firewall icmp 8
DROP firewall -> net tcp/udp 137-139, 445, 631, 5353-5354
ACCEPT net -> firewall tcp 22 (ssh)
IPv6 firewall tables: Again, I use shore wall, but I'll paste many of the iptables rules, as the list is much shorter...
Overall goal: IPv6 connection tracking firewall, routes connections to/from hosts inside the firewall. The SSH port is explicitly open but only to the firewall host itself.
Chain AllowICMPs (2 references)
target prot opt source destination
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp destination-unreachable /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp packet-too-big /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp time-exceeded /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp parameter-problem /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-solicitation /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-advertisement /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp redirect /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 141 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 142 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 130 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 131 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 132 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 143 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 148 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 149 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 151 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 152 /* Needed ICMP types (RFC4890) */
ACCEPT ipv6-icmp fe80::/10 anywhere ipv6-icmptype 153 /* Needed ICMP types (RFC4890) */
Chain Broadcast (2 references)
target prot opt source destination
DROP all anywhere 2001:1938:240:1000::/128
DROP all anywhere 2001:1938:240:1000:ffff:ffff:ffff:ff80/121
DROP all anywhere 2001:1938:240:2000::/128
DROP all anywhere 2001:1938:240:2000:ffff:ffff:ffff:ff80/121
DROP all anywhere 2001:1938:240:3000::/128
DROP all anywhere 2001:1938:240:3000:ffff:ffff:ffff:ff80/121
DROP all anywhere 2001:1938:81:a5::/128
DROP all anywhere 2001:1938:81:a5:ffff:ffff:ffff:ff80/121
DROP all anywhere ip6-mcastprefix/8
Chain Drop (16 references)
target prot opt source destination
reject tcp anywhere anywhere tcp dpt:auth /* Auth */
AllowICMPs ipv6-icmp anywhere anywhere
Broadcast all anywhere anywhere
Invalid all anywhere anywhere
DROP udp anywhere anywhere multiport dports loc-srv,microsoft-ds /* SMB */
DROP udp anywhere anywhere udp dpts:netbios-ns:netbios-ssn /* SMB */
DROP udp anywhere anywhere udp spt:netbios-ns dpts:1024:65535 /* SMB */
DROP tcp anywhere anywhere multiport dports loc-srv,netbios-ssn,microsoft-ds /* SMB */
NotSyn tcp anywhere anywhere
DROP udp anywhere anywhere udp spt:domain /* Late DNS Replies */
Chain Reject (0 references)
target prot opt source destination
reject tcp anywhere anywhere tcp dpt:auth /* Auth */
AllowICMPs ipv6-icmp anywhere anywhere
Broadcast all anywhere anywhere
Invalid all anywhere anywhere
reject udp anywhere anywhere multiport dports loc-srv,microsoft-ds /* SMB */
reject udp anywhere anywhere udp dpts:netbios-ns:netbios-ssn /* SMB */
reject udp anywhere anywhere udp spt:netbios-ns dpts:1024:65535 /* SMB */
reject tcp anywhere anywhere multiport dports loc-srv,netbios-ssn,microsoft-ds /* SMB */
NotSyn tcp anywhere anywhere
DROP udp anywhere anywhere udp spt:domain /* Late DNS Replies */
Chain sixxs2fw6 (1 references)
target prot opt source destination
dynamic all anywhere anywhere ctstate INVALID,NEW
ACCEPT all anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp anywhere 2001:1938:240:1000::1/128 tcp dpt:ssh
Drop all anywhere anywhere
LOG all anywhere anywhere LOG level info prefix "Shorewall:sixxs2fw6:DROP:"
DROP all anywhere anywhere
Clock sync is via NTP:
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+2607:fa18::2407 .GPS. 1 u 1013 1024 17 111.235 12.692 0.694
*home.curby.net .PPS. 1 u 433 1024 377 75.246 -10.278 36.657
Wireshark is showing heartbeats going out over the ipv4 to the PoP: (filter: eth1 udp.port == 3740)
)
(I wish I could copy/paste, but I can't seem to figure out how to do it in wireshark...)
Knowing what I should be looking for (inbound/outbound, protocols, ports, which interface) would be useful to know; it seemed logical to me to look at my outgoing IPv4 Ethernet port, and UDP port 3740, since that's where the heartbeat exits. (I have no idea if anything is supposed to come back, though)
The PoP is usphx01
No heartbeat detected?
eth0: - internal network; provides NAT IPv4 to the 'inside' - I doubt this part is causing issues...
Note that I wrote:
Next to of course "My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker".
That thing is very important as it is sneaky timeout behavior that is unexpected, when one uses the tunnel your packets keep on flowing, but when you don't generate packets from the inside the tunnel dies off for any incoming packets from the outside.
Chain AllowICMPs (2 references)
As a side-note: It really does not make any sense to 'block' ICMP that way IMHO...
Chain Broadcast (2 references)
As there is no such thing as broadcast in IPv6, that name is certainly wrong. It looks like you are trying to block the subnet anycast addresses, which generally is a bad idea too.
ACCEPT all anywhere anywhere ctstate RELATED,ESTABLISHED
There you go, a nice connection tracker. Note that those things live on both IPv4 and IPv6 and affect thus your connectivity on both.
No heartbeat detected?
Shadow Hawkins on Monday, 23 January 2012 22:35:22Next to of course "My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker".
That thing is very important as it is sneaky timeout behavior that is unexpected, when one uses the tunnel your packets keep on flowing, but when you don't generate packets from the inside the tunnel dies off for any incoming packets from the outside.
Understood; however I run a znc relay (ZNC is an IRC bouncer), and it connects to several IPv6 IRC servers, and is constantly lurking on a few channels - so there is always a little traffic over IPv6; my wireshark dumps bear this out.
As a side-note: It really does not make any sense to 'block' ICMP that way IMHO...
I realize that; it was more of an experiment when I was playing with ICMP & shorewall that was left on.
As there is no such thing as broadcast in IPv6, that name is certainly wrong. It looks like you are trying to block the subnet anycast addresses, which generally is a bad idea too.
That ruleset is auto-generated by shorewall6 (the IPv6 version of shore wall). If you can explain why it's a bad idea, (as I'm not overly qualified; I'm using sixxs to learn, after all...). I'll file an appropriate bug with the developer.
As an aside: I noted earlier you mentioned that the website isn't always reliable. (ie. One of the many reasons why we are moving to sixxsd v4.. I can accept & live with that.
I'm still not (and haven't been - for at least 2 years) earning ISK.
- I can ping my PoP via IPv4 & IPv6. The tunnel rarely (every few months at most) goes down.
- Wireshark and tcpdump clearly show that I'm sending out heartbeats:
tcpdump -i eth1 dst usphx01.sixxs.net and port 3740
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:23:46.232974 IP c-24-10-222-127.hsd1.ut.comcast.net.38947 > usphx01.sixxs.net.3740: UDP, length 86
14:24:46.233276 IP c-24-10-222-127.hsd1.ut.comcast.net.59487 > usphx01.sixxs.net.3740: UDP, length 86
So, my question remains: Am I missing something in the heartbeat that's needed to "earn" ISK? Does the PoP (or sixxs) send out heartbeats to my machine? Are there packets I should be expecting from sixxs but are possibly being dropped by my firewall?
No heartbeat detected?
so there is always a little traffic over IPv6; my wireshark dumps bear this out.
While having a little traffic might help, it might not be enough to keep the right things open, hence why there is a FAQ item about it.
I realize that; it was more of an experiment when I was playing with ICMP & shorewall that was left on.
And how many other things where still left on as an experiment that can block the packets needed for your endpoint to be seen as alive?
If you can explain why it's a bad idea,
Firewalls are not something that can be point and clicked together, it just does not work that way. But for some people it works for some it doesn't.
I noted earlier you mentioned that the website isn't always reliable.
That is not what I stated.
One of the many reasons why we are moving to sixxsd v4..
While that is what I stated, it is out of context. We are moving to sixxsd v4 as it provides features not present in v3, hence the newer version number. Note that sixxsd is the PoP software and hence has little to do with the website.
- Wireshark and tcpdump clearly show that I'm sending out heartbeats:
Heartbeat is for informing the PoP that your tunnel endpoint is currently at the given IPv4 address. It has nothing to do with the latency check. Please see the FAQ.
Am I missing something in the heartbeat that's needed to "earn" ISK?
Yes, the fact that heartbeat is not used for checking if the tunnel is alive, ICMPv6 from <tunnel>::1 (PoP) to <tunnel>::2 (Your endpoint) is.
Does the PoP (or sixxs) send out heartbeats to my machine?
No, why would we? Your endpoint is the dynamic part of the tunnel, that is why, with the heartbeats you are telling that your endpoint is currently there. The PoP's side of the tunnel is static.
Are there packets I should be expecting from sixxs but are possibly being dropped by my firewall?
Very likely. See the FAQ for the exact details.
Do realize that you need a combination of all the FAQs, we could of course put everything on one page, but that would make it quite messy.
No heartbeat detected?
Shadow Hawkins on Tuesday, 24 January 2012 00:21:55And how many other things where still left on as an experiment that can block the packets needed for your endpoint to be seen as alive?
None; I can say that for certain having just verified it.
While that is what I stated, it is out of context.
I meant no offense; I was stating the way I understood the response. With little else to go on (and no background of how sixxs works internally), the context seemed to be about how the PoP communicates to the web server. Just a miscommunication, and I'm sorry.
Firewalls are not something that can be point and clicked together, it just does not work that way. But for some people it works for some it doesn't.
I agree completely; for what it's worth shorewall is not point and click.
Heartbeat is for informing the PoP that your tunnel endpoint is currently at the given IPv4 address. It has nothing to do with the latency check. Please see the FAQ.
This is the first time I've read the term "latency check" in the context of sixxs - and I've been scouring the FAQ's most of the day.
I originally understood "The host pinged yet another week" at the bottom of ISK credits to mean my host pinged sixxs; not that sixxs was able to (or would even attempt to) ping my host.
As far as asking about a heartbeat from sixxs to my machine - It would be better described as asking whether sixxs sends a signal to my machine and waiting for a response - like a ping.
As I (mis)understood "The host pinged yet another week" to mean "from my host -> the sixxs pop", it was not clear to me that sixxs sends a ping to my machine. (This ping was absolutely blocked by my firewall - when I said I only allowed ssh to enter, I meant it...)
I've gone through most of the FAQ documents; I've found other useful things (for the benefit of anybody else reading):
connection tracking info - I've started using this.
heartbeat information - which mentions using wireshark to check for heartbeats, as well as checking protocol 41 for aiccu traffic - which are both things I've done.
So, it appears that if I allow sixxs to ping my machine via IPv6, I'll start earning ISK again.
Thanks for your help.
No heartbeat detected?
You might want to check I have a firewall, what ports/protocols are used? too...
|
![[ch]](/s/countries/ch.gif)
on Monday, 23 January 2012 11:16:16
Posting is only allowed when you are