Mike Belopuhov: > > > It's also not clear what's wrong with those broken NS/ND > > > packets that you receive. > > > > 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?
My ping6 packet (IPv6-ICMPv6) goes into the network stack. It gets IPv6-encapsulated for the tunnel. Then it gets ESP-encapsulated, which is where m_makespace() is called. Then, somewhere after esp_output(), the stack notices that it doesn't know where to send the packet and generates the first neighbor solicitation. This NS packet is not encapsulated, so m_makespace() is not involved there. The different mbuf layout generated by m_makespace() somehow causes the neighbor solicitation code to choose a different source address. Combined from the tcpdumps on em0 and enc0 on the host that tries to send the ping6: # the initial ping6 packet goes through IPsec processing 17:30:10.141545 (authentic,confidential): SPI 0xdeadbeef: 2001:6f8:124a::2 > 2001:6f8:124a::4: icmp6: echo request (encap) # the neighbor solicitation 17:30:10.192307 2001:6f8:124a::2 > ff02::1:ff00:4: icmp6: neighbor sol: who has 2001:6f8:124a::4 # in reply, the neighbor advertisement comes through the tunnel 17:30:10.192737 esp 2001:6f8:124a::4 > 2001:6f8:124a::2 spi 0xbeefdead seq 2 len 120 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) > > 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 > > ======================= > > 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? What do you mean? That's the same mbuf chain above. The first m_makespace() call makes room for the ESP header, the second for the ESP trailer. -- Christian "naddy" Weisgerber na...@mips.inka.de
