Voortgang Kuunskop 12-6-2010
Zo. Radiator hangt, tweede laag saus op de muren, plafond werkkamer gewit, twee plinten verwijderd en gaten gevuld!
Voortgang Kuunskop 10-6-2010
Vandaag t laatste behang verwijderd, werkende afsluitdop op de radiator-onderblok gezet en de slaapkamer gesaust!
Weird ipv6 bug in Debian Etch (kernel 2.6.18-6-amd64)
Found this while configuring our serverpark to enable ipv6 connections.
It seems that the current etch kernel, 2.6.18-6-amd64, has a bug which prevents ipv6 from functioning correctly. The issue can be worked around with by setting the network card in promiscuous mode, which can be done by running tcpdump or tshark, and consequently pinging the ipv6 address. Setting promiscuous mode is not enough, the “fix” is only triggered when pinging the host and capturing ipv6 traffic.
To illustrate the problem, see below the output from a ssh session:
e3-srv54:~# ping6 www.geenstijl.nl
PING www.geenstijl.nl(ipv6proxy.prolocation.net) 56 data bytes— www.geenstijl.nl ping statistics —
10 packets transmitted, 0 received, 100% packet loss, time 9022mse3-srv54:~# ip -6 ro
2a00:1478:20::/64 dev eth0 metric 256 expires 21334013sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 metric 256 expires 20553607sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0 metric 256 expires 20553607sec mtu 1500 advmss 1440 hoplimit 4294967295
default via 2a00:1478:20::1 dev eth0 metric 1024 expires 21334016sec mtu 1500 advmss 1440 hoplimit 4294967295e3-srv54:~# ip -6 addr
1: lo: mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qlen 1000
inet6 2a00:1478:20:0:4:54:0:1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21c:c4ff:fe0d:7048/64 scope link
valid_lft forever preferred_lft forevere3-srv54:~# ping6 2a00:1478:20::1
PING 2a00:1478:20::1(2a00:1478:20::1) 56 data bytes— 2a00:1478:20::1 ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2002ms
As you can see, a valid IPv6 address is configured on the host, and the gateway is set. The gateway is not pingable however.
Next, we run tshark to capture ip6 traffic without enabling promiscuous mode:
e3-srv54:~# tshark -p ip6
Capturing on eth0
Now we ping6 the ip address:
rick@Rick-PC:~$ ping6 e3-srv54.server.eu
PING e3-srv54.server.eu(2a00:1478:20:0:4:54:0:1) 56 data bytes
^C
--- e3-srv54.server.eu ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8013ms
e3-srv54:~# tshark -p ip6
Capturing on eth0
0 packets captured
e3-srv54:~#
As you can see, no replies and also no traffic is captured on the host.
Next, we run tshark normally, with promiscuous mode:
e3-srv54:~# tshark ip6
Capturing on eth0
0.000000 fe80::221:5900:142b:2a80 -> ff02::1:ff00:1 ICMPv6 Neighbor solicitation
0.999605 fe80::221:5900:142b:2a80 -> ff02::1:ff00:1 ICMPv6 Neighbor solicitation
1.999514 fe80::221:5900:142b:2a80 -> ff02::1:ff00:1 ICMPv6 Neighbor solicitation
Enabling the promiscuous mode immediately shows ip6 traffic being captured from neighbouring hosts.
Now, when we send any kind of ipv6 data to the host, this somehow triggers something in the ipv6 stack to start functioning:
114.352176 2001:1690:xxxxxx -> 2a00:1478:20:0:4:54:0:1 ICMPv6 Echo request
114.352187 2a00:1478:20:0:4:54:0:1 -> 2001:1690:xxxxxx ICMPv6 Echo reply
139 packets captured
e3-srv54:~#
After quitting tshark, ipv6 starts functioning as it should.