|
AICCU tunnel stops working, won't work again unless daemon is restarted
![[br]](/s/countries/br.gif) Carmen Sandiego on Tuesday, 12 March 2013 01:28:40
Good evening people.
I've successfully set up AICCU on my Fedora Linux 18 box with the binary provided by the Fedora repository. Information on the package version follows:
Name : aiccu
Version : 2007.01.15
Release : 15.fc18
Architecture: x86_64
Install Date: Dom 10 Mar 2013 20:57:06 BRT
Group : System Environment/Daemons
Size : 74782
License : BSD
Signature : RSA/SHA256, Qui 09 Ago 2012 16:27:24 BRT, Key ID ff01125cde7f38bd
Source RPM : aiccu-2007.01.15-15.fc18.src.rpm
Build Date : Seg 06 Ago 2012 21:17:30 BRT
Build Host : buildvm-20.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.sixxs.net/tools/aiccu/
Summary : SixXS Automatic IPv6 Connectivity Client Utility
When the tunnel is activated, everything seems to be fine and initially the tunnel is completely functional: Log follows:
Mar 11 22:03:22 wotan systemd[1]: Starting AICCU (AAutomatic IPv6 Connectivity Configuration Utility)...
Mar 11 22:03:23 wotan aiccu: TIC Server does not support TLS but TLS is not required, continuing
Mar 11 22:03:25 wotan aiccu: Succesfully retrieved tunnel information for T118818
Mar 11 22:03:25 wotan aiccu: AICCU running as PID 23198
Mar 11 22:03:25 wotan aiccu[23193]: Tunnel Information for T118818:
Mar 11 22:03:25 wotan aiccu[23193]: POP Id : brudi01
Mar 11 22:03:25 wotan aiccu[23193]: IPv6 Local : 2001:1291:200:447::2/64
Mar 11 22:03:25 wotan aiccu[23193]: IPv6 Remote : 2001:1291:200:447::1/64
Mar 11 22:03:25 wotan aiccu[23193]: Tunnel Type : ayiya
Mar 11 22:03:25 wotan aiccu[23193]: Adminstate : enabled
Mar 11 22:03:25 wotan aiccu[23193]: Userstate : enabled
Mar 11 22:03:25 wotan aiccu[23193]: Tunnel Information for T118818:
Mar 11 22:03:25 wotan aiccu[23193]: POP Id : brudi01
Mar 11 22:03:25 wotan aiccu[23193]: IPv6 Local : 2001:1291:200:447::2/64
Mar 11 22:03:25 wotan aiccu[23193]: IPv6 Remote : 2001:1291:200:447::1/64
Mar 11 22:03:25 wotan aiccu[23193]: Tunnel Type : ayiya
Mar 11 22:03:25 wotan aiccu[23193]: Adminstate : enabled
Mar 11 22:03:25 wotan aiccu[23193]: Userstate : enabled
Mar 11 22:03:25 wotan systemd[1]: Started AICCU (AAutomatic IPv6 Connectivity Configuration Utility).
Mar 11 22:03:25 wotan NetworkManager[905]: <warn> /sys/devices/virtual/net/sixxs: couldn't determine device driver; ignoring...
Mar 11 22:03:25 wotan aiccu: [AYIYA-start] : Anything in Anything (draft-02)
Mar 11 22:03:25 wotan aiccu: [AYIYA-tun->tundev] : (Socket to TUN) started
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ ping6 v6.ipv6.br
PING v6.ipv6.br(ipv6.br) 56 data bytes
64 bytes from ipv6.br: icmp_seq=1 ttl=56 time=63.3 ms
64 bytes from ipv6.br: icmp_seq=2 ttl=56 time=51.3 ms
64 bytes from ipv6.br: icmp_seq=3 ttl=56 time=47.4 ms
64 bytes from ipv6.br: icmp_seq=4 ttl=56 time=48.2 ms
^C
--- v6.ipv6.br ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 47.452/52.612/63.391/6.390 ms
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ ping6 www.kame.net
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=51 time=393 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=2 ttl=51 time=395 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=3 ttl=51 time=405 ms
^C64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=4 ttl=51 time=387 ms
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ tracepath6 www.kame.net
1?: [LOCALHOST] 0.124ms pmtu 1280
1: gw-1096.udi-01.br.sixxs.net 29.712ms
1: gw-1096.udi-01.br.sixxs.net 43.353ms
2: brudi01.sixxs.net 33.176ms asymm 1
3: ge-0-2-0-71.edge-b.ula001.ctbc.com.br 153.255ms
4: ge-1-0-7-0.core-b.ula001.ctbc.com.br 38.931ms asymm 3
5: ae3-0.core-b.spo511.ctbc.com.br 57.439ms asymm 4
6: ae5-0.core-a.spo511.ctbc.com.br 78.488ms asymm 5
7: xe-0-0-0-0.border-a.mia.ctbc.com.br 154.703ms asymm 6
8: ??? 170.798ms asymm 7
9: 10gigabitethernet1-1.core1.atl1.he.net 267.494ms asymm 6
10: 10gigabitethernet6-4.core1.ash1.he.net 179.120ms asymm 5
11: xe-0.equinix.asbnva01.us.bb.gin.ntt.net 201.426ms asymm 9
12: ae-6.r21.asbnva02.us.bb.gin.ntt.net 196.915ms asymm 9
13: ae-5.r21.sttlwa01.us.bb.gin.ntt.net 284.989ms asymm 8
14: ae-0.r20.sttlwa01.us.bb.gin.ntt.net 247.034ms asymm 8
15: as-3.r20.tokyjp01.jp.bb.gin.ntt.net 367.292ms asymm 10
16: ae-1.r24.tokyjp01.jp.bb.gin.ntt.net 421.501ms asymm 12
17: po-1.a15.tokyjp01.jp.ra.gin.ntt.net 408.307ms asymm 10
18: ge-8-2.a15.tokyjp01.jp.ce.gin.ntt.net 394.405ms asymm 11
19: ve44.foundry6.otemachi.wide.ad.jp 366.223ms asymm 12
20: 2001:200:0:180a:a6ba:dbff:fe1d:19f4 342.641ms asymm 13
21: 2001:200:dff:fff1:216:3eff:feb1:44d7 375.878ms reached
Resume: pmtu 1280 hops 21 back 51
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ traceroute6 v6.ipv6.br
traceroute to v6.ipv6.br (2001:12ff:0:4::22), 30 hops max, 80 byte packets
1 gw-1096.udi-01.br.sixxs.net (2001:1291:200:447::1) 45.390 ms 45.530 ms 45.524 ms
2 brudi01.sixxs.net (2001:1291:2::b) 45.521 ms 45.513 ms 45.510 ms
3 ge-0-2-0-71.edge-b.ula001.ctbc.com.br (2001:1291:2::a) 45.586 ms 45.831 ms 50.705 ms
4 ge-1-0-7-0.core-b.ula001.ctbc.com.br (2001:1291:0:2::b) 50.605 ms 50.617 ms 50.612 ms
5 ae3-0.core-b.spo511.ctbc.com.br (2001:1291:0:4::b) 69.394 ms 69.704 ms 69.201 ms
6 xe-0-1-0-0.edge-c.spo511.ctbc.com.br (2001:1291:0:15::b) 69.216 ms 50.976 ms 51.172 ms
7 2001:1291:1301:e::b (2001:1291:1301:e::b) 51.506 ms 51.688 ms 51.715 ms
8 xe-5-0-1-0.core2.nu.registro.br (2001:12ff:1::168) 51.083 ms 51.449 ms 51.671 ms
9 ae0-0.ar4.nu.registro.br (2001:12ff:2:1::250) 51.649 ms 58.162 ms ae0-0.ar3.nu.registro.br (2001:12ff:2:1::249) 58.508 ms
10 ipv6.br (2001:12ff:0:4::22) 58.452 ms 51.893 ms 57.503 ms
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ traceroute6 brudi01.sixxs.net
traceroute to brudi01.sixxs.net (2001:1291:2::b), 30 hops max, 80 byte packets
1 gw-1096.udi-01.br.sixxs.net (2001:1291:200:447::1) 33.536 ms 33.526 ms 33.518 ms
2 brudi01.sixxs.net (2001:1291:2::b) 33.504 ms 33.492 ms 33.480 ms
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ traceroute brudi01.sixxs.net
traceroute to brudi01.sixxs.net (201.48.254.14), 30 hops max, 60 byte packets
1 loge.walhalla (192.168.1.1) 0.153 ms 0.208 ms 0.236 ms
2 189.38.148.1.user.ajato.com.br (189.38.148.1) 8.370 ms 8.379 ms 8.381 ms
3 200-170-105-1.user.ajato.com.br (200.170.105.1) 14.438 ms 14.472 ms 14.534 ms
4 as16735.sp.ptt.br (187.16.217.48) 14.532 ms 14.428 ms 14.503 ms
5 xe-1-2-0-0.core-b.spo511.ctbc.com.br (201.48.46.34) 14.748 ms 14.736 ms 14.722 ms
6 ae1-0.core-b.ula001.ctbc.com.br (201.48.44.13) 34.087 ms 33.824 ms 33.825 ms
7 ge-1-0-0-0.edge-b.ula001.ctbc.com.br (201.48.44.70) 33.811 ms 31.800 ms 31.561 ms
8 brudi01.sixxs.net (201.48.254.14) 31.470 ms 37.049 ms 36.980 ms
--------------------------------------------------------------------------------
However, after some time (no more than half an hour normally) the connection just stops working silently. No logs from AICCU on /var/log/messages.log, but I know the connection is down because GMail and GTalk won't work anymore sometimes when this happens. The only way to reactivate the IPv6 connection is restarting the AICCU daemon.
My setup is deceptively simple: the only computer which is using IPv6 has a wired connection to the wireless router, a TP-LINK WDR3600 with the latest firmware (which even supports IPv6 but not AICCU). This router is connected to the cable modem of my ISP (20 Mbps downlink/1 Mbps uplink) and it also does NAT for my entire home network.
Route tables follow:
[pfessel@wotan ~]$ ip -6 route list
unreachable ::/96 dev lo metric 1024 error -101
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
2001:1291:200:447::/64 dev p22p1 proto kernel metric 256
2001:1291:200:447::/64 dev sixxs proto kernel metric 256
unreachable 2002:a00::/24 dev lo metric 1024 error -101
unreachable 2002:7f00::/24 dev lo metric 1024 error -101
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
unreachable 2002:ac10::/28 dev lo metric 1024 error -101
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
unreachable 2002:e000::/19 dev lo metric 1024 error -101
2800:3f0:4001:803::1005 via 2001:1291:200:447::1 dev sixxs metric 0
cache
2800:3f0:4001:803::100e via 2001:1291:200:447::1 dev sixxs metric 0
cache
2800:3f0:4001:803::1015 via 2001:1291:200:447::1 dev sixxs metric 0
cache
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
fe80::/64 dev p22p1 proto kernel metric 256
fe80::/64 dev sixxs proto kernel metric 256
default via 2001:1291:200:447::1 dev sixxs metric 1024
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ ip route list
default via 192.168.1.1 dev p22p1 proto static
192.168.1.0/24 dev p22p1 proto kernel scope link src 192.168.1.4
--------------------------------------------------------------------------------
There is no firewall activated locally on this machine (except for fail2ban, but this regards only SSH and exists only for IPv4):
[pfessel@wotan ~]$ sudo ip6tables -L
[sudo] password for pfessel:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[pfessel@wotan ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-SSH (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
--------------------------------------------------------------------------------
Address and link tables follow:
[pfessel@wotan ~]$ ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: p22p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 48:5b:39:b8:3b:66 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT
link/sit 0.0.0.0 brd 0.0.0.0
10: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 500
link/none
--------------------------------------------------------------------------------
[pfessel@wotan ~]$ ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: p22p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 48:5b:39:b8:3b:66 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global p22p1
inet6 2001:1291:200:447::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4a5b:39ff:feb8:3b66/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
10: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet6 2001:1291:200:447::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1091:200:447:2/64 scope link
valid_lft forever preferred_lft forever
At this very moment it is still working. Any suggestions on where must I check first? The router is brand new and it's been working flawlessly with IPv4. Should I disable IPv6 on the router just in case?
AICCU tunnel stops working, won't work again unless daemon is restarted
Fedora Linux 18 box with the binary provided by the Fedora repository
What changes do they make to it?
(no more than half an hour normally)
Sounds a lot like a connection tracker time out.
No logs from AICCU on /var/log/messages.log
AICCU in AYIYA mode just sends UDP packets, these can be lost anywhere along the path.
If packets get rejected already locally AICCU will log this, but otherwise there is little it can see.
but I know the connection is down because GMail and GTalk won't work anymore sometimes when this happens.
Got traceroutes and/or tcpdumps?
My setup is deceptively simple
Deception indeed, as you are forgetting that packets do not only cross your computer and network, but also the traverse the whole stack up to the PoP. A problem could be in any of these.
it also does NAT
Does your cable modem perform the NAT or the TP-LINK WDR3600?
2001:1291:200:447::/64 dev p22p1 proto kernel metric 256 2001:1291:200:447::/64 dev sixxs proto kernel metric 256
Why do you have the tunnel prefix assigned to two interfaces? That will not work.
What is this "p22p1" interface?
There is no firewall activated locally on this machine
Even if you don't have a firewall you will have state tracking. Also note that there is a firewall active as you have one for fail2ban rules.
Any suggestions on where must I check first?
When posting there is shown a big yellow/orange box, it points to the contact page, there you will find a long list of things to check.
The router is brand new and it's been working flawlessly with IPv4.
Which "router"? The cable box or the TP-Link?
Should I disable IPv6 on the router just in case?
Which component do you do IPv6 with?
AICCU tunnel stops working, won't work again unless daemon is restarted
Carmen Sandiego on Tuesday, 12 March 2013 09:18:32
Let's go in parts, like Jack would do.
Fedora Linux 18 box with the binary provided by the Fedora repository
What changes do they make to it?
As far as I could tell, they apply three patches: two of them are very simple and just changes some paths of the configuration file and the runtime pid; the second patch just changes aiccu log level to DAEMON. The third patch is longer and I'm reposting it below:
+++ aiccu/common/common.c 2008-10-17 22:11:52.000000000 -0500
@@ -365,6 +365,7 @@ TLSSOCKET connect_client(const char *hos
{
sock->socket = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (sock->socket == -1) continue;
+ fcntl(sock->socket, F_SETFD, FD_CLOEXEC);
if (connect(sock->socket, res->ai_addr, (unsigned int)res->ai_addrlen) == 0) break;
closesocket(sock->socket);
sock->socket = -1;
@@ -428,6 +429,7 @@ TLSSOCKET listen_server(const char *desc
sock->socket = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (!(sock->socket < 0))
{
+ fcntl(sock->socket, F_SETFD, FD_CLOEXEC);
setsockopt(sock->socket, SOL_SOCKET, SO_REUSEADDR, (const char *)&on, sizeof(on));
if (bind(sock->socket, res->ai_addr, (unsigned int)res->ai_addrlen) == 0) break;
closesocket(sock->socket);
diff -urNp --exclude-from=/home/mdomsch/excludes --minimal aiccu.orig/common/heartbeat.c aiccu/common/heartbeat.c
--- aiccu.orig/common/heartbeat.c 2008-10-17 18:43:13.000000000 -0500
+++ aiccu/common/heartbeat.c 2008-10-17 22:12:51.000000000 -0500
@@ -58,6 +58,7 @@ SOCKET heartbeat_socket(
dolog(LOG_ERR, "Couldn't open a socket for determining current IPv4 address\n");
return -1;
}
+ fcntl(sockfd, F_SETFD, FD_CLOEXEC);
#if defined(SOL_SOCKET) && defined(SO_BINDTODEVICE)
/*
diff -urNp --exclude-from=/home/mdomsch/excludes --minimal aiccu.orig/common/tun.c aiccu/common/tun.c
--- aiccu.orig/common/tun.c 2008-10-17 18:43:13.000000000 -0500
+++ aiccu/common/tun.c 2008-10-17 22:12:42.000000000 -0500
@@ -696,6 +696,8 @@ bool tun_start(struct tun_reader *tun)
/* Create a new tap device */
tun_fd = open("/dev/net/tun", O_RDWR);
+ if (tun_fd >= 0)
+ fcntl(tun_fd, F_SETFD, FD_CLOEXEC);
if (tun_fd == -1)
{
tun_log(LOG_ERR, "start", "Couldn't open device %s: %s (%d)\n", "/dev/net/tun", strerror(errno), errno);
@@ -725,6 +727,8 @@ bool tun_start(struct tun_reader *tun)
tun_log(LOG_DEBUG, "start", "Trying Configured TUN/TAP interface %s...\n", g_aiccu->ipv6_interface);
snprintf(buf, sizeof(buf), "/dev/%s", g_aiccu->ipv6_interface);
tun_fd = open(buf, O_RDWR);
+ if (tun_fd >= 0)
+ fcntl(tun_fd, F_SETFD, FD_CLOEXEC);
if (tun_fd < 0)
{
/* Fall back to trying all /dev/tun* devices */
@@ -735,6 +739,7 @@ bool tun_start(struct tun_reader *tun)
tun_fd = open(buf, O_RDWR);
if (tun_fd >= 0)
{
+ fcntl(tun_fd, F_SETFD, FD_CLOEXEC);
/* Copy over the name of the interface so that configging goes okay */
if (g_aiccu->ipv6_interface) free(g_aiccu->ipv6_interface);
snprintf(buf, sizeof(buf), "tun%u", i);
I'm no C expert but it seems that they're setting an additional flag (FD_CLOEXEC) to the tunnel's file descriptor.
My setup is deceptively simple
WDR3600 does the NAT. The cable modem is just a bridge between the cable network and the WAN ethernet port.
Deception indeed, as you are forgetting that packets do not only cross your computer and network, but also the traverse the whole stack up to the PoP. A problem could be in any of these. it also does NAT
Does your cable modem perform the NAT or the TP-LINK WDR3600? 2001:1291:200:447::/64 dev p22p1 proto kernel metric 256
2001:1291:200:447::/64 dev sixxs proto kernel metric 256
p22p1 is my wired ethernet interface. I also find it stupid but it's just the new way FC18 names ethernet interfaces (instead of the traditional ethX).
I don't know why the tunnel prefix is assigned to these two interfaces. The configuration file for the ethernet port is as follows:
Why do you have the tunnel prefix assigned to two interfaces? That will not work. What is this "p22p1" interface? DEVICE="p22p1"
BOOTPROTO=none
ONBOOT="yes" UUID="70d64a7e-7d52-4ff5-8b4b-38f4e65a1c2d"
TYPE=Ethernet
DNS1=200.162.196.29
DNS2=200.162.194.244
DOMAIN=ajato.com.br DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes NAME="Sistema p22p1"
IPADDR0=192.168.1.4
PREFIX0=24
GATEWAY0=192.168.1.1
IPV6_AUTOCONF=no
IPV6_DEFAULTGW=::
IPV6ADDR=2001:1291:200:447::2/64
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=yes
HWADDR=48:5B:39:B8:3B:66
DNS3=2a02:578:1:8::2
DNS4=2001:770:18:8::4
IPV6_PRIVACY=no
There is no firewall activated locally on this machine
The firewall is active but only for IPv4. And the only rule it has regards to fail2ban, which blocks the idiots who keep trying to ssh me (on IPv4) trying to get root logins and so on. There isn't any other rule that can impart AICCU (unless you use 22/tcp for some obscure reason not stated on the documentation). And I've just checked that there is not even connection tracking by the firewall, as the ipt_conntrack module is not even loaded.
Even if you don't have a firewall you will have state tracking. Also note that there is a firewall active as you have one for fail2ban rules. The router is brand new and it's been working flawlessly with IPv4.
Again: the cable box is not a router, but just a bridge. TP-Link is the router.
Which "router"? The cable box or the TP-Link? Should I disable IPv6 on the router just in case?
IPv6 is done just on Linux machine (FC18). Router (TP-Link) has IPv6 capabilities but I'm not using them at the moment.
As of now I don't have IPv6 connectivity. Traceroutes as requested:
Which component do you do IPv6 with? [pfessel@wotan Downloads]$ traceroute brudi01.sixxs.net
traceroute to brudi01.sixxs.net (201.48.254.14), 30 hops max, 60 byte packets
1 loge.walhalla (192.168.1.1) 0.165 ms 0.225 ms 0.255 ms
2 189.38.148.1.user.ajato.com.br (189.38.148.1) 8.703 ms 8.720 ms 8.736 ms
3 200-170-105-1.user.ajato.com.br (200.170.105.1) 16.626 ms 16.757 ms 16.805 ms
4 as16735.sp.ptt.br (187.16.217.48) 16.676 ms 16.561 ms 16.581 ms
5 xe-1-2-0-0.core-b.spo511.ctbc.com.br (201.48.46.34) 16.979 ms 16.676 ms 16.922 ms
6 ae1-0.core-b.ula001.ctbc.com.br (201.48.44.13) 36.029 ms 35.673 ms 35.670 ms
7 ge-1-0-0-0.edge-b.ula001.ctbc.com.br (201.48.44.70) 35.667 ms 31.595 ms 31.447 ms
8 brudi01.sixxs.net (201.48.254.14) 37.329 ms 37.321 ms 37.523 ms
[pfessel@wotan Downloads]$ traceroute6 brudi01.sixxs.net
traceroute to brudi01.sixxs.net (2001:1291:2::b), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
...
How should I forward the ethernet captures? Directly to info@sixxs.net?
AICCU tunnel stops working, won't work again unless daemon is restarted
WDR3600 does the NAT.
Did you check the logs on that device?
The configuration file for the ethernet port is as follows: IPV6ADDR=2001:1291:200:447::2/64
Because of that. You need to use your subnet there. In your case 2001:1291:200:8447::1/64, typically one numbers the router of the subnet <prefix>::1.
The firewall is active but only for IPv4.
Please note that IPv6 packets are tunneled over IPv4, thus IPv4 affects IPv6 because of that.
Connection tracking is always active. See the FAQ for more details.
(unless you use 22/tcp for some obscure reason not stated on the documentation)
No it does not. See the firewall FAQ for the exact ports. Though do note that outbound packets can be sourced from any source port as AICCU lets the OS choose. Typically that will mean they are in the 1024-65k range though.
the ipt_conntrack module is not even loaded.
As it is a default component of most Linux kernels thus no modules are needed...
Also note that connection tracking for sure will happen in your WDR3600 as it does NAT.
How should I forward the ethernet captures?
What about looking at them and checking what might go wrong?
AICCU tunnel stops working, won't work again unless daemon is restarted
Carmen Sandiego on Tuesday, 12 March 2013 13:52:41
Jeroen Massar wrote:
> WDR3600 does the NAT.
Did you check the logs on that device?
The WDR3600 is probably the culprit. I've found a page where one controls its SPI (stateful) firewall, but it's just an on-off configuration - no controls for enabling or disabling specific protocols. I'll probably have to install OpenWRT on this beast to make it work...
> The configuration file for the ethernet port is as follows:
I'll try this.
IPV6ADDR=2001:1291:200:447::2/64
Because of that. You need to use your subnet there. In your case 2001:1291:200:8447::1/64, typically one numbers the router of the subnet <prefix>::1.
> The firewall is active but only for IPv4.
Please note that IPv6 packets are tunneled over IPv4, thus IPv4 affects IPv6 because of that.
Connection tracking is always active. See the FAQ for more details.
Again: how connection tracking can be active if the kernel module that enables it (in my case, /lib/modules/3.8.2-206.fc18.x86_64/kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko) is not even loaded?
Also, I don't have an /proc/net/ip_conntrack entry. And I'm not doing NAT on Linux, so this becomes a non-issue (IMNSHO).
(unless you use 22/tcp for some obscure reason not stated on the documentation)
> the ipt_conntrack module is not even loaded.
As it is a default component of most Linux kernels thus no modules are needed...
Also note that connection tracking for sure will happen in your WDR3600 as it does NAT.
For the first, you're wrong. Fedora Linux's kernels ARE modularized. On the other hand, the WDR3600 will really do connection tracking (see above).
AICCU tunnel stops working, won't work again unless daemon is restarted
Again: how connection tracking can be active if the kernel module that enables it
Because every hop in the network might have it. For instance that WDR3600.
For the first, you're wrong. Fedora Linux's kernels ARE modularized.
The conntrack module which is split into multiple modules only provides the actual tracking, but the hooks are all already in the main stack and those can cause this issue already.
AICCU tunnel stops working, won't work again unless daemon is restarted
Carmen Sandiego on Tuesday, 12 March 2013 15:28:48
I've seem to have solved the issue. But I must ping an IPv6 address every minute, or else the tunnel stops working.
Anyway, thanks for your attention.
AICCU tunnel stops working, won't work again unless daemon is restarted
Paulo Afonso Graner Fessel wrote:
I've seem to have solved the issue. But I must ping an IPv6 address every minute, or else the tunnel stops working.
If you have to keep on sending traffic to let the tunnel keep on working then you definitely have a connection tracker issue....
Try figuring out which component in your network is causing that and resolve it properly, the world is already too full with ICMPv6.
AICCU tunnel stops working, won't work again unless daemon is restarted
Carmen Sandiego on Tuesday, 12 March 2013 16:06:51
Jeroen Massar wrote:
Paulo Afonso Graner Fessel wrote:
Heh. Even with the pings it just stops working. I've been trying on www.uol.com.br (a local ISP) and by the 468th it stopped working.
I'll probably try to enable the WDR3600's DMZ feature for my workstation. Time to work on some firewall rules on my local machine...
I've seem to have solved the issue. But I must ping an IPv6 address every minute, or else the tunnel stops working.
If you have to keep on sending traffic to let the tunnel keep on working then you definitely have a connection tracker issue....
Try figuring out which component in your network is causing that and resolve it properly, the world is already too full with ICMPv6.
AICCU tunnel stops working, won't work again unless daemon is restarted
Paulo Afonso Graner Fessel wrote:
I've been trying on www.uol.com.br (a local ISP) and by the 468th it stopped working.
Are you sure that you did not hit a rate limit there, or that packets are lost on the path there?
Pinging unrelated remote entities rarely makes sense unless you are monitoring that path and you check what is affected by that path.
AICCU tunnel stops working, won't work again unless daemon is restarted
Carmen Sandiego on Tuesday, 12 March 2013 16:03:54
I've seem to have solved the issue. But I must ping an IPv6 address every minute, or else the tunnel stops working.
Anyway, thanks for your attention.
|
![[ch]](/s/countries/ch.gif)
on Tuesday, 12 March 2013 01:56:32
Posting is only allowed when you are