On Wed, Oct 12, 2016 at 18:00 +0200, Christian Weisgerber wrote: > Mike Belopuhov: > > > It's also not clear what's wrong with those broken NS/ND > > packets that you receive. > > Oct 12 17:30:10 bardioc /bsd: nd6_na_input: ND packet from non-neighbor > Oct 12 17:30:12 bardioc last message repeated 2 times > Oct 12 17:30:15 bardioc /bsd: nd6_ns_input: NS packet from non-neighbor > Oct 12 17:30:15 bardioc /bsd: nd6_ns_input: src=2001:6f8:124a::4 > Oct 12 17:30:15 bardioc /bsd: nd6_ns_input: dst=2001:6f8:124a::2 > Oct 12 17:30:15 bardioc /bsd: nd6_ns_input: tgt=2001:6f8:124a::2 > Oct 12 17:30:16 bardioc /bsd: nd6_ns_input: NS packet from non-neighbor > Oct 12 17:30:16 bardioc /bsd: nd6_ns_input: src=2001:6f8:124a::4 > Oct 12 17:30:16 bardioc /bsd: nd6_ns_input: dst=2001:6f8:124a::2 > Oct 12 17:30:16 bardioc /bsd: nd6_ns_input: tgt=2001:6f8:124a::2 > Oct 12 17:30:17 bardioc /bsd: nd6_ns_input: NS packet from non-neighbor > Oct 12 17:30:17 bardioc /bsd: nd6_ns_input: src=2001:6f8:124a::4 > Oct 12 17:30:17 bardioc /bsd: nd6_ns_input: dst=2001:6f8:124a::2 > Oct 12 17:30:17 bardioc /bsd: nd6_ns_input: tgt=2001:6f8:124a::2 > > What seems to be wrong is that they are going through the tunnel. >
But what does it have to do with m_makespace then? It's called by the esp_output, therefore the decision to apply the transformation has been already made at this point. Which SPD lookup succeeds that shouldn't? > > Do you get any ESP errors? > > No. > > > Could you please try the following diff. Unfortunately, > > it might produce too much output. If you could narrow it > > down to affected packets this would help a lot. > > I can narrow it down to a single packet. Here's the result from > ping6 -c1 2001:6f8:124a::4 : > > 2: PKTHDR (0xffffff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) > 16 > 2: MBUF (0xffffff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184 > 2: MBUF (0xffffff00dfa9da00): len 32, total 224, leading(-) 72, trailing(+) > 120 > ======================= > 3: PKTHDR (0xffffff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) > 16 > 3: MBUF (0xffffff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184 > 3: MBUF (0xffffff00dfa9da00): len 56, total 224, leading(-) 72, trailing(+) 96 > ======================= > > That corresponds to the two m_makespace() calls in esp_output(). > > I already dug around earlier. The input packet layout looks like > this: > > mbuf mbuf > +------+------+ +--------+ > | IPv6 | IPv6 | ---- | ICMPv6 | > +------+------+ +--------+ > > After the first m_makespace(): > > +------+-----+ +------+ +--------+ > | IPv6 | ESP | ---- | IPv6 | ---- | ICMPv6 | > +------+-----+ +------+ +--------+ > > After the second m_makespace(): > > +------+-----+ +------+ +--------+-----+ > | IPv6 | ESP | ---- | IPv6 | ---- | ICMPv6 | ESP | > +------+-----+ +------+ +--------+-----+ > > With m_inject(), it would instead be something like this: > > +------+ +-----+ +------+ +-------- > | IPv6 |----| ESP | ---- | IPv6 | ---- | ICMPv6 ... > +------+ +-----+ +------+ +-------- > > Yes, I don't see anything wrong with this. For some reason you get the same addresses for your mbuf chain components. Are they statically allocated somehow? > The corresponding traffic this ping6 triggers on the outgoing em0 > interface: > > 17:30:10.192307 2001:6f8:124a::2 > ff02::1:ff00:4: icmp6: neighbor sol: who > has 2001:6f8:124a::4 > 17:30:10.192737 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 2 > len 120 > 17:30:11.189521 2001:6f8:124a::2 > ff02::1:ff00:4: icmp6: neighbor sol: who > has 2001:6f8:124a::4 > 17:30:11.189738 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 3 > len 120 > 17:30:12.189831 2001:6f8:124a::2 > ff02::1:ff00:4: icmp6: neighbor sol: who > has 2001:6f8:124a::4 > 17:30:12.190033 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 4 > len 120 > 17:30:15.187608 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 5 > len 120 > 17:30:16.188826 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 6 > len 120 > 17:30:17.194123 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 7 > len 120 > > And on enc0: > > 17:30:10.141545 (authentic,confidential): SPI 0xdeadbeef: 2001:6f8:124a::2 > > 2001:6f8:124a::4: icmp6: echo request (encap) > 17:30:10.192872 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor adv: tgt is 2001:6f8:124a::4 (encap) > 17:30:11.189809 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor adv: tgt is 2001:6f8:124a::4 (encap) > 17:30:12.190101 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor adv: tgt is 2001:6f8:124a::4 (encap) > 17:30:15.187706 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor sol: who has 2001:6f8:124a::2 (encap) > 17:30:16.188924 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor sol: who has 2001:6f8:124a::2 (encap) > 17:30:17.194226 (authentic,confidential): SPI 0xbeefdead: 2001:6f8:124a::4 > > 2001:6f8:124a::2: icmp6: neighbor sol: who has 2001:6f8:124a::2 (encap) > > -- > Christian "naddy" Weisgerber [email protected]
