Re: pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Marc Espie 
On Wed, Oct 12, 2016 at 10:51:59AM +0200, Martin Natano wrote:
> I've seen this since the new signing method has been implemented. I
> blamed it on something being out of date/sync on my machine, but after
> updating to the latest snapshot yesterday (the one from ftp.fr) it
> becomes clear that either something is seriously hosed on my system or
> there is an issue in pkg_add or signify.
> 
> I see this when calling pkg_add directly in xterm or script, but not
> when called inside tmux.
> 
> 
> xterm/script:
> 
> natano@watschnbaum:~$ pkg_add -nuix vim
> quirks-2.261 signed on 2016-10-11T14:06:48Z
> Error from 
> http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python3-ruby.tgz
> signify: write to stdout: Broken pipe

I don't see any of this here.

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

2016-10-12 Thread Mike Larkin 
On Wed, Oct 12, 2016 at 10:56:49AM +0300, Özgür Kazancci wrote:
> Hi again,
> 
> Just wanted to make sure that my last response has arrived you and wanted
> to ask if there's anything new (maybe your new requests from me?) regarding
> the issue?
> 

Yes, I got the email. Just been busy with other things. I'll get to it
when I have a chance.

-ml

> Thanks,
> Kind Regards.
> 
> 
> 
> On Sat, Oct 1, 2016 at 1:49 AM, Özgür Kazancci 
> wrote:
> 
> > Here are the outputs after using the latest snapshot.
> >
> > Hope they'll be useful.
> >
> > Regards.
> >
> > On 28 Sep 2016 12:12, "Özgür Kazancci"  wrote:
> >
> >> Mike,
> >>
> >> Before I try the latest snapshot including the commit you mentioned
> >> earlier, I wanted to give it a try on FreeBSD,
> >> The system works okay, doesn't hang, however, I get "ACPI Error:"
> >> messages in the console, from time to time.
> >> And I thought it would help -at least give an idea- to find a solution
> >> maybe?
> >> Screenshot is attached,
> >>
> >> Regards.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Sep 27, 2016 at 2:52 PM, Özgür Kazanççı 
> >> wrote:
> >>
> >>> Thanks a lot, I'll be waiting for the next snapshot.
> >>>
> >>> Here are few additional steps that I tried so far;
> >>>
> >>> -I tried a new installation from scratch from the latest snapshot
> >>> available, didn't help.
> >>> -I wanted to try booting OpenBSD by turning the ACPI off, however, the
> >>> laptop's BIOS has absolutely NO option on ACPI/Power/Suspend/Resume, etc.
> >>> -I reduced the "heavyness" of the hardware in the BIOS; disabled a lot
> >>> of stuff (Such as ODD, Webcam, CardReader, Bluetooth, NetBoot, USB 3.0).
> >>> -HP Support page for HP 250 G5 Notebook had "Important BIOS Update" and
> >>> an important harddisk firmware update, - so I fetched them both and
> >>> updated, then done an another fresh installation, still, nothing has
> >>> changed.
> >>>
> >>> I'll be waiting for the next snapshot - to be able to send you further
> >>> details on the issue.
> >>> Many thanks,
> >>> Best,
> >>> Özgür.
> >>>
> >>>
> >>> On Tue, Sep 27, 2016 at 1:05 PM, Mike Larkin 
> >>> wrote:
> >>>
>  On Mon, Sep 26, 2016 at 08:37:23PM +0300, Özgür Kazanççı wrote:
>  > Today I bought a brand new HP 250 G5 laptop.
>  >
>  > It has a humble, basic hardware configuration;
>  >
>  > Intel® Celeron® Processor N3060 (2M Cache, up to 2.48 GHz)
>  > 4 GB RAM, 500 GB HDD
>  >
>  > This is a new model HP laptop, made for basic Internet and Office
>  needs.
>  >
>  > I installed OpenBSD 6.0. Getting kernel panic during the boot. :(
>  >
>  > I must say that OpenBSD would be a perfect choice for me on this
>  laptop.
>  > But unfortunately, it seems it has troubles with the hardware of this
>  PC.
>  >
>  > The details are attached,
>  >
>  > Many thanks in advance for your valuable efforts on making OpenBSD
>  even
>  > better!
>  >
>  > And please let me know whatever you'd need, whatever I could do for
>  you to
>  > investigate the problem.
>  >
>  > Kindest Regards.
> 
>  I just committed a change that will print the type of operation region
>  that is failing. Please wait for the next snapshot and try a new kernel.
>  It will still fail, but it should at least give us more info.
> 
>  -ml
> 
> >>>
> >>>
> >>

Re: pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Marc Espie 
On Wed, Oct 12, 2016 at 10:24:25AM +0100, Stuart Henderson wrote:
> On 2016/10/12 11:09, Marc Espie wrote:
> > On Wed, Oct 12, 2016 at 10:51:59AM +0200, Martin Natano wrote:
> > > I've seen this since the new signing method has been implemented. I
> > > blamed it on something being out of date/sync on my machine, but after
> > > updating to the latest snapshot yesterday (the one from ftp.fr) it
> > > becomes clear that either something is seriously hosed on my system or
> > > there is an issue in pkg_add or signify.
> > > 
> > > I see this when calling pkg_add directly in xterm or script, but not
> > > when called inside tmux.
> > > 
> > > 
> > > xterm/script:
> > > 
> > > natano@watschnbaum:~$ pkg_add -nuix vim
> > > quirks-2.261 signed on 2016-10-11T14:06:48Z
> > > Error from 
> > > http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python3-ruby.tgz
> > > signify: write to stdout: Broken pipe
> > 
> > I don't see any of this here.
> > 
> 
> I've seen it sometimes with some packages, but not in the last few updates.
> 
> There's cvs:~sthen/ktrace.out.gz from one failing run. This one was from
> ftp.fr but I've seen it from other servers (including ftp.openbsd.org)
> too.
> 
> The EPIPE to signify occured after this:
> 
>  29287 perl CALL  write(1,0x8e2d000,0x39)
>  29287 perl GIO   fd 1 wrote 57 bytes
>"\rChecking packages|No change in calc-2.12.5.4 (1/2)\^[[K\^[[K"
>  29287 perl RET   write 57/0x39
>  29287 perl CALL  lseek(6,0x9647,SEEK_SET)
>  29287 perl RET   lseek -1 errno 29 Illegal seek
>  29287 perl CALL  close(6)
>  29287 perl RET   close 0
>  29287 perl CALL  wait4(53158,0x7f7ddd44,0<>,0)

Hum... there might be a seek somewhere within the unpacking code, because
it's definitely not in pkg_add proper.

Re: pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Stuart Henderson 
On 2016/10/12 11:09, Marc Espie wrote:
> On Wed, Oct 12, 2016 at 10:51:59AM +0200, Martin Natano wrote:
> > I've seen this since the new signing method has been implemented. I
> > blamed it on something being out of date/sync on my machine, but after
> > updating to the latest snapshot yesterday (the one from ftp.fr) it
> > becomes clear that either something is seriously hosed on my system or
> > there is an issue in pkg_add or signify.
> > 
> > I see this when calling pkg_add directly in xterm or script, but not
> > when called inside tmux.
> > 
> > 
> > xterm/script:
> > 
> > natano@watschnbaum:~$ pkg_add -nuix vim
> > quirks-2.261 signed on 2016-10-11T14:06:48Z
> > Error from 
> > http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python3-ruby.tgz
> > signify: write to stdout: Broken pipe
> 
> I don't see any of this here.
> 

I've seen it sometimes with some packages, but not in the last few updates.

There's cvs:~sthen/ktrace.out.gz from one failing run. This one was from
ftp.fr but I've seen it from other servers (including ftp.openbsd.org)
too.

The EPIPE to signify occured after this:

 29287 perl CALL  write(1,0x8e2d000,0x39)
 29287 perl GIO   fd 1 wrote 57 bytes
   "\rChecking packages|No change in calc-2.12.5.4 (1/2)\^[[K\^[[K"
 29287 perl RET   write 57/0x39
 29287 perl CALL  lseek(6,0x9647,SEEK_SET)
 29287 perl RET   lseek -1 errno 29 Illegal seek
 29287 perl CALL  close(6)
 29287 perl RET   close 0
 29287 perl CALL  wait4(53158,0x7f7ddd44,0<>,0)

pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Martin Natano 
I've seen this since the new signing method has been implemented. I
blamed it on something being out of date/sync on my machine, but after
updating to the latest snapshot yesterday (the one from ftp.fr) it
becomes clear that either something is seriously hosed on my system or
there is an issue in pkg_add or signify.

I see this when calling pkg_add directly in xterm or script, but not
when called inside tmux.


xterm/script:

natano@watschnbaum:~$ pkg_add -nuix vim
quirks-2.261 signed on 2016-10-11T14:06:48Z
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python3-ruby.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-lua.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-no_x11-lua.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-no_x11-perl-python3-ruby.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-no_x11-ruby.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python-ruby.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-no_x11.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-no_x11-perl-python-ruby.tgz
signify: write to stdout: Broken pipe
Error from 
http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2.tgz
signify: write to stdout: Broken pipe
natano@watschnbaum:~$ ^D

The same errors are shown when called without -inx by root.


tmux:

natano@watschnbaum:~$ pkg_add -nui vim 
quirks-2.261 signed on 2016-10-11T14:06:48Z
natano@watschnbaum:~$ ^D


I tried to look into this myself, but got stuck due to my non-existent
perl skills.

natano


pkg.conf:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/%a/


BUILDINFO:
Build date: 1476119003 - Mon Oct 10 17:03:23 UTC 2016

Re: pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Marc Espie 
On Wed, Oct 12, 2016 at 11:09:30AM +0200, Marc Espie wrote:
> On Wed, Oct 12, 2016 at 10:51:59AM +0200, Martin Natano wrote:
> > I've seen this since the new signing method has been implemented. I
> > blamed it on something being out of date/sync on my machine, but after
> > updating to the latest snapshot yesterday (the one from ftp.fr) it
> > becomes clear that either something is seriously hosed on my system or
> > there is an issue in pkg_add or signify.
> > 
> > I see this when calling pkg_add directly in xterm or script, but not
> > when called inside tmux.
> > 
> > 
> > xterm/script:
> > 
> > natano@watschnbaum:~$ pkg_add -nuix vim
> > quirks-2.261 signed on 2016-10-11T14:06:48Z
> > Error from 
> > http://ftp.fr.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/vim-8.0.0004-gtk2-perl-python3-ruby.tgz
> > signify: write to stdout: Broken pipe
> 
> I don't see any of this here.

Hum, what does it say if you remove the signify step, e.g.,
pkg_add -Dunsigned ?

Re: pkg_add "signify: write to stdout: Broken pipe"

2016-10-12 Thread Martin Natano 
On Wed, Oct 12, 2016 at 11:21:51AM +0200, Marc Espie wrote:
> 
> Hum, what does it say if you remove the signify step, e.g.,
> pkg_add -Dunsigned ?

natano@watschnbaum:~$ pkg_add -Dunsigned -nuix vim
natano@watschnbaum:~$ ^D

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

2016-10-12 Thread Özgür Kazancci 
Hi again,

Just wanted to make sure that my last response has arrived you and wanted
to ask if there's anything new (maybe your new requests from me?) regarding
the issue?

Thanks,
Kind Regards.



On Sat, Oct 1, 2016 at 1:49 AM, Özgür Kazancci 
wrote:

> Here are the outputs after using the latest snapshot.
>
> Hope they'll be useful.
>
> Regards.
>
> On 28 Sep 2016 12:12, "Özgür Kazancci"  wrote:
>
>> Mike,
>>
>> Before I try the latest snapshot including the commit you mentioned
>> earlier, I wanted to give it a try on FreeBSD,
>> The system works okay, doesn't hang, however, I get "ACPI Error:"
>> messages in the console, from time to time.
>> And I thought it would help -at least give an idea- to find a solution
>> maybe?
>> Screenshot is attached,
>>
>> Regards.
>>
>>
>>
>>
>>
>> On Tue, Sep 27, 2016 at 2:52 PM, Özgür Kazanççı 
>> wrote:
>>
>>> Thanks a lot, I'll be waiting for the next snapshot.
>>>
>>> Here are few additional steps that I tried so far;
>>>
>>> -I tried a new installation from scratch from the latest snapshot
>>> available, didn't help.
>>> -I wanted to try booting OpenBSD by turning the ACPI off, however, the
>>> laptop's BIOS has absolutely NO option on ACPI/Power/Suspend/Resume, etc.
>>> -I reduced the "heavyness" of the hardware in the BIOS; disabled a lot
>>> of stuff (Such as ODD, Webcam, CardReader, Bluetooth, NetBoot, USB 3.0).
>>> -HP Support page for HP 250 G5 Notebook had "Important BIOS Update" and
>>> an important harddisk firmware update, - so I fetched them both and
>>> updated, then done an another fresh installation, still, nothing has
>>> changed.
>>>
>>> I'll be waiting for the next snapshot - to be able to send you further
>>> details on the issue.
>>> Many thanks,
>>> Best,
>>> Özgür.
>>>
>>>
>>> On Tue, Sep 27, 2016 at 1:05 PM, Mike Larkin 
>>> wrote:
>>>
 On Mon, Sep 26, 2016 at 08:37:23PM +0300, Özgür Kazanççı wrote:
 > Today I bought a brand new HP 250 G5 laptop.
 >
 > It has a humble, basic hardware configuration;
 >
 > Intel® Celeron® Processor N3060 (2M Cache, up to 2.48 GHz)
 > 4 GB RAM, 500 GB HDD
 >
 > This is a new model HP laptop, made for basic Internet and Office
 needs.
 >
 > I installed OpenBSD 6.0. Getting kernel panic during the boot. :(
 >
 > I must say that OpenBSD would be a perfect choice for me on this
 laptop.
 > But unfortunately, it seems it has troubles with the hardware of this
 PC.
 >
 > The details are attached,
 >
 > Many thanks in advance for your valuable efforts on making OpenBSD
 even
 > better!
 >
 > And please let me know whatever you'd need, whatever I could do for
 you to
 > investigate the problem.
 >
 > Kindest Regards.

 I just committed a change that will print the type of operation region
 that is failing. Please wait for the next snapshot and try a new kernel.
 It will still fail, but it should at least give us more info.

 -ml

>>>
>>>
>>

Re: IPv6/NDP/IPsec breakage in -current

2016-10-12 Thread Christian Weisgerber 
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.

> 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 (0xff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) 16
2: MBUF (0xff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184
2: MBUF (0xff00dfa9da00): len 32, total 224, leading(-) 72, trailing(+) 120
===
3: PKTHDR (0xff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) 16
3: MBUF (0xff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184
3: MBUF (0xff00dfa9da00): 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  ...
+--++-+  +--+  +


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  na...@mips.inka.de

Re: IPv6/NDP/IPsec breakage in -current

2016-10-12 Thread Mike Belopuhov 
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 (0xff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) 
> 16
> 2: MBUF (0xff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184
> 2: MBUF (0xff00dfa9da00): len 32, total 224, leading(-) 72, trailing(+) 
> 120
> ===
> 3: PKTHDR (0xff00dfa9d200): len 64, total 152, leading(-) 72, trailing(+) 
> 16
> 3: MBUF (0xff00dfa9db00): len 40, total 224, leading(-) 0, trailing(+) 184
> 3: MBUF (0xff00dfa9da00): 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