Received packet didn't start with a 6, thus is not IPv6
Carmen Sandiego on Friday, 21 March 2008 00:53:42
Hi,
During the last two or three weeks 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
All works fine.
I can't remember having made a change to provoke this behaviour. I suspect it's due to some software change on the server, but I don't know which.
Here is a fifteen minute excerpt from /var/log/messages:
http://huis.heesakkers.info/~oliver/IPv6messages3
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 recently 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: vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::250:8dff:fe51:5d19%vr0 prefixlen 64 scopeid 0x1
inet 192.168.1.1 netmask 0xffff0000 broadcast 192.168.255.255
inet6 2001:610:6ce:1::1 prefixlen 64
ether 00:50:8d:51:5d:19
media: Ethernet autoselect (100baseTX <full-duplex> )
status: active
plip0: flags=108851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33208
pfsync0: flags=41<UP,RUNNING> mtu 2020
syncpeer: 224.0.0.240 maxupd: 128
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
inet6 fe80::250:8dff:fe51:5d19%tun0 prefixlen 64 scopeid 0x6
inet6 fe80::410:600:3a1:2%tun0 prefixlen 64 scopeid 0x6
inet6 2001:610:600:3a1::2 --> 2001:610:600:3a1::1 prefixlen 128
netstat -rn:Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.254 UGS 0 9427945 vr0
127.0.0.1 127.0.0.1 UH 0 8904 lo0
192.168.0/16 link#1 UC 0 0 vr0
192.168.1.1 00:50:8d:51:5d:19 UHLW 1 12 lo0
192.168.1.2 00:16:17:12:a8:44 UHLW 1 39359 vr0 612
192.168.1.68 00:18:de:54:44:b3 UHLW 1 46 vr0 876
192.168.1.71 00:40:8c:7a:f3:6c UHLW 1 29466 vr0 486
192.168.1.93 00:91:00:00:7c:2f UHLW 1 702954 vr0 727
192.168.1.254 00:14:7f:10:e0:22 UHLW 2 1423 vr0 1200
192.168.255.255 ff:ff:ff:ff:ff:ff UHLWb 1 2055 vr0
Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0 =>
default 2001:610:600:3a1::1 UGS tun0
::1 ::1 UHL lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
2001:610:600:3a1::1 link#6 UHL tun0
2001:610:600:3a1::2 link#6 UHL lo0
2001:610:6ce:1::/64 link#1 UC vr0
2001:610:6ce:1::1 00:50:8d:51:5d:19 UHL lo0
2001:610:6ce:1:216:17ff:fe12:a844 00:16:17:12:a8:44 UHLW vr0
fe80::/10 ::1 UGRS lo0
fe80::%vr0/64 link#1 UC vr0
fe80::216:17ff:fe12:a844%vr0 00:16:17:12:a8:44 UHLW vr0
fe80::250:8dff:fe51:5d19%vr0 00:50:8d:51:5d:19 UHL lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#3 UHL lo0
fe80::%tun0/64 link#6 UC tun0
fe80::250:8dff:fe51:5d19%tun0 link#6 UHL lo0
fe80::410:600:3a1:2%tun0 link#6 UHL lo0
ff01:1::/32 link#1 UC vr0
ff01:3::/32 ::1 UC lo0
ff01:6::/32 link#6 UC tun0
ff02::/16 ::1 UGRS lo0
ff02::%vr0/32 link#1 UC vr0
ff02::%lo0/32 ::1 UC lo0
ff02::%tun0/32 link#6 UC tun0
So, is there something I can do to get rid of this message (other than redirecting the aiccu-output)?
Many thanks in advance.
Greets,
Oliver Heesakkers
Received packet didn't start with a 6, thus is not IPv6
Carmen Sandiego on Saturday, 22 March 2008 23:58:54
Is nobody else seeing these messages?
On further investigation I took a laptop and did a fresh install of FreeBSD 6.2 on it. Customized the kernel in a similar fashion as the server and tried aiccu on that. --> same message
Then did a fresh install of FreeBSD 6.3: GENERIC kernel --> same message, custom kernel --> same message.
Then did a fresh install of FreeBSD 7.0: GENERIC kernel --> same message.
Tired of that game I tried changing my tunnel-type, but it seems my speedtouch 716 can't work protocol 41 reliably, I was never able to ping my PoP IPv6 Endpoint, no traffic ever came back, if it even reached the PoP.
{Administrator}[nat]=>mapadd
intf = Internet
[type] = NAT
[outside_addr] = 86.80.52.251
[inside_addr] = 192.168.1.1
[access_list] =
[foreign_addr] = 192.87.102.107
[protocol] = 41
[outside_port] =
[inside_port] =
:nat mapadd intf=Internet type=nat outside_addr=86.80.52.251 inside_addr=192.168.1.1 foreign_addr=192.87.102.107 protocol=6to4
So I'm back with ayiya and the "packet didn't start with a 6"-messages keep on coming.
Next step is probably dragging the laptop to a friends house, to see if it's the internet connection.
Received packet didn't start with a 6, thus is not IPv6
Shadow Hawkins on Tuesday, 01 April 2008 21:24:09
Well, if it's the internet connection, it must be my connections as well. Both at home with a fresh FreeBSD 7.0-RELEASE install over Orange ADSL and at work on a FreeBSD 6.2-STABLE machine connected via Signet I get the same messages. Even worse: with both installs my connection stops working after a few megabytes of traffic.
[edwinm@joshua ~]$ ping6 www.sixxs.net
PING6(56=40+8+8 bytes) 2001:610:600:47d::2 --> 2001:838:1:1:210:dcff:fe20:7c7c
ping6: sendmsg: No buffer space available
ping6: wrote noc.sixxs.net 16 chars, ret=-1
ping6: sendmsg: No buffer space available
ping6: wrote noc.sixxs.net 16 chars, ret=-1
Mind you: this connection works after a fresh start of sixxs-aiccu, but stops working when a few MB's of data have been transferred. The 7.0 machine has no firewall enabled.
Received packet didn't start with a 6, thus is not IPv6
Shadow Hawkins on Thursday, 01 May 2008 21:35:13
I'm having the same problems here. I changed nothing, a few months ago these messages started appearing in the syslog:
May 1 21:31:39 server aiccu: [AYIYA-tun->tundev] [192.87.102.107]:5072 : Received packet didn't start with a 6, thus is not IPv6
They appear about every two minutes. Any ideas?
Received packet didn't start with a 6, thus is not IPv6
Shadow Hawkins on Thursday, 01 May 2008 22:20:06
It's clearly a problem with the Ayiya hearbeat protocol. The message is generated by the heartbeat receiver. Apparently there is a mismatch of what is sent and expected. You can read this in file common/ayiya.c.
Report it to SixXS.
Posting is only allowed when you are logged in. |