The state of this ticket has been changed to user

You clearly did not read it as a lot of information is missing. You can only receive that message if something is received by AICCU on the tunnel interface which is not IPv6 (aka starts with a 6) though it gets tagged as IPv6. The PoPs don't send those packets.

* Always include clear descriptive information about your problem or inquiry. Did that * When on a UNIX-alike platform that supports AICCU, please run AICCU and run it using "aiccu test". Did that * When using AICCU, check that you are using the latest version, and of course please specify where the binary comes from. Did that * Always provide your NIC handle and if applicable the Tunnel or Route IDs you wish to discuss. Gave the NIC handle, tunnel ID T11278 * Use the email address you have provided in your handle as that is what we use as a contact handle. Can't do that, this is online * Provide details of the setup, type of connections, where NATs are located. Did that (everything regular, told you about the NAT) * Provide information of your OS type, version and release (ie. uname -a), noting also the distribution name. "Debian Etch" says enough, IMO * Include full interface, routing and firewall tables. I didn't think this was required, routing and firewall is default, here comes the full interface table: eth0 Link encap:Ethernet HWaddr 00:C0:26:A7:1D:BE inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2001:610:6d0:1337::/128 Scope:Global inet6 addr: 2001:610:6d0:1337::1/128 Scope:Global inet6 addr: fe80::2c0:26ff:fea7:1dbe/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:21586511 errors:9 dropped:0 overruns:0 frame:0 TX packets:23221950 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:19653096 (18.7 MiB) TX bytes:4035785250 (3.7 GiB) Interrupt:11 Base address:0x9400 sixxs Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: 2001:610:600:3a7::2/64 Scope:Global inet6 addr: fe80::410:600:3a7:2/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1 RX packets:1426 errors:0 dropped:0 overruns:0 frame:0 TX packets:1398 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:457423 (446.7 KiB) TX bytes:150280 (146.7 KiB) * Include a IPv4 and IPv6 traceroute to the PoP in question. Did that (the IPv6 traceroute is of course just one hop) * With heartbeat tunnels, first check clock synchronization or better: use AICCU. I'm using aiccu * 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. Told you why I haven't done this yet. * 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. PoP is obviously up * We are not your personal helpdesk, thus first read the FAQ and/or use the forum, many cases can already be solved that way, but we do want to have you actually use the tunnel thus do contact us if the problem persists. Did that. I don't really think a lot was missing. About the dump, I've got it (let's hope you wanted the dump on eth0), but it's got a lot of SSH data because as I said, I don't know how to filter that out. As it turns out, there were only five UDP packets in the dump. Two of them were going to sixxs.surfnet.nl, three were coming from there. Now there's not a lot I know about raw network packets, but I don't see a '6' in the raw dump of any of the three packets, while I got only one warning. (Oddly enough, both packets coming from me had incorrect UDP checksums, Wireshark says.) If you think it helps, maybe I can filter the UDP packets out, and put them online somewhere. I'm sorry, but I can't help it I receive these packets. Nothing on my side is changing them, as far as I know, and I hear other people are getting the warnings too. Either something is changing the data, or the PoP's *are* sending the packets. Don't look at me as if I'm making up this warning.

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: I would like to say that I have the exact same problem. I'm running FreeBSD 7.0-CURRENT, with AICCU built from Ports. The packets are coming from sixxs.surfnet.nl, with the only difference from the report above that FreeBSD truncates the message to "last message repeated x times" when the error is sent multiple times in a short period.

Since early march, I'm getting the following message in /var/log/messages and on the console every couple of minutes: Received packet didn't start with a 6, thus is not IPv6 I mentioned this problem earlier here: https://noc.sixxs.net/forum/?msg=setup-692703 Now that others confirm having this problem, I'm posting it as a ticket. This ticket is basically a copy, some new log-info in the end. Here is a fifteen minute excerpt from /var/log/messages: http://huis.heesakkers.info/~oliver/IPv6messages3 Since then I'm redirecting it to a separate local7.log In that fifteen minute period tcpdump -nAs 2048 port 5072 recorded the following: http://huis.heesakkers.info/~oliver/IPv6dump3 When matching the two, this remains: http://huis.heesakkers.info/~oliver/IPv6matches3 I'm running FreeBSD 6.2-RELEASE-p11 and latest sixxs-aiccu from ports (recompiled in march as part of the troubleshooting) Tunnel: T11203 (ayiya on nlams05) Username: OHA1-SIXXS pf firewall in place, but disabling it did not affect the problem. ifconfig: netstat -rn: As all logging now goes to local7, I can provide a full log of bringing up my tunnel (for the first time in a month):