On Sat, 19 Dec 2009 15:09:08 +0100 Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> wrote: > > So, I assume the packet is lost somewhere in netfilter, but I've no > > idea how to tell why it's getting discarded like that. > > Have you tried to track the packet in the mangle/POSTROUTING chain > too, either with the LOG target in that chain or with the TRACE > target in the raw/PREROUTING chain ? Didn't know about it, very handy way to check what's happening. Thanks. Pity I've missed it before. As for the results - it seems that everything is passing through netfilter just fine, more about it below. > > Strangely enough (for me), when I type "ping6 > > 2001:0470:1f0b:11de::21" on router machine it gives "Destination > > unreachable: Address unreachable" > > This indicates that the neighbour discovery for that address failed, > either because the ICMPv6 neighbour solicitation request could not be > sent or the ICMPv6 neighbour advertisement reply was not received. If > neighbour discovery fails, packets cannot be sent or forwarded to that > destination. Yes, that seem to be the cause of a problem, but then I don't seem to understand why router doesn't send these requests. I've set TRACE to packets with 2001:470:1f0b:11de::22 as a destination in raw.PREROUTING and -j LOG to INPUT and OUTPUT chains of filter table. On VM start tcpdump (with "ip6" filter) shows these: IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 IP6 :: > ff02::1:ff00:22: ICMP6, neighbor solicitation, who has 2001:470:1f0b:11de::22, length 24 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 Then I start the simple ping6 from lan network to vde (VM): IP6 2001:470:1f0b:11de::13 > 2001:470:1f0b:11de::22: ICMP6, echo request, seq 1, length 64 TRACE: raw:PREROUTING:policy:2 IN=lan OUT= MAC=00:22:15:3a:ef:7d:00:17:c4:10:7f:4f:86:dd SRC=2001:0470:1f0b:11de:0000:0000:0000:0013 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=29452 SEQ=1 TRACE: mangle:PREROUTING:policy:1 IN=lan OUT= MAC=00:22:15:3a:ef:7d:00:17:c4:10:7f:4f:86:dd SRC=2001:0470:1f0b:11de:0000:0000:0000:0013 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=29452 SEQ=1 TRACE: mangle:FORWARD:policy:1 IN=lan OUT=vde SRC=2001:0470:1f0b:11de:0000:0000:0000:0013 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=29452 SEQ=1 TRACE: filter:FORWARD:policy:1 IN=lan OUT=vde SRC=2001:0470:1f0b:11de:0000:0000:0000:0013 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=29452 SEQ=1 TRACE: mangle:POSTROUTING:policy:1 IN= OUT=vde SRC=2001:0470:1f0b:11de:0000:0000:0000:0013 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=29452 SEQ=1 IP6 2001:470:1f0b:11de::22 > ff02::1:ff00:21: ICMP6, neighbor solicitation, who has 2001:470:1f0b:11de::21, length 32 IN=vde OUT= MAC=33:33:ff:00:00:21:00:16:3e:16:38:41:86:dd SRC=2001:0470:1f0b:11de:0000:0000:0000:0022 DST=ff02:0000:0000:0000:0000:0001:ff00:0021 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 IP6 2001:470:1f0b:11de::21 > 2001:470:1f0b:11de::22: ICMP6, neighbor advertisement, tgt is 2001:470:1f0b:11de::21, length 32 IN= OUT=vde SRC=2001:0470:1f0b:11de:0000:0000:0000:0021 DST=2001:0470:1f0b:11de:0000:0000:0000:0022 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0 IP6 2001:470:1f0b:11de::22 > 2001:470:1f0b:11de::13: ICMP6, echo reply, seq 1, length 64 ...and so on until tcpdump just stops, while traces show the same thing. On lan interface, unlike vde, neighbor requests seem to be passed quite frequently: ... IP6 2001:470:1f0b:11de::13 > 2001:470:1f0b:11de::22: ICMP6, echo request, seq 5, length 64 IP6 2001:470:1f0b:11de::22 > 2001:470:1f0b:11de::13: ICMP6, echo reply, seq 5, length 64 IP6 fe80::222:15ff:fe3a:ef7d > 2001:470:1f0b:11de::13: ICMP6, neighbor solicitation, who has 2001:470:1f0b:11de::13, length 32 IP6 2001:470:1f0b:11de::13 > fe80::222:15ff:fe3a:ef7d: ICMP6, neighbor advertisement, tgt is 2001:470:1f0b:11de::13, length 24 IP6 2001:470:1f0b:11de::13 > 2001:470:1f0b:11de::22: ICMP6, echo request, seq 6, length 64 IP6 2001:470:1f0b:11de::22 > 2001:470:1f0b:11de::13: ICMP6, echo reply, seq 6, length 64 ... And when I type "ping6 2001:470:1f0b:11de::22" on router itself I can see neighbor solicitation in tcpdump and pings from lan start working again, although not for long (if I ping on router): [complete silence] IP6 2001:470:1f0b:11de::21 > ff02::1:ff00:22: ICMP6, neighbor solicitation, who has 2001:470:1f0b:11de::22, length 32 IP6 2001:470:1f0b:11de::22 > 2001:470:1f0b:11de::21: ICMP6, neighbor advertisement, tgt is 2001:470:1f0b:11de::22, length 32 IP6 2001:470:1f0b:11de::13 > 2001:470:1f0b:11de::22: ICMP6, echo request, seq 135, length 64 IP6 2001:470:1f0b:11de::22 > 2001:470:1f0b:11de::13: ICMP6, echo reply, seq 135, length 64 ... So I guess that pinpoints the problem as "router doesn't send neighbor solicitation requests along with forwarded packets", thanks to your suggestion. I have to admit that "neighbor solicitation", although basic IPv6 mechanism, is a obscure to me, since I haven't done necessary research on the topic before setting the network up, and that's quite a stupid mistake I'm going to fix right now ;) Guess that gives me something to search for and debug further, so I'll probably be able to either fix it or come up with another, more specific, question. Thanks for your help. > Regardless of your problem, 2001:470:1f0b:11de::10 and > 2001:470:1f0b:11de::20 are the prefix addresses of > 2001:470:1f0b:11de::10/25 and 2001:470:1f0b:11de::20/25 and have a > special status : they are anycast addresses meaning "any router > connected to that prefix". So I guess that they should not be assigned > to an interface. While that worked before, I agree that it's a bad practice, and I've fixed it now, although it doesn't seem to affect this particular problem indeed. For the above tests I've changed ...::10 to 11, ...::20 to 21 and ...::21 to 22. > ICMPv6 packets involved in neighbour discovery go through the INPUT > and OUTPUT chains. What do these chains contain ? Connection tracking > of these ICMPv6 types changed in kernel 2.6.29. These (as well as the rest of ICMPv6) were unrestricted in all chains, but for the sake of this test (dumps/traces posted above) I've set everything to ACCEPT explicitly. > You wrote in the subject "with ip6tables". Do you mean that it works > without ip6tables, without ip6_tables loaded or without > ip6table_filter loaded, or with all chains empty and with ACCEPT > default policy ? My mistake, sorry, ip6tables tool probably have nothing to do with it, it's just that the whole forwarding concept is closely associated with iptables in my mind ;) ACCEPT everywhere doesn't affect the test, and above results acquired with just that setup. -- Mike Kazantsev // fraggod.net
Attachment:
signature.asc
Description: PGP signature
