Re: bgpd not starting since Oct 5 snapshot (tame related?)

[Theo de Raadt]

> On 2015-10-07, Theo de Raadt  wrote:
> >> I noticed that my bpgd is down after the reboot with the following new
> >> messages in dmesg:
> >> 
> >> bgpd(13184): sysctl 6: 4 17 0 0 3 0
> >> bgpd(13184): syscall 202
> >
> > Please ktrace -di it.  I suspect this is ICMPV6CTL_MTUDISC_LOWAT,
> > I'll look into it and add it once I determine it is safe in tame.
> >
> >
> 
> 4 CTL_NET
> 17 PF_ROUTE
> 0
> 0
> 3 NET_RT_TABLE
> 0 [rtableid]
> 
> This is fetching the route table, I don't have a new enough kernel on a box
> where I can test bgpd yet, but this should be working OK with the 'tame 
> "route"'
> addition.

yes, this should be fixed in -current now.

Re: httpd syscall 72

[Scott Vanderbilt]

On 10/7/2015 12:38 PM, Daniel Jakots wrote:

On Wed, 7 Oct 2015 12:18:32 -0700, Scott Vanderbilt
 wrote:


Might anyone have an idea where I can start to look for the problem?


semarie@ explained how to debug/report tame(2) problem :
https://marc.info/?l=openbsd-tech=144412493925465=2


The post from tech@ is elucidating, but the diff provided by semarie@ is 
bgpd-specific. Sadly, I'm not knowledgeable enough to extrapolate from 
that how to patch httpd. If anyone could kindly provide a patch, I will 
gladly recompile and generate the core.


The syscall (72) maps to  SYS_kevent 72.

Here is the (I believe) relevant extract from the kdump output:

 10818 httpdCALL  tame(0x10525251dde9,0)
 10818 httpdSTRU  tame request="malloc cmsg"
 10818 httpdRET   tame 0
 10818 httpdCALL  kbind(0x7f7f4938,0x18,0x67b077efcdf46f05)
 10818 httpdRET   kbind 0
 10818 httpdCALL  kbind(0x7f7f4938,0x18,0x67b077efcdf46f05)
 10818 httpdRET   kbind 0
 10818 httpdCALL  kbind(0x7f7f4938,0x18,0x67b077efcdf46f05)
 10818 httpdRET   kbind 0
 10818 httpdCALL  clock_gettime(CLOCK_MONOTONIC,0x7f7f4920)
 10818 httpdSTRU  struct timespec { 4436<"Dec 31 17:13:56 
1969">.154449146 }

 10818 httpdRET   clock_gettime 0
 10818 httpdCALL  kevent(17,0x10553aeb3800,4,0x105536daf000,64,0)
 10818 httpdPSIG  SIGKILL SIG_DFL
 30352 httpdRET   kevent 2

Thank you.

unlocking em - unable to fill any rx descriptors

[Hrvoje Popovski]

Hi all,

i have fairly simple setup with receiver connected to em2 and sender
connected to em3. Both em are Intel I350. Setup is without pf with these
sysctls:

kern.pool_debug=1
   net.inet.ip.forwarding=1
net.inet.ip.ifq.maxlen=8192
ddb.console=1

with if_em.c revisions 1.307 and 1.306 i can trigger
em2: unable to fill any rx descriptors
when doing ifconfig em2 down/up (receiver side) while generating
traffic. i can't trigger this with ifconfig em3 down/up (sender side) or
destroying bridge and enabling it. this is reproducible.

with bridged setup when doing ifconfig em2 down/up i'm getting rx
descriptors log and bridge stops bridging traffic until doing this:
stop generating traffic
ifconfig em2 down
ifconfig em3 down
ifconfig bridge0 destroy
ifconfig em2 up
ifconfig em3 up
sh netstart bridge0
start generating traffic


with routed setup when doing ifconfig em2 down/up traffic is not
forwarded until
stop generating traffic
ifconfig em2 down
ifconfig em2 up
start generating traffic


with if_em.c revisions 1.305 and if_em.h revision 1.57 i can't trigger
rx descriptors log and bridge starts to bridge traffic almost instantly
when doing ifconfig em2 up


i am willing to debug this further but i don't know how...


OpenBSD 5.8-current (GENERIC.MP) #3: Thu Oct  8 00:34:55 CEST 2015
r...@.srce.hr:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 34314596352 (32724MB)
avail mem = 33270505472 (31729MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e67c000 (84 entries)
bios0: vendor IBM version "-[D7E146CUS-1.82]-" date 04/09/2015
bios0: IBM IBM System x3550 M4 Server -[7914T91]-
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP TCPA ERST HEST HPET APIC MCFG OEM1 SLIT SLIC
SSDT SSDT SSDT SSDT DMAR
acpi0: wakeup devices MRP1(S4) DCC0(S4) MRP3(S4) MRP5(S4) EHC2(S5)
PEX0(S5) PEX7(S5) EHC1(S5) IP2P(S3) MRPB(S4) MRPC(S4) MRPD(S4) MRPF(S4)
MRPG(S4) MRPH(S4) MRPI(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2400.35 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2399.99 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2399.99 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2399.99 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2399.99 MHz
cpu4:
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2399.99 MHz
cpu5:

Re: httpd syscall 72

[Theo de Raadt]

> The syscall (72) maps to  SYS_kevent 72.

Someone uses tame "malloc" instead of tame "stdio".

Re: Bulkget & snmpd

[Stuart Henderson]

On 2015-10-07, Denis Fondras  wrote:
> I'm using snmpd from base on 5.8 and while playing with snmpbulkget (from
> net-snmp), I noticed a weirdness.

Note, I've replied on tech@.

Re: httpd syscall 72

[Adam Wolk]

On Wed, 7 Oct 2015 12:18:32 -0700
Scott Vanderbilt  wrote:

> Running latest snapshot (amd64), I get a 'sycall 72' message when 
> attempting to start httpd, e.g.:
> 
>  httpd(10043): syscall 72
> 
> I'm pretty sure this started with snapshots after Sept. 27.
> 
> Might anyone have an idea where I can start to look for the problem?
> 
> Thanks.
> 

I have the same dmesg since Oct 7 snapshot. Not present in Oct 5
snapshot.

 30007 basename CALL  tame(0x1636d4d01089,0)
 30007 basename STRU  tame request="stdio"
 30007 basename RET   tame 0

   855 id   CALL  tame(0x19334f201fe2,0)
   855 id   STRU  tame request="stdio getpw"
   855 id   RET   tame 0

   855 id   CALL  tame(0x19334f201fe2,0)
   855 id   STRU  tame request="stdio getpw"
   855 id   RET   tame 0

 11057 httpdCALL  tame(0x1fcf4ca1dc70,0)
 11057 httpdSTRU  tame request="malloc inet cmsg cpath rpath wpath
 proc ioctl" 11057 httpdRET   tame 0

 31228 httpdCALL  tame(0x1fcf4ca1e4e0,0)
 31228 httpdSTRU  tame request="malloc cmsg rpath proc inet unix
 ioctl" 31228 httpdRET   tame 0

 13028 httpdCALL  tame(0x1fcf4ca1dde9,0)
 13028 httpdSTRU  tame request="malloc cmsg"
 13028 httpdRET   tame 0

 29181 httpdCALL  tame(0x1fcf4ca1e4e0,0)
 29181 httpdSTRU  tame request="malloc cmsg rpath proc inet unix
 ioctl" 29181 httpdRET   tame 0

  9705 httpdCALL  tame(0x1fcf4ca1e4e0,0)
  9705 httpdSTRU  tame request="malloc cmsg rpath proc inet unix
  ioctl" 9705 httpdRET   tame 0

 13028 httpdPSIG  SIGKILL SIG_DFL
 11057 httpdPSIG  SIGCHLD caught handler=0x1fd1c9ab83e0 mask=0<>

Regards,
Adam

Re: bgpd not starting since Oct 5 snapshot (tame related?)

[Stuart Henderson]

On 2015-10-07, Theo de Raadt  wrote:
>> I noticed that my bpgd is down after the reboot with the following new
>> messages in dmesg:
>> 
>> bgpd(13184): sysctl 6: 4 17 0 0 3 0
>> bgpd(13184): syscall 202
>
> Please ktrace -di it.  I suspect this is ICMPV6CTL_MTUDISC_LOWAT,
> I'll look into it and add it once I determine it is safe in tame.
>
>

4 CTL_NET
17 PF_ROUTE
0
0
3 NET_RT_TABLE
0 [rtableid]

This is fetching the route table, I don't have a new enough kernel on a box
where I can test bgpd yet, but this should be working OK with the 'tame "route"'
addition.

Re: httpd syscall 72

[Rob Pierce]

>From Stuart in response to a previous inquiry:

Rob

> >> If you need a working version, the diffs aren't committed yet, so you can
> >> rebuild httpd from source and it should work fine.
> >> 
> > Thanks for the info Ted. I'm currently rebuilding the src, following the 
> > "5 - Building the System from Source" page. I just want to ask another 
> > question, can I just rebuild only the httpd from source? Thanks again.
> 
> Yes,
> 
> $ cd /usr/src/usr.sbin/httpd
> $ cvs up -PdA
> $ make obj && make depend && make
> $ su root -c 'make install'
> 

Thank you very much Stuart!

Re: OS X 10.11 'El Capitan' IKEv2

[matthew j weaver]

> On Oct 3, 2015, at 5:32 AM, Reyk Floeter  wrote:
> In summary, the GUI part is very easy but certificate configuration is
> a bit difficult.  It's the same complexity as in Windows.  But much
> better compared to earlier IPsec configurations.

  Agreed, thanks for the update. I made some time to come around to this work 
again today.

  Works fine on -current, using “no” authentication and a machine certificate.

  I used ikectl to build all the certificates.

  enc0 configured with 10.23.0.1, running a unbound, etc (as Reyk describes).

  For those playing the home game, here’s my iked.conf snippet:

ikev2 "aapl" passive esp \
from 0.0.0.0/0 to 0.0.0.0/0 \
local (server ip) peer any \
childsa enc 3des \
scrod (server ip) dusted (made-up fqdn in client certificate) \
config address 10.23.0.1/24 \
config name-server 10.23.0.1 \
tag "$name-$id”

  Thanks, Reyk.
  weaver

Re: Captive portal with OpenBSD as a hostap

[laudarch]

Here is the diff I made,
it simply calls a program when a user logs in with authpf and when a
user logs out.

to use this diff you must add these lines to authpf.conf

start=/path/to/startsession.pl
end=/path/to/endsession.pl

follows is the diff

Index: src/usr.sbin/authpf/authpf.c
===
RCS file: /cvs/src/usr.sbin/authpf/authpf.c,v
retrieving revision 1.123
diff -u -r1.123 authpf.c
--- src/usr.sbin/authpf/authpf.c 21 Jan 2015 21:50:32 - 1.123
+++ src/usr.sbin/authpf/authpf.c 8 Oct 2015 01:21:58 -
@@ -52,12 +52,15 @@
static int change_filter(int, const char *, const char *);
static int change_table(int, const char *);
static void authpf_kill_states(void);
+static int exec_callback(int);

int dev; /* pf device */
char anchorname[PF_ANCHOR_NAME_SIZE] = "authpf";
char rulesetname[PATH_MAX - PF_ANCHOR_NAME_SIZE - 2];
char tablename[PF_TABLE_NAME_SIZE] = "authpf_users";
int user_ip = 1; /* controls whether $user_ip is set */
+char startcommand[PATH_MAX - PF_ANCHOR_NAME_SIZE - 2] = "";
+char endcommand[PATH_MAX - PF_ANCHOR_NAME_SIZE - 2] = "";

FILE *pidfp;
int pidfd = -1;
@@ -411,6 +414,19 @@
sizeof(tablename)) >= sizeof(tablename))
goto parse_error;
}
+ if (strcasecmp(pair[0], "start") == 0) {
+ if (!pair[1][0] || strlcpy(startcommand, pair[1],
+ sizeof(startcommand)) >= sizeof(startcommand))
+ goto parse_error;
+ syslog(LOG_INFO, "start: %s", startcommand);
+ }
+
+ if (strcasecmp(pair[0], "end") == 0) {
+ if (!pair[1][0] || strlcpy(endcommand, pair[1],
+ sizeof(endcommand)) >= sizeof(endcommand))
+ goto parse_error;
+ syslog(LOG_INFO, "end: %s", endcommand);
+ }
} while (!feof(f) && !ferror(f));
fclose(f);
return (0);
@@ -821,11 +837,23 @@
goto error;
}

+ if (startcommand != NULL) {
+ if (exec_callback(0) != 0) {
+ goto error;
+ }
+ }
+
gettimeofday(, NULL);
syslog(LOG_INFO, "allowing %s, user %s", ipsrc, luser);
} else {
remove_stale_rulesets();

+ if (endcommand != NULL) {
+ if (exec_callback(1) != 0) {
+ goto error;
+ }
+ }
+
gettimeofday(, NULL);
syslog(LOG_INFO, "removed %s, user %s - duration %d seconds",
ipsrc, luser, (int)(Tend.tv_sec - Tstart.tv_sec));
@@ -952,3 +980,78 @@
syslog(LOG_ERR, "cannot unlink %s (%m)", pidfile);
exit(ret);
}
+
+/*
+ * execute an external program on start and or end of session
+ */
+static int
+exec_callback(int end)
+{
+ pid_t pid;
+ gid_t gid;
+ int s;
+ char prog[PATH_MAX - PF_ANCHOR_NAME_SIZE - 2];
+ char *pargv[5] = {"/bin/ls", "luser", "ip", "pid", NULL};
+
+ if (end == 0) {
+ if (startcommand != NULL) {
+ strlcpy(prog, startcommand, sizeof(startcommand));
+ } else {
+ goto done;
+ }
+ }
+
+ if (end == 1) {
+ if (endcommand != NULL) {
+ strlcpy(prog, endcommand, sizeof(endcommand));
+ } else {
+ goto done;
+ }
+ }
+
+ pargv[0] = prog;
+ pargv[1] = luser;
+ pargv[2] = ipsrc;
+ if (asprintf([3], "%ld", (long)getpid()) == -1)
+ goto no_mem;
+
+ switch (pid = fork()) {
+ case -1:
+ syslog(LOG_ERR, "fork failed");
+ goto error;
+ case 0:
+ /* revoke group privs before exec */
+ gid = getgid();
+ if (setregid(gid, gid) == -1) {
+ err(1, "setregid");
+ }
+
+ execvp(prog, pargv);
+ syslog(LOG_INFO, "exec of %s %s %s %s", prog, pargv[1],
+ pargv[2], pargv[3]);
+ warn("exec of %s %s %s %s [] failed", prog, pargv[1],
+ pargv[2], pargv[3]);
+ _exit(1);
+ }
+
+ /* parent */
+ waitpid(pid, , 0);
+ if (s != 0) {
+ syslog(LOG_ERR, "%s exited abnormally", prog);
+ goto error;
+ }
+done:
+ return (0);
+
+no_mem:
+ if (errno == ENOMEM)
+ syslog(LOG_ERR, "calloc failed");
+ syslog(LOG_ERR, "NO MEM");
+ return (-1);
+
+error:
+ free(pargv[3]);
+ syslog(LOG_ERR, "ERROR RETURNING -1");
+ return (-1);
+}
+

PS: I have used this for a little pocket money ISP for three years now
along side a custom sqlite db for authentication on web, scraping
zeroed users in pf is the way to go with a cron job.


On 10/06/2015 07:43 AM, C. L. Martinez wrote:

On Mon, Oct 5, 2015 at 1:26 PM, laudarch  wrote:

I made a custom implementation and a diff to authpf, will share that
later just in case anyone wants it.

I hope this helps you, it pretty simple
http://bastienceriani.fr/?p=70



Thanks laudarch ... Very close to what I am searching... I will try 
your config.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

you missed my update which followed that post. it did not survive the night
- even with lm disabled in the kernel, some number of reboots later i
encountered the same failure. that update is on the list, but i'll include
the copy/paste below.

meanwhile, is there still hope for answers relating to acpi?

-- Forwarded message --
From: Dewey Hylton 
To: misc@openbsd.org
Cc:
Date: Tue, 15 Sep 2015 19:19:10 + (UTC)
Subject: Re: requesting help working around boot failures with supermicro
atom board
Dewey Hylton  gmail.com> writes:

>
> Mark Kettenis  xs4all.nl> writes:

> > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > your kernel?  You can do:
> >
> > # config -ef /bsd
> > ...
> > ukc> disable lm
> > 254 lm0 disabled
> > 255 lm* disabled
> > 256 lm* disabled
> > ukc> quit
> > Saving modified kernel.
> > # reboot
> >
> > That reboot will probably still hang.  But it'd be interesting to see
> > if any subsequent reboots work better.
>


sadly, the first thing i heard when entering the lab this morning was
BEP!

so disabling the sensor drivers in the kernel did not do the trick. without
other ideas, i'm down to providing acpidump output and hoping someone can
tell me where to go next ...


On Wed, Oct 7, 2015 at 12:41 AM, Mike Larkin  wrote:

> On Tue, Sep 15, 2015 at 02:45:02AM +, Dewey Hylton wrote:
> > Mark Kettenis  xs4all.nl> writes:
> >
> > >
> > > > # sysctl -a|grep 'sensors.*temp'
> > > > hw.sensors.cpu0.temp0=30.00 degC
> > > > hw.sensors.lm1.temp0=0.00 degC
> > > > hw.sensors.lm1.temp1=14.00 degC
> > > > hw.sensors.lm1.temp2=14.00 degC
> > > > # reboot
> > > >
> > > > BEEEP!
> > >
> > > Oh that is interesting.  Can you try disabling the lm(4) driver in
> > > your kernel?  You can do:
> > >
> > > # config -ef /bsd
> > > ...
> > > ukc> disable lm
> > > 254 lm0 disabled
> > > 255 lm* disabled
> > > 256 lm* disabled
> > > ukc> quit
> > > Saving modified kernel.
> > > # reboot
> > >
> > > That reboot will probably still hang.  But it'd be interesting to see
> > > if any subsequent reboots work better.
> >
> > *this* interests me, and was basically what i was asking in the original
> > post - except i had no idea what might need to be disabled. one step at a
> > time, it's been interesting the things that have popped up.
> >
> > still no idea whether this has anything to do with the seemingly
> > openbsd-only issue, but ...
> >
> > i made this change, booted the new kernel, ran 'cksum /dev/mem' a bunch
> of
> > times in hopes of raising the temperature somewhat (did get to 36C,
> which is
> > higher than in my previous tests). then i rebooted, and the box came
> back up
> > without incident.
> >
> > so i'm going to run through this several times with reboots in every 20
> > minutes or so and see if it survives the night.
> >
>
> Based on this and my previous email, my recommendation would be to disable
> lm(4) on this particular machine.

httpd syscall 72

[Scott Vanderbilt]

Running latest snapshot (amd64), I get a 'sycall 72' message when 
attempting to start httpd, e.g.:


httpd(10043): syscall 72

I'm pretty sure this started with snapshots after Sept. 27.

Might anyone have an idea where I can start to look for the problem?

Thanks.

# /etc/rc.d/httpd start
httpd(ok)
# tail /var/log/daemon | grep httpd
Oct  7 12:07:45 aeneas httpd[12798]: startup
Oct  7 12:07:45 aeneas httpd[17646]: server exiting, pid 17646
Oct  7 12:07:45 aeneas httpd[12212]: server exiting, pid 12212
Oct  7 12:07:45 aeneas httpd[10633]: server exiting, pid 10633
Oct  7 12:07:45 aeneas httpd[12798]: parent terminating, pid 12798
#
# httpd -nvd
configuration OK
#
# cat /etc/httpd.conf
ext_ip="162.229.163.201"
server "default" {
listen on $ext_ip port 80
#listen on $ext_ip tls port 443
}
#
# httpd -vvvd
startup
socket_rlimit: max open files 1024
server_privinit: adding server default
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
server exiting, pid 27705
server exiting, pid 24831
server exiting, pid 2216
parent terminating, pid 13942
#
# dmesg
OpenBSD 5.8-current (GENERIC.MP) #1437: Wed Oct  7 09:59:34 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4186652672 (3992MB)
avail mem = 4055646208 (3867MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe92a0 (93 entries)
bios0: vendor American Megatrends Inc. version "0402" date 07/18/2011
bios0: ASUSTeK Computer INC. P8H61-M LX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET
acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) BR20(S3) EUSB(S4) 
P0P3(S4) P0P4(S4) P0P1(S4) P0P2(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) 
PEX4(S4) PEX5(S4) PEX6(S4) [...]

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) Celeron(R) CPU G530 @ 2.40GHz, 2394.95 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU G530 @ 2.40GHz, 2394.56 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P3)
acpiprt2 at acpi0: bus -1 (P0P4)
acpiprt3 at acpi0: bus 1 (P0P1)
acpiprt4 at acpi0: bus -1 (P0P2)
acpiprt5 at acpi0: bus 2 (PEX0)
acpiprt6 at acpi0: bus 3 (PEX1)
acpiprt7 at acpi0: bus 4 (PEX2)
acpiprt8 at acpi0: bus 6 (PEX4)
acpicpu0 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), 
C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), 
C1(1000@1 halt), PSS

acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 
1900, 1800, 1700, 1600 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x05: msi
azalia0: codecs: Realtek/0x0887
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: msi
pci2 at ppb1 bus 2
"Realtek RTL8192CE" rev 0x01 at pci2 dev 0 function 0 not configured
ppb2 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb5: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 2 "Intel 6 Series PCIE" rev 0xb5: msi
pci4 at ppb3 bus 4
re0 at pci4 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E-VL 
(0x2c80), msi, address 14:da:e9:b7:15:30

rgephy0 at re0 phy 7: 

Re: unbreak trunk(4)

[Stefan Wollny]

Am 10/07/15 um 15:47 schrieb Mike Belopuhov:
> On Wed, Oct 07, 2015 at 15:41 +0200, Mike Belopuhov wrote:
>> Hi,
>>
>> If you have noticed recent problems with trunk(4) please try the
>> diff below as it fixes a subtle issue (not introduced by my changes!)
>> with setting lladdr on non primary trunk ports: trunk_port_ioctl
>> needs to be able to lookup the trunk port, but we didn't put it on
>> the list yet, doh!
>>
>> OK's are welcome as well.
>>
> 
> boo hoo, it clashes with some uncommitted changes, here's a rebased version.
> 
> 
> diff --git sys/net/if_trunk.c sys/net/if_trunk.c
> index 8678fe4..2aaa339 100644
> --- sys/net/if_trunk.c
> +++ sys/net/if_trunk.c
> @@ -358,18 +358,18 @@ trunk_port_create(struct trunk_softc *tr, struct ifnet 
> *ifp)
>   tr->tr_primary = tp;
>   tp->tp_flags |= TRUNK_PORT_MASTER;
>   trunk_lladdr(>tr_ac, tp->tp_lladdr);
>   }
>  
> - /* Update link layer address for this port */
> - trunk_port_lladdr(tp,
> - ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
> -
>   /* Insert into the list of ports */
>   SLIST_INSERT_HEAD(>tr_ports, tp, tp_entries);
>   tr->tr_count++;
>  
> + /* Update link layer address for this port */
> + trunk_port_lladdr(tp,
> + ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
> +
>   /* Update trunk capabilities */
>   tr->tr_capabilities = trunk_capabilities(tr);
>  
>   /* Add multicast addresses to this port */
>   trunk_ether_cmdmulti(tp, SIOCADDMULTI);
> 
Hi Mike,

I am sorry to report, but still no connection on startup, but after
login 'doas sh /etc/netstart' is doing fine.

(I applied both patches.)

OpenBSD 5.8-current (GENERIC.MP) #1255: Tue Oct  6 13:56:04 MDT 2015

Do you want the output of '!/sbin/ifconfig -A >/root/ifconfig.out 2>&1'
again?

Any other info needed?

Best,
STEFAN

Re: requesting help working around boot failures with supermicro atom board

[lists]

Tue, 6 Oct 2015 21:41:15 -0700 Mike Larkin 
> I had thought this was acpi related earlier (before we realized that disabling
> lm* fixes it). So I have no news here, as I don't think the solution is going
> to be found in the AML.

Thanks for the update and pointer in the right direction (regarding
disabling lm(4) sensor). Indeed this does not happen with bsd.rd during
upgrades, and I recall back in the day this issue may not have been
originally present back in 2011.

> The lm(4) sensor is probably getting wedged somehow, which is causing the bios
> to think the machine is too hot on reboot. Even though it's not.

Makes sense as the readings are improbable after running for a while
and things looks stuck somehow, including in the BMC web interface.

Side note: I know, just don't sway to the insane design flaws regarding
security and interfaces, there are popcorn scary topics on the list,
now stay on topic pls.

Here is the reading from a long run where the sensors appear stuck both
on the shell and in the BMC:

$ sysctl hw.sensors
hw.sensors.cpu0.temp0=33.00 degC
hw.sensors.lm1.temp0=-1.00 degC
hw.sensors.lm1.temp1=-0.50 degC
hw.sensors.lm1.temp2=-0.50 degC
hw.sensors.lm1.volt0=2.04 VDC (VCore)
hw.sensors.lm1.volt1=13.46 VDC (+12V)
hw.sensors.lm1.volt2=4.08 VDC (+3.3V)
hw.sensors.lm1.volt3=4.08 VDC (+3.3V)
hw.sensors.lm1.volt4=1.85 VDC (-12V)
hw.sensors.lm1.volt5=0.00 VDC
hw.sensors.lm1.volt6=0.00 VDC
hw.sensors.lm1.volt7=4.08 VDC (3.3VSB)
hw.sensors.lm1.volt8=2.04 VDC (VBAT)
$

And again after resetting the IPMI device these look only incorrect at
some readings, but not as stuck as above:

$ sysctl hw.sensors 
hw.sensors.cpu0.temp0=33.00 degC
hw.sensors.lm1.temp0=41.00 degC
hw.sensors.lm1.temp1=42.00 degC
hw.sensors.lm1.temp2=26.00 degC
hw.sensors.lm1.volt0=1.10 VDC (VCore)
hw.sensors.lm1.volt1=6.86 VDC (+12V)
hw.sensors.lm1.volt2=3.33 VDC (+3.3V)
hw.sensors.lm1.volt3=3.33 VDC (+3.3V)
hw.sensors.lm1.volt4=-10.34 VDC (-12V)
hw.sensors.lm1.volt5=1.28 VDC
hw.sensors.lm1.volt6=1.82 VDC
hw.sensors.lm1.volt7=3.28 VDC (3.3VSB)
hw.sensors.lm1.volt8=1.57 VDC (VBAT)


> I don't know a lot about the lm(4) driver so I don't think I'll be able to
> help much here. One of the things I do know about it is that sometimes you
> don't actually even have a real lm(4), and that it's simulated by some other
> component or even SMM. Maybe the manufacturer did a poor job. Shrug.

Please compare the above with the values presented in the BMC web
interface:

NameStatus  Reading
System Temp Normal  41 degrees C
CPU TempNormal  42 degrees C
CPU FAN N/A Not Present!
SYS FAN N/A Not Present!
CPU Vcore   Normal  1.096 Volts
VichcoreNormal  1.04 Volts
+3.3VCC Normal  3.328 Volts
VDIMM   Normal  1.528 Volts
+5 VNormal  5.12 Volts
+12 V   Normal  12.084 Volts
+3.3VSB Normal  3.28 Volts
VBATNormal  3.136 Volts
Chassis Intru   OK
PS Status   Presence detected.

Here is from the ipmitool over the network:

$ ipmitool -I lanplus -U musr1 -f .ipmipass -H 10.10.10.10 sdr 
System Temp  | 41 degrees C  | ok
CPU Temp | 42 degrees C  | ok
CPU FAN  | no reading| ns
SYS FAN  | no reading| ns
CPU Vcore| 1.10 Volts| ok
Vichcore | 1.04 Volts| ok
+3.3VCC  | 3.33 Volts| ok
VDIMM| 1.54 Volts| ok
+5 V | 5.12 Volts| ok
+12 V| 12.08 Volts   | ok
+3.3VSB  | 3.28 Volts| ok
VBAT | 3.14 Volts| ok
Chassis Intru| 0x00  | ok
PS Status| 0x00  | ok
$

Same thing with mode details and thresholds (untouched from defaults,
for reference only where the lm(4) sensor may be getting some of the
funny values):

$ ipmitool -I lanplus -U musr1 -f .ipmipass -H 10.10.10.10 sensor 
System Temp  | 42.000 | degrees C  | ok| -9.000| -7.000| 
-5.000| 75.000| 77.000| 79.000
CPU Temp | 42.000 | degrees C  | ok| -11.000   | -8.000| 
-5.000| 85.000| 90.000| 95.000
CPU FAN  | na || na| na| na| na 
   | na| na| na
SYS FAN  | na || na| na| na| na 
   | na| na| na
CPU Vcore| 1.096  | Volts  | ok| 0.640 | 0.664 | 
0.688 | 1.344 | 1.408 | 1.472 
Vichcore | 1.040  | Volts  | ok| 0.808 | 0.824 | 
0.840 | 1.160 | 1.176 | 1.192 
+3.3VCC  | 3.328  | Volts  | ok| 2.816 | 2.880 | 
2.944 | 3.584 | 3.648 | 3.712 
VDIMM| 1.528  | Volts  

unbreak trunk(4)

[Mike Belopuhov]

Hi,

If you have noticed recent problems with trunk(4) please try the
diff below as it fixes a subtle issue (not introduced by my changes!)
with setting lladdr on non primary trunk ports: trunk_port_ioctl
needs to be able to lookup the trunk port, but we didn't put it on
the list yet, doh!

OK's are welcome as well.

diff --git sys/net/if_trunk.c sys/net/if_trunk.c
index a97741a..9a3dbb5 100644
--- sys/net/if_trunk.c
+++ sys/net/if_trunk.c
@@ -356,18 +356,18 @@ trunk_port_create(struct trunk_softc *tr, struct ifnet 
*ifp)
tr->tr_primary = tp;
tp->tp_flags |= TRUNK_PORT_MASTER;
trunk_lladdr((struct ifnet *)>tr_ac, tp->tp_lladdr);
}
 
-   /* Update link layer address for this port */
-   trunk_port_lladdr(tp,
-   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
-
/* Insert into the list of ports */
SLIST_INSERT_HEAD(>tr_ports, tp, tp_entries);
tr->tr_count++;
 
+   /* Update link layer address for this port */
+   trunk_port_lladdr(tp,
+   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
+
/* Update trunk capabilities */
tr->tr_capabilities = trunk_capabilities(tr);
 
/* Add multicast addresses to this port */
trunk_ether_cmdmulti(tp, SIOCADDMULTI);

Re: unbreak trunk(4)

[Mike Belopuhov]

On Wed, Oct 07, 2015 at 15:41 +0200, Mike Belopuhov wrote:
> Hi,
> 
> If you have noticed recent problems with trunk(4) please try the
> diff below as it fixes a subtle issue (not introduced by my changes!)
> with setting lladdr on non primary trunk ports: trunk_port_ioctl
> needs to be able to lookup the trunk port, but we didn't put it on
> the list yet, doh!
> 
> OK's are welcome as well.
> 

boo hoo, it clashes with some uncommitted changes, here's a rebased version.


diff --git sys/net/if_trunk.c sys/net/if_trunk.c
index 8678fe4..2aaa339 100644
--- sys/net/if_trunk.c
+++ sys/net/if_trunk.c
@@ -358,18 +358,18 @@ trunk_port_create(struct trunk_softc *tr, struct ifnet 
*ifp)
tr->tr_primary = tp;
tp->tp_flags |= TRUNK_PORT_MASTER;
trunk_lladdr(>tr_ac, tp->tp_lladdr);
}
 
-   /* Update link layer address for this port */
-   trunk_port_lladdr(tp,
-   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
-
/* Insert into the list of ports */
SLIST_INSERT_HEAD(>tr_ports, tp, tp_entries);
tr->tr_count++;
 
+   /* Update link layer address for this port */
+   trunk_port_lladdr(tp,
+   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
+
/* Update trunk capabilities */
tr->tr_capabilities = trunk_capabilities(tr);
 
/* Add multicast addresses to this port */
trunk_ether_cmdmulti(tp, SIOCADDMULTI);

Bulkget & snmpd

[Denis Fondras]

Hello,

I'm using snmpd from base on 5.8 and while playing with snmpbulkget (from
net-snmp), I noticed a weirdness.

* 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.1' is ok
* 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1' is ok

By "ok", I mean it returns the correct MIB results. However,

* 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1
 iso.3.6.1.2.1.1' is not ok :
-8<-
 iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "em0"
 iso.3.6.1.2.1.1.1.0 = STRING: "OpenBSD test.my.domain 5.8 GENERIC#3 i386"
 iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.30155.23.1
 iso.3.6.1.2.1.1.3.0 = Timeticks: (217) 0:00:02.17
 iso.3.6.1.2.1.1.4.0 = STRING: "r...@test.my.domain"
 iso.3.6.1.2.1.1.5.0 = STRING: "test.my.domain"
 iso.3.6.1.2.1.1.6.0 = ""
 iso.3.6.1.2.1.1.7.0 = INTEGER: 74
 iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
 iso.3.6.1.2.1.1.9.1.1.1 = INTEGER: 1
 iso.3.6.1.2.1.1.9.1.1.2 = INTEGER: 2
-8<-

As you can see, only the first sub-OID of iso.3.6.1.2.1.31.1.1 is returned.
It seems that the loop surrounding mps_getbulkreq() in snmpe.c is breaking
the return of multiple OIDs but I can't find where exactly lies the bug.

Can anyone help ?

TIA,
Denis

Re: CD's arrived

[Theo de Raadt]

> CD's arrived today UK. Thanks again.

A note all all who are receiving their CDs before the official release
day.

We are opening up 5.8/packages on the download mirrors today, so that
people receiving the release early can install packages.

The rest of the 5.8 release files will come out on release day.

CD's arrived

[M Wheeler]

CD's arrived today UK. Thanks again.

Re: CD's arrived

[Raf Czlonka]

On Wed, Oct 07, 2015 at 03:51:28PM BST, M Wheeler wrote:

> CD's arrived today UK. Thanks again.

Got mine today, too :^)

Raf

Re: "dd if=/dev/srandom of=/dev/wd0e bs=1024 count=1" WIPES my wd0 disklabel. Is this intended, bug, how come, how workaround ??? Incl reproduction script+console output+dmesg

[Mikael]

Thanks everyone for clarifying that the sectors 0 to 79 should be
considered reserved on OpenBSD MBR partitions (and thus within the context
of the "disklabel" tool).


There is just one thing I don't understand now, and that is what
dysfunction-potential there is in inappropriate handling of sectors 64 to
79.

I'll specify my Q below - so what do you say?

Last, I agree that the concept of "binary blob partitions" is slightly
archaic, but not by any standards obsolete.

Probably the most common blob-level use of partitions you do would be
"dd"-based backuping - and we learned here now, that restoring such a
partition backup could trash the disklabel if it started at less than
offset = 512 * 8 !

Thanks



*Impression:*
Based on what Benny and I think someone else said, I got an approximative
impression something like that the whole disklabelling system is actually
designed with the intention that every disklabel is required to

1) Have an "a" partition that
2) Starts on sector 64 and continues at least up to and including sector 79
and
2) Be of the 4.2BSD or RAID type,

Because otherwise something bad happens.

*Example, for clarity:*
I mean, if on an 999-sector disk where I want to put an 9-sector
binary blob in its own partition, and then give all the remaining space to
a "main" UFS-partition, if it wasn't for this conversation I'd just have
gone into the "disklabel" tool, wipe the disklabel and then first have
added my blob partition at the beginning of the disk and then the "main"
partition after it (i.e. blob partition would be sectors 64 to 100063 and
the UFS partition would be sectors 100064 to 998).

This conversation shows that the binary blob partition should be put at
sectors >= 80 (i.e. sector 80 to 100078 would have worked for it, so then
the UFS partition at sectors 100079 to 998), BUT,

Because of what possible dysfunction is it that I should put the UFS
partition in the beginning and the binary blob partition after it (i.e. UFS
partition on sector 64 to 981, and blob partition on sector 990 to
998)?


2015-10-07 2:48 GMT+08:00 Benny Lofgren :
...

> If you place a 4.2BSD or a RAID partition from the first sector (64) of
> the BSD usable part of the disk (as limited by the "boundstart" and
> "boundend" disklabel parameters) you will never get in trouble. Anything
> else and you need to know more about the system internals to be safe.
>
> You ask about saved butts. Just a couple of example scenarios:
>
> Consider the option to encasing the partition metadata in the first
> partition (and again, first physical address-wise, not first partition
> letter-wise), which is to leave a gap in the beginning: First of all,
> I'm not even sure the boot code is able to cope with that scenario, but
> let's say it is. Whenever you want to add a new partition, disklabel
> will suggest you populate the first free area on your disk - guess where
> that is going to be...
>
> If you wreck your disklabel and have done something non-standard, such
> as move the first partition from its expected position, you're pretty
> much in the dark when it comes to actually *find*, not to mention
> hopefully recover, your partitions.
>
> It is well known and understood since decades what's on these first
> sectors of a) a disk, b) of the BSD usable area and c) of each partition
> (type). Why are you having trouble accepting that things are the way
> they are and that they WORK as they are, if you don't turn everything on
> its head? Well, at least they work until you start messing with things
> you have not yet had any experience with. The upside is you'll quickly
> gain useful experience, of how not to do. :-)

Re: bgpd not starting since Oct 5 snapshot (tame related?)

[Theo de Raadt]

> I noticed that my bpgd is down after the reboot with the following new
> messages in dmesg:
> 
> bgpd(13184): sysctl 6: 4 17 0 0 3 0
> bgpd(13184): syscall 202

Please ktrace -di it.  I suspect this is ICMPV6CTL_MTUDISC_LOWAT,
I'll look into it and add it once I determine it is safe in tame.

bgpd not starting since Oct 5 snapshot (tame related?)

[Adam Wolk]

Hi misc@,

I noticed that my bpgd is down after the reboot with the following new
messages in dmesg:

bgpd(13184): sysctl 6: 4 17 0 0 3 0
bgpd(13184): syscall 202


The message appears on boot:

starting network daemons: sshd bgpd ssmtpdbgpd(13184): sysctl 6: 4 17 0
0 3 0
bgpd(13184) syscall 202
 httpd sndiod.
starting package daemons: .

No more appearances after the bootup sequence.

kern.version=OpenBSD 5.8-current (GENERIC) #1332: Mon Oct  5 01:01:28
MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Previous snapshot I used was from September 24th and I didn't notice
that message. Though I might have missed it since I disabled spamd a
while ago which was the only reason bgpd is running on this host
(synchronizing white-listed hosts).

Though rc.conf.local still contains:
bgpd_flags=""

Regards,
Adam