Re: Performance Clang

[Heiko]

Thank you.

Am 20.04.17 um 03:55 schrieb Michael McConville:
> An email from Miod that gets cited often:
> 
> https://marc.info/?l=openbsd-misc=137530560232232=2

Re: Performance Clang

[Theo de Raadt]

> I was not aware that the difference is 340%.
> 
> So I guess the main advantage is the license?

No.

> Or is clang technically (binaries, debug) better?

No.

Basically, this cannot be oversimplified by 1 line questions followed
by 1 line answers.

Re: Performance Clang

[Heiko]

I was not aware that the difference is 340%.

So I guess the main advantage is the license?
Or is clang technically (binaries, debug) better?

Am 20.04.17 um 03:42 schrieb Theo de Raadt:
>> I'm using current on amd64 (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz,
>> 3411.91 MHz)
>>
>> I noticed that with clang it needs 109 minutes for "make build" and
>> before with gcc 32 minutes.
>>
>> Is this a normal behavior?
> 
> For sure.  Why the surprise?
> 

Re: Performance Clang

[Michael McConville]

Heiko wrote:
> I noticed that with clang it needs 109 minutes for "make build" and
> before with gcc 32 minutes.
> 
> Is this a normal behavior?

An email from Miod that gets cited often:

https://marc.info/?l=openbsd-misc=137530560232232=2

Re: Performance Clang

[Theo de Raadt]

> I'm using current on amd64 (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz,
> 3411.91 MHz)
> 
> I noticed that with clang it needs 109 minutes for "make build" and
> before with gcc 32 minutes.
> 
> Is this a normal behavior?

For sure.  Why the surprise?

Performance Clang

[Heiko]

Hello Misc,

I'm using current on amd64 (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz,
3411.91 MHz)

I noticed that with clang it needs 109 minutes for "make build" and
before with gcc 32 minutes.

Is this a normal behavior?

Best,
Heiko

Re: Sites in firefox stop loading with "out of memory" in console

[George]

On Wed, 19 Apr 2017 00:06:10 -0300
Daniel Bolgheroni  wrote:

> Ultimately some sites opened with Firefox 52 stop loading with "out of
> memory" in console.  Two ofenders are https://app.wire.com and
> https://www.protonmail.com/login, and both seem related to asm.js.
> 
> Note that Firefox doesn't crash, but the sites beeing loaded just stop
> being loaded, and the F12 console notifies the error (console messages
> below). This occurred also with the previous 51 version but not with
> firefox-esr 45. Chrome works OK.
> 

Hi Daniel,

This is most probably a JavaScript issue. Try disabling JavaScript,
PrefBar add-on, and checking whether you get the out-of-memory messages
if it is the case I am not sure what you or OpenBSD can do about it as
it is a program served by the site. Try blocking or not downloading the
asm.js but I'd venture a guess it will be of no use to you then then.

Web NO-point-Oh what can I say ;)

Good luck!
George

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Sjöholm Per-Olov]

> On 20 Apr 2017, at 00:39, Fred  wrote:
> 
> On 04/19/17 23:30, Sjöholm Per-Olov wrote:
>> Anyone with a clue would be _very_ much appreciated….
>> I upgraded from 6.0 to 6.1 two days ago and **did not change anything to the 
>> network** stuff at all. After that clients have random problems reaching my 
>> dmz web server (centos + nginx). I have checked the release notes, but could 
>> not see any clue there. Se logs below
>> # Relevant rules from PF
>> LAN_INT="vlan2"
>> DMZ1_INT="vlan3"
>> DMZ2_INT="vlan4"
>> GUEST_INT="vlan1003"
>> INTERNET_INT="em3
>> ALL_INTERFACES="{" $LAN_INT $GUEST_INT $DMZ1_INT $DMZ2_INT $INTERNET_INT "}"
>> pass out on $ALL_INTERFACES inet proto {tcp gre esp udp icmp ipv6} all keep 
>> state
>> pass out on $ALL_INTERFACES inet6  proto {tcp gre esp udp icmp6} all keep 
>> state
>> pass out on $IPV6_TUNNEL_INT inet6 all keep state
>> pass in log quick on $INTERNET_INT inet proto tcp  from any  to 
>> $DMZ1_DAEDALUS port  { 80 443 } label "webstats:$dstport" flags S/SAFR keep 
>> state (max-src-nodes 90, max-src-states 150, max-src-conn 150, 
>> max-src-conn-rate 250/30,  overload  flush global)
>> # Log that after upgrade shows problems in the logs related to this directly 
>> after the upgrade
>> root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.6|grep block|grep 
>> 155.4|grep out |grep ': R'
>> tcpdump: WARNING: snaplen raised from 116 to 160
>> root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.5|grep block|grep 
>> 155.4|grep out |grep ': R'
>> tcpdump: WARNING: snaplen raised from 116 to 160
>> root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.4|grep block|grep 
>> 155.4|grep out |grep ': R'
>> tcpdump: WARNING: snaplen raised from 116 to 160
>> root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.3|grep block|grep 
>> 155.4|grep out |grep ': R'
>> tcpdump: WARNING: snaplen raised from 116 to 160
>> root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.2|grep block|grep 
>> 155.4|grep out |grep ': R'
>> tcpdump: WARNING: snaplen raised from 116 to 160
>> Apr 17 05:43:36.359067 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 164.132.161.92.46942: R 0:0(0) ack 2697518940 win 0 (DF)
>> Apr 17 05:43:37.358688 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
>> Apr 17 05:43:39.362671 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
>> Apr 17 06:10:24.490412 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 139.162.111.147.33930: R 0:0(0) ack 1409896759 win 0 (DF)
>> Apr 17 06:32:45.198754 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 180.76.15.26.42835: R 0:0(0) ack 3718886589 win 0 (DF)
>> Apr 17 06:32:46.198338 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 180.76.15.26.42835: R 0:0(0) ack 1 win 0 (DF)
>> Apr 17 06:41:29.366359 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 51.255.65.91.42819: R 0:0(0) ack 4294673273 win 0 (DF)
>> Apr 17 06:41:30.365396 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
>> Apr 17 06:41:32.369399 rule 63/(match) block out on em3: 155.4.8.28.80 > 
>> 51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
>> — cut the rest —
>> What have I missed?
>> Tnx in advance
>> Peo
>> Thanks
>> Peo
> 
> You might get some clues from:
> 
> pfctl -sr -R 63
> 
> Cheers
> 
> Fred
> 

I know that that rule is my default block…

root@xanadu:/etc#pfctl -g -sr|grep "@63"
@63 block drop log all
root@xanadu:/etc#

But why is this happening after upgrade. I have netiher touched pf.conf, 
sysctl.conf  or /etc/hostname* nor found any changes in release notes related 
to this. So I see no reason for the packet to get stuck on that rule. But I am 
probably missing something obvious :)


Peo

Re: Strange PF behaviour after 6.0 -> 6.1 pgrade

[Fred]

On 04/19/17 23:30, Sjöholm Per-Olov wrote:

Anyone with a clue would be _very_ much appreciated….


I upgraded from 6.0 to 6.1 two days ago and **did not change anything to the 
network** stuff at all. After that clients have random problems reaching my dmz 
web server (centos + nginx). I have checked the release notes, but could not 
see any clue there. Se logs below

# Relevant rules from PF
LAN_INT="vlan2"
DMZ1_INT="vlan3"
DMZ2_INT="vlan4"
GUEST_INT="vlan1003"
INTERNET_INT="em3
ALL_INTERFACES="{" $LAN_INT $GUEST_INT $DMZ1_INT $DMZ2_INT $INTERNET_INT "}"
pass out on $ALL_INTERFACES inet proto {tcp gre esp udp icmp ipv6} all keep 
state
pass out on $ALL_INTERFACES inet6  proto {tcp gre esp udp icmp6} all keep state
pass out on $IPV6_TUNNEL_INT inet6 all keep state
pass in log quick on $INTERNET_INT inet proto tcp  from any  to $DMZ1_DAEDALUS port  { 80 443 } 
label "webstats:$dstport" flags S/SAFR keep state (max-src-nodes 90, max-src-states 
150, max-src-conn 150, max-src-conn-rate 250/30,  overload  flush global)



# Log that after upgrade shows problems in the logs related to this directly 
after the upgrade

root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.6|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.5|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.4|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.3|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.2|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
Apr 17 05:43:36.359067 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 2697518940 win 0 (DF)
Apr 17 05:43:37.358688 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
Apr 17 05:43:39.362671 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:10:24.490412 rule 63/(match) block out on em3: 155.4.8.28.80 > 
139.162.111.147.33930: R 0:0(0) ack 1409896759 win 0 (DF)
Apr 17 06:32:45.198754 rule 63/(match) block out on em3: 155.4.8.28.80 > 
180.76.15.26.42835: R 0:0(0) ack 3718886589 win 0 (DF)
Apr 17 06:32:46.198338 rule 63/(match) block out on em3: 155.4.8.28.80 > 
180.76.15.26.42835: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:41:29.366359 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 4294673273 win 0 (DF)
Apr 17 06:41:30.365396 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:41:32.369399 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
— cut the rest —


What have I missed?

Tnx in advance
Peo


Thanks
Peo



You might get some clues from:

pfctl -sr -R 63

Cheers

Fred

Strange PF behaviour after 6.0 -> 6.1 pgrade

[Sjöholm Per-Olov]

Anyone with a clue would be _very_ much appreciated….


I upgraded from 6.0 to 6.1 two days ago and **did not change anything to the 
network** stuff at all. After that clients have random problems reaching my dmz 
web server (centos + nginx). I have checked the release notes, but could not 
see any clue there. Se logs below

# Relevant rules from PF
LAN_INT="vlan2"
DMZ1_INT="vlan3"
DMZ2_INT="vlan4"
GUEST_INT="vlan1003"
INTERNET_INT="em3
ALL_INTERFACES="{" $LAN_INT $GUEST_INT $DMZ1_INT $DMZ2_INT $INTERNET_INT "}"
pass out on $ALL_INTERFACES inet proto {tcp gre esp udp icmp ipv6} all keep 
state
pass out on $ALL_INTERFACES inet6  proto {tcp gre esp udp icmp6} all keep state
pass out on $IPV6_TUNNEL_INT inet6 all keep state
pass in log quick on $INTERNET_INT inet proto tcp  from any  to $DMZ1_DAEDALUS 
port  { 80 443 } label "webstats:$dstport" flags S/SAFR keep state 
(max-src-nodes 90, max-src-states 150, max-src-conn 150, max-src-conn-rate 
250/30,  overload  flush global)



# Log that after upgrade shows problems in the logs related to this directly 
after the upgrade

root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.6|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.5|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.4|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.3|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
root@xanadu:/var/log#tcpdump -e -n -ttt -r /var/log/pflog.2|grep block|grep 
155.4|grep out |grep ': R'
tcpdump: WARNING: snaplen raised from 116 to 160
Apr 17 05:43:36.359067 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 2697518940 win 0 (DF)
Apr 17 05:43:37.358688 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
Apr 17 05:43:39.362671 rule 63/(match) block out on em3: 155.4.8.28.80 > 
164.132.161.92.46942: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:10:24.490412 rule 63/(match) block out on em3: 155.4.8.28.80 > 
139.162.111.147.33930: R 0:0(0) ack 1409896759 win 0 (DF)
Apr 17 06:32:45.198754 rule 63/(match) block out on em3: 155.4.8.28.80 > 
180.76.15.26.42835: R 0:0(0) ack 3718886589 win 0 (DF)
Apr 17 06:32:46.198338 rule 63/(match) block out on em3: 155.4.8.28.80 > 
180.76.15.26.42835: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:41:29.366359 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 4294673273 win 0 (DF)
Apr 17 06:41:30.365396 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
Apr 17 06:41:32.369399 rule 63/(match) block out on em3: 155.4.8.28.80 > 
51.255.65.91.42819: R 0:0(0) ack 1 win 0 (DF)
— cut the rest —


What have I missed?

Tnx in advance
Peo


Thanks
Peo

Re: ipsec ... again

[Remi Locherer]

On Tue, Apr 18, 2017 at 01:35:58PM +0200, Markus Rosjat wrote:
> Hi there,
> 
> since my attempt with ikev2 failed I thought I go back to ikev1 but it seems
> since the last time I used it something has changed with that too.
> 
> I simply try to set up a site to site tunnel with a PSK
> 
> here is the ipsec.conf on the openbsd machine
> 
> ike from {10.10.10.0/24} to 10.10.15.0/24 \

You need to add "peer AA.BB.CC.DD" here.

>   main auth hmac-sha1 enc blowfish group modp1024\
>   quick auth hmac-sha1 enc blowfish group modp1024\
>   psk "my_psk"
> 

If you control both ends of the VPN I recommend you choose stronger
cyphers. Check the defaults of OpenBSD or the recommendation of ENISA:
https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014

How do you start isakmpd? This should configure your system to start
isakmpd and load the ipsec rules during boot:

# rcctl enable isakmpd
# rcctl set isakmpd flags -vK
# rcctl enable ipsec

> and here is the pf.conf

Add the log keyword to your pf rules. Without that it's hard to debug.
Also check man ipsec.conf for a full example.

> 
> ### define networks ##
> tun_in="10.10.15.0/24"
> tun_end="{10.10.10.0/24}"
> 
> # simple ipsec
> pass in proto { esp ah } to ($ext_if)
> pass in on $ext_if proto udp from any to port {500 4500} keep state
> 
> pass in on enc0 proto ipencap
> pass in on enc0 from {$tun_in} to $tun_end
> 
> pass out proto {esp ah}
> pass out on enc0 from $tun_end to {$tun_in}
> 
> this works at least for a openbsd 5.6 and a srewsoft client (this is
> basically my other endpoint).
> 
> with this setup Im not able to connect to a openBSD 6.1 and the logs don't
> show anything helpfull
> 
> so the question is where do I need to do the rewriting and is there some
> example beside the ipsec.conf in /etc/examples ?
> 
> Regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT

Re: OpenBSD 6.1 Release Notes

[Martin Schröder]

2017-04-19 21:00 GMT+02:00  :
> I'd like to help write them! What's your process/format for doing so?
>
> - Sent from Outlook for Android

Hint: It uses OpenBSD

OpenBSD 6.1 Release Notes

[darin]

I'd like to help write them! What's your process/format for doing so?




Best regards,


Darin Luckie

Devops & Cyber Security Engineering

Technotic Support Services

T: 438.338.4600

E: supp...@technotic.ca

W: technotic.ca


- Sent from Outlook for Android

Re: GUI desktop autologin options

[Andre Smagin]

On Tue, 18 Apr 2017 20:44:05 -0700
"Sha'ul"  wrote:

> I'm trying to figure how setup an auto login from boot to some kind of GUI
> desktop interface. What are my options? I'm not interested in Gnome 3, but
> I will use anything else like Lumina, KDE, XFCE, etc. as long as it can
> load straight into desktop environment when I turn on computer. Which
> ones, besides Gnome 3, support autologin?

Just add to /etc/X11/xenodm/xenodm-config

DisplayManager.*.autoLogin: your_user_name

enable xenodm in /etc/rc.conf.local with

xenodm_flags=

and add the startup command for your window manager to ~/.xsession

If I remember correctly, it's something like
xfce4-session || startkde || gnome-session || xterm
to start those DEs. Other window managers are more straightforward and
usually use their name as the main executable.

Re: howto show IPv6 address lifetime?

[Dimitris Papastamos]

On Wed, Apr 19, 2017 at 09:32:56AM -0400, Eike Lantzsch wrote:
> On Wednesday, 19 April 2017 14:22:32 -04 Peter N. M. Hansteen wrote:
> > On Wed, Apr 19, 2017 at 11:16:44AM +0200, Harald Dunkel wrote:
> > > > Give a try to ifconfig as regarde privacy policy lifetime : pltime &
> > > > vltime if i'm still right. You can also preset this two counters using
> > > > the same command.> 
> > > ??? Sorry, but I don't understand this first sentence.
> > > 
> > > I would like to see the address lifetime, which address is preferred,
> > > which is deprecated, etc. On Linux a simple command like "ip a s" shows.
> > As quoted above, ifconfig is your friend:
> > 
> > [Wed Apr 19 14:19:35] peter@elke:~$ ifconfig iwm0
> > iwm0: flags=208943
> > mtu 1500 lladdr a0:a8:cd:63:ab:b9
> > index 1 priority 4 llprio 3
> > groups: wlan egress
> > media: IEEE802.11 autoselect (HT-MCS4 mode 11n)
> > status: active
> > ieee80211: nwid we_collect_all_your_nasty-bits5 chan 36 bssid
> > e0:3f:49:23:bb:2c 29% wpakey  wpaprotos wpa2 wpaakms psk
> > wpaciphers ccmp wpagroupcipher ccmp inet6 fe80::a2a8:cdff:fe63:abb9%iwm0
> > prefixlen 64 scopeid 0x1 inet 192.168.103.126 netmask 0xff00 broadcast
> > 192.168.103.255 inet6 2001:470:28:658:a2a8:cdff:fe63:abb9 prefixlen 64
> > autoconf pltime 604759 vltime 2591959 inet6
> > 2001:470:28:658:54c6:1b6f:ee43:32b9 prefixlen 64 deprecated autoconf
> > autoconfprivacy pltime 0 vltime 43 inet6
> > 2001:470:28:658:9039:71e4:30e2:a37e prefixlen 64 autoconf autoconfprivacy
> > pltime 11955 vltime 530703
> > 
> > That's output from my laptop just now, with autoconfigured inet6 addresses.
> > I believe the pltime and vltime values are given in seconds.
> 
> can it be that ifconfig outputs pltime and vltime only if the values are set 
> but not in the case that they are forever? Or are the values not shown or in 
> case of using virtual interfaces? The man page does not say.
> I'm asking because :
> 
> $ doas ifconfig
> [snip re0 and re1]
> vether0: flags=8943 mtu 1500
> lladdr fe:e1:ba:d0:52:8d
> index 8 priority 0 llprio 3
> groups: vether
> media: Ethernet autoselect
> status: active
> inet 192.168.12.1 netmask 0xff00 broadcast 192.168.12.255
> inet6 fe80::fce1:baff:fed0:528d%vether0 prefixlen 64 scopeid 0x8
> inet6 2001:470:1f0b:ca9::1 prefixlen 64

You don't seem to have any autoconfigured addresses.
Try ifconfig vether0 inet6 autoconf first.

Re: Is randomizing UID/GUID would make sense?

[Christian Weisgerber]

On 2017-04-19, Philip Guenther  wrote:

> For a broader answer to the "why?", take a look at the patches under
> /usr/ports/ which add uses of the *_deterministic() calls.

For instance, take graphics/netpbm and look at its multitude of
image manipulation tools that take a -randomseed=integer argument
to ensure that the same result can be obtained on separate invocations.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: howto show IPv6 address lifetime?

[Eike Lantzsch]

On Wednesday, 19 April 2017 14:22:32 -04 Peter N. M. Hansteen wrote:
> On Wed, Apr 19, 2017 at 11:16:44AM +0200, Harald Dunkel wrote:
> > > Give a try to ifconfig as regarde privacy policy lifetime : pltime &
> > > vltime if i'm still right. You can also preset this two counters using
> > > the same command.> 
> > ??? Sorry, but I don't understand this first sentence.
> > 
> > I would like to see the address lifetime, which address is preferred,
> > which is deprecated, etc. On Linux a simple command like "ip a s" shows.
> As quoted above, ifconfig is your friend:
> 
> [Wed Apr 19 14:19:35] peter@elke:~$ ifconfig iwm0
> iwm0: flags=208943
> mtu 1500 lladdr a0:a8:cd:63:ab:b9
> index 1 priority 4 llprio 3
> groups: wlan egress
> media: IEEE802.11 autoselect (HT-MCS4 mode 11n)
> status: active
> ieee80211: nwid we_collect_all_your_nasty-bits5 chan 36 bssid
> e0:3f:49:23:bb:2c 29% wpakey  wpaprotos wpa2 wpaakms psk
> wpaciphers ccmp wpagroupcipher ccmp inet6 fe80::a2a8:cdff:fe63:abb9%iwm0
> prefixlen 64 scopeid 0x1 inet 192.168.103.126 netmask 0xff00 broadcast
> 192.168.103.255 inet6 2001:470:28:658:a2a8:cdff:fe63:abb9 prefixlen 64
> autoconf pltime 604759 vltime 2591959 inet6
> 2001:470:28:658:54c6:1b6f:ee43:32b9 prefixlen 64 deprecated autoconf
> autoconfprivacy pltime 0 vltime 43 inet6
> 2001:470:28:658:9039:71e4:30e2:a37e prefixlen 64 autoconf autoconfprivacy
> pltime 11955 vltime 530703
> 
> That's output from my laptop just now, with autoconfigured inet6 addresses.
> I believe the pltime and vltime values are given in seconds.

can it be that ifconfig outputs pltime and vltime only if the values are set 
but not in the case that they are forever? Or are the values not shown or in 
case of using virtual interfaces? The man page does not say.
I'm asking because :

$ doas ifconfig
[snip re0 and re1]
vether0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:52:8d
index 8 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 192.168.12.1 netmask 0xff00 broadcast 192.168.12.255
inet6 fe80::fce1:baff:fed0:528d%vether0 prefixlen 64 scopeid 0x8
inet6 2001:470:1f0b:ca9::1 prefixlen 64
bridge0: flags=41
index 9 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
vether0 flags=3
port 8 ifpriority 0 ifcost 0
athn0 flags=3
port 4 ifpriority 0 ifcost 0
re2 flags=3
port 3 ifpriority 0 ifcost 0
[snip]
pflog0: flags=141 mtu 33144
index 12 priority 0 llprio 3
groups: pflog
gif0: flags=8051 mtu 1280
index 13 priority 0 llprio 3
groups: gif egress
tunnel: inet 181.121.5.112 -> 216.66.80.30
inet6 fe80::20d:b9ff:fe41:2214%gif0 ->  prefixlen 64 scopeid 0xd
inet6 2001:470:1f0a:ca8::2 -> 2001:470:1f0a:ca8::1 prefixlen 128

Greetings
Eike

Re: Adding default IPv6 route fails on 6.1

[Marc Peters]

Am 04/19/17 um 08:47 schrieb Harald Dunkel:
> On 04/18/17 17:05, Stuart Henderson wrote:
> 
>> Mine is in the pkg-readme.
> 
> 
> 
> A pkg-readme? Is this included in the binary package?

Try

$ less /usr/local/share/doc/pkg-readmes/dhcpcd-6.11.5



signature.asc
Description: OpenPGP digital signature

Re: howto show IPv6 address lifetime?

[Peter N. M. Hansteen]

On Wed, Apr 19, 2017 at 11:16:44AM +0200, Harald Dunkel wrote:
> > Give a try to ifconfig as regarde privacy policy lifetime : pltime & vltime 
> > if i'm still right. You can also preset this two counters using the same 
> > command.
> 
> ??? Sorry, but I don't understand this first sentence.
> 
> I would like to see the address lifetime, which address is preferred, which 
> is deprecated, etc. On Linux a simple command like "ip a s" shows.

As quoted above, ifconfig is your friend:

[Wed Apr 19 14:19:35] peter@elke:~$ ifconfig iwm0
iwm0: flags=208943 
mtu 1500
lladdr a0:a8:cd:63:ab:b9
index 1 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS4 mode 11n)
status: active
ieee80211: nwid we_collect_all_your_nasty-bits5 chan 36 bssid 
e0:3f:49:23:bb:2c 29% wpakey  wpaprotos wpa2 wpaakms psk 
wpaciphers ccmp wpagroupcipher ccmp
inet6 fe80::a2a8:cdff:fe63:abb9%iwm0 prefixlen 64 scopeid 0x1
inet 192.168.103.126 netmask 0xff00 broadcast 192.168.103.255
inet6 2001:470:28:658:a2a8:cdff:fe63:abb9 prefixlen 64 autoconf pltime 
604759 vltime 2591959
inet6 2001:470:28:658:54c6:1b6f:ee43:32b9 prefixlen 64 deprecated 
autoconf autoconfprivacy pltime 0 vltime 43
inet6 2001:470:28:658:9039:71e4:30e2:a37e prefixlen 64 autoconf 
autoconfprivacy pltime 11955 vltime 530703

That's output from my laptop just now, with autoconfigured inet6 addresses. I 
believe the pltime and vltime
values are given in seconds.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: howto show IPv6 address lifetime?

[Harald Dunkel]

> On Apr 19, 2017, at 10:43, Eric Huiban  wrote:
> 
> Hi,
> 
> Give a try to ifconfig as regarde privacy policy lifetime : pltime & vltime 
> if i'm still right. You can also preset this two counters using the same 
> command.

??? Sorry, but I don't understand this first sentence.

I would like to see the address lifetime, which address is preferred, which is 
deprecated, etc. On Linux a simple command like "ip a s" shows.

Regards
Harri

Re: howto show IPv6 address lifetime?

[Eric Huiban]

Hi,

Give a try to ifconfig as regarde privacy policy lifetime : pltime & vltime if 
i'm still right. You can also preset this two counters using the same command.

Eric

Re: GUI desktop autologin options

[Sha'ul]

You can't click on Shut Down and leave the computer to turn off on its own?

I'm using slim as the Display Manager on 6.1-RELEASE on my main laptop,
with Lumina for the time being as my DE. I just added the following to the
end of /etc/slim.conf and it does auto-login for me. Frustratingly, "log
out" immediately logs me back in instead of prompting. If you're okay with
that, then give it a go.

auto_login  yes
default_useraxon

Slim obeys the .xsession script for whatever Desktop Environment or Window
Manager you've chosen, or you can adjust the default sessions in slim.conf
as well. Both my .xsession and .xinitrc contain this line that starts up
Lumina.

exec start-lumina-desktop

Cheers

On Tue, Apr 18, 2017 at 10:44 PM, Sha'ul  wrote:

> I'm trying to figure how setup an auto login from boot to some kind of
> GUI
> desktop interface. What are my options? I'm not interested in Gnome 3,
> but
> I will use anything else like Lumina, KDE, XFCE, etc. as long as it can
> load straight into desktop environment when I turn on computer. Which
> ones, besides Gnome 3, support autologin?
>
>

Re: Adding default IPv6 route fails on 6.1

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/18/17 17:05, Stuart Henderson wrote:
> 
> Mine is in the pkg-readme.
> 
> 

A pkg-readme? Is this included in the binary package?

# find / -iname \*readme\* -print | grep -i dhcp
# echo $?
1


Regards
Harri

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAlj3CA8ACgkQCp4qnmbT
gcv65Qf/S7weEvhxdy7OTXdOd5Y+iDq1X1jkvQzW7j5d8DRriOjbTTR+3lNbc6vW
JNrgvH0LUGiUQzbc7g2rFB+ISHBgPpJfFyvhErOawZgDVvY5dhXeuXQ4nYYWAM7g
/MKBW6Rjy3WV+24YqEp0QxSCbC2KZfHpt5a6lkZDAhDsOaccLWiGU5VJQIzy76z2
O+wAC/xuXIcPBgCC53dXiRZzjUe8coxnl0Egi2DfCOGxyAbuziMC/hdFob1Hs+/h
tnjyHBq4+u5fnpl/AHAi3/qUEtqyKHk8dT7WpGQceypLYSDU/m5N30oERXpAVUfH
HvpjAexQgCE8A4aghOoX06Db1B1r4Q==
=JPo5
-END PGP SIGNATURE-

howto show IPv6 address lifetime?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

AFAIR IPv6 addresses have a lifetime and some other attributes.
Is there some way to show? "sysctl -a", "ifconfig -a" and netstat
don't.


Probably I am just missing the right command. Every helpful hint
is highly appreciated.

Harri
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAlj3Bo4ACgkQCp4qnmbT
gcvTvQf/VlNt8XHhVGNj9V0nS68w2nWrMlbMzaoofl1q0YppEVVrov4rYDH3EapC
qbL3jOxjG5RbYfmuhMSt796F/R2vD/u40q7dv//CQoS8rhvYN3G6rnoOVGWz8WLU
bVr4RrOZk8uBM4emX3jr+AxpUEU/PyQQXNpoQ2K98PNIlLXcpsh8V2Xwq4kQtbb5
g/flcJjUcKrXHeO+9jH052maymqLVu9Z+oUJPENyeNhWZvkvWIbZZgVA1BtiYRCr
ZFIHaNoYiJy9qryzE4+Psrj4gDi+JSp/QDsA1E0KUA/M+FNLxv3TB9aZLI2p46H7
lwWWIuu0nv08a3GnMLiAQG2iWQBZKw==
=aZGh
-END PGP SIGNATURE-

Re: kqueue

[Luke Small]

It looks like you will be limited to 4096 timers and to valid file
descriptors that don't exceed INT_MAX. My guess is that if you need more,
you could run another kqueue for more timers or different kevents on
identical file descriptors.

Otherwise, the man page says:
kevent() returns the number of events placed in the eventlist, up to the
 value given by nevents.  If an error occurs while processing an element
 of the changelist and there is enough room in the eventlist, then the
 event will be placed in the eventlist with EV_ERROR set in flags and
the
 system error in data.  Otherwise, -1 will be returned, and errno will
be
 set to indicate the error condition.