add -powersave to hostname.if

2018-06-18 Thread Ken M
My thought was just to add the line

-powersave

in the file, just like I had added it to an iconfig commandline. Hostname.if man
pages don't specify anything about it that I can see.

Was my thought a stupid thought?

Ken



Re: user directory and wheel group

2018-06-18 Thread andrew fabbro
On Fri, Jun 15, 2018 at 2:42 PM, Stuart Henderson 
wrote:

> One thing to be aware of is the not-very-well-known restriction that one
> user can be in a maximum of 16 groups.


If memory serves, this limitation derives from an nfs limitation.

-- 
andrew fabbro
and...@fabbro.org


Re: Different sound sources interfere with each other

2018-06-18 Thread Родин Максим
May be the system becomes ... too busy to serve these actions 
simultaneously?
It seemed to me that any task which made decent use of computer 
resources was able to cause that behavior.


18.06.2018 18:22, Maxim Tarasov пишет:

Hi,

I was able to find another trigger for this sound glitch:

dd if=/dev/zero of=/tmp/test bs=1m count=256
rm /tmp/test

Sound sometimes interrupts in the middle of dd(1) call, and always
interrupts at the time of rm(1) call on files larger than 200 Mb. It
looks like in case of dd/rm not only sound is affected, but mouse
cursor controlled by USB mouse also stops responding.

unlink(2) call seem to take a long time:

$ dd if=/dev/zero of=test bs=1m count=1024 && ktrace rm test && kdump -R | grep 
unlink
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 2.265 secs (473858546 bytes/sec)
24666 rm   0.01 CALL  unlink(0x7f7bb91b)
24666 rm   0.431070 RET   unlink 0

Can anybody provide any pointers on how to debug this further or
suggestions on what the problem might be?



--
С уважением,
Родин Максим



xscreensaver on lumina (6.3) does not work well

2018-06-18 Thread Tuyosi T
hi all .
xscreensaver on lumina (snapshots)  works well ,
but
xscreensaver on lumina (6.3) does not work well .

namely
i cannnot restore screen by moving mouse or typing keyboard .

and
urtwn0 and run0 by snapshots works well , but  urtwn0 by 6.3 did not
get address
from wifi router .

---
regards


Re: Weird timing with hw.smt=0

2018-06-18 Thread Theo de Raadt
Benjamin Baier  wrote:

> Anybody seen this, too? Can't be twice as fast _without_ hypertreading.

Why not?

Our scheduler doesn't know how to use HT correctly.  And soon when
we all realize how broken HT is, we won't be able to use it correctly
in the super-restricted way it can be used.



Weird timing with hw.smt=0

2018-06-18 Thread Benjamin Baier
Anybody seen this, too? Can't be twice as fast _without_ hypertreading.

Greetings Ben

$ sysctl hw.smt
hw.smt=1
$ time sha256 -tt& time sha256 -tt& time sha256 -tt& time sha256 -tt& 
[1] 50365
[2] 71708
[3] 79327
[4] 63724
SHA256 time trial.  Processing 10 1-byte blocks...SHA256 time trial.  
Processing 10 1-byte blocks...SHA256 time trial.  Processing 10 
1-byte blocks...SHA256 time trial.  Processing 10 1-byte blocks...$ 
Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 16.57 seconds
Speed  = 60350030.175015 bytes/second
0m16.68s real 0m16.57s user 0m00.01s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 16.61 seconds
Speed  = 60204695.966285 bytes/second
0m16.69s real 0m16.61s user 0m00.01s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 16.60 seconds
Speed  = 60240963.855422 bytes/second
0m16.71s real 0m16.60s user 0m00.00s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 16.66 seconds
Speed  = 60024009.603842 bytes/second
0m16.72s real 0m16.67s user 0m00.00s system

[4] + Done time sha256 -tt 
[3] - Done time sha256 -tt 
[2]   Done time sha256 -tt 
[1]   Done time sha256 -tt

$ sysctl hw.smt=0 
hw.smt: 1 -> 0
$ time sha256 -tt& time sha256 -tt& time sha256 -tt& time sha256 -tt& 
[1] 41881
[2] 73097
[3] 58187
[4] 17276
SHA256 time trial.  Processing 10 1-byte blocks...SHA256 time trial.  
Processing 10 1-byte blocks...SHA256 time trial.  Processing 10 
1-byte blocks...SHA256 time trial.  Processing 10 1-byte blocks...$ 
Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 8.79 seconds
Speed  = 113765642.775882 bytes/second
0m17.05s real 0m08.79s user 0m00.00s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 8.73 seconds
Speed  = 114547537.227950 bytes/second
0m17.23s real 0m08.73s user 0m00.00s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 8.83 seconds
Speed  = 113250283.125708 bytes/second
0m17.61s real 0m08.83s user 0m00.00s system

Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
Time   = 8.77 seconds
Speed  = 114025085.518814 bytes/second
0m17.68s real 0m08.77s user 0m00.01s system

[4] + Done time sha256 -tt 
[3] - Done time sha256 -tt 
[2]   Done time sha256 -tt 
[1]   Done time sha256 -tt 



OpenBSD 6.3-current (GENERIC.MP) #25: Sun Jun 17 08:13:18 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451125248 (8059MB)
avail mem = 8117284864 (7741MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
bios0: vendor LENOVO version "8DET69WW (1.39 )" date 07/18/2013
bios0: LENOVO 4287CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT 
SSDT DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 MHz
cpu2: 

Re: rtadvd bug ?

2018-06-18 Thread Florian Obser
Be careful not to break dhcpv6-pd.

I suspect the problem is actually in make_prefix() in config.c which 
unconditionally sets
onlink and autoconf.

I stared at this for some time but can't figure out how to fix this.

RFC 4861 has this which I don't think rtadvd is implementing correctly:

  Prefix Information
 These options specify the prefixes that are on-link
 and/or are used for stateless address
 autoconfiguration.  A router SHOULD include all its
 on-link prefixes (except the link-local prefix) so
 that multihomed hosts have complete prefix
 information about on-link destinations for the
 links to which they attach.  If complete
 information is lacking, a host with multiple
 interfaces may not be able to choose the correct
 outgoing interface when sending traffic to its
 neighbors.

On Sun, Jun 17, 2018 at 10:57:57PM +0200, Sebastian Benoit wrote:
> Hi,
> 
> Denis Fondras(open...@ledeuns.net) on 2018.06.17 21:45:37 +0200:
> > On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote:
> > > Because it's lower than RTP_CONNECTED and I don't know what it is. The
> > > /* local address routes (must be the highest) */ comment makes me think
> > > it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may
> > > be related to interface addresses; I did not check in the kernel code
> > > how this flag is set. (hence the question marks)
> > > 
> > 
> > RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c
> > anyway.
> > 
> > Here is a diff if you want to try :
> > 
> > Index: if.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v
> > retrieving revision 1.46
> > diff -u -p -r1.46 if.c
> > --- if.c12 Aug 2017 07:38:26 -  1.46
> > +++ if.c17 Jun 2018 19:37:55 -
> > @@ -285,6 +285,14 @@ get_ifm_flags(char *buf)
> > return (ifm->ifm_flags);
> >  }
> >  
> > +u_char
> > +get_priority(char *buf)
> > +{
> > +   struct rt_msghdr *rtm = (struct rt_msghdr *)buf;
> > +
> > +   return (rtm->rtm_priority);
> > +}
> > +
> >  int
> >  get_prefixlen(char *buf)
> >  {
> > Index: if.h
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 if.h
> > --- if.h10 Aug 2017 19:07:14 -  1.14
> > +++ if.h17 Jun 2018 19:37:55 -
> > @@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *);
> >  int get_rtm_ifindex(char *);
> >  int get_ifm_ifindex(char *);
> >  int get_ifam_ifindex(char *);
> > +u_char get_priority(char *);
> >  int get_ifm_flags(char *);
> >  int get_prefixlen(char *);
> >  int prefixlen(u_char *, u_char *);
> > Index: rtadvd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v
> > retrieving revision 1.91
> > diff -u -p -r1.91 rtadvd.c
> > --- rtadvd.c22 Aug 2017 01:44:09 -  1.91
> > +++ rtadvd.c17 Jun 2018 19:37:55 -
> > @@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg
> >  {
> > int n, type, ifindex = 0, oldifflags, plen;
> > char *rtm;
> > -   u_char ifname[IF_NAMESIZE];
> > +   u_char ifname[IF_NAMESIZE], prio;
> > struct prefix *prefix;
> > struct rainfo *rai;
> > struct in6_addr *addr;
> > @@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg
> >  
> > addr = get_addr(rtm);
> > plen = get_prefixlen(rtm);
> > +   prio = get_priority(rtm);
> > +
> > +   if (!(prio & RTP_CONNECTED))
> > +   break;
> > +
> 
> 
> you have to do check
> 
>   if (rtm->rtm_flags & RTF_CONNECTED)
> 
> The priority of a connected route depends on the interface priority,
> see ifconfig(8) on the priority option and wifi and carp interfaces have a
> different default prio than other interfacs. So the prio is not an indicator
> for the type of the route.
> 
> /Benno
> 
> > /* sanity check for plen */
> > /* as RFC2373, prefixlen is at least 4 */
> > if (plen < 4 || plen > 127) {
> > 
> 
> -- 
> 

-- 
I'm not entirely sure you are real.



Re: /etc/services for MQTT protocol

2018-06-18 Thread Daniel Jakots
On Sun, 17 Jun 2018 17:59:56 +0200, gro...@grompf.net wrote:

> Hello,
> 
> Here's a tiny diff i used during my MQTT exploration while coupling
> some Dyson(tm) stuff with my openbsd homeserver.
> 
> a203 1
> mqtt1883/tcp# MQTT protocol
> a285 1
> secure-mqtt 8883/tcp# Secure MQTT

https://marc.info/?l=openbsd-tech=151520867321072=2

and I think there was also another argument about the ports being added
to the baddynamic sysctls but I can't find it.

Cheers,
Daniel



Re: Different sound sources interfere with each other

2018-06-18 Thread Maxim Tarasov
Hi,

I was able to find another trigger for this sound glitch:

dd if=/dev/zero of=/tmp/test bs=1m count=256
rm /tmp/test

Sound sometimes interrupts in the middle of dd(1) call, and always
interrupts at the time of rm(1) call on files larger than 200 Mb. It
looks like in case of dd/rm not only sound is affected, but mouse
cursor controlled by USB mouse also stops responding.

unlink(2) call seem to take a long time:

$ dd if=/dev/zero of=test bs=1m count=1024 && ktrace rm test && kdump -R | grep 
unlink
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 2.265 secs (473858546 bytes/sec)
24666 rm   0.01 CALL  unlink(0x7f7bb91b)
24666 rm   0.431070 RET   unlink 0

Can anybody provide any pointers on how to debug this further or
suggestions on what the problem might be?



Re: The wireless card TL-WN725N version 3 works fine

2018-06-18 Thread Patrick Harper
Not to put too finer point on it but the FAQ asks you to send the dmesg output 
as plain text in the body of an email to @dmesg, with some comments in the 
subject. External links are not very helpful.

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 15 Jun 2018, at 07:33, Guillaume DUALÉ wrote:
> Hello,
> Yes no problem, here is my dmesg : https://pastebin.com/iB4X5T9M
> Regards,
> Guillaume.
> 
> Le ven. 15 juin 2018 à 15:24, Stephane HUC "PengouinBSD" <
> b...@stephane-huc.net> a écrit :
> 
> > Please, add your dmesg as explain into FAQ:
> >
> > https://www.openbsd.org/faq/faq4.html#SendDmesg
> >
> > ;)
> >
> > Le 06/15/18 à 15:12, Guillaume DUALÉ a écrit :
> > > Hello,
> > > I just bought this card : TP-LINK TL-WN725N(EU) Ver:3.0
> > > And it works fine !
> > >
> > > In the man of the used driver «urtwn» : http://man.openbsd.org/urtwn
> > only
> > > the version 2 is listed.
> > > So you can add this new version in the list.
> > >
> > > If you want I do tests, I can, just ask.
> > >
> > > Regards,
> > > Guillaume.
> > >
> >
> > --
> > ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
> > 
> > Stephane HUC as PengouinBSD or CIOTBSD
> > b...@stephane-huc.net
> >
> >



Re: How to search for "hostap" in man pages.

2018-06-18 Thread Karel Gardas
On Sat, 16 Jun 2018 16:57:08 -0700
Andrew Hewus Fresh  wrote:

[...]
> $ apropos any=Hostap
[...]


Thanks! This does the job indeed.

Karel