OpenBGPd error /bsd: bgpd(): syscall 105

[Atanas Vladimirov]

Snapshot from sep 30 bgpd didn't startup:
Oct  1 08:32:28 ns /bsd: bgpd(28055): syscall 105
Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 
0

Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE
Oct  1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or 
directory
Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 
0

Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control
Oct  1 08:32:28 ns bgpd[27739]: main: Lost connection to SE
Oct  1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated; 
signal 9


[ns]~/upgrade$ dmesg
OpenBSD 5.8-current (GENERIC.MP) #1397: Wed Sep 30 10:10:03 MDT 2015
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4261285888 (4063MB)
avail mem = 4128014336 (3936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9510 (23 entries)
bios0: vendor American Megatrends Inc. version "1.1" date 04/29/2014
bios0: Supermicro X9SBAA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SPMI EINJ ERST HEST BERT
acpi0: wakeup devices PRP4(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU S1260 @ 2.00GHz, 1995.22 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU S1260 @ 2.00GHz, 1995.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU S1260 @ 2.00GHz, 1995.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 512KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU S1260 @ 2.00GHz, 1995.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu3: 512KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xc000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PRP1)
acpiprt2 at acpi0: bus 2 (PRP2)
acpiprt3 at acpi0: bus 4 (P3P4)
acpicpu0 at acpi0: C1(1000@20 halt), PSS
acpicpu1 at acpi0: C1(1000@20 halt), PSS
acpicpu2 at acpi0: C1(1000@20 halt), PSS
acpicpu3 at acpi0: C1(1000@20 halt), PSS
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 175 degC
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1900, 1800, 1700, 1600, 
1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 700, 600 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Atom S1260 Host" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel Atom S1200 PCIE" rev 0x01
pci1 at ppb0 bus 1
ahci0 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x10: msi, 
AHCI 1.2

ahci0: port 0: 6.0Gb/s
ahci0: port 2: 1.5Gb/s
ahci0: port 7: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c50040390431

sd0: 152627MB, 512 bytes/sector, 312581808 sectors
sd1 at scsibus1 targ 2 lun 0:  SCSI3 
0/direct fixed naa.5000cca205d8de7f

sd1: 157066MB, 512 bytes/sector, 321672960 sectors
uk0 at scsibus1 targ 7 lun 0:  ATAPI 3/processor 
removable

ppb1 at pci0 dev 2 function 0 "Intel Atom S1200 PCIE" rev 0x01
pci2 at ppb1 bus 2
xhci0 at pci2 dev 0 function 0 "Renesas uPD720201 xHCI" rev 0x03: msi
xhci0: reset timeout
xhci0: init failed, error=5
ppb2 at pci0 dev 3 function 0 "Intel Atom S1200 PCIE" rev 0x01
pci3 at ppb2 bus 3
ppb3 at pci3 dev 0 function 0 "Newbridge PEB383 PCIE-PCI" rev 0x01
pci4 at ppb3 bus 4
em0 at pci4 dev 0 function 0 "Intel 82540EM" rev 0x02: apic 2 int 21, 
address 00:07:e9:10:32:a8

vga1 at pci4 dev 3 

Re: HSTS configuration in httpd.conf

[Carlin Bingham]

On Fri, 2 Oct 2015, at 03:37 AM, Pablo Méndez Hernández wrote:
> Hi misc@,
> 
> I'm trying to configure HSTS for my personal domain to no avail.
> 
> According to my understanding of httpd.conf, you'd only need to include the
> 'hsts' keyword in the tls part of the configuration with no need to
> redirect to https in the http case, but my configuration doesn't seem to
> work.

No, you still need to create a virtual host that listens on port 80 and does a 
redirect to https.


--
Carlin

> 
> My configuration is as follows:
> 
> $ cat /etc/httpd.conf
> #
> # Macros
> #
> ext_addr="egress"
> 
> #
> # Servers
> #
> 
> # A name-based "virtual" server
> server "www.mydomain.org" {
> listen on $ext_addr tls port 443
> 
> hsts {
> subdomains
> }
> 
> tls {
> ciphers "secure"
> }
> 
> root "/htdocs/www.mydomain.org"
> }
> 
> With this configuration, whenever I try to connect using http://, Chrome
> fails with ERR_CONNECTION_REFUSED
> 
> 
> Thanks in advance.
> 
> --
> 
> Pablo Méndez Hernández

HSTS configuration in httpd.conf

[Pablo Méndez Hernández]

Hi misc@,

I'm trying to configure HSTS for my personal domain to no avail.

According to my understanding of httpd.conf, you'd only need to include the
'hsts' keyword in the tls part of the configuration with no need to
redirect to https in the http case, but my configuration doesn't seem to
work.

My configuration is as follows:

$ cat /etc/httpd.conf
#
# Macros
#
ext_addr="egress"

#
# Servers
#

# A name-based "virtual" server
server "www.mydomain.org" {
listen on $ext_addr tls port 443

hsts {
subdomains
}

tls {
ciphers "secure"
}

root "/htdocs/www.mydomain.org"
}

With this configuration, whenever I try to connect using http://, Chrome
fails with ERR_CONNECTION_REFUSED


Thanks in advance.

--

Pablo Méndez Hernández

Re: OpenBGPd error /bsd: bgpd(): syscall 105

[Michael McConville]

Atanas Vladimirov wrote:
> Snapshot from sep 30 bgpd didn't startup:
> Oct  1 08:32:28 ns /bsd: bgpd(28055): syscall 105
> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE
> Oct  1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or
> directory
> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control
> Oct  1 08:32:28 ns bgpd[27739]: main: Lost connection to SE
> Oct  1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated;
> signal 9

This looks like a result of the new tame(2)ing. Below are the tame calls
that were just added to bgpd, according to Theo's diff.

Syscall 105 is setsockopt(2). Both "unix" and "inet" allow it. However,
the man page notes that "inet" restricts setsockopt significantly.
Because this error looks like it's happening within a setsockopt call,
maybe that's the issue. Changing "inet" to "unix" could potentially fix
it, as could refactoring the bgpd code.

I may have time to look into this more later.


Index: usr.sbin/bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.339
diff -u -p -u -r1.339 rde.c
--- usr.sbin/bgpd/rde.c 21 Sep 2015 09:47:15 -  1.339
+++ usr.sbin/bgpd/rde.c 28 Sep 2015 20:15:11 -
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bgpd.h"
 #include "mrt.h"
@@ -185,6 +186,9 @@ rde_main(int debug, int verbose)
setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) ||
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
+
+   if (tame("malloc unix cmsg", NULL) == -1)
+   err(1, "tame");
 
signal(SIGTERM, rde_sighdlr);
signal(SIGINT, rde_sighdlr);
Index: usr.sbin/bgpd/session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.340
diff -u -p -u -r1.340 session.c
--- usr.sbin/bgpd/session.c 4 Aug 2015 14:46:38 -   1.340
+++ usr.sbin/bgpd/session.c 28 Sep 2015 20:15:11 -
@@ -219,6 +219,9 @@ session_main(int debug, int verbose)
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
 
+   if (tame("malloc inet cmsg", NULL) == -1)
+   err(1, "tame");
+
signal(SIGTERM, session_sighdlr);
signal(SIGINT, session_sighdlr);
signal(SIGPIPE, SIG_IGN);

Re: OpenBGPd error /bsd: bgpd(): syscall 105

[Sebastien Marie]

On Thu, Oct 01, 2015 at 12:21:33PM -0400, Michael McConville wrote:
> Atanas Vladimirov wrote:
> > Snapshot from sep 30 bgpd didn't startup:
> > Oct  1 08:32:28 ns /bsd: bgpd(28055): syscall 105
> > Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> > Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE
> > Oct  1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or
> > directory
> > Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> > Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control
> > Oct  1 08:32:28 ns bgpd[27739]: main: Lost connection to SE
> > Oct  1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated;
> > signal 9
> 
> This looks like a result of the new tame(2)ing. Below are the tame calls
> that were just added to bgpd, according to Theo's diff.
> 

the revision 1.46 of src/sys/kern/kern_tame.c should have corrected the
problem.

bgpd use IPv6 setsockopts that weren't allowed.
-- 
Sebastien Marie

Re: HSTS configuration in httpd.conf

[Carlin Bingham]

On Fri, 2 Oct 2015, at 04:27 AM, Pablo Méndez Hernández wrote:
> Thanks!
> 
> As suggested by you, if I add this:
> 
> server "www.mydomain.org" {
> listen on $ext_addr port 80
> 
> block return 301 "https://$SERVER_NAME;
> }
> 
> it works, but in that case I don't see the point of configuring HSTS if we
> are forcing the redirect... :/
> 

That redirect will only be used the first time a browser (that supports HSTS) 
accesses the domain. Once they've been redirected to your https host the HSTS 
flag will be set in their browser and from then on the browser will immediately 
use https for your domain without going through the redirect.

--
Carlin

> 
> Kind regards.
> 
> >
> --
> Pablo Méndez Hernández

Re: HSTS configuration in httpd.conf

[Pablo Méndez Hernández]

Hi Carlin,

On Thu, Oct 1, 2015 at 4:53 PM, Carlin Bingham  wrote:

> On Fri, 2 Oct 2015, at 03:37 AM, Pablo Méndez Hernández wrote:
> > Hi misc@,
> >
> > I'm trying to configure HSTS for my personal domain to no avail.
> >
> > According to my understanding of httpd.conf, you'd only need to include
> the
> > 'hsts' keyword in the tls part of the configuration with no need to
> > redirect to https in the http case, but my configuration doesn't seem to
> > work.
>
> No, you still need to create a virtual host that listens on port 80 and
> does a redirect to https.
>

Thanks!

As suggested by you, if I add this:

server "www.mydomain.org" {
listen on $ext_addr port 80

block return 301 "https://$SERVER_NAME;
}

it works, but in that case I don't see the point of configuring HSTS if we
are forcing the redirect... :/


Kind regards.

>
> > My configuration is as follows:
> >
> > $ cat /etc/httpd.conf
> > #
> > # Macros
> > #
> > ext_addr="egress"
> >
> > #
> > # Servers
> > #
> >
> > # A name-based "virtual" server
> > server "www.mydomain.org" {
> > listen on $ext_addr tls port 443
> >
> > hsts {
> > subdomains
> > }
> >
> > tls {
> > ciphers "secure"
> > }
> >
> > root "/htdocs/www.mydomain.org"
> > }
> >
> > With this configuration, whenever I try to connect using http://, Chrome
> > fails with ERR_CONNECTION_REFUSED
> >
> >
> > Thanks in advance.
> >
> > --
> >
> > Pablo Méndez Hernández
> >
>



--

Pablo Méndez Hernández

Re: APU re(4) how can I debug this further?

[Peter J. Philipp]

OK the condition happened again.  I had a suspended netbook at the
headless serial console of the APU router (gamma) and was able to ping
the fritzbox at 192.168.179.5,  I also logged into uranus and could not
ping 192.168.179.1 which is gamma.  This is majorly weird.  I noticed
the arp timer for uranus on gamma was low at about 4 seconds.  In this
ordeal which lasted about 5 minutes I assumed that I could ping fritzbox
from uranus as that is always the case.  Which leads to a weird
scenario, which is that fritzbox (192.168.179.5) can be pinged from
either side but not beyond.  I have firewall rules on uranus to reset
anything hitting it so pinging from gamma to uranus would fail.

Just wanted to give an update on this, perhaps someone knows how I can
get more verbose messages on that interface.  I cycled it too btw, but
that didn't make it ping.  Anything else I can try?

Cheers,

-peter

On 09/30/15 11:10, Peter J. Philipp wrote:
> On Wed, Sep 30, 2015 at 10:36:21AM +0200, Benny Lofgren wrote:
>>> Thanks for your help,
>> I assume you are not able to ping the other way around either when the
>> network goes down, i e from gamma to fritzbox?
> Since everything in that part of the apartment is headless (fritzbox, gamma
> and mercury) I haven't been able to attach anything in time before the 
> disruption is over.  However thanks for pointing it out I'll attach a
> netbook to its serial port and have it hibernate until the problem occurs
> again.  I forgot to mention the problem is highly sporadic.
>
>> Are you able to ping mercury from gamma? (But as I interpret your map
>> they are not on the same network i/f on gamma so that might not provide
>> much useful info.)
> I'll try that out next time when I've set up the netbook.
>
>> What happens if you do ifconfig re1 down / ifconfig re1 up on gamma when
>> the fault have occured?
> I'll have to try that out.
>
>> Or if you unplug and then put the network cable back again?
> Haven't tried that yet.
>
>> In other words, how do you usually recover from the problem?
> Usually I log into uranus from spica or a vm of spica and start pinging to
> see if the fritzbox is available then i start a ping on gamma and notice it
> will be down.  The vm of spica has a gif tunnel and IPSEC to mercury so that
> is the first indication that nothing works.
>
> I have in the past rebooted the fritzbox which solved the problem, but that 
> stopped when I started mailing AVM.  The problem can take up to 5-10 minutes 
> downtime which would be as much time as me getting out a netbook, booting it 
> connecting it to gamma, logging in and doing network checks.
>
>> Are there any clues in /var/log/messages that might be of interest?
> Unfortnately not.
>
>> Also, the usual first question on this list is: can you provide a full
>> dmesg from gamma?
>> It is almost always more helpful than people think, so never leave home
>> without it! :-)
>>
>>
>> Regards,
>>
>> /Benny
> Thanks for your effort Benny.  The dmesg follows...
>
> -peter
>
>
> OpenBSD 5.7 (GENERIC.MP) #2: Fri Jul 31 18:51:07 CEST 2015
> p...@gamma.virgostar.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2098520064 (2001MB)
> avail mem = 2038796288 (1944MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries)
> bios0: vendor coreboot version "4.0" date 09/08/2014
> bios0: PC Engines APU
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) 
> PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) 
> UOH4(S3) UOH5(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD G-T40E Processor, 1000.15 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu0: 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 200MHz
> cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD G-T40E Processor, 1000.01 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
> 

Re: OpenBGPd error /bsd: bgpd(): syscall 105

[Stuart Henderson]

On 2015-10-01, Michael McConville  wrote:
> Atanas Vladimirov wrote:
>> Snapshot from sep 30 bgpd didn't startup:
>> Oct  1 08:32:28 ns /bsd: bgpd(28055): syscall 105
>> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
>> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE
>> Oct  1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or
>> directory
>> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
>> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control
>> Oct  1 08:32:28 ns bgpd[27739]: main: Lost connection to SE
>> Oct  1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated;
>> signal 9
>
> This looks like a result of the new tame(2)ing. Below are the tame calls
> that were just added to bgpd, according to Theo's diff.
>
> Syscall 105 is setsockopt(2). Both "unix" and "inet" allow it. However,
> the man page notes that "inet" restricts setsockopt significantly.
> Because this error looks like it's happening within a setsockopt call,
> maybe that's the issue. Changing "inet" to "unix" could potentially fix
> it, as could refactoring the bgpd code.

I think this should be ok under a newer kernel. But if not, please run
bgpd under ktrace ("ktrace -i bgpd" or similar), then run kdump and
include the last page or so of output.

Same for any other crashes which show up in dmesg like 'program(12345): syscall 
XXX'.

Re: inet6 autoconf will not remove invalid addresses on -current

[Daniel Gillen]

On 01.10.2015 10:48, Martin Pieuchot wrote:
> Hello,
> 
> On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
>> [...]
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev vlan35 \
>> authproto pap \
>> authname "@vo.lu" \
>> authkey ""
>> dest 0.0.0.1
>> inet6 autoconf
>> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
>> !/sbin/route add ::/0 -ifp pppoe0 fe80::
>>
>> As you can see, it get my IPv6 address trough autoconfiguration.
>>
>> After my pppoe reconnected again, I saw the following in ifconfig:
> 
> What do you mean by "reconnected again" ?
> 
>> pppoe0: flags=208851
>> mtu 1492
>> priority: 0
>> dev: vlan35 state: session
>> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
>> sppp: phase network authproto pap authname "@vo.lu"
>> groups: pppoe egress
>> status: active
>> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
>> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 556434 vltime 2543634
>> [...]
>> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 1835 vltime 520374
>> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
>> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 604755 vltime 2591955
>> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 37915 vltime 556755
>>
>> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
>> added it to my interface.
>>
>> But it didn't remove the now invalid and no longer working
>> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
>> my NAT was still using that address for part of the connections.
>>
>> Shouldn't those be removed as soon as their prefix is no longer valid?
>> Or at least all be deprecated?
> 
> If this happens again could you include the output of "# ndp -p",
> "# route -n show -inet6" and "# ndp -r" in your report?
> 
> Thanks,
> Martin
> 

I managed to reproduce the issue and executed the commands you told me.

Just one sidenode as it might matter, I'm running -current freshly
checked out and build Thu Oct 1, 18:33:57 CEST 2015.

# uname -a
OpenBSD gate 5.8 GENERIC.MP#1 amd64

And here we go, the short version:

# reboot

# ifconfig pppoe0
IPv4 address is 80.XX.XX.227
Autoconfigured IPv6 address is 2001:XX:XX:707:XX:XX:XX:6c3a

# ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
Pinging google with that source address works

# ndp -p
2001:XX:XX:707::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m39s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)

# route -n show -inet6
See long version below

# ndp -r
fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
expire=29m59s

Now I simmulated a PPPoE dis-/re-connect (Thx again to Todd for the tip)
# ifconfig pppoe0 down up

# ifconfig pppoe0
New IPv4 address is 85.XX.XX.98
But now I have 2 autoconfigured IPv6 addresses, the old
2001:XX:XX:707:XX:XX:XX:6c3a address and the new
2001:XX:XX:7c5:XX:XX:XX:6c3a address.

# ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
# ping6 -c 1 -S 2001:XX:XX:7c5:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
Pinging google with the old 2001:XX:XX:707::/64 prefix address does not
work anymore, but the new 2001:XX:XX:7c5::/64 prefix address works.

# ndp -p
2001:XX:XX:7c5::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m47s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)
2001:XX:XX:707::/64 if=pppoe0
flags=LAD vltime=2592000, pltime=604800, expire=29d23h58m45s, ref=2
advertised by
fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)

# route -n show -inet6
Again, see below

# ndp -r
fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
expire=29m28

I think the old 2001:XX:XX:707::/64 prefix should be removed as soon as
the same router (fe80::46d3:caff:fe9c:ef00) advertises a new prefix.

Or am I getting something wrong here?

**
And here the log version including 'route' output:

# reboot

# ifconfig pppoe0
pppoe0: flags=208851
mtu 1492
priority: 0
dev: vlan35 state: session
sid: 0x47c PADI retries: 0 PADR retries: 0 time: 00:00:21
sppp: phase network authproto pap authname "@vo.lu"
groups: pppoe egress
status: active
inet6 fe80::XX:XX:XX:6c3a%pppoe0 -> prefixlen 64 scopeid 0x8
inet 80.XX.XX.227 --> 80.XX.XX.143 netmask 0x
inet6 2001:XX:XX:707:XX:XX:XX:6c3a -> prefixlen 64 autoconf pltime
604796 vltime 2591996
inet6 2001:XX:XX:707:XX:XX:XX:e080 -> prefixlen 64 autoconf
autoconfprivacy pltime 85930 vltime 604780

# ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
PING6(72=40+8+24 bytes) 2001:XX:XX:707:XX:XX:XX:6c3a -->
2a00:1450:4001:806::1009
32 bytes from 

Re: HSTS configuration in httpd.conf

[Giancarlo Razzolini]

Em 01-10-2015 12:58, Carlin Bingham escreveu:
> That redirect will only be used the first time a browser (that supports HSTS) 
> accesses the domain. Once they've been redirected to your https host the HSTS 
> flag will be set in their browser and from then on the browser will 
> immediately use https for your domain without going through the redirect.

The redirect is still necessary, given the fact that STS headers have a
expiration time. So, configure and forget the redirect and always
maintain your TLS setup working, and you should be fine.

Cheers,
Giancarlo Razzolini

iked ikev2 x509 authentication problem - no valid local certificate found

[Rob]

Hi,

I’m a little stuck getting two different clients connected to my OpenBSD
5.7 (i386) VPN ikev2 server.  I suspect the clients are at fault as I can
get past the error when connecting one OpenBSDs iked to another iked.

FWIW the clients are both Apple, one IOS 9.1 device and one OSX 10.11.1
laptop, so I’m a little stuck with the VPN client I can use.

I have the following configuration:

ikev2 "road_warrior" passive esp \
from 192.168.20.0/24 to 192.168.40.0/24 \
local 192.168.20.4 peer any \
ikesa enc aes-128 prf hmac-sha2-256 \ 
auth hmac-sha2-256 group modp2048 \
childsa enc aes-128 auth hmac-sha2-256 \
srcid "local.example.net \
dstid "peer.example.net" \
config address 192.168.40.10/29 \
config netmask 255.255.255.0 \
config name-server 192.168.20.53 \
config protected-subnet 192.168.40.0/24

(IPs and names have been changed to protect the innocent)

I have keys installed as follows:

/etc/iked/ca/example.net.crt
/etc/iked/certs/local.example.net.crt
/etc/iked/private/local.key
/etc/iked/pubkeys/fqdn/peer.example.net
/etc/iked/local.pub


I believe the client isn’t sending the certificate request, but I
could be completely wrong, the error appears to be:

ikev2_sa_negotiate: score 4
sa_stateflags: 0x18 -> 0x18 authvalid,sa (required 0x1f 
cert,certvalid,auth,authvalid,sa)
sa_stateok: VALID flags 0x18, require 0x1f cert,certvalid,auth,authvalid,sa
sa_state: cannot switch: AUTH_SUCCESS -> VALID
config_free_proposals: free 0x77286c80
ca_getreq: no valid local certificate found

The client is sending peer.example.net.crt to the server, which gets
validated correctly:

ca_validate_cert: /C=UK/L=London/O=Example Net/CN=peer.example.net ok
ikev2_dispatch_cert: peer certificate is valid
sa_stateflags: 0x1c -> 0x1e certvalid,auth,authvalid,sa (required 0x1f 
cert,certvalid,auth,authvalid,sa)

I’ve been at this for a number of days and am completely stuck, so if
anyone has any ideas/advice/clue-sticks I’d be very grateful.  If you
need any further log information please let me know.


thanks

Rob

Re: iked ikev2 x509 authentication problem - no valid local certificate found

[mxb]

http://marc.info/?l=openbsd-tech=144362542514318=2


> On 1 okt. 2015, at 21:25, Rob  wrote:
>
> Hi,
>
> I’m a little stuck getting two different clients connected to my OpenBSD
> 5.7 (i386) VPN ikev2 server.  I suspect the clients are at fault as I can
> get past the error when connecting one OpenBSDs iked to another iked.
>
> FWIW the clients are both Apple, one IOS 9.1 device and one OSX 10.11.1
> laptop, so I’m a little stuck with the VPN client I can use.
>
> I have the following configuration:
>
> ikev2 "road_warrior" passive esp \
>from 192.168.20.0/24 to 192.168.40.0/24 \
>local 192.168.20.4 peer any \
>ikesa enc aes-128 prf hmac-sha2-256 \
>auth hmac-sha2-256 group modp2048 \
>childsa enc aes-128 auth hmac-sha2-256 \
>srcid "local.example.net \
>dstid "peer.example.net" \
>config address 192.168.40.10/29 \
>config netmask 255.255.255.0 \
>config name-server 192.168.20.53 \
>config protected-subnet 192.168.40.0/24
>
> (IPs and names have been changed to protect the innocent)
>
> I have keys installed as follows:
>
> /etc/iked/ca/example.net.crt
> /etc/iked/certs/local.example.net.crt
> /etc/iked/private/local.key
> /etc/iked/pubkeys/fqdn/peer.example.net
> /etc/iked/local.pub
>
>
> I believe the client isn’t sending the certificate request, but I
> could be completely wrong, the error appears to be:
>
> ikev2_sa_negotiate: score 4
> sa_stateflags: 0x18 -> 0x18 authvalid,sa (required 0x1f
cert,certvalid,auth,authvalid,sa)
> sa_stateok: VALID flags 0x18, require 0x1f cert,certvalid,auth,authvalid,sa
> sa_state: cannot switch: AUTH_SUCCESS -> VALID
> config_free_proposals: free 0x77286c80
> ca_getreq: no valid local certificate found
>
> The client is sending peer.example.net.crt to the server, which gets
> validated correctly:
>
> ca_validate_cert: /C=UK/L=London/O=Example Net/CN=peer.example.net ok
> ikev2_dispatch_cert: peer certificate is valid
> sa_stateflags: 0x1c -> 0x1e certvalid,auth,authvalid,sa (required 0x1f
cert,certvalid,auth,authvalid,sa)
>
> I’ve been at this for a number of days and am completely stuck, so if
> anyone has any ideas/advice/clue-sticks I’d be very grateful.  If you
> need any further log information please let me know.
>
>
> thanks
>
> Rob

Re: APU re(4) how can I debug this further?

[Mihai Popescu]

Hello,

Your network map is almost useless without configuration data for
interfaces. Try to draw it again using IP addresses and network masks.
Something like:

[gaia](192.168.1.10/24)--
or
[gaia](192.168.1.10/255.255.255.0)--
or
[gaia](dhcp)--

Fill in the blanks for all interfaces, then specify if you are going
thru some network switch. Let people know if you are running a DHCP
server then tell them on what machine, too.

I have a PPPoE link, and my ISP is passing an IP address and a gateway
address for pppoe0 interface. The interface IP is a public class, but
the gateway is a private IP, something like 10.0.0.1. If I use this
second IP class for my private LAN too (10.0.0.0/24), then nothing is
working. There is some routing conflict I think. I don't know PPPoE in
details, but I am sure this will not work.

Thanks.

Re: sleep with tame(2)?

[Sebastien Marie]

On Thu, Oct 01, 2015 at 01:32:54PM +0800, johnw wrote:
> Hi all,
> 
> After upgrade to 30-Sep-2015 12:20 snapshot (AMD64),
> (download from http://ftp.openbsd.org)
> 
> I noticed /bin/sleep with run tame(2) call, but I can not find any tame call
> in source code (cvsweb.openbsd.org).

snapshots occasionnally contains uncommited patchs for testing purpose.
Here, it is the case for tame(2) call in sleep(1).

> when I run sleep:
> john@pdc:[~]$ sleep
> Killed
> then I run dmesg, the last line show me
> sleep(31307): syscall 4
>

thanks to reported this kind of problem.

syscall 4 is for SYS_write (see /usr/include/sys/syscall.h).

It means the request in the (uncommited) tame call in sleep is wrong: it
should be expected to the program to call usage() as some point. 

It means also a dev will not have cookie :)

Thanks.
-- 
Sebastien Marie

10Gb single mode fibre adapters

[James A. Peltier]

Hi Misc,

I'm looking to get some insight into those that have 10Gb single mode fibre 
adaptors in their OpenBSD machines and if they're being used in bridging mode?  
I've got a user who is asking what the current state of 10Gb is on OpenBSD 
given all the MP work that's been done.  There will be 70 or so VLANs, some 
traffic shaping, and packet filter taking place on this device and so choosing 
the appropriate hardware is rather important.  Any input from heavy 
bridging/VLAN use is even more important.  Thanks.

-- 
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 604-365-6432
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology

Re: inet6 autoconf will not remove invalid addresses on -current

[Daniel Gillen]

On 01/10/2015 10:48, Martin Pieuchot wrote:
> Hello,
> 
> On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
>> [...]
>> inet 0.0.0.0 255.255.255.255 NONE \
>> pppoedev vlan35 \
>> authproto pap \
>> authname "@vo.lu" \
>> authkey ""
>> dest 0.0.0.1
>> inet6 autoconf
>> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
>> !/sbin/route add ::/0 -ifp pppoe0 fe80::
>>
>> As you can see, it get my IPv6 address trough autoconfiguration.
>>
>> After my pppoe reconnected again, I saw the following in ifconfig:
> 
> What do you mean by "reconnected again" ?

The connection was dropped (LCP keepalive timeout) and PPPoE established
a new connection once (I would suspect) PPPoE was available again.

> 
>> pppoe0: flags=208851
>> mtu 1492
>> priority: 0
>> dev: vlan35 state: session
>> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
>> sppp: phase network authproto pap authname "@vo.lu"
>> groups: pppoe egress
>> status: active
>> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
>> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 556434 vltime 2543634
>> [...]
>> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 1835 vltime 520374
>> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
>> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
>> pltime 604755 vltime 2591955
>> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
>> autoconfprivacy pltime 37915 vltime 556755
>>
>> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
>> added it to my interface.
>>
>> But it didn't remove the now invalid and no longer working
>> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
>> my NAT was still using that address for part of the connections.
>>
>> Shouldn't those be removed as soon as their prefix is no longer valid?
>> Or at least all be deprecated?
> 
> If this happens again could you include the output of "# ndp -p",
> "# route -n show -inet6" and "# ndp -r" in your report?
> 
> Thanks,
> Martin
> 

Sure, will try this evening to reproduce it somehow and then send you
the output.

Thx

Daniel

Re: 10Gb single mode fibre adapters

[Chris Cappuccio]

James A. Peltier [jpelt...@sfu.ca] wrote:
> Hi Misc,
> 
> I'm looking to get some insight into those that have 10Gb single mode fibre 
> adaptors in their OpenBSD machines and if they're being used in bridging 
> mode?  I've got a user who is asking what the current state of 10Gb is on 
> OpenBSD given all the MP work that's been done.  There will be 70 or so 
> VLANs, some traffic shaping, and packet filter taking place on this device 
> and so choosing the appropriate hardware is rather important.  Any input from 
> heavy bridging/VLAN use is even more important.  Thanks.
> 

I've tested the Xeon CPU E5-1630v3 (3.70GHz, 4 core), myricom myx,
intel ix and emulex oce cards, and the results under 5.8-current
are great. OpenBSD 5.8 is not bad either. Under 5.8-current, a
small routing table of 500 or so routes and option ART, plus PF
NAT enabled and 1.4Gbps/200kpps of load, vlans, the average load
is 11%, which transates to load of 30-40% on two cores and almost
none on two (or sometimes evenly loads across three cores, out of
nowhere). The network stack is undergoing big changes so this keeps
improving.

The oce card/driver gives me .06ms round-trip ping times across a 
cisco 5020 whereas ix and myx are currently at .2ms-.3ms rtt on 
the same switch. I'm not sure why, but it's fascinating. 

Chris

Re: inet6 autoconf will not remove invalid addresses on -current

[Martin Pieuchot]

Hello,

On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
> [...]
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev vlan35 \
> authproto pap \
> authname "@vo.lu" \
> authkey ""
> dest 0.0.0.1
> inet6 autoconf
> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
> !/sbin/route add ::/0 -ifp pppoe0 fe80::
> 
> As you can see, it get my IPv6 address trough autoconfiguration.
> 
> After my pppoe reconnected again, I saw the following in ifconfig:

What do you mean by "reconnected again" ?

> pppoe0: flags=208851
> mtu 1492
> priority: 0
> dev: vlan35 state: session
> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
> sppp: phase network authproto pap authname "@vo.lu"
> groups: pppoe egress
> status: active
> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
> pltime 556434 vltime 2543634
> [...]
> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
> autoconfprivacy pltime 1835 vltime 520374
> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
> pltime 604755 vltime 2591955
> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
> autoconfprivacy pltime 37915 vltime 556755
> 
> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
> added it to my interface.
> 
> But it didn't remove the now invalid and no longer working
> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
> my NAT was still using that address for part of the connections.
> 
> Shouldn't those be removed as soon as their prefix is no longer valid?
> Or at least all be deprecated?

If this happens again could you include the output of "# ndp -p",
"# route -n show -inet6" and "# ndp -r" in your report?

Thanks,
Martin

off-topic: experience with public pki providers?

[Marko Cupać]

Hi,

I know this is completely unrelated to OpenBSD but I value experience
of misc@ members much more than google's results for 'best pki provider
2015', so here's the question:

Can you recommend me some good public PKI?

My personal opinion is that whole 'trusted providers' idea is scam, and
has nothing to do with trust or security. However, a client of mine
wants 'trusted' ssl and s/mime certificates, and I need to choose one.

Thank you in advance,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/