Re: ftp(1) fails when HTTP redirected to a relative URI containing the string "://"

[Stuart Henderson]

On 2016/01/08 14:04, Lauri Tirkkonen wrote:
> On Wed, Dec 30 2015 11:26:48 +0200, Lauri Tirkkonen wrote:
> > >Synopsis:  ftp(1) fails when HTTP redirected to a relative URI containing 
> > >the string "://"
> 
> > >Fix:
> > Patch attached.
> 
> No takers?

The problem is valid, but the diff doesn't go far enough, it needs
an additional check to avoid breaking currently-working cases.

Before patching:

$ ftp -Mo- https://junkpile.org/redir-to-colon
Trying 195.95.187.26...
Requesting https://junkpile.org/redir-to-colon
Redirected to https://junkpile.org/test:file.txt
Trying 195.95.187.26...
Requesting https://junkpile.org/test:file.txt
testing...
11 bytes received in 0.00 seconds (44.02 KB/s)

After:

$ obj/ftp -Mo- https://junkpile.org/redir-to-colon
Trying 195.95.187.26...
Requesting https://junkpile.org/redir-to-colon
Redirected to test:file.txt
ftp: url_get: Invalid URL 'test:file.txt'

This is a contrived test, but there are definitely URLs in the
wild containing : and it wouldn't be entirely unexpected to see
a relative redirect to them.

Re: ftp(1) fails when HTTP redirected to a relative URI containing the string "://"

[Stuart Henderson]

On 2016/01/08 14:55, Lauri Tirkkonen wrote:
> On Fri, Jan 08 2016 12:43:59 +0000, Stuart Henderson wrote:
> > On 2016/01/08 14:04, Lauri Tirkkonen wrote:
> > > On Wed, Dec 30 2015 11:26:48 +0200, Lauri Tirkkonen wrote:
> > > > >Synopsis:  ftp(1) fails when HTTP redirected to a relative URI 
> > > > >containing the string "://"
> > > 
> > > > >Fix:
> > > > Patch attached.
> > > 
> > > No takers?
> > 
> > The problem is valid, but the diff doesn't go far enough, it needs
> > an additional check to avoid breaking currently-working cases.
> > 
> > Before patching:
> > 
> > $ ftp -Mo- https://junkpile.org/redir-to-colon
> > Trying 195.95.187.26...
> > Requesting https://junkpile.org/redir-to-colon
> > Redirected to https://junkpile.org/test:file.txt
> > Trying 195.95.187.26...
> > Requesting https://junkpile.org/test:file.txt
> > testing...
> > 11 bytes received in 0.00 seconds (44.02 KB/s)
> > 
> > After:
> > 
> > $ obj/ftp -Mo- https://junkpile.org/redir-to-colon
> > Trying 195.95.187.26...
> > Requesting https://junkpile.org/redir-to-colon
> > Redirected to test:file.txt
> > ftp: url_get: Invalid URL 'test:file.txt'
> > 
> > This is a contrived test, but there are definitely URLs in the
> > wild containing : and it wouldn't be entirely unexpected to see
> > a relative redirect to them.
> 
> I was following RFC 3986 which states that relative-path segments
> containing a colon cannot be used as the first segment [0].
> 
> [0]: https://tools.ietf.org/html/rfc3986#section-4.2

Ah, thanks for pointing that out. In which case, I think we
should refer to the RFC (and use KNF style for the multi-line
comment). While there, I'd like to add an XXX comment that
we don't handle // redirects.

Any OKs to commit this?

Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.143
diff -u -p -r1.143 fetch.c
--- fetch.c 13 Oct 2015 08:53:43 -  1.143
+++ fetch.c 8 Jan 2016 13:13:42 -
@@ -833,10 +833,15 @@ again:
} else if (isredirect &&
strncasecmp(cp, LOCATION, sizeof(LOCATION) - 1) == 0) {
cp += sizeof(LOCATION) - 1;
-   if (strstr(cp, "://") == NULL) {
+   /*
+* If there is a colon before the first slash, this URI
+* is not relative. RFC 3986 4.2
+*/
+   if (cp[strcspn(cp, ":/")] != ':') {
 #ifdef SMALL
errx(1, "Relative redirect not supported");
 #else /* SMALL */
+   /* XXX doesn't handle protocol-relative URIs */
if (*cp == '/') {
locbase = NULL;
cp++;

Re: kernel panic with SP kernel

[Stuart Henderson]

On 2016/01/13 15:01, timo.my...@wickedbsd.net wrote:
> >Synopsis:kernel panics after some time of normal operation
> >Category:kernel
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9-beta (GENERIC) #1679: Fri Jan  8 23:44:41 MST 
> 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After booting GENERIC gernel and running it for a while, the kernel 
> panics with following:
>   
>   kernel: protection fault trap, code=0
>   Stopped at _bpf_mtap+0x50: movl 0x18(%rdx),%eax
>   ddb> trace
>   _bpf_mtap() at _bpf_mtap+0x50
>   bpf_mtap_ether() at bpf_mtap_ether+0x39
>   em_start() at em_start+0xa7

Some em(4) issues were fixed after the snapshot you're running was built.

Please update and report back if it still occurs.

Re: kernel panic when booting MP kernel

[Stuart Henderson]

On 2016/01/13 15:23, Stefan Sperling wrote:
> This is the real fix, for all drivers.
> I messed this up while removing turbo mode.

Aargh, I read and re-read those lines in particular and didn't spot it!

So compared to the "pre turbo removal" code it's essentially this:

@@ -767,13 +750,10 @@ ieee80211_setmode(struct ieee80211com *i
for (i = 0; i <= IEEE80211_CHAN_MAX; i++) {
c = &ic->ic_channels[i];
if (mode == IEEE80211_MODE_AUTO) {
-   /* ignore turbo channels for autoselect */
-   if ((c->ic_flags &~ IEEE80211_CHAN_TURBO) != 0)
+   if (c->ic_flags != 0)
break;
} else if ((c->ic_flags & modeflags) == modeflags)
break;
}
if (i > IEEE80211_CHAN_MAX) {
DPRINTF(("no channels found for mode %u\n", mode));
@@ -787,13 +767,10 @@ ieee80211_setmode(struct ieee80211com *i
for (i = 0; i <= IEEE80211_CHAN_MAX; i++) {
c = &ic->ic_channels[i];
if (mode == IEEE80211_MODE_AUTO) {
-   /* take anything but pure turbo channels */
-   if ((c->ic_flags &~ IEEE80211_CHAN_TURBO) != 0)
+   if (c->ic_flags != 0)
setbit(ic->ic_chan_active, i);
} else if ((c->ic_flags & modeflags) == modeflags)
setbit(ic->ic_chan_active, i);
}



This looks correct to me.

Re: installer amd64 'Get/Verify bsd' -> 'Illegal instruction' - shuttle ds47d

[Stuart Henderson]

On 2016/01/27 20:10, Stefan Kempf wrote:
> So what I suspect to happen is that: 
> - userland does a syscall
> - something goes wrong in the kernel, causing it to call
>   sigexit(SIGILL), terminating the process
> - and the offending instruction you see in the core dump
>   is the 'syscall' instruction.

If this is the case, perhaps ktrace will give clues.

Re: cannot connect to mirrors

[Stuart Henderson]

On 2016/01/27 22:27, Herminio Hernandez, Jr. wrote:
> I cannot install packages using pkg_add as root. I am getting a no
> route to host error. However I can ping the mirror so I know I have ip
> connectivity. I tried using curl to get a package from the mirror and
> that failed as well. Below are the commands I ran.
> 
> # pkg_add ddrescue
> Error from http://mirror.esc7.net/pub/OpenBSD/5.8/packages/amd64/
> ftp: connect: No route to host

Is the packet blocked by a firewall, possibly PF on the host you're
running it on?

Re: panic with soekris net5501 on OpenBSD 5.9-beta (GENERIC) #1536: Thu Jan 28 20:18:35 MST 2016

[Stuart Henderson]

On 2016/01/29 16:57, Lars Noodén wrote:
> I'm getting frequent panics from the snapshot OpenBSD 5.9-beta
> (GENERIC) #1536: Thu Jan 28 20:18:35 MST 2016 on a Soekris Net5501.
> 
> It seems to happen when I connect physically via ethernet.  Normally I
> have dhcpd running but even if I kill that first, just plugging the
> cable in seems to cause the panic.   Below are console output, ddb
> trace, ddb ps and the dmesg.

I'm not sure exactly which code is in current snaps, please build
a new kernel from up-to-date current source and see if it recurs.


> Regards,
> Lars
> 
> # panic: kernel diagnostic assertion "pd.m->m_pkthdr.pf.statekey ==
> NULL" failed: file "../../../../net/pf.c", line 6569
> Stopped at  Debugger+0x7:   leave
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *18936  18936  0 0x14000  0x2100  softnet
> Debugger(d09feb68,f523fd14,d09d9764,f523fd14,d6057b00) at Debugger+0x7
> panic(d09d9764,d0957746,d09cf8c8,d09cf988,19a9) at panic+0x71
> __assert(d0957746,d09cf988,19a9,d09cf8c8,0) at __assert+0x2e
> pf_test(2,1,d1abd800,f523fe90,d0b56680) at pf_test+0xf2d
> ipv4_input(d6057b00,d0203028,60,f523fecc,d041c580) at ipv4_input+0x23e
> ipintr(d041c580,56ab7825,0,f523fec8,d177cbc0) at ipintr+0x16
> netintr(0,d0b56680,d5e01700,f523ff0c,d03b8482) at netintr+0x62
> softintr_dispatch(1) at softintr_dispatch+0x5a
> Xsoftnet() at Xsoftnet+0x12
> --- interrupt ---
> uvm_fault(0xd0bbe100, 0x0, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  db_read_bytes+0x17: movzbl  0(%esi,%ecx,1),%eax
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *18936  18936  0 0x14000  0x2100  softnet
> db_read_bytes(3,4,f523fae8,d0b52180,) at db_read_bytes+0x17
> db_get_value(3,4,0,d03cbe95,d09feb68) at db_get_value+0x38
> db_numargs(,f523fb80,0,3,d03cbe70) at db_numargs+0x24
> db_stack_trace_print(d0558f07,0,5,d09cb91a,d03cbe70) at 
> db_stack_trace_print+0x
> 3a7
> db_trap(1,0,58,a,5) at db_trap+0xd2
> kdb_trap(1,0,f523fc78,f523fcd4,0) at kdb_trap+0xcc
> trap() at trap+0x2a5
> --- trap (number 1) ---
> Bad frame pointer: 0xd09d9764
> "net5501.dhcp.inet.fi" 16:32 29-Jan-16
> 0:
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> 
> ddb> trace
> db_read_bytes(3,4,f523fae8,d0b52180,) at db_read_bytes+0x17
> db_get_value(3,4,0,d03cbe95,d09feb68) at db_get_value+0x38
> db_numargs(,f523fb80,0,3,d03cbe70) at db_numargs+0x24
> db_stack_trace_print(d0558f07,0,5,d09cb91a,d03cbe70) at 
> db_stack_trace_print+0x
> 3a7
> db_trap(1,0,58,a,5) at db_trap+0xd2
> kdb_trap(1,0,f523fc78,f523fcd4,0) at kdb_trap+0xcc
> trap() at trap+0x2a5
> --- trap (number 1) ---
> Bad frame pointer: 0xd09d9764
> 0:
> 
> ddb> ps
>TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
>  23954  30431  23954   1000  30x100083  ttyin ksh
>  30431   8219   8219   1000  30x90  selectsshd
>   8219   6698   8219  0  30x92  poll  sshd
>  26385  15218  26385  0  30x100083  ttyin ksh
>  15218  1  15218  0  30x100080  kqreadtmux
>   3685   7798   3685  0  30x100083  kqreadtmux
>   7798  1   7798  0  30x10008b  pause ksh
>   5022  1   5022  0  30x100098  poll  cron
>  22234  12425  12425 74  30x100090  bpf   pflogd
>  12425  1  12425  0  30x80  netio pflogd
>  26320  1  26320  0  30x100080  poll  ntpd
>  10186   6497  10186 83  30x100090  poll  ntpd
>   6497  1   6497 83  30x100090  poll  ntpd
>   8180  1   8180 77  30x100090  poll  dhclient
>  20082  1  20082  0  30x80  poll  dhclient
>   3112  1   3112 99  30x100090  poll  sndiod
>  30808  1  30808110  30x100090  poll  sndiod
>  15178  1  15178109  30x90  kqreadftp-proxy
>988   2777   2777 95  30x100090  kqreadsmtpd
>603   2777   2777 95  30x100090  kqreadsmtpd
>  17455   2777   2777 95  30x100090  kqreadsmtpd
>  24674   2777   2777 95  30x100090  kqreadsmtpd
>  19851   2777   2777 95  30x100090  kqreadsmtpd
>   2160   2777   2777103  30x100090  kqreadsmtpd
>   2777  1   2777  0  30x100080  kqreadsmtpd
>   1609  1   1609 77  30x100090  poll  dhcpd
>   6698  1   6698  0  30x80  selectsshd
>   6268  11201  11821 83  30x100090  poll  ntpd
>  11201  11821  11821 83  30x100090  poll  ntpd
>  11821  1  11821  0  30x100080  poll  ntpd
>  24477  30672  30672 74  30x100090  bpf   pflogd
>  30672  1  30672  0  30x80  netio

Re: panic: kernel diagnostic assertion "pd.m->m_pkthdr.pf.statekey == NULL" failed

[Stuart Henderson]

Replying to Paul's post and adding CCs, but Lars' post is also related
http://marc.info/?l=openbsd-bugs&m=145409292029625&w=2

Lars, and anyone else seeing this, what interface types do you have?
Any tunnels (gif gre tun vxlan, etc.) or anything else out of the ordinary
(bridges? don't know what else..)?

On 2016/01/30 01:09, Paul de Weerd wrote:
> I've just confirmed this still happens with the latest snap (OpenBSD
> 5.9-beta (GENERIC.MP) #1865: Thu Jan 28 20:18:15 MST 2016) and with a
> kernel built from the latest sources (checkout from less than an hour
> ago).
> 
> 
> panic: kernel diagnostic assertion "pd.m->m_pkthdr.pf.statekey == NULL" 
> failed: file "../../../../net/pf.c", line 6569
> Stopped at  Debugger+0x9:   leave
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> * 4209   4209  0 0x14000  0x2102  softnet
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> __assert() at __assert+0x25
> pf_test() at pf_test+0xe26
> ipv4_input() at ipv4_input+0x240

So this is the code by the assert

6563 if (pd.dir == PF_IN && s && s->key[PF_SK_STACK]) {
6564 /*
6565  * ASSERT() below fires whenever caller forgets to call
6566  * pf_pkt_addr_changed(). This might happen when we deal 
with
6567  * IP tunnels.
6568  */
6569 KASSERT(pd.m->m_pkthdr.pf.statekey == NULL);
6570 pd.m->m_pkthdr.pf.statekey =
6571 pf_state_key_ref(s->key[PF_SK_STACK]);
6572 }

and pf_pkt_addr says

/*
 * must be called whenever any addressing information such as
 * address, port, protocol has changed
 */

ipv4_input isn't changing the packet address but maybe the 'IP tunnels'
comment is relevant, since I see openvpn is running on Paul's machine
which is going to either use tun(4) or tap(4).

However it is not running on Lars' machine.

igmpproxy is also running on Paul's so I am assuming there are likely to
be multicast packets floating around, probably with ip options. Don't
know if that is relevant.

We could do with figuring out what packets are triggering this.
Something like this before the KASSERT maybe,

if (pd.m->m_pkthdr.pf.statekey != NULL)
printf("mbuf 0x%p\n", pd.m);

then "show mbuf 0x(addr)" in ddb...?

I have not yet run into this assert myself - I am running the 28 Jan
snapshot with vlan carp pppoe ipsec trunk..

Re: Reproducable but intermittent: CVS fails to check out large files on amd64

[Stuart Henderson]

On 2016/02/01 12:44, cho...@jtan.com wrote:
> >Synopsis:CVS fails to check out large files on amd64, sometimes
> >Category:user amd64
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 
> 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When checking out large files using a local CVS server, the 
>   final 'ok' line is not printed about 2/3 of the time and the 
>   checkout subsequently fails.
> 
>   I heard through the grapevine (aka. #openbsd on freenode) that 
>   this is a known problem affecting amd64. Hopefully some 
>   diagnosis can shed some light on it. Personally I don't relish 
>   the thought of digging into cvs' source.

Not seeing this here but you may be running into memory limits.
See dlimit in CVSROOT/config.

Re: Reproducable but intermittent: CVS fails to check out large files on amd64

[Stuart Henderson]

Trying to resend, jtan.com mail server rejected the last one as spam.

Remote-MTA: dns; mail-filter-1.jtan.com 

Diagnostic-Code: smtp; 550-FAKE-REJECT - SPAMCOUNT-HI - [77 NP=-1 PHP=-1 LNK=-1 

BODY=40 HEAD=-6 550-FLAGS=-5] [S=77 -] - X=pascal   

H=symphytum.spacehopper.org [82.68.199.130] 

550-HELO=[symphytum.spacehopper.org] SN=[st...@openbsd.org] 

T=[cho...@jtan.com] 550-S=[Re: Reproducable but intermittent: CVS fails to  

check out large 550 files on amd64]   

I suspect that, despite the SPF for openbsd.org being "~all" rather than
"-all", some sites are increasing spam scores based on the SMTP sender
not being listed.


On 2016/02/01 12:44, cho...@jtan.com wrote:
> >Synopsis:CVS fails to check out large files on amd64, sometimes
> >Category:user amd64
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 
> 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When checking out large files using a local CVS server, the 
>   final 'ok' line is not printed about 2/3 of the time and the 
>   checkout subsequently fails.
> 
>   I heard through the grapevine (aka. #openbsd on freenode) that 
>   this is a known problem affecting amd64. Hopefully some 
>   diagnosis can shed some light on it. Personally I don't relish 
>   the thought of digging into cvs' source.

Not seeing this here but you may be running into memory limits.
See dlimit in CVSROOT/config.

Re: your mail

[Stuart Henderson]

On 2016/02/05 10:19, ilavsky.mar...@gmail.com wrote:
> >Synopsis:escape rksh when user has access to man(1)
> >Category:system
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   user can escape rksh shell when he has access to man(1) using custom 
> MANPAGER env variable

I don't think this is a bug. You are expecting more of rksh than
it offers.

You don't even need a custom MANPAGER, the default pager will allow
'v' to run $EDITOR which will also usually allow dropping to a shell.

> # ll /home/whoo/bin/
> total 872
> drwxr-xr-x  2 root  whoo 512 Feb  5 10:10 .
> drwxr-xr-x  4 whoo  whoo 512 Feb  5 00:06 ..
> -r-xr-xr-x  1 root  bin   422520 Aug 16 10:19 man
> #
> 
> man copied from /usr/bin/
..
> >Fix:

Don't allow access to programs which allow the user to escape to
an unrestricted shell?

If you need man, maybe run it from a wrapper that enforces environment
variables (MANPAGER, LESSSECURE), or uses 'man -c'.

Re: bug installing OpenVPN

[Stuart Henderson]

On 2016/02/08 15:29, Феликс Фролов wrote:
> OpenBSD 5.8 GENERIC.MP#1098 i386
> easy-rsa-2.2.0p0
> openssl-1.0.1pp1
> openvpn-2.3.7
> 
> # ./build-ca
> error on line 37 of /usr/local/share/easy-rsa/openssl.cnf
> 68958:error:0E065068:configuration file routines:STR_COPY:variable
> has no 
> value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_def.c:573:line
> 37
> 
> -- 
> 
> Felix Frolov
> +7 (965) 6600015
> felix.fro...@gmail.com
> EOF
> 

Update easy-rsa from -stable ports. Assuming you have already got a copy
of the ports tree:

cd /usr/ports/security/easy-rsa
cvs up -r OPENBSD_5_8
make clean && make update

Or pre-built -stable packages are available from stable.mtier.org.

Re: i386 GENERIC 5.8 build #1066 crashes while booting on AMD 5x86 133, 5.7 #738 and 5.9-current #1540 are ok

[Stuart Henderson]

On 2016/02/11 16:12, Frank Scheiner wrote:
> Hi,
> 
> On 02/10/2016 07:34 PM, Philip Guenther wrote:
> >On Wed, 10 Feb 2016, Frank Scheiner wrote:
> >>>Description:
> >>I'm trying to netboot an ALi 1487/1489 based PCI motherboard (Abit PB-4)
> >>with an AMD 5x86 133 processor with the GENERIC i386 kernel of OpenBSD
> >>5.8. But the kernel always drops to ddb after the "cpu0 at mainbus0:
> >>(uniprocessor)" message. Using the 5.7 kernel or the kernel of
> >>5.9-current build #1540 works ok though. I face the same problem when
> >>using another AMD processor (an AMD DX4 100). Like the AMD 5x86 the AMD
> >>DX4 is also working with the 5.7 and 5.9-current build #1540 kernel but
> >>crashes with the 5.8 kernel. Interestingly, when using an Intel DX4-S
> >>100 OVERDRIVE processor the same 5.8 kernel boots through without a
> >>problem.
> >
> >Yep, this was a regression in 5.8-release that wasn't caught until some
> >time after release.  Once jsg@ hit it we fixed the bad part of the change
> >I had made (I assumed the %cr4 register is always present, but it isn't on
> >"most 486s"), so it'll stay fixed in 5.9.
> 
> I see, thanks for clarification. I'd like to fix that locally in a 5.8
> kernel, would you be so kind to point me to the relevant file(s) in the
> source code and the patch?

See /sys/arch/i386/i386/cpu.c rev 1.68.

Re: bug installing OpenVPN

[Stuart Henderson]

On 2016/02/18 12:34, Феликс Фролов wrote:
> Your method also does not work, I used version easy-rsa-2.2.0p1
> All releases of OpenSSL uses the variable $ENV::
> Openbsd do not use this variable with version 5.8

It was intended that 2.2.0p1 patches things to use openssl
(/usr/local/bin/eopenssl binary) instead of libressl but this
didn't work correctly.

You can edit vars and change this line

export OPENSSL="openssl"

to

export OPENSSL="eopenssl"

But there are other problems with this version of easy-rsa, it doesn't
set CN correctly, which causes problems when generating more than one
certificate. 

For now I would recommend this:

- pkg_delete easy-rsa
- extract 
https://github.com/OpenVPN/easy-rsa/releases/download/3.0.1/EasyRSA-3.0.1.tgz
- cp vars.example vars
- edit vars and set this:

set_var EASYRSA_OPENSSL "/usr/local/bin/eopenssl"

Re: OpenVPN doesn't start (hangs) in routing domain.

[Stuart Henderson]

On 2016/02/16 08:47, Rafał Ramocki wrote:
> Hi,
> 
> Synopis: When OpenVPN installed by pkg_add is started in rdomain it hangs
> during initialization.
> 
> Category:  system user kernel amd64 i386
> Environment:
> System  : OpenBSD 5.8
> Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04
> MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> 
> Description:
> 
> I've configured routing domain with few interfaces. I'm trying to start
> OpenVPN in it with following configuration:

If it still happens on -current and you can provide log with 'verb 11'
then I'll try to take a look sometime. (I have only a very small
interest in openvpn and definitely not enough that I'm going to look
at anything pre -current; there have been very many changes in this
area since 5.8).

Re: Package update fails with permission errors

[Stuart Henderson]

On 2016/02/21 01:06, Ежи рыбы wrote:
> Ah, the update seems to run smoothly now. Should PKG_PATH supersede the
> settings in /etc/pkg.conf?

Yes, PKG_PATH takes priority, the path in pkg.conf is only used
if PKG_PATH is not set.

Re: panic with soekris 5501 on OpenBSD 5.9-current (GENERIC) #1573: Sun Mar 6 19:15:08 MST 2016

[Stuart Henderson]

On 2016/03/07 18:15, Lars Noodén wrote:
> I had two panics with soekris 5501 on OpenBSD 5.9-current (GENERIC)
> #1573: Sun Mar  6 19:15:08 MST 2016, apparently from just logging in
> and typing in the shell.  It has not happened a third time however.
> Below are the panic, trace, ps , and dmesg from the second one.

Are you using bridge?

Or anything else unusual with networking?

Re: panic with soekris 5501 on OpenBSD 5.9-current (GENERIC) #1573: Sun Mar 6 19:15:08 MST 2016

[Stuart Henderson]

On 2016/03/08 06:07, Lars Noodén wrote:
> On Tue, Mar 8, 2016 at 12:08 AM, Stuart Henderson wrote:
> > On 2016/03/07 18:15, Lars Noodén wrote:
> > > I had two panics with soekris 5501 on OpenBSD 5.9-current (GENERIC)
> > > #1573: Sun Mar  6 19:15:08 MST 2016, apparently from just logging in
> > > and typing in the shell.  It has not happened a third time however.
> > > Below are the panic, trace, ps , and dmesg from the second one.
> >
> > Are you using bridge?
> >
> > Or anything else unusual with networking?
> 
> Yes, I have a bridge and a virtual Ethernet interface.  The bridge
> contains vr0, vr1, vr2, vr3, and vether0.  vether0 is only IPv4.

It is likely that this has been fixed by a recent commit,
I don't think it will be in a snapshot yet but you can update
from cvs or wait and it should be in the next snap.

Re: Broken "Upgrade Guide" link from the 59.html page

[Stuart Henderson]

On 2016/03/11 21:16, Theo Buehler wrote:
> On Fri, Mar 11, 2016 at 12:00:16PM -0800, Yadwinder Grewal wrote:
> > Hello,
> > 
> > I found a broken link on this page:
> > 
> > http://www.openbsd.org/59.html
> > 
> > The link in question can be found under the "How to upgrade" section
> > 
> > How to upgradeIf you already have an OpenBSD 5.8 system, and do not want to
> > reinstall, upgrade instructions and advice can be found in the Upgrade Guide
> > .
> 
> thanks. that page just isn't written, yet. 59.html is still work in
> progress, the upgrade guide will be ready for the release on may 1st.
> 

Or hopefully a bit before for people who ordered the CDs, because they
usually arrive early.

Re: kernel PPP doesn't set IP address on PPPOE interface from IPV6CP

[Stuart Henderson]

On 2016/03/23 14:07, Stefan Sperling wrote:
> On Wed, Mar 23, 2016 at 09:40:24PM +0900, stephane Tranchemer wrote:
> > So the connection should be fine, problem is how to get gateway information
> > on the hosts behind the router...
> 
> > FYI, I have a /56 class assigned.
> 
> So it sounds like this should work:
> 
> Make sure your router can ping the IPv6 interface across its pppoe1
> interface with the link-local address assigned.
> BTW, if you set the netmask of pppeo1 to 128, you'll see the peer's
> address in the output of ifconfig pppoe1. You can use that as default
> route, or you can use pppoe1's own link-local address as default route.
> Alternatively just keep using your fe80:: default route.
> Which option you choose really doesn't matter, it's a point-to-point
> link so as long as you push packets across it somehow they will reach
> the other end. As long as you can ping global IPv6 addresses from the
> router, you're set.
> 
> Now assign a /64, carved out of your /56, to the internal interface.
> Pick one (any) address out of this /64 for your router's internal interface.
> Run rtadvd(8) on the internal interface.
> 
> Either use IPv6 autoconf on the clients, or statically assign unique
> addresses from the /64 to them and use the router's address from the /64
> as gateway address (default route) on clients.
> 
> Ensure that sysctl net.inet6.ip6.forwarding=1 is set on your router,
> and use pf(4) to filter IPv6 traffic as needed.
> 

If they are following the Broadband Forum spec or something close to
it, then you should be able to use autoconf on the PPP interface on
your router to fetch an address and default route if you like, it's
not necessary because this should all work with a link-local address
on the point-to-point interface and fe80:: default route, but
sometimes it can be useful to have an "outside" address that you
can ping independently of your "inside" address.

Many ISPs will route your whole assignment towards your PPP interface
when you connect, but not all of them do this: some require that you
fetch subnets using DHCP6-PD on your router in order for them to be
routed towards you. So if it doesn't work hardcoded, this might be
something that needs doing (if this is required, the ISP ought to be
able to advise).

Re: Mar 23 snapshot and ipv6 problem

[Stuart Henderson]

On 2016/03/24 20:27, Sebastien Marie wrote:
> Hi,
> 
> I encountered a problem with IPv6 connectivity after upgrade to snapshot
> Mar 23 on my amd64 router.
> 
> The router use a pppoe session to get IPv4 and IPv6. I had to made a
> DHCP-ND request to get routable IPv6, and I use dhcpcd from ports for
> that.
> 
> The IPv4 is ok, but for IPv6, dhcpcd has the following error:
> 
> Mar 24 20:16:33 alf dhcpcd[43667]: DUID 00:01:00:01:1e:40:7c:6c
> Mar 24 20:16:33 alf dhcpcd[43667]: pppoe0: IAID 00:00:00:01
> Mar 24 20:16:33 alf dhcpcd[43667]: pppoe0: IAID 00:00:00:02
> Mar 24 20:16:33 alf dhcpcd[43667]: pppoe0: rebinding prior DHCPv6 lease
> Mar 24 20:16:35 alf dhcpcd[43667]: pppoe0: dhcp6_sendmessage: sendmsg: 
> Invalid argument
> Mar 24 20:17:03 alf dhcpcd[43667]: timed out
> Mar 24 20:17:03 alf dhcpcd[43667]: forked to background, child pid 10317

This is due to the new in6_pcbaddrisavail() check in udp6_output.c
(that is also in the 5.9 errata). This will work-around it for now:

Index: udp6_output.c
===
RCS file: /cvs/src/sys/netinet6/udp6_output.c,v
retrieving revision 1.46
diff -u -p -r1.46 udp6_output.c
--- udp6_output.c   23 Mar 2016 15:50:36 -  1.46
+++ udp6_output.c   29 Mar 2016 10:24:34 -
@@ -175,7 +175,7 @@ udp6_output(struct inpcb *in6p, struct m
valid.sin6_len = sizeof(valid);
error = in6_pcbaddrisavail(in6p, &valid, 0, p);
if (error)
-   goto release;
+   printf("udp6_output: in6_pcbaddrisavail\n");
}
} else {
if (IN6_IS_ADDR_UNSPECIFIED(&in6p->inp_faddr6)) {

(or just remove it).

> I had ktraced it for grabing the sendmsg syscall arguments used:
> 
>  43667 dhcpcd   CALL  sendmsg(10,0x1abbb5052020,0)
>  43667 dhcpcd   STRU  struct msghdr { name=0x7f7c5260, namelen=28, 
> iov=0x1abbb5052050, iovlen=1, control=0x1abbb5052070, controllen=40, flags=0 }
>  43667 dhcpcd   STRU  struct iovec { base=0x1abb901b5000, len=167 }
>  43667 dhcpcd   STRU  struct sockaddr { AF_INET6, [ff02::1:2]:547 }
>  43667 dhcpcd   STRU  struct cmsghdr { len=36, level=41, type=46 }
>  43667 dhcpcd   RET   sendmsg -1 errno 22 Invalid argument

With this check disabled/neutered, the packets are sent like so:

11:26:43.567469 PPPoE 
code Session, version 1, type 1, id 0x02db, length 213
IPV6: fe80::225:90ff:fec0:77b5.546 > ff02::1:2.547: [udp sum ok]dhcp6 
reconfig [hlim 1] (len 171)
11:26:43.581748 PPPoE 
code Session, version 1, type 1, id 0x02db, length 155
IPV6: fe80::d2f0:dbff:fe6c:e000.547 > fe80::225:90ff:fec0:77b5.546: 
[udp sum ok]dhcp6 [class 0xc0] (len 113, hlim 64)

$ fstat | grep 546
root dhcpcd  1384   10* internet6 dgram udp *:546

As you'd expect, fe80::225:90ff:fec0:77b5 is the link-local address
on the pppoe interface.

Re: ifconfig media doesn't show inet6 addresses

[Stuart Henderson]

On 2016/03/29 16:57, Peter Hessler wrote:
> On 2016 Mar 29 (Tue) at 14:36:04 + (+), Christian Weisgerber wrote:
> :On 2016-03-28, Theo de Raadt  wrote:
> :
> :>> Providing the 'media' parameter to ifconfig only shows ipv4
> :>> addresses and not ipv6.
> :>
> :> This decision was made almost 15+ years and still stands today.
> :>
> :> If you want to see v6 addresses, use -a.
> :>
> :> Most people who use ifconfig are in a v4 world, and don't want their
> :> screen to scroll.
> :
> :Wait, but interfaces don't get v6 addresses by default any longer.
> :If you are in a v4-only world, your interfaces don't have any v6
> :addresses.  The old reasoning doesn't apply.
> :
> 
> IMHO, all addresses or no addresses should be printed.  This middle
> ground is no good.

Current behaviour, without using "media":

"ifconfig -a" does the same as "ifconfig": prints all v6,
but for v4 only prints the primary (no aliases).

"ifconfig -A" or "ifconfig " prints all v6
*and* all v4 including aliases.

Add "media" with any other options and it stops printing v6,
v4 alias handling is unchanged (i.e. printed with 
or -A, otherwise not).

Re: ftp download stalls after ~76M, dumps core on ^C

[Stuart Henderson]

On 2016/03/31 10:17, Theo Buehler wrote:
> After roughly 76M download via ftp, the download stalls (and doesn't
> continue even after leaving it for hours). On aborting with ^C, ftp
> dumps core. The precise number of downloaded bytes varies by about 1M.

Try -k 0, some hosts have a problem with the NOOP hack (I suspect this
may be because we don't read responses on the control channel until the
transfer is done). Don't know if that's it, but worth a try.

Re: /usr/libexec/security symlink permission check warnings

[Stuart Henderson]

On 2016/04/10 18:50, Ingo Schwarze wrote:
> [Cc:ing the print/cups maintainer]
> 
> Hi Stephen,
> 
> Stephen Hassard wrote on Sat, Apr 09, 2016 at 06:30:04PM +:
> 
> > After installing the cups package I'm getting a warning from the daily
> > insecurity check about /etc/printcap.
> > 
> > The security output is as follows:
> > ---
> > Checking special files and directories.
> > Output format is:
> > filename:
> > criteria (shouldbe, reallyis)
> > etc/printcap:
> > type (file, link)
> > permissions (0644, 0755)
> > mtree special: exit code 2
> > ---
> > 
> > It seems that security is incorrectly reporting the mode of the symlink
> > rather than the target file (/etc/cups/printcap in this case) which has
> > the recommended 644 mode.
> 
> Changing which mode is checked won't help you because security(8)
> also complains that printcap(5) is a symlink rather than the expected
> regular file.  So you would still et spammed.
> 
> Antoine, is it normal that CUPS replaces /etc/printcap with a symlink?
> Any idea how to prevent people from getting spammed about that?
> If we had an idea, we could explain it in README-main, which is
> already quite good in many other respects.
> 
> Yours,
>   Ingo
> 

That is normal.

Between that, a few files where I have slightly wider read permissions
for operational reasons, and the check on the DNSSEC root key in
/var/unbound/db/root.key (where the timestamp in a comment is updated
twice a day in normal operations), I divert those mails from many
systems to a rarely read folder..

I'd be much more likely to read these if it only reported when there
are *differences* in the mtree output.

Re: /usr/libexec/security symlink permission check warnings

[Stuart Henderson]

On 2016/04/12 02:30, Ingo Schwarze wrote:
> Hi Stuart,
> 
> Stuart Henderson wrote on Sun, Apr 10, 2016 at 09:27:06PM +0100:
> 
> > Between that, a few files where I have slightly wider read
> > permissions for operational reasons,
> 
> Which are those?
> 
> Would it maybe make sense to weaken these checks for everybody?
> If those permissions make sense for you, maybe they are not
> insanely dangerous in general?

I often have 640 root:wheel for things like ospf{,6}d.conf, bgpd.conf,
pf.conf, crontab so I can review configuration as a wheel user without
having to authenticate again.

> > and the check on the DNSSEC root key in /var/unbound/db/root.key
> > (where the timestamp in a comment is updated twice a day in normal
> > operations),
> 
> Hum, neither unbound(8) nor unbound.conf(5) teach me anything about
> that file.  Whatever program may be changing that file, is there
> no way to fix it such that it keeps the comment constant?
> Even if time information is interesting for some reason, isn't that
> already available from the file write access date?

This is the usual file used with "auto-trust-anchor-file", which is
used when DNSSEC validation is enabled. It is written by unbound itself
and also by unbound-anchor(8) which is called conditionally from the
rc.d script.

   auto-trust-anchor-file: 
  File with trust anchor for one zone, which is tracked with
  RFC5011 probes.  The probes are several times per month, thus
  the machine must be online frequently.  The initial file can be
  one with contents as described in trust-anchor-file.  The file
  is written to when the anchor is updated, so the unbound user
  must have write permission.

$ cat /var/unbound/db/root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1460418862 ;;Tue Apr 12 00:54:22 2016
;;last_success: 1460418862 ;;Tue Apr 12 00:54:22 2016
;;next_probe_time: 1460460850 ;;Tue Apr 12 12:34:10 2016
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.   172800  IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 
;;lastchange=1396470602 ;;Wed Apr  2 21:30:02 2014

I'd sooner remove it from changelist, but some people wanted it (I could
modify it locally, I don't have that many machines running unbound, but I like
to avoid things that require manual sysmerge sdiff runs in files which are
updated fairly often in the OS.

> > I divert those mails from many systems to a rarely read folder..
> 
> That seems unfortunate indeed.  I spent some work to get daily(8)
> silent by default with VERBOSESTATUS=0 (which i would still like
> to make the default, but that's maybe a seperate matter).

I used to adjust files locally to achieve that, but mtree is hard to handle
that way after updates.

> > I'd be much more likely to read these if it only reported when there
> > are *differences* in the mtree output.
> 
> I fear i don't understand that remark.  The security(8) script is
> not producing any mtree(1) output.  It runs mtree(1) in the
> default checking mode (with -el), not in -c mode.
> 
> But tracking down and fixing whatever is spammy in sane configurations
> seems worthwhile to me.

I meant "changes in the output from mtree(1) as included in the security mails",
i.e. if there is any difference from the "mtree -el" output from the last run.
Edge-triggered vs. level-triggered. It's a trade-off though, it would reduce
unwanted mail, but makes it more important that a given message is delivered
and noticed.

Re: can't set lladdr on apu1 re(4) nics (vlan over trunk problem?) on 5.9

[Stuart Henderson]

On 2016/04/14 19:53, Daniel Jakots wrote:
> On Sun, 10 Apr 2016 18:04:04 +0200, Daniel Jakots 
> wrote:
> 
> > I just upgraded to OpenBSD 5.9 -stable for my apu which I use as home
> > router.
> 
> I installed OpenBSD -current on a usb key, and put my /etc in it (I
> only changed fstab) and same problem.
> 
> I didn't notice before but even in the dmesg their address is 00:... so
> could it be a hardware problem?

It normally starts 00:0d:b9 on pc engines boards. Sounds like software
is more likely, do you have a time window of when it broke? If
it's too wide, can you bisect to narrow it down further?

X / wscons broken with serial console

[Stuart Henderson]

If the bootloader sets up a serial console, I can no longer get X to
start:

[   138.658] (--) checkDevMem: using aperture driver /dev/xf86
[   138.738] (EE) 
Fatal server error:
[   138.738] (EE) xf86OpenConsole: No console driver found
Supported drivers: wscons
Check your kernel's console driver configuration and /dev entries(EE) 
[   138.738] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[   138.738] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[   138.738] (EE) 
[   138.739] (EE) Server terminated with error (1). Closing log file.

Any ideas what it was that might have broken this?

OpenBSD 5.9-current (ARTLESS.MP) #6: Thu Apr 21 11:56:10 BST 2016
st...@symphytum.spacehopper.org:/usr/src/sys/arch/amd64/compile/ARTLESS.MP
real mem = 8477306880 (8084MB)
avail mem = 8216145920 (7835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (90 entries)
bios0: vendor Dell Inc. version "A04" date 07/20/2014
bios0: Dell Inc. PowerEdge T20
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) 
RP07(S4) PXSX(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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.59 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,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 E3-1225 v3 @ 3.20GHz, 3392.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,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 E3-1225 v3 @ 3.20GHz, 3392.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus -1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
"PNP0103" at acpi0 not configured
"INT3F0D" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3392 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 
2300, 2200, 2000, 1800, 1700, 1500, 1300, 1100, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 a

Re: X / wscons broken with serial console

[Stuart Henderson]

On 2016/04/21 22:04, Matthieu Herrb wrote:
> > Very probably the switch to native WSCONS support in the X server, and
> > more precisely the fact that the X server now uses sysctl to figure
> > out what is the console device to open.
> > 
> > I need to tink a bit on a good solution... 
> >
> 
> This diff should fix the problem by testing if the console device is a
> wsdisplay(4) device and falling back to /dev/ttyCn otherwise. I've
> changed the logic a bit in the hope to make the code more readable,
> but it's still a bit of a mess.

Thanks Matthieu, that makes sense and a bit more readable, also it fixes
things for me. OK.

> I don't know if we need to add a knob to explicitely set the path of
> the device to use for X.

As Mark mentioned, I don't think it's something I am likely to use
myself, but the use cases he suggested do make sense to me.

> Index: bsd_init.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/os-support/bsd/bsd_init.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 bsd_init.c
> --- bsd_init.c2 Apr 2016 14:25:10 -   1.18
> +++ bsd_init.c21 Apr 2016 19:55:19 -
> @@ -611,17 +611,27 @@ xf86OpenWScons(void)
>  if (xf86Info.ShareVTs)
>  FatalError("-sharevt is not supported with wscons\n");
>  
> +/* default value if probing the console device fails */
> +snprintf(vtprefix, sizeof(vtprefix), "/dev/ttyC");
> +
> +/* probe console device - it my be /dev/ttyD0 on some multi-heads setups 
> */
>  mib[0] = CTL_KERN;
>  mib[1] = KERN_CONSDEV;
>  len = sizeof(dev);
>  if (sysctl(mib, 2, &dev, &len, NULL, 0) != -1) {
> -snprintf(vtprefix, sizeof(vtprefix), "/dev/%s", devname(dev, 
> S_IFCHR));
> -/* strip number, assuming 0 */
> -p = strchr(vtprefix, '0');
> -*p = '\0';
> -} else
> -snprintf(vtprefix, sizeof(vtprefix), "/dev/ttyC");
> -
> +snprintf(vtname, sizeof(vtname), "/dev/%s", devname(dev, S_IFCHR));
> + if ((fd = open(vtname, O_RDWR)) != -1) {
> + if (ioctl(fd, WSDISPLAYIO_GTYPE, &i) == 0) {
> +/* console is a wsdisplay(4) device */
> +strlcpy(vtprefix, vtname, sizeof(vtprefix));
> +/* strip number, assuming 0 */
> +p = strchr(vtprefix, '0');
> +*p = '\0';
> + close(fd);
> + fd = -1;
> + }
> + }
> +}
>  if (VTnum != -1) {
>  snprintf(vtname, sizeof(vtname), "%s%01x", vtprefix, VTnum - 1);
>  xf86Info.vtno = VTnum;
> 
> -- 
> Matthieu Herrb

Re: mplayer tv:// little hang when quiting

[Stuart Henderson]

On 2016/04/22 10:23, Walter Alejandro Iglesias wrote:
> Last year I posted this on misc@:
> 
> http://comments.gmane.org/gmane.os.openbsd.misc/223190
> 
> I'm not a developer so I can't figure out why it happens.
> 
> As I said in that message I was able to reproduce it in different
> machines and usb cameras so anyone with a usb webcam and mplayer
> installed should be able to reproduce it, that's why I didn't append
> dmesg or any output to that message.  Anyway:

What does top(1) say about mplayer when this is happening?
It will probably be easier to see if you use 'g mplayer' and
's .1' when top is running before you close mplayer; the WAIT
column might have something interesting.
> 

Re: SNMPD replies with wrong IP

[Stuart Henderson]

snmpd only binds to a single socket (on 0.0.0.0 by default), you need
to use "listen on " to make sure the correct source address is
used for reply packets in most non-simple network setups.

Re: SNMPD replies with wrong IP

[Stuart Henderson]

On 2016/04/22 11:50, BARDOU Pierre wrote:
> So if I want snmpd to listen on CARP and physical interface, I must launch it 
> two times ?

Possibly. I'm not sure why you would want to do that though?


> --
> Cordialement,
> Pierre BARDOU
> 
> 
> -Message d'origine-
> De : Stuart Henderson [mailto:s...@spacehopper.org] 
> Envoyé : vendredi 22 avril 2016 13:25
> À : BARDOU Pierre 
> Cc : bugs@openbsd.org
> Objet : Re: SNMPD replies with wrong IP
> 
> snmpd only binds to a single socket (on 0.0.0.0 by default), you need to use 
> "listen on " to make sure the correct source address is used for 
> reply packets in most non-simple network setups.

Re: ftp does not accept standalone certificates

[Stuart Henderson]

On 2016/04/26 16:04, Elmar Stellnberger wrote:
> >Synopsis: ftp does not accept standalone certificates
> >Category:security/certificate management
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC) #1561: Fri Feb 26 01:22:37 MST 2016
>
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> 
>   Architecture: OpenBSD.i386
>   Machine : i386
> >Description:
>   The ftp program does not allow downloads by provision of a self-signed or
> not root-ca-validated cert. Though this may be good as a default behaviour
> some people may prefer to validate certificates on their own by comparing
> the sha256 hash of the cert or by use of DNSSEC/DANE via dig. If so no
> root-ca will be given; just a standalone cert as validated via other means.
> The ftp program should be perpared for this case. AFAIK the only program
> which allows for this kind of manual validation by the time is stunnel.
> 
> >How-To-Repeat:
>   in an empty directory do the following:
> $ ftp -S capath=. -S cafile=../www.elstel.org.pem
> https://www.elstel.org/auxil/estellnb.pubkey.asc
> Trying 91.102.11.177...
> Requesting https://www.elstel.org/auxil/estellnb.pubkey.asc

Okay, let's look at this server:

$ openssl s_client -connect www.elstel.org:443 -servername www.elstel.org   
  
CONNECTED(0003)
depth=1 C = US, O = "GeoTrust, Inc.", OU = Domain Validated SSL, CN = Secure 
Site Starter DV SSL CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=elstel.org
   i:/C=US/O=GeoTrust, Inc./OU=Domain Validated SSL/CN=Secure Site Starter DV 
SSL CA - G2
 1 s:/C=US/O=GeoTrust, Inc./OU=Domain Validated SSL/CN=Secure Site Starter DV 
SSL CA - G2
   i:/C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use 
only/CN=GeoTrust Primary Certification Authority - G3
---


> www.elstel.org.pem contains the following:

And this is certificate 0 from the chain; CN=elstel.org issued by
GeoTrust's "Secure Site Starter DV SSL CA - G2". So this one should
already be accepted, and shouldn't need any additional flag to do
so, except it's not working because you're running into this problem:

http://article.gmane.org/gmane.os.openbsd.tech/47048

Re: wish: add DANE support to dig

[Stuart Henderson]

On 2016/04/26 16:54, Elmar Stellnberger wrote:
> >Synopsis: wish: add DANE support to dig
> >Category:security/certificate management
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC) #1561: Fri Feb 26 01:22:37 MST 2016
>
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> 
>   Architecture: OpenBSD.i386
>   Machine : i386
> >Description:
>   Support for DANE with dig would be a nice thing. It will not only be
> useful for the sysadmin who wants to check his DANE setup but also for
> casual users; f.i. you can download a cert, verify its sha256 via DANE and
> then check that you have the right cert with programs like filezilla. It is
> also possible to delete all root certs for Firefox and then only import
> specially trusted certs.

# pkg-add isc-bind
# /usr/local/bin/dig @192.33.4.12 +trusted-key=/etc/trusted-key.key [...]

Re: ftp does not accept standalone certificates

[Stuart Henderson]

On 2016/04/26 17:29, Elmar Stellnberger wrote:
> Am 2016-04-26 um 16:04 schrieb Stuart Henderson:
> > > www.elstel.org.pem contains the following:
> > 
> > And this is certificate 0 from the chain; CN=elstel.org issued by
> > GeoTrust's "Secure Site Starter DV SSL CA - G2". So this one should
> > already be accepted, and shouldn't need any additional flag to do
> > so, except it's not working because you're running into this problem:
> > 
> > http://article.gmane.org/gmane.os.openbsd.tech/47048
> > 
> 
>   Yes; that report is similar; as soon as any intermediate or leave cert is
> known there should at least be a switch to accept that cert even if the
> given root cert is missing. Basically it should be possible to accept such a
> cert by default as well?

It's not just ftp, it's everything using the library. A switch for this
makes no sense, it should be the default (there are ~15 entries we should
remove from cert.pem that we can't because of this).

>   There is good reason to disable certain root certs as many rogue certs
> issued for intelligence services are known to be circulating.

>   When will that bug be fixed for the ftp program?

Well, it's a tricky area - OpenSSL introduced a vulnerability when they
fixed it in their code (post-libressl-fork). So it won't be fixed until
libressl people find a sane way to do it.

Re: ftp does not accept standalone certificates

[Stuart Henderson]

On 2016/05/01 21:29, Elmar Stellnberger wrote:
> 
> 
> Am 2016-04-26 um 17:04 schrieb Stuart Henderson:
> > >   When will that bug be fixed for the ftp program?
> > 
> > Well, it's a tricky area - OpenSSL introduced a vulnerability when they
> > fixed it in their code (post-libressl-fork). So it won't be fixed until
> > libressl people find a sane way to do it.
> > 
> 
>   What vulnerability did they introduce? I am still heavily relying on
> OpenSSL since not all my planned OpenBSD systems are in productive use yet.

"Alternative chains certificate forgery" (CVE-2015-1793).

>   Will it be sufficient to subscribe to annou...@openbsd.org in order to
> receive a message when libressl should be as far as to accept any
> descendants of intermediate certificates?

I imagine it will probably be included in release notes if this is
implemented in libressl.

>   btw.: do you know since what version that is enabled for OpenSSL?

They introduced this in 1.0.2b / 1.0.1n and fixed the vuln
in 1.0.2d / 1.0.1p.

Re: Feature Request

[Stuart Henderson]

On 2016/05/17 18:35, Kevin Wier wrote:
> I would like to submit a feature request to where networks could
> be announced per neighbor instead of globally. This would afford the
> benefit of manipulating inbound BGP preferences to utilize a larger
> inbound connection by announcing the smaller ranges, being more specific
> than the larger range announced on the other smaller links. This still
> provides failed link redundancy as the other connections will still be
> used when the larger connection is down. I have included proposed config
> examples to reference.

Use "announce all" and use filters to choose what is sent to each
neighbour.

Re: Feature Request

[Stuart Henderson]

On 2016/05/17 21:34, Stuart Henderson wrote:
> On 2016/05/17 18:35, Kevin Wier wrote:
> > I would like to submit a feature request to where networks could
> > be announced per neighbor instead of globally. This would afford the
> > benefit of manipulating inbound BGP preferences to utilize a larger
> > inbound connection by announcing the smaller ranges, being more specific
> > than the larger range announced on the other smaller links. This still
> > provides failed link redundancy as the other connections will still be
> > used when the larger connection is down. I have included proposed config
> > examples to reference.
> 
> Use "announce all" and use filters to choose what is sent to each
> neighbour.

Following up with a bit more detail..

As well as filter rules themselves you need two things in
the top part of the file:

1. The prefixes need to be created somewhere. Either coming from
another router, or redistributed from static routes or connected
routes, or generated with "network" lines e.g.:

network 10.2.0.0/18
network 10.2.4.0/24
network 10.2.5.0/24
network 10.2.6.0/24

i.e. one for each individual prefix you're announcing.

The prefixes coming from neighbours and the prefixes from
"network" lines feed into:

2. "announce" in the neighbour config selects which of the
above prefixes are passed to filter rules.  You can use
"announce all" here and do everything else in the filter
rules. Or actually (and contrary to my first mail), you
could also use "self" here, which may be helpful to avoid
mistakes in filter rules accidentally advertising transit
routes to bad places.

3. Prefixes that make it through "announce" get fed into
the filter rules. These are just the allow/deny rules like
you'll see in the sample configuration - it's PF-like and
see the FILTER and PARAMETERS sections of bgpd.conf(5)
for the syntax description.

A contrived example with the above networks:

deny to any
allow to any prefix 10.2.0.0/18
allow to group somegroup prefix {10.2.4.0/24 10.2.5.0/24}
allow to 5.6.7.8 prefix 10.2.6.0/24
allow to 5.6.7.10  # send all routes to this transit customer

Re: sparc64 ntpd panic crash

[Stuart Henderson]

On 2016/05/19 18:15, rick...@nym.hush.com wrote:
> Info in file, comment at top.  Includes trace, ps, dmesg.
> 
> Very reproducable.  I'm willing to provide more info if requested.
> 
> Kind regards,
> Rick

Several people have seen this "panic: psycho0: uncorrectable DMA error"
crash but I don't think anyone has known where to dig further.

I don't think anyone noticed the ntpd connection before - is it always
ntpd that's the active process? does it go away if you disable ntpd?
That could be quite useful information if so ..

Re: iwm0: unhandled firmware response 0x7e/0xe0000004 rx ring 9[23]

[Stuart Henderson]

On 2016/05/21 16:25, Peter N. M. Hansteen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 05/21/16 16:12, Stefan Sperling wrote:
> > On Sat, May 21, 2016 at 04:04:35PM +0200, Peter N. M. Hansteen
> > wrote:
> >> The main reason I reported this was that I also had an episode of
> >> lost link for long enough for me to notice for the first time in
> >> quite a while. Again, could be unrelated.
> > 
> > Did your AP decide to switch channels when this happened? We don't
> > follow channel changes automatically (yet).
> 
> That could very well be what happened.
> 
> But looking at my logs I don't seem to have sufficient info to be
> sure, perhaps I should put the interface into debug mode for a while
> to collect info.

tcpdump -yIEEE802_11_RADIO -niiwm0 -l | grep -w csa

Re: ratelimit_plz

[Stuart Henderson]

On 2016/05/24 11:47, Artturi Alm wrote:
> >How-To-Repeat:
> modern browser
..
> chrome(83796): mmap: mandatory W^X
> chrome(19957): mmap: mandatory W^X
> firefox(74606): mmap: mandatory W^X
> chrome(6007): mmap: mandatory W^X
> chrome(50373): mmap: mandatory W^X

Any idea what you were doing in Firefox when this triggered?

On 2016/05/24 13:17, Artturi Alm wrote:
> Obviously, if there was something on cvs to send a diff against, i wouldn't
> have resorted to patching w/dd..

Didn't you think of building a kernel from a cvs checkout
before perpetrating that hack? ;)

On 2016/05/24 10:58, Jeremie Courreges-Anglas wrote:
> 
> It may be useless for you, but it is currently useful for developers.
> Did you consider ignoring it?

It does cause problems if it's at a high enough rate (sbcl
builds are a good one) and you have a "low" speed serial console
- kernel printfs lock the kernel for an appreciable time.

Same reason why you should think twice before using "pfctl
-x debug" on a busy firewall (especially one doing nat) with
serial console.

Re: ratelimit_plz

[Stuart Henderson]

On 2016/05/24 14:34, Artturi Alm wrote:
> On Tue, May 24, 2016 at 11:31:31AM +0100, Stuart Henderson wrote:
> > On 2016/05/24 11:47, Artturi Alm wrote:
> > > >How-To-Repeat:
> > > modern browser
> > ..
> > > chrome(83796): mmap: mandatory W^X
> > > chrome(19957): mmap: mandatory W^X
> > > firefox(74606): mmap: mandatory W^X
> > > chrome(6007): mmap: mandatory W^X
> > > chrome(50373): mmap: mandatory W^X
> > 
> > Any idea what you were doing in Firefox when this triggered?
> > 
> it was totally fresh firefox install w/no existing config nor plugins/addons
> w/e they are on that browser, figured i would uninstall once i found it
> suffering from mmap: mandatory W^X too, however i believe it was
> running/idling with these tabs:
> https://github.com
> http://ftp.openbsd.org/
> https://www.google.com/
> http://www.openbsd.org/faq/ 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/
> 
> can still provide exact urls off-list if you want, as it still seemed to
> launch with same set of tabs i left it running with while i was testing it
> before reboot to get rid of the msg.

Any chance you could try it with this diff and obtain a
backtrace? Knowing browsers it might not be useful anyway, but
it may just give us some clues..

Index: uvm_mmap.c
===
RCS file: /cvs/src/sys/uvm/uvm_mmap.c,v
retrieving revision 1.125
diff -u -p -u -r1.125 uvm_mmap.c
--- uvm_mmap.c  11 May 2016 21:52:51 -  1.125
+++ uvm_mmap.c  20 May 2016 20:40:40 -
@@ -351,6 +351,10 @@ sys_mmap(struct proc *p, void *v, regist
 */
if ((prot & PROT_MASK) != prot)
return (EINVAL);
+   if ((prot & (PROT_EXEC|PROT_WRITE)) == (PROT_EXEC|PROT_WRITE)) {
+   printf("%s(%d): mmap: mandatory W^X\n", p->p_comm, p->p_pid);
+   return (EACCES);
+   }
if ((flags & MAP_FLAGMASK) != flags)
return (EINVAL);
if (flags & MAP_OLDCOPY)
@@ -664,6 +668,11 @@ sys_mprotect(struct proc *p, void *v, re

if ((prot & PROT_MASK) != prot)
return (EINVAL);
+
+   if ((prot & (PROT_EXEC|PROT_WRITE)) == (PROT_EXEC|PROT_WRITE)) {
+   printf("%s(%d): mprotect: mandatory W^X\n", p->p_comm, 
p->p_pid);
+   sigexit(p, SIGSEGV);
+   }
 
error = pledge_protexec(p, prot);
if (error)

Re: Having trouble with IPSEC negotiating BlackBerry 10 OS smartphone with OBSD 6.1 amd64

[Stuart Henderson]

On 2017/08/10 11:13, Denis wrote:
> Or what phone model (Brand) I can use to have IPSEC working on the road?

IKEv1 (either on its own with just isakmpd, or combined with L2TP from
npppd) works widely.

IKEv2/iked works with iPhones in some setups (though Theodore Wynnychenko
ran into a problem that was introduced with a commit in March so it
doesn't work in all setups there). Tim Stewart has been looking at
getting it working with recent strongswan on Android (see various diffs
"Add Diffie-Hellman group negotiation" on tech@).

Re: coredump of ..., write failed: errno 14

[Stuart Henderson]

On 2017/07/13 17:16, Stuart Henderson wrote:
> I've seen this a lot recently (14 = EFAULT)
> 
> 2017-07-13T16:05:57.935Z symphytum /bsd: coredump of Xorg(62706), write 
> failed: errno 14
> 2017-07-13T16:05:57.993Z symphytum /bsd: coredump of chrome(46797), write 
> failed: errno 14
> 2017-07-13T16:05:58.081Z symphytum /bsd: coredump of vi(26461), write failed: 
> errno 14
> 2017-07-13T16:05:58.124Z symphytum /bsd: coredump of ksh(24425), write 
> failed: errno 14
> 
> partial coredumps get saved but they aren't usable with gdb..
> This is with kern.nosuidcoredump=2, there's plenty of space in /var/crash.
> 
> Any ideas?
> 

And a number of similar ones with EACCES now. These are all truncated.

total 7904
-rw-r--r--  1 root  wheel5 May 31 00:21 minfree
-rw---  1 root  wheel   196744 Aug 11 23:05 mysqld.core
-rw---  1 root  wheel21840 Aug 12 09:56 nginx.core
-rw---  1 root  wheel   112536 Aug 12 00:55 rspamd.core
-rw---  1 root  wheel  3654504 Aug 11 22:58 unbound.core

OpenBSD 6.1-current (GENERIC.MP) #52: Tue Aug  8 23:36:00 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8477265920 (8084MB)
avail mem = 8213995520 (7833MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (90 entries)
bios0: vendor Dell Inc. version "A12" date 05/11/2017
bios0: Dell Inc. PowerEdge T20
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) 
RP03(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) 
XHC_(S4) HDEF(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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.05 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3193051520 Hz
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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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 E3-1225 v3 @ 3.20GHz, 3192.61 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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 E3-1225 v3 @ 3.20GHz, 3192.61 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus -1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical t

Re: coredump of ..., write failed: errno 14

[Stuart Henderson]

On 2017/08/12 05:08, Philip Guenther wrote:
> On Sat, 12 Aug 2017, Stuart Henderson wrote:
> > On 2017/07/13 17:16, Stuart Henderson wrote:
> > > I've seen this a lot recently (14 = EFAULT)
> > > 
> > > 2017-07-13T16:05:57.935Z symphytum /bsd: coredump of Xorg(62706), write 
> > > failed: errno 14
> > > 2017-07-13T16:05:57.993Z symphytum /bsd: coredump of chrome(46797), write 
> > > failed: errno 14
> > > 2017-07-13T16:05:58.081Z symphytum /bsd: coredump of vi(26461), write 
> > > failed: errno 14
> > > 2017-07-13T16:05:58.124Z symphytum /bsd: coredump of ksh(24425), write 
> > > failed: errno 14
> > > 
> > > partial coredumps get saved but they aren't usable with gdb..
> > > This is with kern.nosuidcoredump=2, there's plenty of space in /var/crash.
> > > 
> > > Any ideas?
> > 
> > And a number of similar ones with EACCES now. These are all truncated.
> > 
> > total 7904
> > -rw-r--r--  1 root  wheel5 May 31 00:21 minfree
> > -rw---  1 root  wheel   196744 Aug 11 23:05 mysqld.core
> > -rw---  1 root  wheel21840 Aug 12 09:56 nginx.core
> > -rw---  1 root  wheel   112536 Aug 12 00:55 rspamd.core
> > -rw---  1 root  wheel  3654504 Aug 11 22:58 unbound.core
> 
> What's the readelf -a output for one or more of these?
> 
> 
> Philip
> 

Picking the smallest one to include directly, readelf -a nginx.core is below.

Others are ~300+KB each so I've uploaded them:
https://junkpile.org/readelf.mysqld.txt
https://junkpile.org/readelf.nginx.txt
https://junkpile.org/readelf.rspamd.txt
https://junkpile.org/readelf.unbound.txt

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  CORE (Core file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  0 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 151
  Size of section headers:   0 (bytes)
  Number of section headers: 0
  Section header string table index: 0

There are no sections in this file.

There are no sections in this file.

Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  LOAD   0x2550 0x069ca42d3000 0x
 0x3000 0x3000  R  1000
  LOAD   0x5550 0x069ca42d6000 0x
 0x00011000 0x00011000  RW 1000
  LOAD   0x00016550 0x069ca42e7000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x00017550 0x069ca42e8000 0x
 0x2000 0x00011000  RW 1000
  LOAD   0x00019550 0x069ca42f9000 0x
 0x2000 0xd000  RW 1000
  LOAD   0x0001b550 0x069ca4306000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x0001c550 0x069ea6e4b000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x0001d550 0x069ea8a0f000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x0001e550 0x069ea8db1000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x0001f550 0x069ea9ae2000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x00020550 0x069eabcf9000 0x
 0x2000 0x2000  RW 1000
  LOAD   0x00022550 0x069eac79a000 0x
 0x4000 0x4000  RW 1000
  LOAD   0x00026550 0x069eb5b48000 0x
 0x1000 0x1000  RW 1000
  LOAD   0x00027550 0x069eb5e53000 0x
 0x5000 0x5000  RW 1000
  LOAD   0x0

Re: acme-client subject alternative names bug?

[Stuart Henderson]

On 2017/09/14 15:04, William Leuschner wrote:
>   When acme-client is asked to renew a certificate which uses the Subject 
> Alternative Names feature, it fails with the error "domain not listed: 
> example.com". The configuration file I'm using is below:
..
> domain headcount.se.rit.edu {
>   alternative names { headcount.se.rit.edu peanut.se.rit.edu }

Renewals work for me. How does your current certificate look?

$ openssl x509 -in  -text -noout

One difference between your config and mine is that I don't repeat the
"main" domain in "alternative names". (It's not required, and maybe that
triggers a bug).

ospfd neighbour state problems

[Stuart Henderson]

Two routers on a point-to-point ethernet, the link between them dropped
out but ports stayed up. The link came back after ~2h or so but ospfd
doesn't recover -

first router:

195.95.187.31   FULL/OTHER   00:00:03 195.95.187.16   ix1   1d14h45m

Neighbor 195.95.187.3, interface address 195.95.187.16
  Area 0.0.0.0, interface ix1
  Neighbor priority is 1, State is FULL, 92 state changes
  DR is 195.95.187.16, BDR is 0.0.0.0
  Options -|O|-|-|-|-|E|-
  Dead timer due in 00:00:03
  Uptime 1d14h49m
  Database Summary List 0
  Link State Request List 0
  Link State Retransmission List 0


second router:

195.95.187.11   FULL/OTHER   00:00:03 195.95.187.17   vlan730   1d14h45m

Neighbor 195.95.187.1, interface address 195.95.187.17
  Area 0.0.0.0, interface vlan730
  Neighbor priority is 1, State is FULL, 12 state changes
  DR is 195.95.187.17, BDR is 0.0.0.0
  Options -|O|-|-|-|-|E|-
  Dead timer due in 00:00:03
  Uptime 1d14h46m
  Database Summary List 0
  Link State Request List 0
  Link State Retransmission List 1


i.e. they both think that they're DR and that there's no BDR.
(1d14h ago, yeah I was a bit slow spotting it this time..)

Not the first time I've seen it (on various links over various releases)..
In this case they're on a /31 though I've seen it on /30's previously.

Are other people seeing this?

Does anyone have an idea where the bug might be, or a better suggestion
than removing the interfaces from ospfd.conf, reloading, re-adding,
reloading again?

dmesg from one end for completeness, but it's not really relevant.

OpenBSD 6.1-current (GENERIC.MP) #44: Thu Aug  3 12:12:07 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4268331008 (4070MB)
avail mem = 4132614144 (3941MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xbf79c000 (62 entries)
bios0: vendor Dell Inc. version "1.1.4" date 10/30/2009
bios0: Dell Inc. PowerEdge R210
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT EINJ 
TCPA SSDT
acpi0: wakeup devices PCI0(S5) USBA(S0) USBB(S0)
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) Xeon(R) CPU X3430 @ 2.40GHz, 2394.31 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2394313000 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
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 X3430 @ 2.40GHz, 2393.98 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
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 X3430 @ 2.40GHz, 2393.98 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
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 X3430 @ 2.40GHz, 2393.98 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (LYD0)
acpiprt2 at acpi0: bus -1 (LYD2)
acpiprt3 at acpi0: bus -1 (HVD0)
acpiprt4 at acpi0: bus -1 (HVD2)
acpiprt5 at acpi0: bus 4 (PEX0)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpiprt8 at acpi0: bus 5 (COMP)
acpicpu0 at acpi0: !C3(350@96 mwait.1@0x20), !C2(500@64 mwait.1@0x10), 
C1(1000@1 mwait.1)
acpicpu1 at acpi0: !C3(350@96 mwait.1@0x20), !C2(500@64 mwait.1@0x10), 
C1(1000@1 mwait.1)
acpicpu2 at acpi0: !C3(350@96 mwait.1@0x20), !C2(500@64 mwait.1@0x10), 
C1(1000@1 mwait.1)
acpicpu3 at acpi0: !C3(350@96 mwait.1@0x20), !C2(500@64 mwait.1@0x10), 
C1(1000@1 mwait.1)
"PNP0C33" at acpi0 not configured
"ACPI000D" at acpi0 not configured
"IPI0001" at ac

Re: ospfd neighbour state problems

[Stuart Henderson]

On 2017/09/23 09:27, Claudio Jeker wrote:
> On Thu, Sep 21, 2017 at 03:45:28PM +0100, Stuart Henderson wrote:
> > Two routers on a point-to-point ethernet, the link between them dropped
> > out but ports stayed up. The link came back after ~2h or so but ospfd
> > doesn't recover -
> > 
> > first router:
> > 
> > 195.95.187.31   FULL/OTHER   00:00:03 195.95.187.16   ix1   1d14h45m
> > 
> > Neighbor 195.95.187.3, interface address 195.95.187.16
> >   Area 0.0.0.0, interface ix1
> >   Neighbor priority is 1, State is FULL, 92 state changes
> >   DR is 195.95.187.16, BDR is 0.0.0.0
> >   Options -|O|-|-|-|-|E|-
> >   Dead timer due in 00:00:03
> >   Uptime 1d14h49m
> >   Database Summary List 0
> >   Link State Request List 0
> >   Link State Retransmission List 0
> > 
> > 
> > second router:
> > 
> > 195.95.187.11   FULL/OTHER   00:00:03 195.95.187.17   vlan730   1d14h45m
> > 
> > Neighbor 195.95.187.1, interface address 195.95.187.17
> >   Area 0.0.0.0, interface vlan730
> >   Neighbor priority is 1, State is FULL, 12 state changes
> >   DR is 195.95.187.17, BDR is 0.0.0.0
> >   Options -|O|-|-|-|-|E|-
> >   Dead timer due in 00:00:03
> >   Uptime 1d14h46m
> >   Database Summary List 0
> >   Link State Request List 0
> >   Link State Retransmission List 1
> > 
> > 
> > i.e. they both think that they're DR and that there's no BDR.
> > (1d14h ago, yeah I was a bit slow spotting it this time..)
> > 
> > Not the first time I've seen it (on various links over various releases)..
> > In this case they're on a /31 though I've seen it on /30's previously.
> > 
> > Are other people seeing this?
> > 
> > Does anyone have an idea where the bug might be, or a better suggestion
> > than removing the interfaces from ospfd.conf, reloading, re-adding,
> > reloading again?
> > 
> 
> Do you have tcpdumps of the OSPF traffic by any chance?

I don't, but I'll try to scrape together a test network to reproduce and
collect them.

> I think there is a case where the hello protocol gets confused and so you
> end up with multiple DRs that stick to themself.
> You could try to down/up the interface which may be enough to get out of
> this state...

I have some recollection of hitting other problems when I've done that
in the past, remove/reload/add/reload is a bit annoying but seems fairly
low impact.

panic - vmxnet3_getbuf: buffer has mbuf

[Stuart Henderson]

panic occurred with rsync-over-ssh copying a ~50MB file to the machine.
active processes according to the auto-listing at panic: sshd, softnet

cpu0 trace: (in full in the screenshots)

db_enter
panic
vmxnet3_getbuf(801ae560,0) at vmxnet3_getbuf+0x117
vmxnet3_rxintr(81ac94e0,1) at vmxnet3_rxintr+0x2bc
vmxnet3_intr(801ac000) at vmxnet3_intr+0x70
intr_handler
Xintr_ioapic_level10
--- interrupt ---

screenshots from sh reg, sh malloc, sh all pools, ps at
http://junkpile.org/vmxnet3_getbuf/

ddb hanged at "mach ddbcpu 1" so I can't get a cpu1 trace.

esxi 5.5, vm version 8, for some reason it's currently set as freebsd (32-bit).

$ dmesg
OpenBSD 6.2-beta (GENERIC.MP) #82: Fri Sep  8 11:18:48 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6425608192 (6127MB)
avail mem = 6223855616 (5935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 04/14/2014
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) 
PE50(S3) S1F0(S3) [...]
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) Xeon(R) CPU E5630 @ 2.53GHz, 2533.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2533406930 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2533.93 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2533.95 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2534.06 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
"PNP0001" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0400" at acpi0 not configured
"PNP0700" at acpi0 not configured
acpiac0 at acpi0: AC unit online
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled
"VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02
pci2 at ppb1 bus 2
ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01
pci3 at ppb2 bus 3
mpi0 at pci3 dev 0 function 0 "Symbios Logic SAS1068" rev 0x01: apic 4 int 18
mpi0: SAS3444, firmware 1.3.41.32
scsibus2 at mpi0: 256 targets, initiator 16
sd0 at scsibus2 targ 0 lun 0:  SCSI2 0/direct fixed
sd0: 20480MB, 512 bytes/sector, 41943040 sectors
sd1 at scsibus2 targ 1 l

Re: ftp proxies and redirects

[Stuart Henderson]

On 2017/10/02 19:56, Ted Unangst wrote:
> I believe there's a bug with ftp and redirects when using a proxy. ftp seems
> to add the redirect URL to the proxy host, fetching http://proxy/new-url
> instead of http://orighost/new-url. I'm not certain this isn't a server or
> proxy bug, in part because I'm not certain who's supposed to say what or how
> it's interpreted, but my first guess is to blame ftp. :) In the same setup,
> chrome redirects to http://orighost/new-url.
> 

I can't replicate that here. How does it looks with ftp -d ? 

Re: 6.2 regression: syspatch: invalid URL configured in /etc/installurl

[Stuart Henderson]

On 2017/10/12 11:31, Harald Dunkel wrote:
> Hi folks,
> 
> since 6.2 systpatch complains
> 
> # syspatch
>
> syspatch: invalid URL configured in /etc/installurl
> # cat /etc/installurl 
>
> https://ftp.halifax.rwth-aachen.de/openbsd/
> 
> Is this just because there are no patches yet? If yes, then
> the error message might appear to be misleading.
> 
> 
> Regards
> Harri
> 

Remove the trailing slash.

Re: Amusing quirk, maybe qualifies as bug: NTPD will not work on a machine that has an incorrect system date already, as NTPD uses TLS and TLS is time-sensitive

[Stuart Henderson]

On 2017/10/15 03:46, ti...@openmailbox.org wrote:
> An effective fix here is to simply remove the "constraints" line
> in /etc/ntpd.conf , this way ntpd makes no attempt to make any TLS
> connection (to https://www.google.com/ which is used as constraint in
> the default /etc/ntpd.conf) and instead just goes into time syncing work
> with pool.ntp.org .

I think that's the only reasonable approach if you're on a machine with
no/wrong RTC. If you're going to ignore certificate errors you might as
well not use HTTPS constraints.

> Also, I am not super happy about NTPD connecting by default to
> www.google.com in particular.

Same here. Some people agreed with me when I asked about that before,
others didn't mind it. I change that from site*.tgz on autoinstalled
machines.

Re: ThinkPad X1 Yoga 2nd gen panics on 6.2-stable

[Stuart Henderson]

Send the output from "sendbug" run as root - if you have working mail on 
the machine you can run it directly, otherwise "sendbug -p > somefile" and 
copy that to another machine to send.


--
 Sent from a phone, apologies for poor formatting.



On 17 October 2017 06:14:04 Jay Kruer  wrote:


Hi all,

I recently installed 6.2-stable on my 2nd gen ThinkPad X1 Yoga. I now get
panics when inserting/removing my power adapter and when attempting to
start X. The reason I mention them together is that they both seem related
to ACPI. I've attached panic "logs" for both as images (the one that occurs
when starting X has thinkpad_set_brightness in the trace) I've also
attached the output of dmesg. I'm a bit lost where to proceed from here and
would be very grateful for any pointers in the right direction.
[image: Inline image 1]

Thanks,
– Jay

Re: Bug

[Stuart Henderson]

On 2017/10/23 11:06, Kyle Farmer wrote:
> isakmpd doesn't start properly during boot up.  The rc.d file is pointed
> towards sasyncd

That's intentional.



> current;
> 
> #!/bin/sh
> #
> # $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
> 
> daemon="/sbin/isakmpd"
> 
> . /etc/rc.d/rc.subr
> 
> pexp="isakmpd: monitor \[priv\]"
> 
> rc_pre() {
> [ X"${sasyncd_flags}" != X"NO" ] && \
> daemon_flags="-S ${daemon_flags}"
> return 0
> }
> 
> rc_cmd $1
> 
> 
> to:
> 
> #!/bin/sh
> #
> # $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
> 
> daemon="/sbin/isakmpd"
> 
> . /etc/rc.d/rc.subr
> 
> pexp="isakmpd: monitor \[priv\]"
> 
> rc_pre() {
> [ X"${isakmpd_flags}" != X"NO" ] && \
> daemon_flags="-S ${daemon_flags}"
> return 0
> }
> 
> rc_cmd $1

Re: Bug

[Stuart Henderson]

On 2017/10/23 11:24, Kyle Farmer wrote:
> Wouldn't that conflict with -S and the -K flags.

> > > rc_pre() {
> > > [ X"${sasyncd_flags}" != X"NO" ] && \
> > > daemon_flags="-S ${daemon_flags}"
> > > return 0

What this is doing is automatically adding -S if sasyncd is enabled.

It doesn't matter if -S is already given in isakmpd_flags, isakmpd is
still happy with -S -S if it's given.

Re: rcctl: howto set flags for disabled services?

[Stuart Henderson]

On 2017/11/20 10:10, Harald Dunkel wrote:
> Hi Sebastian,
> 
> On 11/15/17 12:22 PM, Sebastian Benoit wrote:
> > Harald Dunkel(harald.dun...@aixigo.de) on 2017.11.14 07:48:01 +0100:
> >>
> >> Do you think the request to distinguish between the "usual" command
> >> line flags and the information whether a service should be started
> >> at boot time is unreasonable?
> > 
> > Thats only one solution to your problem, but not the only one.
> > 
> > Possible solutions that change the way rc.conf variables work are difficult,
> > and i dont see why they are needed.
> > 
> 
> They are needed to keep the command line flags separate from the
> information whether a service should be run at all. Some tools like
> openvpn and dnsmasq support a pretty complex set of command line
> flags. If you disable such a service for the next reboot, then all
> these flags are lost.
> 
> > Going to a rc.conf.local format where you have
> > 
> >   daemon=YES|NO
> >   daemon_flags=-foo
> > 
> > does not help you much. Then the next problem becomes how you switch from NO
> > to YES.
> > 
> 
> You could use "rcctl enable", as documented. My suggestion was to
> change the rc script internals, keeping rcctl as it is. Did you
> notice that rcctl(8) seems to imply that the flags can be set inde-
> pendently from enable/disable? Sample session:
> 
> bash-4.4# rcctl get apmd flags
> -C
> bash-4.4# rcctl disable apmd
> bash-4.4# rcctl enable apmd
> bash-4.4# rcctl get apmd flags
> bash-4.4#
> 
> Sorry to say, but this is not as documented. To me the lost command
> line flags look like an unwanted side effect, i.e. a bug.

There is a difference in the mechanism between daemons from packages
(where it would be _possible_ to enable/disable independent of storing
flags) and daemons from base (where it is not, unless changes are made
to rc.conf - and I don't see a good way to do this without a difficult
transition)..

And I don't think standard rcctl operations should work differently
depending on whether something is in base or is a package.

> > So here is one way to store your flags and switch your configs
> > automatically, with no changes to how rc.d works:
> > 
> > * run ifstated (or something else) to monitor your state
> > * use a script thats run on promotion/demotion of a machine, that script 
> > runs rcctl(8) as
> >   needed
> > * on state change, have ifstated (or something else) run the script
> > 
> > Now you have the flags of your programms in the arguments
> > of "rcctl set  flags ...", all in one file that you can keep in
> > sync over multiple machines.
> > 
> 
> You mean I should write a wrapper for each service and put all
> knowledge about the command line arguments into this script?
> Actually I thought thats what rcctl is good for.
> 
> Please check https://www.openbsd.org/faq/faq10.html. It says
> 
> "Do not alter rc.conf(8) directly. Instead, use the rcctl(8)
> utility to maintain the /etc/rc.conf.local file. This makes
> future upgrades easier -- all the changes are in the one file
> that isn't touched during upgrade."
> 
> Your suggestion is to put the command line flags somewhere
> else. Wouldn't you agree that this is a conflict? Not to
> mention that according to the quote rcctl has been provided
> as a command line interface to the rc internals, which means
> changes to the internals *are* possible.

- it's simple to do what you want here really, just that you need
to do some setup without using rcctl. all you *actually* need to do
in this case is set openvpn_flags and dnsmasq_flags in rc.conf.local
(note, not rc.conf) and don't list them in pkg_scripts; then just
"rcctl start openvpn" and "rcctl stop openvpn" etc as needed.

- do you really need to stop and start these daemons anyway? can you
just run them even when the machine is not master?

Re: kernel panic

[Stuart Henderson]

On 2017/11/28 08:48, claris prant wrote:
> 
> accept 43D2-F0B3-04CE
> 
> Tuesday, May 30, 2017 5:57 AM
> From: "claris prant" 
> To:  owner-b...@openbsd.org
> 
> will be difficult to help you resolving bug being a « kernel panic « 
> according to words appearing on my display with impossibility to make a dmsg
> 
> beginner
> was never able to have openbsd running as os on my desktop
> 
> no knowledge in coding
> 
> Strasbourg
> France
> 
> see more here
> 
> https://marc.info/?l=openbsd-bugs&m=149612290518443&w=2
> 
> panic () at panic+0xfe
> 
> __stack_smash_handler() at __stack_smash_handler()+0x19
> 
> msleep() at msleep+0x194
> 

>From that mail :

:: pci Hp 5077 fr - 1 G de ram - radeon hd 5450 caicos no fan - cpu pentium 4 - 
ht \
:: technology - 3,2 ghz - amd64
:: 
:: bios 3.20 - 03/31/05

Some older HP ACPI BIOS are a bit broken. I would suggest trying to find
a BIOS update. I don't know if it will help, but there's a chance it
might. Otherwise I'd look for a different machine if you want to try
running OpenBSD (or try it in a VM), this is not going to be a good
first machine to run OpenBSD on ..

Re: System freezes periodically (6.2 -stable on Lenovo G550 with Intel GM45 GPU)

[Stuart Henderson]

On 2017/12/06 03:47, Anonymous wrote:
> The freezes can be short - a few seconds - or longer, about a minute
> long. This often happens when I launch or quit mpv, these freezes are
> typically long. I'm working on a small GLFW+OpenGL program, at this
> point it basically creates a window, does some other stuff and quits. So
> a window is quickly created and destroyed - that also causes freezes,
> typically short ones. Once the system froze while I was downloading a
> file. The LED indicating disk activity kept flashing as well as the LEDs
> in the Ethernet port. During a long freeze the fans spin faster judging
> by the noise. Overall the graphical side feels more sluggish that in
> 6.1, I don't use the console for anything but logging in and starting X.
> 
> In 'messages' (a copy of /var/log/messages) look for 'Resetting chip
> after gpu hang' as well as the error messages at the start.

There's not a lot of RAM. Is the system swapping?

Re: System freezes periodically (6.2 -stable on Lenovo G550 with Intel GM45 GPU)

[Stuart Henderson]

On 2017/12/06 20:54, Anonymous wrote:
> Stuart Henderson:
> > On 2017/12/06 03:47, Anonymous wrote:
> >> The freezes can be short - a few seconds - or longer, about a minute
> >> long. This often happens when I launch or quit mpv, these freezes are
> >> typically long. I'm working on a small GLFW+OpenGL program, at this
> >> point it basically creates a window, does some other stuff and quits. So
> >> a window is quickly created and destroyed - that also causes freezes,
> >> typically short ones. Once the system froze while I was downloading a
> >> file. The LED indicating disk activity kept flashing as well as the LEDs
> >> in the Ethernet port. During a long freeze the fans spin faster judging
> >> by the noise. Overall the graphical side feels more sluggish that in
> >> 6.1, I don't use the console for anything but logging in and starting X.
> >>
> >> In 'messages' (a copy of /var/log/messages) look for 'Resetting chip
> >> after gpu hang' as well as the error messages at the start.
> > 
> > There's not a lot of RAM. Is the system swapping?
> 
> No. top gives me:
> 
> load averages:  0.06,  0.11,  0.06localhost 20:41:54
> 65 processes: 64 idle, 1 on processor  up 1 day,  6:48
> CPU0 states:  2.1% user,  0.0% nice,  0.8% system,  0.3% interrupt,
> 96.8% idle
> CPU1 states:  2.4% user,  0.0% nice,  1.2% system,  0.0% interrupt,
> 96.4% idle
> Memory: Real: 409M/1015M act/tot Free: 918M Cache: 322M Swap: 0K/2055M
> 
> and that's a common picture. I ran top right after a couple of freezes
> and got a similar output. I use i3, lxterminal, and vim/neovim for most
> of my work and I'm writing this in Thunderbird. Also in that situation
> when I was downloading a file I was using a cli program so it looks like
> only X was affected by the freeze.
> 

Thanks, that was one possible cause and easy enough to check. I have
run into similar problems myself (usually worse when certain processes
exited, chromium was the big one, mpv was fairly bad too), though
I haven't hit it recently.

Not sure what else to suggest but if you can catch top -S output while
it's hitting the problem (just before/after?) it might give some clues,
especially the WAIT column.

Re: /etc/daily in 6.2

[Stuart Henderson]

On 2017/12/05 19:07, Szilveszter Ciurdar wrote:
> I was updating an old system with root filesystem on CF so I disabled
> the daily email on line 179 in /etc/daily. I happened to find why my
> tmux session detached at 1:30am and woke up to a failed kernel build.
> Could you fix this problem for everyone who might leave their session
> overnight so it does not remove anything tmux related from /tmp?

Many of us have tmux sessions open for weeks if not months so there's
no general problem. /etc/daily already skips tmux files in /tmp, and
various others (those related to ssh, X11, vi).

Re: panic: vmxnet3_getbuf: buffer has mbuf

[Stuart Henderson]

https://marc.info/?l=openbsd-bugs&m=149256099403302&w=2
On 2017/04/19 01:16, Stuart Henderson wrote:
> panic: vmxnet3_getbuf: buffer has mbuf

https://marc.info/?l=openbsd-bugs&m=150028524915195&w=2
On 2017/07/17 10:53, Stuart Henderson wrote:
> I ran into "vmxnet3_getbuf: buffer has mbuf" on an esxi VM (5.5.0 -
> VM version 8) running librenms and unifi (java/mongodb). Lots of snmp
> fetches, lots of disk io from rrdtool, fairly high memory utilisation.

https://marc.info/?l=openbsd-bugs&m=150641651900601&w=2
On 2017/09/26 10:01, Stuart Henderson wrote:
> panic occurred with rsync-over-ssh copying a ~50MB file to the machine.
> active processes according to the auto-listing at panic: sshd, softnet

Still hitting these, latest was on 6.2 + syspatches.

I'm switching to ethernet0.virtualDev = "e1000" to see how that goes.
If anyone has a suggestion for something that would get useful debug
out of it I can switch back.

panic: vmxnet3_getbuf: buffer has mbuf
Stoppped at db_enter+0x5
tidpid   uid prflags pflags cpu command
344935 91229 0   0x14000 0x200  1   softnet

trace:

db_enter
panic
vmxnet3_getbuf+0x117
vmxnet3_rxintr+0x2bc
vmxnet3_intr+0x70
intr_handler+0x5e
Xintr_ioapic_level10+0xd0
--- interrupt ---
end of kernel
end trace frame: 0xc748faffdc9cbbe9, count: 8
acpi_pdirpa+0x669c78:

OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017

r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6425608192 (6127MB)
avail mem = 6223851520 (5935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 04/14/2014
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) 
S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) 
PE50(S3) S1F0(S3) [...]
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) Xeon(R) CPU E5630 @ 2.53GHz, 2533.39 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2533385710 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2533.87 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2534.02 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2534.17 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
"PNP0001" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0400" at acpi0 not configured
"PNP0700" at acpi0 not configured
acpiac0 at acpi0: AC unit online
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 

Re: Openbsd 6.2 will not load on hardware that runs 6.1

[Stuart Henderson]

On 2018/01/10 00:36, Barnaby Wilmott wrote:
> I think this problem is not something I can fix without help but I would
> appreciate some ideas.  Should I just continue using 6.1 and hope it gets
> fixed in 6.3?

Can you try booting a snapshot kernel?

(For ease of testing you can download the kernel to / under a different
name and "boot " at the boot loader prompt. Not much point
doing a normal upgrade and updating userland unless that gets further
than the 6.2 kernel).

Re: Openbsd 6.2 will not load on hardware that runs 6.1

[Stuart Henderson]

On 2018/01/10 17:29, Stuart Henderson wrote:
> On 2018/01/10 00:36, Barnaby Wilmott wrote:
> > I think this problem is not something I can fix without help but I would
> > appreciate some ideas.  Should I just continue using 6.1 and hope it gets
> > fixed in 6.3?
> 
> Can you try booting a snapshot kernel?
> 
> (For ease of testing you can download the kernel to / under a different
> name and "boot " at the boot loader prompt. Not much point
> doing a normal upgrade and updating userland unless that gets further
> than the 6.2 kernel).
> 

Barnaby replied off list with more information - hang in 6.2/snap occurs at the
point where inteldrm switches mode - boots OK with inteldrm disabled, dmesg like
that below.



- Forwarded message from Barnaby Wilmott  
-

From: Barnaby Wilmott 
Date: Thu, 11 Jan 2018 19:30:33 +
To: Stuart Henderson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 
Thunderbird/52.5.0
Subject: Re: Openbsd 6.2 will not load on hardware that runs 6.1

Stuart,

Many thanks again.

I have no problem with you posting to the buglist.  At least if you do it, I
will not fall foul of any protocols!

By changing a couple of file names, I have organised such that my (essentially
6.1) system will boot to bsd.mp from the released 6.2.

With inteldrm disabled, the boot completes, there is no change of font during
the start process and I can login on the network with ssh, allowing me to
generate and capture dmesg output.

The dmesg listing is...

OpenBSD 6.2 (GENERIC.MP) #166: Tue Oct  3 19:58:05 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("GenuineIntel" 686-class) 1.80
GHz
cpu0: 
FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
real mem  = 3654131712 (3484MB)
avail mem = 3570016256 (3404MB)
User Kernel Config
UKC> disable inteldrm
250 inteldrm* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xeb510 (72 entries)
bios0: vendor American Megatrends Inc. version "FA" date 02/25/2014
bios0: Gigabyte Technology Co., Ltd. C1037UN-EU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
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.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz ("GenuineIntel" 686-class) 1.80
GHz
cpu1: 
FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
"INT3F0D" at acpi0 not configured
"PNP0400" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
bio

Re: mpd crashes on i386 when no .mpdignore file is present

[Stuart Henderson]

On 2018/01/14 15:00, Florian Viehweger wrote:
> What I don't understand is that the same setup with the same
> configuration files do work under amd64.

There's some bug with mpd on i386, others have run into it too.
It's not a config problem, same with very simple configs.

Re: Disklabel

[Stuart Henderson]

On 2018/01/14 14:02, Jason Green wrote:
> I've been running into some problems with a feature. I'm not looking for 
> technical support, however, it is in the program called disklabel. There are 
> issues with the installer also and I'm not sure if it is a feature or a bug. 
> In the installer, when disklabel is called it displays it in kilobytes, but 
> when when you enter "p" for print it prints it as sectors. So I'm confused 
> what exactly is being displayed when I hit "p".

You can use "p k", "p m", "p g", etc. from disklabel's interactive mode.

> When I drop to a shell (control C) and manually call "disklabel -E -p g sd0" 
> the formatting for "p" displays sectors also. If possible, I would appreciate 
> an individual response.

See SYNOPSIS in the manpage - "-p g" is for this one which just prints
the disklabel:

   disklabel [-Acdtv] [-h | -p unit] [-T file] disk

The interactive mode (-E) only takes these flags:

   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk

Re: mpd crashes on i386 when no .mpdignore file is present

[Stuart Henderson]

On 2018/01/15 10:42, Florian Viehweger wrote:
> > There's some bug with mpd on i386, others have run into it too.
> > It's not a config problem, same with very simple configs.
> 
> Thank you. Do you have any pointers? A quick search in their (mpd)
> GitHub repo and on marc.info revealed no new information.

Not specifically. There has been a problem with c++ exception handling
and pure/const before (https://github.com/MusicPlayerDaemon/MPD/issues/41)
so my first hunch would be to try with these (in src/Compiler.h) changed.. 

#define gcc_pure __attribute__((pure))
#define gcc_const __attribute__((const))

just define them to nothing i.e.

#define gcc_pure
#define gcc_const

Re: Disklabel

[Stuart Henderson]

On 2018/01/14 18:19, Jason Green wrote:
> Sorry, I'm a noob but in the default install, the disklabel displays sectors, 
> -h in my opinion
> does not work.

disklabel has several modes: display (no extra flag), write (-w),
edit with $EDITOR (-e), edit interactively (-E), restore (-R).

"SYNOPSIS" in the manual page shows which options are available for
the various modes of disklabel.

"-h" and "-p g" are only documented as working for "display" and
do work there:

disklabel -h sd0
disklabel -p g sd0

The interactive mode (-E) does not support these on the command line,
and is not documented as supporting these on the command line.

The interactive mode does support typing "p g" as shown in the table
of commands for this mode. See the paragraph starting "The built-in
label editor (fourth form) provides a simple interactive label editor"
and the paragraphs and table of commands following.

> Partitioning in Archlinux is easy. When I install OpenBSD everything seems ok
> until I get to installblocks and the computer timeouts.  I get "ioctl 
> DIOCWDINFO" error. I used
> -E with -p g and it displays sector only.
> 
> Also I disabled uefi and it installed cleanly.
> 
> I used the amd64 distribution

Sounds like it's somehow related to UEFI then - I've readded
bugs@openbsd.org to CC's because I've not used this on x86 and
maybe someone else will have an idea. Would be good to include
a dmesg.





> 
> 
> On Jan 14, 2018, Stuart Henderson  wrote:
> 
> On 2018/01/14 14:02, Jason Green wrote:
> 
> I've been running into some problems with a feature. I'm not looking 
> for technical
> support, however, it is in the program called disklabel. There are 
> issues with the
> installer also and I'm not sure if it is a feature or a bug. In the 
> installer, when
> disklabel is called it displays it in kilobytes, but when when you 
> enter "p" for print
> it prints it as sectors. So I'm confused what exactly is being 
> displayed when I hit
> "p".
> 
> 
> You can use "p k", "p m", "p g", etc. from disklabel's interactive mode.
> 
> 
> When I drop to a shell (control C) and manually call "disklabel -E -p 
> g sd0" the
> formatting for "p" displays sectors also. If possible, I would 
> appreciate an individual
> response.
> 
> 
> See SYNOPSIS in the manpage - "-p g" is for this one which just prints
> the disklabel:
> 
> disklabel [-Acdtv] [-h | -p unit] [-T file] disk
> 
> The interactive mode (-E) only takes these flags:
> 
> disklabel -E [-Acdnv] [-F|-f file] [-T file] disk
> 
> 

Re: CLEANUP: move mailer.conf to /etc/examples

[Stuart Henderson]

On 2018/01/16 01:52, Clint Pachl wrote:
> Because smtpd was made the default years ago and the fact that
> mailwrapper(8) will invoke smtpd(8) if its configuration file
> (/etc/mailer.conf) is missing, perhaps /etc/mailer.conf can be moved to
> /etc/examples?

If you're changing this, you'll also need to check and maybe adjust how
MTAs in ports handle the situation.  I don't think it's worth it.

> Should it be removed from /etc/changelist?

No - even if moved to examples it should remain there. If this file is
present, changes should be noted in the security mails.

> The "optional" keyword should be added for it in /etc/mtree/special:
> 
> --- /etc/mtree/special  Sat Apr  1 12:38:28 2017
> +++ /etc/mtree/special-new  Tue Jan 16 01:23:22 2018
> @@ -47,7 +47,7 @@
>  ldpd.conf  type=file mode=0600 uname=root gname=wheel optional
>  login.conf type=file mode=0644 uname=root gname=wheel
>  mail.rctype=file mode=0644 uname=root gname=wheel
> -mailer.conftype=file mode=0644 uname=root gname=wheel
> +mailer.conftype=file mode=0644 uname=root gname=wheel optional
>  master.passwd  type=file mode=0600 uname=root gname=wheel
>  monthlytype=file mode=0644 uname=root gname=wheel
>  monthly.local  type=file mode=0644 uname=root gname=wheel optional

optional makes sense.

> The BUGS section for mailwrapper/mailer.conf states that the existence of
> such a system is a "crock". I think we should sweep it into the closet and
> slam the door.

It's ugly but reasonably simple...

Re: Help moving OpenBSD installation to new machine

[Stuart Henderson]

On 2018/01/17 16:52, Randall Gellens wrote:
> At 6:44 PM -0800 1/16/18, Randall Gellens wrote:
> >  I have a new box, a Protectli with a dual core Intel Celeron 3865U.
> 
> Following the advice to do a clean install onto the new box, I did so, with
> OpenBSD 6.2.  The install seemed to go smoothly, initializing the disk and
> fetching file sets.  However, when booting it drops into ddb, although "show
> panic" says the kernel did not panic.
> 
> Attached is a zip file containing text captures of the "dmesg" command (as
> files dmesg-1.txt through dmesg-9.txt) and the "trace", "ps", and "show
> panic" commands (as trace-ps.txt).

I've included a copy of your dmesg and trace inline so others can read
it without unzipping the attachment, etc. (Also CC'd bugs@ because it's
likely to be missed on misc@).

It would be worth trying a -current snapshot on this before spending
more time on debugging. If that does indeed fixes things then you can
just run that and update to 6.3 when it's released. (Also I would
generally suggest running in 64-bit mode by using the amd64 version
rather than the i386 version of OpenBSD. The cpu supports it.)

If that doesn't help but the error is different, send a new trace.

inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 610" rev 0x02
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmwar
e i915/kbl_dmc_ver1.bin (-22)
uvm_fault(0xd0c703b8, 0xd3bca000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  execlists_update_context+0x10f: pushl   0x34(%eax)
ddb{0}> ddb{0}>
ddb{0}> 
ddb{0}> trace
execlists_update_context(d5d12800,d0ed6b94,d08ff4fb,d5d298cc,d5d298c4) at execl
ists_update_context+0x10f
execlists_context_unqueue(d5d298b4,0,d5d298c4,d5d297e4,d5d18f40) at execlists_c
ontext_unqueue+0x178
gen8_emit_request(d5bde0fc) at gen8_emit_request+0x224
__i915_add_request(d5bde0fc,0,0) at __i915_add_request+0x9a
i915_gem_init_hw(d5d20800) at i915_gem_init_hw+0x79c
i915_gem_init(d5d20800) at i915_gem_init+0x1d1
i915_driver_load(d5d20800,d0a9b4f0) at i915_driver_load+0xef4
inteldrm_attach(d5d24980,d5d27000,d0ed6d58) at inteldrm_attach+0x331
config_attach(d5d24980,d0c1a950,d0ed6d58,d06f0f80) at config_attach+0x194
config_found_sm(d5d24980,d0ed6d58,d06f0f80,d06f1040,0) at config_found_sm+0x29
pci_probe_device(d5d24980,80001000,0,0) at pci_probe_device+0x502
pci_enumerate_bus(d5d24980,0,0) at pci_enumerate_bus+0xb9
pciattach(d5bf5100,d5d24980,d0ed6eb8) at pciattach+0xe2
config_attach(d5bf5100,d0c191f0,d0ed6eb8,d06bec90) at config_attach+0x194
config_found_sm(d5bf5100,d0ed6eb8,d06bec90,0) at config_found_sm+0x29
mainbus_attach(0,d5bf5100,0) at mainbus_attach+0x2a6
config_attach(0,d0c190d0,0,0) at config_attach+0x194
config_rootfound(d0b10334,0) at config_rootfound+0xc0
cpu_configure(bd832264,ed4000,ee3000,0,d02004ce) at cpu_configure+0x51
main(0,0,0,0,0) at main+0x4a7
ddb{0}> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
*0   0 -1  0  7 0x10200swapper
ddb{0}> 


OpenBSD 6.2 (GENERIC.MP) #166: Tue Oct  3 19:58:05 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Celeron(R) CPU 3865U @ 1.80GHz ("GenuineIntel" 686-class) 1.70 G
Hz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES
64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC
,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,
SMEP,ERMS,INVPCID,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
real mem  = 2346717184 (2238MB)
avail mem = 2287648768 (2181MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/04/16, SMBIOS rev. 3.0 @ 0x8d318000 (86 entries)
bios0: vendor American Megatrends Inc. version "5.12" date 06/08/2017
bios0: Default string YL-SKUL6
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT SSDT UEFI SSDT L
PIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 SPCR DMAR ASF!
acpi0: wakeup devices PS2K(S0) PS2M(S0) PXSX(S0) RP09(S0) PXSX(S0) RP10(S0) PXS
X(S0) RP11(S0) PXSX(S0) RP12(S0) PXSX(S0) RP13(S0) PXSX(S0) RP01(S0) PXSX(S0) R
P02(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU 3865U @ 1.80GHz ("GenuineIntel" 686-class) 1.80 G
Hz
cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES
64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC
,MOVBE,POPCNT,DEADLINE,

Re: pure-ftpd config file

[Stuart Henderson]

On 2018/01/21 13:02, Torsten Boese wrote:
> Hi,
> 
> I'm using OpenBSD 6.2 and I want to use pure-fptd as a daemon. I activated 
> via 
> 
> # rcctl enable pureftpd 
> 
> the daemon ans its starts as expected. The problem is that pure-ftpd ignors 
> the config file.
> As written in /usr/local/share/doc/pure-ftpd/README.Configuration-File I 
> copied the pure-ftpd.conf in 
> 
> # /etc 
> as well as in 
> 
> # /usr/local/etc/
> . But pure-ftpd ignors the config. If I do  
> 
> # pure-ftpd /etc/etc/pure-ftpd.conf
> 
> the config works.
> 
> Where I have to store the config or what is to do to enable using the config 
> file for the daemon?
> 
> 
> Regards
> 

The rc.d script cannot use the config file. If run with a config file,
pure-ftpd doesn't look at command-line options, so there's no way to
force it to run as a daemon. (Same issue with dnscrypt-proxy).

If you want to use the config file instead of command-line options,
it's probably best to start it from /etc/rc.local.

Re: pure-ftpd config file

[Stuart Henderson]

On 2018/01/22 20:07, Torsten Boese wrote:
> Thanks for your response!
> 
> The solution from Landry works fine for me but I think Stuart's solution 
> would also work. But for my goal to have it in the most clean way to work 
> with rcctl is my way.

I've just had another look at the rc script, you can do this:

# rcctl enable pure_ftpd
# rcctl set pure_ftpd flags /etc/pure-ftpd.conf

Make sure "Daemonize yes" is set in the config file.

The only real advantage to doing it this way is that you can comment
the config file, there are no extra settings available - everything
in the file can also be set on the command line.


On 2018/01/21 15:08, Landry Breuil wrote:
> 
> I know debian has/had a perl script which parses a config directory with
> one file by option, which are translated to commandline switches at 
> startup, but that wasnt upstream.

There are two scripts (perl and python) in the pure-ftpd distribution to
do this. They aren't needed any more though, pure-ftpd handles config
files internally.

Re: pf table cannot contain multiple PFRKE_ROUTE to same IP on different interfaces

[Stuart Henderson]

When I used route-to with pppoe before, it didn't matter what IP address 
was used (as a point-to-point interface, no link layer address is needed, 
only the interface). It might have changed now (it definitely has changed 
for normal routing, but perhaps not with route-p), but it's worth a try.


Specifically just try it with different dummy addresses for each interface 
(e.g. 10.0.0.100@tun0, 10.0.0.101@tun1) and see if that works.


--
 Sent from a phone, apologies for poor formatting.



On 30 January 2018 05:25:28 NOP  wrote:


Dear OpenBSD developers,

In packet filter, it is not possible to define a "route-to" rule with
multiple destinations having the same IP address but on different
interfaces.

Minimal example to reproduce the problem:

# cat /etc/hostname.lo5
rdomain 5
inet 127.0.0.1 255.0.0.0
# cat /etc/hostname.lo6
rdomain 6
inet 127.0.0.1 255.0.0.0
# cat /etc/pf.conf
pass in on vio0 to 123.123.123.123 route-to { (lo5 127.0.10.1), (lo6
127.0.10.1) } round-robin
# pfctl -f /etc/pf.conf -v
table <__automatic_5854be65_0> const { 127.0.10.1@lo5 127.0.10.1@lo6 }
pass in on vio0 inet from any to 123.123.123.123 flags S/SA route-to
<__automatic_5854be65_0> round-robin
# pfctl -T show -t __automatic_5854be65_0
   127.0.10.1@lo5

In practice, I need this for routing traffic to several OpenVPN tunnels
in a round-robin fashion. Unfortunately, my VPN provider uses the same
gateway IP for all their servers.

pass in on vlan123 route-to { (tun0 tun0:peer), (tun1 tun1:peer) }
round-robin


The second address is not added because of this:
- In /sys/net/pf_table.c:1653, in the pfr_ina_define function, the call
to pfr_lookup_addr returns non NULL
- In /sys/net/pf_table.c:815, in the pfr_lookup_addr function, rn_match
returns non NULL
- In /sys/net/radix.c:263-265, in the rn_match function, the for loops
checks for differences in the IP prefix, does not find any and returns
the existing node in the tree.

The problem is that only the IP address and mask are taken into
consideration when searching a node in the radix tree, the interface is
ignored. Therefore it's not possible to store two nodes with the same IP
but different interfaces (127.0.10.1@lo5 and 127.0.10.1@lo6).

Unfortunately, I did not manage to understand in details how the radix
tree worked, especially the nodes ordering so I was not able to patch it
to add the interface information.

Can someone who knows this code better try to fix this problem or point
me in the right direction?

Thanks a lot for all your work on OpenBSD and thank you in advance for
your help.

Kind regards,

NOP

Re: duplicated 127.0.0.1/8 ip in lo0, impacts smtpd

[Stuart Henderson]

On 2018/02/14 05:01, Jiri B wrote:
> OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

please uodate.

Re: When installing to softraid, the OS installer creates an unnecessary EFI volume inside the softraid

[Stuart Henderson]

On 2018/02/15 03:57, Tinker wrote:
> When you run the installer (e.g. flash "install62.fs" onto an USB
> memory stick) and install onto a softraid (e.g. by going into (S)hell
> mode at boot, creating a GPT partition table on your system drive e.g.
> "fdisk -igy -b 960 sd0", creating a softraid on sd0 using "bioctl" that
> then appears as sd2, and then install the OS on sd2), the installer
> will create an EFI boot partition on the inner softraid, even though
> that partition never will be used.

Not a huge surprise as the installer doesn't support softraid...
you can go behind its back and have some things work, but as you've
seen it isn't perfect.

Re: llvm issue

[Stuart Henderson]

On 2018/02/23 17:21, Jordon wrote:
> I am running the latest snapshot (Feb 21) and discovered that some changes I
> made to my hobby project this evening make clang++ crash.  It builds find on
> linux with clang 3.8 and a High Sierra machine running whatever version
> Apple ships with that.

No crash here, but it does use 1.6GB during compile. Try raising memory
limits in login.conf (you'll need a new login session, which might mean
restarting X). Or try restricting with ulimit to see if you can trigger
the crash on other OS.

The SEGV is most likely to be due to a malloc without a return code check.

acme-client races

[Stuart Henderson]

I'm seeing some "write: cert: Broken pipe" from my acme-client cron
jobs, it looks like there's a race somewhere:

acme-client: /etc/ssl/private/symphytum.spacehopper.org.key: loaded RSA domain 
key
acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: /etc/ssl/symphytum.spacehopper.org.crt: certificate valid: 50 days 
left
acme-client: write: cert: Broken pipe
acme-client: bad exit: keyproc(43738): 1

Running it in a tight loop I'm seeing it on 15/1000 calls, but seem to be
hitting it much more often than this in cronjobs.

May be connected, even without the bad exit, the output of a normal run
isn't in a consistent order:

run1:acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
run1:acme-client: /etc/ssl/symphytum.spacehopper.org.crt: certificate valid: 50 
days left
run1:acme-client: /etc/ssl/private/symphytum.spacehopper.org.key: loaded RSA 
domain key

run10:acme-client: /etc/ssl/private/symphytum.spacehopper.org.key: loaded RSA 
domain key
run10:acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
run10:acme-client: /etc/ssl/symphytum.spacehopper.org.crt: certificate valid: 
50 days left

run225:acme-client: acme-client: 
/etc/ssl/private/symphytum.spacehopper.org.key: loaded RSA domain 
key/etc/acme/letsencrypt-privkey.pem: loaded RSA account key
run225:acme-client: /etc/ssl/symphytum.spacehopper.org.crt: certificate valid: 
50 days left

run344:acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
run344:acme-client: /etc/ssl/symphytum.spacehopper.org.crt: certificate valid: 
50 days left
run344:acme-client: /etc/ssl/private/symphytum.spacehopper.org.key: loaded RSA 
domain key
run344:acme-client: write: cert: Broken pipe
run344:acme-client: bad exit: keyproc(8172): 1

Re: [PATCH] Fix telnet not sending return

[Stuart Henderson]

On 2015/03/29 14:16, Mark Kettenis wrote:
> > I think we should either take Fred's diff, or revert the previous
> > change. Any preferences? The ability to use telnet to connect to some of
> > the affected devices is more important now that ssh no longer supports
> > v1.
> 
> Revert the diff.  It introduced regressions so it is wrong.  We can
> consider a better diff afterwards.
> 

Yes, that makes sense. Done.

Re: A problem internal to GDB has been detected.

[Stuart Henderson]

On 2015/04/01 20:59, Jiri B wrote:
> I get following output when using gdb:
> 
> ~~~
> $ gdb /usr/local/lib/libreoffice/program/soffice.bin soffice.bin.core

You may get further with the newer gdb from ports. But even then
libreoffice might be a bit too much for it.

Re: Lenovo G50-70 : kernel panic for sh /etc/netstart (current apr 1, amd64, re0, bsd.mp - reproducible)

[Stuart Henderson]

Hi Adam. Are you able to build a kernel with the last re(4)
commits reverted to make sure that didn't introduce a bug?
If not then I could build one for you to test (let me know which arch).

-
PatchSet 4925 
Date: 2015/03/20 12:04:09
Author: dlg
Branch: HEAD
Tag: (none) 
Log:
add support for jumbos on re(4).

this uses hints from the freebsd driver, but the implementation
differs.

freebsd manages two lists of rx descriptors. one for "normal" packets
and the other for jumbos. this continues to use a single list and
uses a per softc variable and MCLGETI to always allocate what the
chip is capable and uses it unconditionally.

other than that, we just need to enable some bits in some registers
to be able to do jumbos.

this relies on the previous commit to properly deal with checksum
offload for packets of different sizes.

from jim smith
ok sthen@

Members: 
re.c:1.176->1.177 
rtl81x9reg.h:1.92->1.93 

Index: src/sys/dev/ic/re.c
diff -u src/sys/dev/ic/re.c:1.176 src/sys/dev/ic/re.c:1.177
--- src/sys/dev/ic/re.c:1.176   Fri Mar 20 11:55:10 2015
+++ src/sys/dev/ic/re.c Fri Mar 20 12:04:09 2015
@@ -1,4 +1,4 @@
-/* $OpenBSD: re.c,v 1.176 2015/03/20 11:55:10 dlg Exp $*/
+/* $OpenBSD: re.c,v 1.177 2015/03/20 12:04:09 dlg Exp $*/
 /* $FreeBSD: if_re.c,v 1.31 2004/09/04 07:54:05 ru Exp $   */
 /*
  * Copyright (c) 1997, 1998-2003
@@ -173,6 +173,8 @@
 intre_ifmedia_upd(struct ifnet *);
 void   re_ifmedia_sts(struct ifnet *, struct ifmediareq *);
 
+void   re_set_jumbo(struct rl_softc *);
+
 void   re_eeprom_putbyte(struct rl_softc *, int);
 void   re_eeprom_getword(struct rl_softc *, int, u_int16_t *);
 void   re_read_eeprom(struct rl_softc *, caddr_t, int, int);
@@ -210,6 +212,10 @@
CSR_WRITE_1(sc, RL_EECMD,   \
CSR_READ_1(sc, RL_EECMD) & ~x)
 
+#define RL_FRAMELEN(mtu)   \
+   (mtu + ETHER_HDR_LEN + ETHER_CRC_LEN +  \
+   ETHER_VLAN_ENCAP_LEN)
+
 static const struct re_revision {
u_int32_t   re_chipid;
const char  *re_name;
@@ -1026,8 +1032,10 @@
 
/* Create DMA maps for RX buffers */
for (i = 0; i < RL_RX_DESC_CNT; i++) {
-   error = bus_dmamap_create(sc->sc_dmat, MCLBYTES, 1, MCLBYTES,
-   0, 0, &sc->rl_ldata.rl_rxsoft[i].rxs_dmamap);
+   error = bus_dmamap_create(sc->sc_dmat,
+   RL_FRAMELEN(sc->rl_max_mtu), 1,
+   RL_FRAMELEN(sc->rl_max_mtu), 0, 0,
+   &sc->rl_ldata.rl_rxsoft[i].rxs_dmamap);
if (error) {
printf("%s: can't create DMA map for RX\n",
sc->sc_dev.dv_xname);
@@ -1042,8 +1050,7 @@
ifp->if_ioctl = re_ioctl;
ifp->if_start = re_start;
ifp->if_watchdog = re_watchdog;
-   if ((sc->rl_flags & RL_FLAG_JUMBOV2) == 0)
-   ifp->if_hardmtu = sc->rl_max_mtu;
+   ifp->if_hardmtu = sc->rl_max_mtu;
IFQ_SET_MAXLEN(&ifp->if_snd, RL_TX_QLEN);
IFQ_SET_READY(&ifp->if_snd);
 
@@ -1163,7 +1170,7 @@
u_int32_t   cmdstat;
int error, idx;
 
-   m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+   m = MCLGETI(NULL, M_DONTWAIT, NULL, RL_FRAMELEN(sc->rl_max_mtu));
if (!m)
return (ENOBUFS);
 
@@ -1172,7 +1179,7 @@
 * alignment so that the frame payload is
 * longword aligned on strict alignment archs.
 */
-   m->m_len = m->m_pkthdr.len = RE_RX_DESC_BUFLEN;
+   m->m_len = m->m_pkthdr.len = RL_FRAMELEN(sc->rl_max_mtu);
m->m_data += RE_ETHER_ALIGN;
 
idx = sc->rl_ldata.rl_rx_prodidx;
@@ -1311,8 +1318,12 @@
BUS_DMASYNC_POSTREAD);
bus_dmamap_unload(sc->sc_dmat, rxs->rxs_dmamap);
 
-   if (!(rxstat & RL_RDESC_STAT_EOF)) {
-   m->m_len = RE_RX_DESC_BUFLEN;
+   if ((sc->rl_flags & RL_FLAG_JUMBOV2) != 0 &&
+   (rxstat & (RL_RDESC_STAT_SOF | RL_RDESC_STAT_EOF)) !=
+   (RL_RDESC_STAT_SOF | RL_RDESC_STAT_EOF)) {
+   continue;
+   } else if (!(rxstat & RL_RDESC_STAT_EOF)) {
+   m->m_len = RL_FRAMELEN(sc->rl_max_mtu);
if (sc->rl_head == NULL)
sc->rl_head = sc->rl_tail = m;
else {
@@ -1346,8 +1357,9 @@
 * if total_len > 2^13-1, both _RXERRSUM and _GIANT will be
 * set, but if CRC is clear, it will still be a valid frame.
 */
-   if (rxstat & RL_RDESC_STAT_RXERRSUM && !(total_len > 8191 &&
-   (rxstat & RL_RDESC_STAT_ERRS) == RL_RDESC_STAT_GIANT)) {
+   if ((rxstat & RL_RDESC_STAT_RXERRSUM) != 0 &&
+   !(rxstat & RL_RDESC_STAT_RXERRSUM && !(total_len > 8191 &&
+  

Re: Lenovo G50-70 : kernel panic for sh /etc/netstart (current apr 1, amd64, re0, bsd.mp - reproducible)

[Stuart Henderson]

On 2015/04/04 14:40, Adam Wolk wrote:
> On Sat, Apr 4, 2015, at 01:53 PM, Stuart Henderson wrote:
> > Hi Adam, you can find kernels that are quite likely to be identical to
> > before that commit
> > if
> > you'd like to give that a try.
> > 
> 
> I did a test with the kernels you provided. Here are the results.

Thanks, so the re(4) jumbo changes are exonerated. I suspect there
may be some other kernel memory corruption taking place which is just
being discovered when the network is coming up.

I'm not the best person to help track this down but I'm wondering if
there is possibly some acpi related issue. It might be useful to
get "machine mem" output from the boot loader and the files generated
by 'acpidump -o /tmp/machinename'. Hopefully someone else can make
suggestions too.



> bsd.sp
>  OpenBSD 5.7 (GENERIC) #825: Sun Mar 8 10:59:14 MDT 2015
>  DHCPDISCOVER on startup doesn't receive a network address (same as new
>  one) - no crash
>  sh /etc/netstart results in panic:
> 
> Note that I'm copying this by hand. If something is 'off' then I
> probably mistyped.
> I have the kernel currently sitting at the ddb prompt - not rebooting
> yet.
> 
> panic: pool_do_get: mc12k free list modified: page 0xff00a569d000;
> item addr 0xff00a569d000; offset 0x0=0x1000608c1aa77cc1 !=
> 0xa23fc8f9e7243410
> Stopped at Debugger+0x9:   leave
> ddb> trace
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> pool_do_get() at pool_do_get+0x2ee
> pool_get() at pool_get+0xb5
> m_clget() at m_clget+0x51
> re_newbuf() at re_newbuf+0x32
> re_rx_list_fill() at re_rx_list_fill+0x35
> re_rxeof() at re_rxeof+0x35e
> re_intr() at re_intr+0x19b
> intr_handler() at intr_handler+0x28
> Xintr_ioapic_edge19() at Xintr_ioapic_edge19+0xdd
> --- interrupt ---
> Bad frame pointer: 0x800032c1cf10
> end trace frame: 0x800032c1cf10, count: -11
> cpu_idle_cycle+0x13:
> ddb>

Re: Panic: malloc: out of space in kmem_map

[Stuart Henderson]

On 2015/04/04 18:16, Ted Unangst wrote:
> Evgeniy Sudyr wrote:
> > How can I help identify this bug, so developers can fix it :)
> 
> Run sudo pstat -d ld acpi_nalloc; then wait some time and run it again. Though
> this looks like it could be a bug not in the OpenBSD ACPI code, but in the
> interpreted AML code.

The bios is old. There doesn't appear to be a changelog but it may be worth
updating it, however there is always some risk in doing this..

Re: X11 font path changed

[Stuart Henderson]

On 2015/04/09 11:39, Norman Golisz wrote:
> After upgrading to the latest snapshot I found that the path for
> third-party fonts changed from /usr/local/lib/X11/fonts to
> /usr/local/share/fonts.
> 
> Is it worth to be mentioned on current.html?

Is this still a problem? I think you should be OK without changing
this with current (April 5 or newer) X snapshots.

> Index: current.html
> ===
> RCS file: /cvs/www/faq/current.html,v
> retrieving revision 1.595
> diff -u -p -u -r1.595 current.html
> --- current.html4 Apr 2015 09:29:08 -   1.595
> +++ current.html9 Apr 2015 09:34:15 -
> @@ -502,6 +502,15 @@ Modify /etc/rc.conf.local accor
> perl -pi -e 's/dbus_daemon/messagebus/;' -e 
> 's/puppetmasterd/puppetmaster/;' -e 's/puppetd/puppet/;' /etc/rc.conf.local
>  
>  
> +2015/04/09 - X11 font path changed
> +The path to third-party fonts has changed. If you have configured
> +additional fonts in your /etc/X11/xorg.conf, you need to change the
> +path from /usr/local/lib/X11/fonts to /usr/local/share/fonts:
> +
> +
> +   perl -pi -e 
> 's/\/usr\/local\/lib\/X11\/fonts/\/usr\/local\/share\/fonts/;' 
> /etc/X11/xorg.conf
> +
> +
>  
>  
>  $OpenBSD: current.html,v 1.595 2015/04/04 09:29:08 jasper Exp 
> $
> 

tmux crash, mar 8 snap (5.7 ish)

[Stuart Henderson]

I'm not sure how much use this is without symbols, but thought I should
mention it anyway. I was just typing into tmux->ssh->mutt at the time.

Core was generated by `tmux'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/bin/tmux
Reading symbols from /usr/lib/libutil.so.12.1...done.
Loaded symbols for /usr/lib/libutil.so.12.1
Reading symbols from /usr/lib/libcurses.so.14.0...done.
Loaded symbols for /usr/lib/libcurses.so.14.0
Reading symbols from /usr/lib/libevent.so.4.1...done.
Loaded symbols for /usr/lib/libevent.so.4.1
Reading symbols from /usr/lib/libc.so.78.1...done.
Loaded symbols for /usr/lib/libc.so.78.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x0d5772447633 in tty_cmd_insertline () from /usr/bin/tmux
(gdb) bt
#0  0x0d5772447633 in tty_cmd_insertline () from /usr/bin/tmux
#1  0x0d5772447a3d in tty_cmd_insertline () from /usr/bin/tmux
#2  0x0d577244856f in tty_cmd_insertline () from /usr/bin/tmux
#3  0x0d5772450b2c in tty_cmd_insertline () from /usr/bin/tmux
#4  0x0d577242e146 in control_callback () from /usr/bin/tmux
#5  0x0d5772433522 in control_callback () from /usr/bin/tmux
#6  0x0d5772437160 in control_callback () from /usr/bin/tmux
#7  0x0d577243861d in server_client_callback ()
   from /usr/bin/tmux
#8  0x0d59c57191a8 in event_base_loop (base=0xd5a215d9000,
flags=Variable "flags" is not available.
) at /usr/src/lib/libevent/event.c:350
#9  0x0d577243aaa0 in server_client_callback ()
   from /usr/bin/tmux
#10 0x0d577243b05a in server_client_callback ()
   from /usr/bin/tmux
#11 0x0d57724128d2 in cfg_default_done () from /usr/bin/tmux
#12 0x0d57724129c8 in cfg_default_done () from /usr/bin/tmux
#13 0x0d57724420a0 in server_client_callback ()
   from /usr/bin/tmux
#14 0x0d577240fdb1 in ?? () from /usr/bin/tmux
#15 0x in ?? ()

Re: tmux crash, mar 8 snap (5.7 ish)

[Stuart Henderson]

On 2015/04/17 10:22, Mark Kettenis wrote:
> > Date: Fri, 17 Apr 2015 09:04:26 +0100
> > From: Nicholas Marriott 
> > 
> > Hi
> > 
> > No not much use without symbols unfortunately.
> 
> Stuart,
> 
> If your didn't update your source tree, building tmux with make
> DEBUG=-g and it should be possible to use the new binary to produce
> backtraces with the old core dump.  Just ignore the warning that GDB
> gives you ;).
> 
> Do check though that the optimization options don't change if you pass
> DEBUG=-g.  Sometimes that leaves off the -O2 option.  In that case,
> build with DEBUG="-g -O2".  If you're paranoid you can disassemble the
> critical bits of code in the original binary and compare with the new
> binary.

I tried that already on the off chance (though wasn't expecting much as I was
running a snapshot rather than my own build), but it didn't produce usable 
results.

(gdb) bt
#0  0x0d5772447633 in ?? ()
#1  0x7f7c4510 in ?? ()
#2  0x0d577255a990 in ?? ()
#3  0x0d5a16e24680 in ?? ()
#4  0x6000 in ?? ()
#5  0x0d5991538000 in ?? ()
#6  0x7f7c4510 in ?? ()
#7  0x0018304ba610 in ?? ()
#8  0x0001 in ?? ()
#9  0x201108089560 in ?? ()
#10 0x in ?? ()

Actually, it seems if I try that with any program with known consistent source
(e.g. build games/rain without -g, run it, send it -ABRT, rebuild with -g,
run gdb) I get similar useless traces.

Re: Predictable Timeout on ThinkPad X201 Intel Centrino Advanced-N 6200 (iwn)

[Stuart Henderson]

On 2015/04/20 13:23, mm...@mykolab.com wrote:
> I run snapshots and upgrading frequently, installing most that are
> released.
> 
> My wireless predictably times out after a minute or two on two
> different WPA wireless networks.
> 
> This is particularly noticeable and disruptive on boot disks, which
> I use pretty frequently because I run snapshots. It seems eerily
> consistent, maybe to the point that it's based on how much data is
> moved. Specifically, it usually times out when the base tarball is
> almost finished downloading (last time, it was at 93%).
> 
> Other than this strange issue, my wifi connection is strong and
> robust. It rarely loses connection.
> 
> Let me know if you have any idea what could be causing this. I can
> try running the interface in debug mode if that'd help.

Running the interface in debug mode would definitely be worth trying.
Just "ifconfig iwn0 debug", and watch dmesg / /var/log/messages.

Re: typo in pf.conf - allow X11 connections from external interface

[Stuart Henderson]

On 2015/04/26 12:48, Danilo Falcão wrote:
> Closed means the range 6000:6009 isn't  filtered when I want only 22 to be
> open.

That's incorrect.

> > > *block return in on ! lo0 proto tcp to port 6000:6010*

This rule says:

"Block TCP packets to port 6000-6010 coming in on any interface other than lo0,
and return an ICMP port unreachable message when anybody tries".

Some people might prefer it without the "port unreachable" message in which case
they can change "return" to "drop".

By removing the !, you have changed it to blocking 6000-6010 on the
loopback but permitting them on all other interfaces.

Re: Missing libtasn1-4.5.tgz package

[Stuart Henderson]

On 2015/05/02 21:31, Daniel Boerner wrote:
> Hi,
> 
> For the i386 port of the snapshot branch, package libtasn1-4.5.tgz is
> listed in the file SHA256 but it isn't actually present in the package
> mirror for download.

Which mirror? The one I just checked has it. In any event, give it a day or
two in case it was mid-sync.

> For the amd64 port the package listed in the file SHA256 is
> libtasn1-4.4.tgz instead of libtasn1-4.5.tgz. It seems that the amd64 port
> package is one version behind the i386 package.

They are built separately.

Re: em0 interface on Lenovo T60 hangs starting as of OpenBSD 5.7

[Stuart Henderson]

Not sure if it will help, but it might be useful to show 'systat mb' and 
'sysctl kern.netlivelocks'. You mention updating packages, I've definitely had 
systems which have been pretty much flattened with netlivelocks/mitigation 
while doing this, perhaps some em(4) don't react very well to this...?

On 3 May 2015 01:13:19 BST, Bryan Linton  wrote:
>On 2015-05-02 00:16:43, Christian Schulte  wrote:
>> >Synopsis:   After some time (minutes or seconds) the em0 interface
>stops working
>> >Category:   system
>> >Environment:
>>  System  : OpenBSD 5.7
>>  Details : OpenBSD 5.7-stable (GENERIC.MP) #0: Fri May  1
>23:59:46 CEST 2015
>>   
>> r...@t60.schulte.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>>  Architecture: OpenBSD.amd64
>>  Machine : amd64
>> >Description:
>>  Following is the contents of the /etc/hostname.em0 file:
>> 
>>  inet 192.168.10.50 255.255.255.0 192.168.10.255
>> 
>>  The em0 interface works as expected. After some time it stops
>> working. Processes currently transmitting data will show a
>> (Broken pipe) error. Doing ifconfig em0 down && sh
>/etc/netstart
>> the interface starts working again for some time and than
>hangs
>> again.
>> 
>> >How-To-Repeat:
>>  The issue is reproducible by simply using the em0 interface.
>> >Fix:
>>  ifconfig em0 down && sh /etc/netstart
>> 
>> [...]
>>
>
>I wonder if this is the same thing that I mentioned here: 
>   http://marc.info/?l=openbsd-misc&m=141007061612003&w=2
>Though I don't get a "(Broken pipe)" error, em0 just hangs and won't
>transmit
>packets.
>
>In a nutshell, CPU activity causes em0 to hang on both my T60 and X61t
>laptops.
>
>Provided I don't do CPU intensive activities, it can run fine for days,
>
>or potentially weeks at a time.  However, running bogofilter (which
>I've stopped
>using since it wedged the network reliably every time I'd fetch my
>email), 
>compiling a large port (smaller ones don't tend to wedge it, only
>larger ones
>that take at least several minutes to compile seem to) or just trying
>to do 
>something like fetch and upgrade packages, or just going to a CPU
>intensive 
>webpage like google maps will invariably cause the network to wedge.
>
>Neither machine will send or receive packets, including responding to
>ping 
>requests when this happens.
>
>If I need to update packages or compile something, I'll usually just
>run a 
>script like the following so I don't need to babysit the computer:
>   while true; do sleep 25 && ifconfig em0 down up && sleep 1 && ifconfig
>em0 down up && echo ping; done
>
>I was contacted privately by a developer and sent a few patches to the
>UVM and 
>softraid systems which caused them to KERNEL_LOCK() and KERNEL_UNLOCK()
>in a 
>few key places which has helped a lot, but the network will still lock
>up 
>reliably with heavy CPU activity.
>
>All I can say is that I first noticed this when I upgraded from a
>mid-July 2014
>snap to an early-September 2014 snap, which I know is a very large
>window.  I've 
>unfortunately been too busy to try to go back and figure out what
>change caused 
>this, and have been getting by with the above script when necessary.
>
>I've seen a lot of work done on the networking code and in UVM over the
>last 
>year or so, so I've been upgrading to newer snaps as they've been
>released
>hoping that they'd fix it, but it seems like the problem may lie
>somewhere 
>else or be obscure or specific to my setup.
>
>I've just assumed that since no one else has reported this problem,
>that there 
>was something unique about my system or setup that was causing this,
>which 
>would tend to lower the severity of this bug since as far as I knew up
>until 
>now, I was the only one affected by it.
>
>I realize this is a rather poor bug report, but hopefully by at least
>mentioning 
>the fact that a few key KERNEL_LOCK()/KERNEL_UNLOCK() calls sprinkled
>around 
>some UVM and softraid code reduce the occurance of this bug, it at
>least gives 
>someone a somewhat smaller target to look at.
>
>I can provide more information if necessary.  A dmesg from the T60
>(with the 
>above mentioned patches applied) follows:

-- 
Sent from a phone, please excuse the formatting.

Re: Abort trap -- amd64 OpenBSD 5.7

[Stuart Henderson]

On 2015/05/03 19:49, Ken.Dickey wrote:
> Perhaps src.tar.gz should follow the common pattern...

This would help this problem (which I've done myself before) but loses
a valuable learning experience: never untar files to a system directory
like this (or even your home directory, etc) if you haven't checked the
contents.

Say this file (which is probably downloaded over http without any
authentication/verification) had src/ prefixes and you unpack in /usr.
But somewhere tucked away in the middle of the file is a malicious
lib/libc.so.* file that overwrites your real one and introduces a
hole. That wouldn't be good...

It's always safer to untar in a newly created or scratch directory.

Re: Ipsec NAT multiple subnets to same source ip

[Stuart Henderson]

On 2015/05/08 11:05, Erwin Schliske wrote:
> Hello,
> 
> I have one question regarding ipsec with NAT.
> 
> With one customer I have to setup a site2site vpn. To avoid address
> conflicts I'd use NAT. Because multiple of our subnets have to use the
> tunnel, I have this config in ipsec.conf:
> 
> ike esp from {192.168.10.0/24 (192.168.1.0/24),192.168.10.0/24 (
> 192.168.2.0/24),192.168.10.0/24 (192.168.3.0/24)} to 10.78.1.0/24 \
>  peer  \
>  local  \
>  main auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 28800 \
>  quick auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 3600 \
>  psk XX

Can you just use this?

ike esp from {192.168.10.0/24 (192.168.0.0/22)} to 10.78.1.0/24 [...]

This would mean that 192.168.0.0/24 is covered in the flow as well, but
unless you also have a matching NAT rule, packets from 192.168.0.0 won't
make it through.

Re: Ipsec NAT multiple subnets to same source ip

[Stuart Henderson]

On 2015/05/08 11:45, Erwin Schliske wrote:
> >
> > Can you just use this?
> >
> > ike esp from {192.168.10.0/24 (192.168.0.0/22)} to 10.78.1.0/24 [...]
> >
> > This would mean that 192.168.0.0/24 is covered in the flow as well, but
> > unless you also have a matching NAT rule, packets from 192.168.0.0 won't
> > make it through.
> 
> 
> This would do it with my example. In real life I have subnets from 10/8 and
> 172.16/12 range. So this workaround is unfortunately not possible.

It might possibly work with 0.0.0.0/0 (though obviously this requires
more care with pf rules). I've done similar but it fits into 192/6 so it
avoids the possible corner case of a /0 prefix length.

Re: em0 interface on Lenovo T60 hangs starting as of OpenBSD 5.7

[Stuart Henderson]

On 2015/05/09 17:10, Brad Smith wrote:
> On Sun, May 03, 2015 at 12:16:21PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 3 May 2015 02:38:12 -0700
> > > From: Bryan Linton 
> > > 
> > > The key difference is the following two lines.  The first wedged,
> > > the second unwedged:
> > > em0  2048 2 2   256 2  
> > > em0  2048 4 2   256 4  
> > > 
> > > It seems like the em0 line always shows the latter line, so I'm hoping 
> > > this indicates something useful.
> > 
> > I believe em(4) needs at least 4 descriptors on its rx ring.  If you
> > fall below that limit (which can happen if the CPU is busy), the card
> > stops receiving packets.  I believe em(4) is supposed to get an
> > interrupt for dropped packets and will attempt to refill the ring if
> > it receives such an interrupt.  It seems that mechanism isn't working
> > for your card.  Perhaps the usual workaround of using a timeout should
> > be added to the driver.
> 
> Good hint, rev 1.280 broke the chips not capable of jumbo frames. Correcting
> the low watermark for the affected chips resolves the issue Christian and
> Bryan were experiencing.

If all em(4) need 4 descriptors, would it make more sense to just enforce
lwm >= 4? Both from a self-documentation point of view, and to avoid a
potential trap if some nic was discovered to support <2k baby jumbos
i.e. give the same result for the if_hardmtu/MCLBYTES sum.
.


> 
> Index: if_em.c
> ===
> RCS file: /home/cvs/src/sys/dev/pci/if_em.c,v
> retrieving revision 1.295
> diff -u -p -u -p -r1.295 if_em.c
> --- if_em.c   11 Feb 2015 23:21:47 -  1.295
> +++ if_em.c   3 May 2015 11:17:49 -
> @@ -2597,6 +2597,7 @@ int
>  em_setup_receive_structures(struct em_softc *sc)
>  {
>   struct ifnet *ifp = &sc->interface_data.ac_if;
> + u_int lwm;
>  
>   memset(sc->rx_desc_base, 0,
>   sizeof(struct em_rx_desc) * sc->num_rx_desc);
> @@ -2608,8 +2609,12 @@ em_setup_receive_structures(struct em_so
>   sc->next_rx_desc_to_check = 0;
>   sc->last_rx_desc_filled = sc->num_rx_desc - 1;
>  
> - if_rxr_init(&sc->rx_ring, 2 * ((ifp->if_hardmtu / MCLBYTES) + 1),
> - sc->num_rx_desc);
> + if (sc->hw.max_frame_size == ETHER_MAX_LEN)
> + lwm = 4;
> + else
> + lwm = 2 * ((ifp->if_hardmtu / MCLBYTES) + 1);
> +
> + if_rxr_init(&sc->rx_ring, lwm, sc->num_rx_desc);
>  
>   if (em_rxfill(sc) == 0) {
>   printf("%s: unable to fill any rx descriptors\n",
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

Re: ftp not working

[Stuart Henderson]

On 2015/07/18 09:04, Rene Galera wrote:
> Hi,
> 
> Love your focus on security.
> 
> I am trying to build a virtual machine in Virtualbox version 4.3.26 in
> Ubuntu 15.04.  When trying to download nano from your 5.7 repository I get
> a message stating "Can't connect or login to host 'ftp.openbsd.com'
> ftp://ftp.openbsd.com/pub/OpenBSD/5.7/packages/i386 is empty Can't find
> nano".
> 
> This happened on a direct connect to the modem, bypassing all firewalls.
> 
> Are you having troubles with ftp?
> 
> Thanks.
> 
> Rene

Works for me. But note the domain is openbsd.*org* not .com.

multiple pxe structures; pxeboot picks the wrong one

[Stuart Henderson]

>Synopsis:  multiple pxe structures; pxeboot picks the wrong one
>Category:  system
>Environment:
System  : OpenBSD 5.8
Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 
2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:

Attempting to pxeboot an Intel NUC DN2820FYK fails, either with a hang or
printing spurious characters. Same for i386 and amd64 pxeboot.

probing: pc0
pxe_init: bad cksum (0xbc) for PXENV+ at 0x97bc8
 pxe![2.1]

The hang occurs when trying to call into the pxe code:

pxe_call(PXENV_GET_CACHED_INFO);

The boot loader has decided that the entry point is seg 0x0 offset 0x100.
It seems unlikely that this is a correct address.

So, the code is just doing a downward search and stops at the first valid
cksum. If I modify the memory scan to continue after the first match, it
finds several structures that have valid checksums:

PXENV+ 0x93752, 0x89110
!PXE   0x936f2, 0x890b0

plus some more with bad cksums.

After discovering http://permalink.gmane.org/gmane.os.netbsd.current/66067
which appears to be the same problem, I tried booting pxelinux which
identified a different entry point with "plan A", 8904:0100.

Forcing seg 0x8904 in our pxeboot allows it to boot. Also, looking at the
second !PXE structure, this is the entry point used there. (The second
PXENV+ has 8904:).

Linux plan A is :

const char *base = GET_PTR(InitStack);
...
/* Plan A: !PXE structure as SS:[SP + 4] */
off = *(const uint16_t *)(base + 48);
seg = *(const uint16_t *)(base + 50);
pxe = MK_PTR(seg, off);
if (is_pxe(pxe))
goto have_pxe;
...

There's a diff (provided as untested) in the netbsd mail. Applied to our code
(http://junkpile.org/pxe-nbp,diff1) it doesn't find a valid checksum, but
I'm unsure whether the diff is just wrong or whether it's looking in the
wrong place.

Can anyone help with an equivalent of Linux's GET_PTR(InitStack)?

>How-To-Repeat:
see subject.
>Fix:

Terrible workaround: force bangpxe_seg = 0x8904.

Workaround diff below is also pretty bad and not really intended for
commit, but at least it won't break every other machine:

Index: libsa/pxe.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/pxe.c,v
retrieving revision 1.6
diff -u -p -r1.6 pxe.c
--- libsa/pxe.c 21 Aug 2014 14:24:08 -  1.6
+++ libsa/pxe.c 18 Aug 2015 21:58:53 -
@@ -344,6 +344,10 @@ pxe_init(int quiet)
"for PXENV+ at 0x%lx\n", cksum,
(u_long) cp);
pxenv = NULL;
+   } else if (pxenv->RMEntry.segment == 0) {
+   printf("\npxe_init: bogus segment 0? "
+   "for PXENV+ at 0x%lx\n", (u_long) 
cp);
+   pxenv = NULL;
}
}
}
@@ -360,6 +364,10 @@ pxe_init(int quiet)
printf("pxe_init: bad cksum (0x%x) "
"for !PXE at 0x%lx\n", cksum,
(u_long) cp);
+   pxe = NULL;
+   } else if (pxe->EntryPointSP.segment == 0) {
+   printf("\npxe_init: bogus segment 0? "
+   "for !PXE at 0x%lx\n", (u_long) cp);
pxe = NULL;
}
}

dmesg:
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4162002944 (3969MB)
avail mem = 4031971328 (3845MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebec0 (46 entries)
bios0: vendor Intel Corp. version "FYBYT10H.86A.0051.2015.0624.1406" date 
06/24/2015
bios0: 
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
 
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT UEFI
acpi0: wakeup devices UAR5(S4) UAR8(S4) PS2K(S3) PS2M(S3) XHC1(S4) EHC1(S4) 
PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0) BRC3(S0)
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 N2830 @ 2.16GHz, 2167.16 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,

Re: (no subject)

[Stuart Henderson]

On 2015/08/19 18:52, Witold Cichoń wrote:
> Hello
> 
> I use OpenBSD version 5.7.
> I noticed a problem with the routing of the IPsec.
> I'm trying to redirect all traffic from a private subnet (192.168.127.0/24)
> to another host.
..
> FLOWS:
> flow esp in from 0.0.0.0/0 to 192.168.127.0/24 peer b.b.b.b type require
> flow esp out from 192.168.127.0/24 to 0.0.0.0/0 peer b.b.b.b type require
..

> I am trying to ping a host directly connected to the host A, but all packets
> are going in IPsec channel (interface enc0). I think packets should go to
> interface rl0.

OpenBSD's ipsec implementation is flow-based, not route-based. It will
hoover up all packets matching the flow irrespective of route table
entries directing them elsewhere (including your local connected routes).

You need a bypass flow to go with this 0.0.0.0/0 entry.

> In previous versions of OpenBSD the command netstat -rn showed routes
> associated with IPsec. In version 5.7, this information was gone. Is there
> any other way to see the routes associated with IPsec?

The best I think you can find at the moment is the FLOWS section
in "ipsecctl -sa".

Re: (no subject)

[Stuart Henderson]

On 2015/08/19 20:47, Witold Cichoń wrote:
> Thanks for the clarification.
> 
> This means that it is not possible to create a IPsec channel between any
> subnet and 0.0.0.0/0?

Like I said:

You need a bypass flow to go with this 0.0.0.0/0 entry.

Re: (no subject)

[Stuart Henderson]

On 2015/08/19 21:15, Witold Cichoń wrote:
> I'm sorry, I missed sentence:
> 
> >You need a bypass flow to go with this 0.0.0.0/0 entry.
> 
> Any advice how to do that?

If I understand correctly what you're trying to do, I think perhaps this:

flow esp from 192.168.127.0/24 to 192.168.127.0/24 type bypass

Re: "panic: free: size too large" when booting into X with latest snapshot

[Stuart Henderson]

On 2015/08/29 13:23, t...@math.ethz.ch wrote:
> panic: free: size too large 18446744073708503040 > 32 (0x8052eb40) 
> type
> memdesc
> Stopped atDebugger+09:leave
> RUN ...
> ddb{0}> trace
> Debuggger() at Debugger+0x9
> panic() at panic+0xfe
> free() at free+0xc9
> mem_ioctl() at mem_ioctl+0x149
> VOP_IOCTL() at VOP_IOCTL+0x44
> vn_ioctl() at vn_ioctl+0x77
> sys_ioctl() at sys_ioctl+0x18b
> syscall() at syscall+0x358
> --- syscall (number 54) ---

>   This must be due to a commit from between 3PM UTC on Aug 27 (kernel
>   built from then boots fine) and 5PM UTC on Aug 28 (kernel panics).
>   I can try to bisect the precise commit sometime tomorrow.

sys/arch/amd64/amd64/mem.c r1.26

I think this will fix it.

Index: mem.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/mem.c,v
retrieving revision 1.26
diff -u -p -r1.26 mem.c
--- mem.c   28 Aug 2015 00:03:53 -  1.26
+++ mem.c   29 Aug 2015 11:35:55 -
@@ -299,7 +299,7 @@ mem_ioctl(dev_t dev, u_long cmd, caddr_t
md->mr_owner[sizeof(md->mr_owner) - 1] = 0;
if (error == 0)
error = mem_range_attr_set(md, &mo->mo_arg[0]);
-   free(md, M_MEMDESC, nd * sizeof(struct mem_range_desc));
+   free(md, M_MEMDESC, sizeof(struct mem_range_desc));
break;
}
return (error);

Re: kernel panic - sparc64 on Netra X1 - psycho0: uncorrectable DMA error AFAR

[Stuart Henderson]

On 2015/09/04 18:02, Fred wrote:
> On 06/23/15 15:30, Mark Kettenis wrote:
> >>Date: Thu, 18 Jun 2015 23:25:15 +0200 (CEST)
> >>From: Mark Kettenis 
> >>
> >>>Date: Thu, 18 Jun 2015 22:48:40 +0200
> >>>From: Jan Vlach 
> >>
> >>>psycho0: uncorrectable DMA error AFAR 6656a250 (pa=0 tte=0/49c10012)
> >>>AFSR 41ff4080
> >>
> >>AFAICT this indicates an uncorrectable ECC error during a DMA
> >>transfer.  Sadly that suggests your hardware is dying.
> >>
> >>Might be worth trying to reseat your memory modules, or swap them out.
> >
> >Bleah.  Looked into the wrong manual.  This isn't an ECC error but an
> >IOMMU error instead.  And that almost certainly is a kernel bug of
> >some sorts.  Will try to hunt it down.
> >
> >What was your last kernel that worked properly?
> >
> 
> With sthen@'s help I have tracked down the kernel that does not display this
> issue for me its:
> 
> OpenBSD 5.6-current (GENERIC) #203: Tue Sep  2 19:32:42 MDT 2014
> 
> full dmesg below [1] and following kernel does have a panic:
> 
> OpenBSD 5.6-current (GENERIC) #205: Thu Sep  4 10:59:20 MDT 2014

could it be this?

CVSROOT:/cvs
Module name:src
Changes by: d...@cvs.openbsd.org 2014/09/03 18:36:00

Modified files:
sys/sys: pool.h
sys/kern   : subr_pool.c

Log message:
rework how pools with large pages (>PAGE_SIZE) are implemented.

this moves the size of the pool page (not arch page) out of the
pool allocator into struct pool. this lets us create only two pools
for the automatically determined large page allocations instead of
256 of them.

while here support using slack space in large pages for the
pool_item_header by requiring km_alloc provide pool page aligned
memory.

lastly, instead of doing incorrect math to figure how how many arch
pages to use for large pool pages, just use powers of two.

ok mikeb@



> full dmesg for this is below at [2].
> 
> The panic happens when I do a tar -xvzf and pkg_add -v in another shell, the
> panic is:
> 
> panic: psycho0: uncorrectable DMA error AFAR 66742250 (pa=0 tte=0/65b46012)
> AFSR 41ff4080
> kdb breakpoint at 15563a4
> Stopped at  Debugger+0x8:   nop
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb> trace
> psycho_ue(47b2900, 40008f7ee00, 0, 4, 40008df7c40, 40008fd0cf0) at
> psycho_u
> e+0x7c
> 
> intr_handler(e0017ec8, 47b2a00, 3c582, 0, 0, 0) at intr_handler+0xc
> sparc_interrupt(0, 3, 40008df5610, 4000f7e9cd8, 1, 0) at
> sparc_interrupt+0x298
> sys_write(4000906dd50, 4000f7e9db8, 4000f7e9df8, 4000f7e6000,
> fff0,
>  14b) at sys_write+0xb0
> 
> syscall(4000f7e9ed0, 404, 25ee90e148, 25ee90e14c, 0, 0) at syscall+0x16c
> softtrap(3, 262656ce84, 54, 25ee90c80c, 0, 0) at softtrap+0x19c
> ddb> ps
>PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
>  29573  21263  21263  0  30x83  pipewrgzip
>  21263  18483  21263  0  2 0x3tar
>  18483  20923  18483   1000  30x8b  pause ksh
> *20923   3390   3390   1000  70x10sshd
>   3390  27250   3390  0  30x92  poll  sshd
>  21865   9404  21865   1000  30x83  ttyin ksh
>   9404  12081  12081   1000  30x90  selectsshd
>  12081  27250  12081  0  30x92  poll  sshd
>  31553  1  31553  0  30x83  ttyin getty
>  25492  1  25492  0  30x80  selectcron
>  23049  1  23049 99  30x90  poll  sndiod
>  17520   2596   2596 95  30x90  kqreadsmtpd
>  30507   2596   2596 95  30x90  kqreadsmtpd
>  15728   2596   2596 95  30x90  kqreadsmtpd
>  21278   2596   2596 95  30x90  kqreadsmtpd
>  20677   2596   2596 95  30x90  kqreadsmtpd
>   7937   2596   2596103  30x90  kqreadsmtpd
>   2596  1   2596  0  30x80  kqreadsmtpd
>  27250  1  27250  0  30x80  selectsshd
>  15422  21838  21838 83  30x90  poll  ntpd
> --db_more--
>  21838  1  21838  0  30x80  poll  ntpd
>  30432  15344  15344 74  30x90  bpf   pflogd
>  15344  1  15344  0  30x80  netio pflogd
>  23915  26895  26895 73  30x90  poll  syslogd
>  26895  1  26895  0  30x80  netio syslogd
>  27216  1  27216 77  30x90  poll  dhclient
>  16326  1  16326  0  30x80  poll  dhclient
>  28617  0  0  0  3 0x14200  aiodoned  aiodoned
>  32169  0  0  0  3 0x14200  syncerupdate
>  18972  0  0  0  3 0x14200  cleaner   cleaner
>  19331  0  0  0  3 0x14200  reaperreaper
>   9312  0 

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Stuart Henderson]

On 2015/09/07 20:26, Landry Breuil wrote:
> I cant help you on the issue itself, but i can confirm you that i've
> been seeing the exact same issue with gem0 on my g4 mac mini here, and
> since some releases. randomly, gem0 just doesnt receive/send pkts
> anymore and needs to be downed/upped.

Interesting - I don't see that on mine.

Out of interest does your switch have flow control enabled? (you will
see rxpause and/or txpause in the ifconfig output). If it does, is there
any change if you disable it on the switch (if you can do so)?

gem0: flags=8863 mtu 1500
lladdr 00:0d:93:63:da:5a
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active

You might get more information from a kernel built with GEM_DEBUG.

OpenBSD 5.8 (GENERIC) #651: Sun Aug 16 04:48:04 MDT 2015
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 1073741824 (1024MB)
avail mem = 1031020544 (983MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac10,1
cpu0 at mainbus0: 7447A (Revision 0x102): 1249 MHz: 512KB L2 cache
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0
memc0 at mainbus0: uni-n rev 0xd2
"hw-clock" at memc0 not configured
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
mpcpcibr0 at mainbus0 pci: uni-north
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00
radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01
drm0 at radeondrm0
radeondrm0: irq 48
mpcpcibr1 at mainbus0 pci: uni-north
pci1 at mpcpcibr1 bus 0
macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00
openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE
macgpio0 at macobio0 offset 0x50
"modem-reset" at macgpio0 offset 0x1d not configured
"modem-power" at macgpio0 offset 0x1c not configured
macgpio1 at macgpio0 offset 0x9: irq 47
"programmer-switch" at macgpio0 offset 0x11 not configured
"gpio5" at macgpio0 offset 0x6f not configured
"gpio6" at macgpio0 offset 0x70 not configured
"extint-gpio15" at macgpio0 offset 0x67 not configured
"escc-legacy" at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
aoa0 at macobio0 offset 0x1: irq 30,1,2
audio0 at aoa0
"timer" at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000
apm0 at adb0: battery flags 0x0, 0% charged
piic0 at adb0
iic1 at piic0
maxtmp0 at iic1 addr 0xc8: max6642
kiic1 at macobio0 offset 0x18000
iic2 at kiic1
wdc0 at macobio0 offset 0x2 irq 24: DMA
ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 
1.0, legacy support
ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0
ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0
ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "Apple OHCI root hub" rev 1.00/1.00 addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci2: USB revision 1.0
uhub3 at usb3 "NEC OHCI root hub" rev 1.00/1.00 addr 1
mpcpcibr2 at mainbus0 pci: uni-north
pci2 at mpcpcibr2 bus 0
kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00
wdc1 at kauaiata0 irq 39: DMA
wd0 at wdc1 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
atapiscsi0 at wdc1 channel 0 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
removable
wd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
cd0(wdc1:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
"Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not configured
gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address 
00:0d:93:63:da:5a
bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4
uftdi0 at uhub2 port 1 configuration 1 interface 0 "FTDI FT232R USB UART" rev 
2.00/6.00 addr 2
ucom0 at uftdi0 portno 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootpath: /pci@f400/ata-6@d/disk@0:/bsd
root on wd0a (d59fb5d073dadba9.a) swap on wd0b dump on wd0b
error: [drm:pid0:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
trying to bind memory to uninitialized GART !
error: [drm:pid0:radeon_ttm_backend_bind] *ERROR* failed to bind 1 pages at 
0x
drm:pid0:radeon_wb_init *WARNING* (-22) create WB bo failed
drm:pid0:r100_init *ERROR* Disabling GPU acceleration
ttm_pool_mm_shrink_fini stub
error: [drm:pid0:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
radeondrm0: 1024x768
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)

Re: Weekly network disconnect with G4 Mac Mini (gem0)

[Stuart Henderson]

On 2015/09/08 17:28, Carlos Fenollosa wrote:
> 
> > On 07 Sep 2015, at 20:40, Stuart Henderson  wrote:
> > 
> > On 2015/09/07 20:26, Landry Breuil wrote:
> >> I cant help you on the issue itself, but i can confirm you that i've
> >> been seeing the exact same issue with gem0 on my g4 mac mini here, and
> >> since some releases. randomly, gem0 just doesnt receive/send pkts
> >> anymore and needs to be downed/upped.
> > 
> > Interesting - I don't see that on mine.
> > 
> > Out of interest does your switch have flow control enabled? (you will
> > see rxpause and/or txpause in the ifconfig output). If it does, is there
> > any change if you disable it on the switch (if you can do so)?
> > 
> > gem0: flags=8863 mtu 1500
> >lladdr 00:0d:93:63:da:5a
> >priority: 0
> >groups: egress
> >media: Ethernet autoselect (100baseTX full-duplex)
> >status: active
> 
> Yes, it seems to be the case:
> 
> gem0: flags=8863 mtu 1500
> lladdr 00:11:24:87:a7:64
> priority: 0
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet 192.168.1.199 netmask 0xff00 broadcast 192.168.1.255
> 
> 
> I have a crappy telco router, I’m actually not sure if I can disable it 
> there. There is a section on QoS, but the option is disabled.
> Could the driver be forced to disable flow control? At least I could try 
> running it for a couple weeks to see if the bug is triggered again.
> 
> 
> Thanks a lot,
> Carlos
> 

Flow control was a complete guess btw and might be unconnected.
This diff ought to disable it but my mac is 1500km away at the moment
so untested!

Landry, does yours show rxpause/txpause on this line?


Index: gem.c
===
RCS file: /cvs/src/sys/dev/ic/gem.c,v
retrieving revision 1.112
diff -u -p -r1.112 gem.c
--- gem.c   24 Jun 2015 09:40:54 -  1.112
+++ gem.c   8 Sep 2015 15:43:51 -
@@ -240,7 +240,7 @@ gem_config(struct gem_softc *sc)
 
gem_mifinit(sc);
 
-   mii_flags = MIIF_DOPAUSE;
+   mii_flags = 0;
 
/* 
 * Look for an external PHY.
@@ -905,7 +905,7 @@ gem_init_regs(struct gem_softc *sc)
bus_space_write_4(t, h, GEM_MAC_RX_CODE_VIOL, 0);
 
/* Set XOFF PAUSE time */
-   bus_space_write_4(t, h, GEM_MAC_SEND_PAUSE_CMD, 0x1bf0);
+   bus_space_write_4(t, h, GEM_MAC_SEND_PAUSE_CMD, 0);
 
/*
 * Set the internal arbitration to "infinite" bursts of the
@@ -1357,17 +1357,6 @@ gem_mii_statchg(struct device *dev)
v &= ~GEM_MAC_XIF_GMII_MODE;
}
bus_space_write_4(t, mac, GEM_MAC_XIF_CONFIG, v);
-
-   /*
-* 802.3x flow control
-*/
-   v = bus_space_read_4(t, mac, GEM_MAC_CONTROL_CONFIG);
-   v &= ~(GEM_MAC_CC_RX_PAUSE | GEM_MAC_CC_TX_PAUSE);
-   if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_ETH_RXPAUSE) != 0)
-   v |= GEM_MAC_CC_RX_PAUSE;
-   if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_ETH_TXPAUSE) != 0)
-   v |= GEM_MAC_CC_TX_PAUSE;
-   bus_space_write_4(t, mac, GEM_MAC_CONTROL_CONFIG, v);
 }
 
 int