Sierra Wireless EM7455 to usbdevs patch

2016-04-20 Thread Bryan Vyhmeister
This patch adds device identification to src/sys/dev/usb/usbdevs for the
Sierra Wireless EM7455 as sold in the Lenovo ThinkPad X260. There is no
driver for the device (see thread on misc@) but it will show up
correctly in usbdevs(8) output.

Bryan


Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.663
diff -u -p -r1.663 usbdevs
--- sys/dev/usb/usbdevs 31 Mar 2016 12:27:48 -  1.663
+++ sys/dev/usb/usbdevs 20 Apr 2016 15:20:31 -
@@ -3832,6 +3832,7 @@ product SIERRA AC885U 0x6880  885U
 product SIERRA C01SW   0x6890  C01SW
 product SIERRA USB305  0x68a3  USB305
 product SIERRA MC8355  0x9013  MC8355
+product SIERRA EM7455  0x9079  EM7455
 
 /* Sigmatel products */
 product SIGMATEL IRDA  0x4200  IrDA



Re: httpd: minor documentation fix for HSTS

2016-04-20 Thread Jason McIntyre
On Thu, Apr 14, 2016 at 12:10:19PM -0500, Tim Baumgard wrote:
> The "hsts" option isn't allowed to be nested within a "location"
> option. See parse.y:572.
> 

fixed, thanks.
jmc

> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.68
> diff -u -p -r1.68 httpd.conf.5
> --- httpd.conf.5  19 Jul 2015 05:17:27 -  1.68
> +++ httpd.conf.5  14 Apr 2016 03:27:58 -
> @@ -300,6 +300,7 @@ argument will be matched against the req
>  A location section may include most of the server configuration rules
>  except
>  .Ic connection ,
> +.Ic hsts ,
>  .Ic listen on ,
>  .Ic location
>  and
> 



Re: changelist: adds iked pub/private key ?

2016-04-20 Thread Sebastian Benoit
Sebastien Marie(sema...@openbsd.org) on 2016.04.20 08:38:40 +0200:
> Hi,
> 
> I noted that iked(8) default key (generated at boot time by rc(8) if it
> doesn't exist yet) aren't present in changelist(5), whereas the same
> keys for isakmpd(8) are.
> 
> Does adding /etc/iked/local.pub and /etc/iked/private/local.key to
> changelist(5) makes sens ?

of course, ok

> 
> -- 
> Sebastien Marie
> 
> 
> Index: changelist
> ===
> RCS file: /cvs/src/etc/changelist,v
> retrieving revision 1.110
> diff -u -p -r1.110 changelist
> --- changelist3 Oct 2015 18:57:11 -   1.110
> +++ changelist20 Apr 2016 06:33:59 -
> @@ -45,6 +45,8 @@
>  /etc/httpd.conf
>  /etc/ifstated.conf
>  +/etc/iked.conf
> +/etc/iked/local.pub
> ++/etc/iked/private/local.key
>  /etc/inetd.conf
>  +/etc/ipsec.conf
>  +/etc/isakmpd/isakmpd.conf
> 

-- 



Re: changelist: rm unbound/db/root.key

2016-04-20 Thread Daniel Jakots
On Wed, 20 Apr 2016 09:21:16 +0100, Stuart Henderson
 wrote:

> This file changes twice a day if you're validating dnssec and
> it's pretty pointless to warn about in security(8).
> 
> OK?

Yes please.



Re: changelist: rm unbound/db/root.key

2016-04-20 Thread Matthieu Herrb
On Wed, Apr 20, 2016 at 09:21:16AM +0100, Stuart Henderson wrote:
> This file changes twice a day if you're validating dnssec and
> it's pretty pointless to warn about in security(8).
> 
> OK?

Yes, thank you.
> 
> Index: changelist
> ===
> RCS file: /cvs/src/etc/changelist,v
> retrieving revision 1.110
> diff -u -p -r1.110 changelist
> --- changelist3 Oct 2015 18:57:11 -   1.110
> +++ changelist20 Apr 2016 08:19:50 -
> @@ -150,7 +150,6 @@
>  /var/cron/cron.deny
>  /var/cron/tabs/root
>  +/var/nsd/etc/nsd.conf
> -/var/unbound/db/root.key
>  /var/unbound/etc/unbound.conf
>  /var/yp/Makefile.main
>  /var/yp/Makefile.yp

-- 
Matthieu Herrb


pgpXsqe_8MaQI.pgp
Description: PGP signature


Re: changelist: rm unbound/db/root.key

2016-04-20 Thread Martijn Rijkeboer

> This file changes twice a day if you're validating dnssec and
> it's pretty pointless to warn about in security(8).

I'm not a developer, but I totally agree. A few months ago I was
asking[1] how to silence these warnings. I'm currently commenting out
that line on my DNS resolvers.

Kind regards,


Martijn Rijkeboer

[1] http://marc.info/?l=openbsd-misc&m=144611060708039&w=2



Re: changelist: rm unbound/db/root.key

2016-04-20 Thread Sebastien Marie
On Wed, Apr 20, 2016 at 09:21:16AM +0100, Stuart Henderson wrote:
> This file changes twice a day if you're validating dnssec and
> it's pretty pointless to warn about in security(8).
> 
> OK?

yes please.

OK semarie@

-- 
Sebastien Marie



Re: Moving away from softnet interrupts

2016-04-20 Thread Dimitris Papastamos
On Mon, Apr 18, 2016 at 10:50:46AM +0200, Martin Pieuchot wrote:
> The current goal of the Network SMP effort is to have a single CPU
> process the IP forwarding path in a process context without holding
> the KERNEL_LOCK().  To achieve this goal we're progressively moving
> code from the softnet interrupt context to the if_input_task.  In
> the end we'll completely get rid of this soft-interrupt.
> 
> So now would be a good time to know if moving all the code currently
> run in a soft-interrupt context to a task uncovers any bug.  I'm
> happily running the diff below on amd64 and macppc, it even gives me
> a small performance boost.
> 
> I'd appreciate more tests especially on exotic archs.

I've been running with this diff since you posted it on my home router.
I have not encountered any issues.

See ifconfig/route show/sysctl.conf/dmesg output below.

ifconfig:

lo0: flags=8049 mtu 32768
priority: 0
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
re0: flags=18843 mtu 1500
lladdr 90:e6:ba:74:0e:38
description: WAN
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 82.13.64.4 netmask 0xf000 broadcast 82.13.79.255
re1: 
flags=18b43 mtu 
1500
lladdr 80:ee:73:9f:1d:3d
description: Main subnet
priority: 0
media: Ethernet autoselect (1000baseT 
full-duplex,master,rxpause,txpause)
status: active
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
inet6 fe80::82ee:73ff:fe9f:1d3d%re1 prefixlen 64 scopeid 0x2
inet6 2001:470:1f15:b42::1 prefixlen 64
inet6 fdfc::1 prefixlen 64
enc0: flags=0<>
priority: 0
groups: enc
status: active
axe0: flags=8843 mtu 1500
lladdr d8:eb:97:bd:8a:77
description: VoIP subnet
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
tun0: flags=8043 mtu 1500
description: tinc VPN
priority: 0
groups: tun
status: active
inet 172.17.0.2 netmask 0xff00 broadcast 172.17.0.255
tun1: flags=8051 mtu 1304
description: cjdns
priority: 0
groups: tun
status: active
inet6 fe80::92e6:baff:fe74:e38%tun1 ->  prefixlen 64 scopeid 0x7
inet6 fcac:2580:3f14:3393:f405:d913:98af:ec5f ->  prefixlen 8
tun2: flags=8051 mtu 1500
description: stun
priority: 0
groups: tun
status: down
inet 10.10.0.2 --> 10.10.0.1 netmask 0x
gif0: flags=8051 mtu 1480
description: Hurricane Electric 6in4 link
priority: 0
groups: gif egress
tunnel: inet 82.13.64.4 -> 216.66.84.46
inet6 fe80::92e6:baff:fe74:e38%gif0 ->  prefixlen 64 scopeid 0x9
inet6 2001:470:1f14:b42::2 -> 2001:470:1f14:b42::1 prefixlen 128
bridge0: flags=41
description: Dedi bridge
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
re1 flags=3
port 2 ifpriority 0 ifcost 0
tap0 flags=3
port 13 ifpriority 0 ifcost 0
pflow0: flags=41 mtu 1492
priority: 0
pflow: sender: 10.0.0.1 receiver: 10.0.0.7:3001 version: 5
groups: pflow
pflog0: flags=141 mtu 33144
priority: 0
groups: pflog
tap0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:b8:5e
priority: 0
groups: tap
status: active
inet 10.0.0.14 netmask 0xff00 broadcast 10.0.0.255

route show:

Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaultcpc92320-cmbg19-2- UGS   13 36158691 - 8 re0  
BASE-ADDRESS.MCAST localhost  URS028680 32768 8 lo0  
10.0.0/24  sunUCP410431 - 4 re1  
10.0.0/24  10.0.0.14  UCP00 - 4 tap0 
sun80:ee:73:9f:1d:3d  UHLl   024952 - 1 re1  
jupiter34:64:a9:9a:5f:1c  UHLc   3 14403576 - 4 re1  
callisto   04:18:d6:f0:47:cd  UHLc   016453 - 4 re1  
pluto-mgmt e4:8d:8c:19:38:af  UHLc   010449 - 4 re1  
10.0.0.14  fe:e1:ba:d0:b8:5e  UHLl   0  125 - 1 tap0 
10.0.0.15  00:bd:ae:38:00:00  UHLc   1 8975 - 4 re1  
10.0.0.255 sunUHPb   0  987 - 1 re1  
10.0.0.255 10.0.0.14  UHPb   00 - 1 tap0 
10.0.1/24  10.0.1.1   UC 18 - 4 axe0 
10.0.1.1   d8:eb:97:bd:8a:77  UHLl   015580 - 1 axe0 
phone  00:0b:82:62:2d:5d  UHLc   1506

Re: changelist: rm unbound/db/root.key

2016-04-20 Thread Martijn van Duren
I have this in my config for quite some time, so OK martijn@

On 04/20/16 10:21, Stuart Henderson wrote:
> This file changes twice a day if you're validating dnssec and
> it's pretty pointless to warn about in security(8).
> 
> OK?
> 
> Index: changelist
> ===
> RCS file: /cvs/src/etc/changelist,v
> retrieving revision 1.110
> diff -u -p -r1.110 changelist
> --- changelist3 Oct 2015 18:57:11 -   1.110
> +++ changelist20 Apr 2016 08:19:50 -
> @@ -150,7 +150,6 @@
>  /var/cron/cron.deny
>  /var/cron/tabs/root
>  +/var/nsd/etc/nsd.conf
> -/var/unbound/db/root.key
>  /var/unbound/etc/unbound.conf
>  /var/yp/Makefile.main
>  /var/yp/Makefile.yp
> 



changelist: rm unbound/db/root.key

2016-04-20 Thread Stuart Henderson
This file changes twice a day if you're validating dnssec and
it's pretty pointless to warn about in security(8).

OK?

Index: changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.110
diff -u -p -r1.110 changelist
--- changelist  3 Oct 2015 18:57:11 -   1.110
+++ changelist  20 Apr 2016 08:19:50 -
@@ -150,7 +150,6 @@
 /var/cron/cron.deny
 /var/cron/tabs/root
 +/var/nsd/etc/nsd.conf
-/var/unbound/db/root.key
 /var/unbound/etc/unbound.conf
 /var/yp/Makefile.main
 /var/yp/Makefile.yp



Re: changelist: adds iked pub/private key ?

2016-04-20 Thread Stuart Henderson
On 2016/04/20 08:38, Sebastien Marie wrote:
> Hi,
> 
> I noted that iked(8) default key (generated at boot time by rc(8) if it
> doesn't exist yet) aren't present in changelist(5), whereas the same
> keys for isakmpd(8) are.
> 
> Does adding /etc/iked/local.pub and /etc/iked/private/local.key to
> changelist(5) makes sens ?

Yes, that should be included.



Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

2016-04-20 Thread Mike Larkin
On Sat, Feb 20, 2016 at 10:42:02PM +0100, Mark Kettenis wrote:
> > Date: Sat, 20 Feb 2016 11:32:15 -0800
> > From: Mike Larkin 
> > 
> > On Sat, Feb 20, 2016 at 10:04:28AM +0100, Mark Kettenis wrote:
> > > > From: Noth 
> > > > Date: Sat, 20 Feb 2016 07:22:56 +0100
> > > > 
> > > > On 02/20/16 06:46, Theo de Raadt wrote:
> > > > >> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> > > > >> immediately.  I have a diff to avoid this wakeup.  Unhibernation 
> > > > >> works
> > > > >> fine.
> > > > >>
> > > > >> The diff seems very bad. :)
> > > > >>
> > > > >> Index: sys/dev/acpi/acpi.c
> > > > >> ===
> > > > >> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> > > > >> retrieving revision 1.303
> > > > >> diff -u -p -r1.303 acpi.c
> > > > >> --- sys/dev/acpi/acpi.c  14 Jan 2016 21:37:18 -  1.303
> > > > >> +++ sys/dev/acpi/acpi.c  21 Jan 2016 08:25:59 -
> > > > >> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
> > > > >>   {
> > > > >>  struct acpi_wakeq *wentry;
> > > > >>   
> > > > >> +return;
> > > > >>  SIMPLEQ_FOREACH(wentry, &sc->sc_wakedevs, q_next) {
> > > > >>  dnprintf(10, "%.4s(S%d) gpe %.2x\n", 
> > > > >> wentry->q_node->name,
> > > > >>  wentry->q_state,
> > > > > That is a very interesting diff.  Mike will probably remember this.
> > > > > Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
> > > > > was doing something wrong.
> > > > >
> > > > > That will assuredly break most thinkpads :)
> > > > >
> > > > >
> > > > 
> > > > That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
> > > > pretty well on this little laptop :)
> > > 
> > > Next step in the debugging process would be to find out which of the
> > > wake GPEs is actually responsible.
> > > 
> > 
> > I have a few reports of these sorts of things failing (eg, resuming
> > immediately) in my inbox from the past. Every time I've tried to
> > debug these, even when disabling all the GPEs, the machine still
> > woke.
> > 
> > Do you have a better idea?
> 
> In this case disabling the GPEs definitely does help.

Cleaning up old email threads ...

So the next step is to hack up that diff to selectively disable GPEs until
you find the one that is causing the instant wake. It's a simple matter 
(usually)
to then find the device responsible, at which point we can make further 
progress.

Short of having physical access to the hardware, this is all I can recommend.

-ml