The state of this ticket has been changed to user

Please actually try to read, the textbox contains pre-filled the following: 8<-------------------------------------------------------------------- I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there: -------------------------------------------------------------------->8 It is there for a reason, the same as the big orange box above and below the textbox. Please use it.

I may have been slightly selective wrt which points on the checklist I covered, nor was I explicit about which points I answered, sorry. I did however read through the FAQ as I filled in the ticket so the relevant bits should already be there. Fortunatly I hadn't closed all windows yet so I could recover some additional information from scrollback buffers: * Always include clear descriptive information about your problem or inquiry. (see original report) * When on a UNIX-alike platform that supports AICCU, please run AICCU and run it using "aiccu test". root@obelix:~# aiccu test root@obelix:~# <---- no output * When using AICCU, check that you are using the latest version, and of course please specify where the binary comes from. root@obelix:~# aiccu version AICCU 2007.01.15-console-linux by Jeroen Massar root@obelix:~# * Always provide your NIC handle and if applicable the Tunnel or Route IDs you wish to discuss. NIC handle: PH2910-RIPE (also account name on your server) TunnelId: T9801 * Use the email address you have provided in your handle as that is what we use as a contact handle. That is also in my user profile * Provide details of the setup, type of connections, where NATs are located. Localhost: 192.168.1.6 NAT to: 81.31.240.106 with a zyxel sdsl router Uplink is 1024kbit SDSL * Provide information of your OS type, version and release (ie. uname -a), noting also the distribution name. * Include full interface, routing and firewall tables. ~$ ifconfig -a eth0 Link encap:Ethernet HWaddr 00:16:E6:53:37:8B inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::216:e6ff:fe53:378b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:263712 errors:0 dropped:0 overruns:0 frame:0 TX packets:262407 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:203299734 (193.8 MB) TX bytes:108808266 (103.7 MB) Interrupt:17 Base address:0xa000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5355 errors:0 dropped:0 overruns:0 frame:0 TX packets:5355 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:971721 (948.9 KB) TX bytes:971721 (948.9 KB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) sixxs Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: 2001:16d8:ff00:11b::2/64 Scope:Global inet6 addr: fe80::14d8:ff00:11b:2/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:2536 (2.4 KB) ~# routel target gateway source proto scope dev tbl 192.168.1.0/ 24 192.168.1.6 kernel link eth0 169.254.0.0/ 16 link eth0 default 192.168.1.1 eth0 192.168.1.0 broadcast 192.168.1.6 kernel link eth0 local 127.255.255.255 broadcast 127.0.0.1 kernel link lo local 192.168.1.6 local 192.168.1.6 kernel host eth0 local 192.168.1.255 broadcast 192.168.1.6 kernel link eth0 local 127.0.0.0 broadcast 127.0.0.1 kernel link lo local 127.0.0.1 local 127.0.0.1 kernel host lo local 127.0.0.0/ 8 local 127.0.0.1 kernel host lo local ::1 :: none lo 2001:16d8:ff00:11b::1 2001:16d8:ff00:11b::1 sixxs cache 2001:16d8:ff00:11b::2 :: none lo 2001:16d8:ff00:11b::/ 64 sixxs fe80::216:e6ff:fe53:378b :: none lo fe80::14d8:ff00:11b:2 :: none lo fe80::/ 64 eth0 fe80::/ 64 sixxs ff00::/ 8 eth0 ff00::/ 8 sixxs default 2001:16d8:ff00:11b::1 sixxs default unreachable none lo unspec This box has no packet filters. * Include a IPv4 and IPv6 traceroute to the PoP in question. The traceroute now stops in front of the POP as it is currently down: traceroute to 82.96.56.14 (82.96.56.14), 64 hops max, 40 byte packets 1 dsl.sandbu (192.168.1.1) 1 ms 1 ms 1 ms 2 81-31-240-1.net.nc-systems.no (81.31.240.1) 8 ms 7 ms 7 ms 3 3953-co-11.net.nc-systems.no (81.31.224.118) 8 ms 8 ms 14 ms 4 842-co-01.net.nc-systems.no (81.31.224.69) 18 ms 12 ms 14 ms 5 193.156.90.67 (193.156.90.67) 13 ms 13 ms 30 ms 6 tc-cr1-c7600.sto.se.p80.net (217.75.100.69) 20 ms 21 ms 20 ms 7 * * * 8 * V6 trace to the far end of the v6 tunnel (2001:16d8:ff00:11b::1/64) went nowhere. With the POP down there is obviously no route. * With heartbeat tunnels, first check clock synchronization or better: use AICCU. aiccu is used * Check with Wireshark or tcpdumps of the interface over which the tunnel runs. Use -n (numeric) as an option and don't filter returning ICMP which could also come from routers between your endpoint and the PoP and also use -s 1500 so that one gets the full packet. tcpdump did show outbound UDP/5072 to the POPs v4 address with nothing returned and no relevant icmp from nodes in between. If someone is filtering, they're not exactly announcing it (silently dropping packets). * The status of the PoP is listed on the PoP Status page, if it is marked down there we are aware of the issue and we will try to resolve it as soon as possible. Additionally other issues are listed in the Ticket Tracker Ticket Tracker. Now it's down, but there was no problem listed when the ticket was first opened.

Ahhh ... noticed that just now while experimenting. I was looking for such information in the manpage, but unfortunately it didn't mention such restrictions. Nor did the page at http://www.sixxs.net/faq/aiccu/ provide much information for debugging/troubleshooting ops. that was either the result of human error in copy paste, incorrect handling of scroll in the buffer or that aiccu had added multiple defaults. I am however sure that the routing table initially only had the first entry above when I first started diagnosing the problem. I.e. everything looked ok, except there were no packets coming back from the pop.