[patch] src etc/root/root.mail - adjust the Emacs package version

2017-03-04 Thread lists
Sat, 4 Mar 2017 14:40:45 -0700 (MST) Theo de Raadt 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   dera...@cvs.openbsd.org 2017/03/04 14:40:45
> 
> Modified files:
>   etc/root   : root.mail 
> 
> Log message:
> fix date and mention installurl way of pkg_add
> 

Hi tech@,

Humble suggestion to adjust the Emacs package version (to ask interactively).
File is here: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/root/root.mail

Kind regards,
Anton Lazarov

$ diff -u root.mail-{r1.120,r1.121}
--- root.mail-r1.120Sun Mar  5 04:13:32 2017
+++ root.mail-r1.121Sun Mar  5 04:14:29 2017
@@ -31,7 +31,7 @@
 is stored into the file /etc/installurl.  Installation of packages is
 as simple as:
 
- # pkg_add -v rsync chromium emacs-24.5p0-no_x11
+ # pkg_add -v rsync chromium emacs--no_x11
 
 Significant efforts were made to centralize all system configuration in the
 /etc directory.  You should be able to find each of the configuration files



Re: Enable TCP ECN by default (for inbound)

2017-03-04 Thread David Hill
On Fri, Oct 07, 2016 at 11:05:28PM -0400, David Hill wrote:
> Hello -
> 
> Many operating systems out there are starting to enable TCP ECN by
> default, most inbound-only.  Linux, FreeBSD, Apple MacOS and iOS.
> 
> This diff mimicks the FreeBSD diff found at
> http://marc.info/?l=freebsd-commits-all=146369644516347=2
> 
> It modifies the net.inet.tcp.ecn from an off and on switch to a 
> three-way setting: off, on, and inbound-only (0, 1, 2, respectively).
> 
> It also enables TCP ECN by default for inbound connections that request
> it.
> 
> My home router has TCP ECN enabled. With 36 hours of uptime, netstat -s
> shows:
>   16165 ECN connections accepted
>   1 ECE packet received
>   6 ECE packets sent
>   589 CWR packets received
>   109 CWR packets sent
> 
> This diff is just to see if there is interest in such a change.  If
> people seem to like the idea, perhaps I could update the diff to also:
>   - Remove TCP_ECN kernel option and always compile in support?
>   - Only allow 0, 1, or 2 via the sysctl net.inet.tcp.ecn knob.
>   - Update pf.os
> 
> Thoughts?
>  - David
>  

Here is a diff that doesn't change the default.

Index: netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.119
diff -u -p -r1.119 tcp_output.c
--- netinet/tcp_output.c9 Feb 2017 15:19:32 -   1.119
+++ netinet/tcp_output.c4 Mar 2017 21:26:02 -
@@ -843,10 +843,12 @@ send:
}
if (!(tp->t_flags & TF_DISABLE_ECN)) {
/*
-* if this is a SYN seg, set ECE and CWR.
-* set only ECE for SYN-ACK if peer supports ECN.
+* If net.inet.tcp.ecn is set to 1 and this is a
+* SYN seg, set both ECE and CWR.
+* Set only ECE for SYN-ACK if peer supports ECN.
 */
-   if ((flags & (TH_SYN|TH_ACK)) == TH_SYN)
+   if (tcp_do_ecn == 1 &&
+   (flags & (TH_SYN|TH_ACK)) == TH_SYN)
flags |= (TH_ECE|TH_CWR);
else if ((tp->t_flags & TF_ECN_PERMIT) &&
 (flags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK))
Index: netinet/tcp_subr.c
===
RCS file: /cvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.160
diff -u -p -r1.160 tcp_subr.c
--- netinet/tcp_subr.c  9 Feb 2017 15:19:32 -   1.160
+++ netinet/tcp_subr.c  4 Mar 2017 21:26:02 -
@@ -110,7 +110,7 @@ int tcp_do_sack = 1;/* RFC 2018 selecti
 #endif
 inttcp_ack_on_push = 0;/* set to enable immediate ACK-on-PUSH */
 #ifdef TCP_ECN
-inttcp_do_ecn = 0; /* RFC3168 ECN enabled/disabled? */
+inttcp_do_ecn = 0; /* RFC3168 TCP ECN 0:off 1:on 2:inbound-only */
 #endif
 inttcp_do_rfc3390 = 2; /* Increase TCP's Initial Window to 10*mss */
 
Index: netinet/tcp_var.h
===
RCS file: /cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.122
diff -u -p -r1.122 tcp_var.h
--- netinet/tcp_var.h   9 Feb 2017 15:19:32 -   1.122
+++ netinet/tcp_var.h   4 Mar 2017 21:26:02 -
@@ -703,7 +703,7 @@ extern  int tcp_do_sack;/* SACK enabled/
 extern struct pool sackhl_pool;
 extern int tcp_sackhole_limit; /* max entries for tcp sack queues */
 #endif
-extern int tcp_do_ecn; /* RFC3168 ECN enabled/disabled? */
+extern int tcp_do_ecn; /* RFC3168 ECN: 0:off 1:on 2:inbound-only */
 extern int tcp_do_rfc3390; /* RFC3390 Increasing TCP's Initial Window */
 
 extern struct pool tcpqe_pool;
 



Re: -current relayd TLS interception and SNI?

2017-03-04 Thread Reyk Floeter

> Am 04.03.2017 um 17:06 schrieb Claudio Jeker :
> 
>> On Fri, Mar 03, 2017 at 10:46:32AM -0500, Michael W. Lucas wrote:
>> Hi folks,
>> 
>> It *appears* that relayd doesn't speak SNI when used as a transparent
>> intercepting proxy ala
>> http://www.reykfloeter.com/post/41814177050/relayd-ssl-interception
> 
> Yes, relayd is lacking SNI support and a few other things like OCSP.
> I started to rewrite relayd using libtls instead of using libssl directly.
> This should allow relayd to get SNI and OCSP support fairly easily.
> 

"rewrite relayd"

First time I hear about this, but it is rather porting it to libtls.

A task that was long planned once libtls has enough features/ ways to use it in 
relayd. For example, the inspection needs quite some libssl internals that are 
not exposed by libtls.

Reyk




Re: -current relayd TLS interception and SNI?

2017-03-04 Thread Claudio Jeker
On Fri, Mar 03, 2017 at 10:46:32AM -0500, Michael W. Lucas wrote:
> Hi folks,
> 
> It *appears* that relayd doesn't speak SNI when used as a transparent
> intercepting proxy ala
> http://www.reykfloeter.com/post/41814177050/relayd-ssl-interception

Yes, relayd is lacking SNI support and a few other things like OCSP.
I started to rewrite relayd using libtls instead of using libssl directly.
This should allow relayd to get SNI and OCSP support fairly easily.

-- 
:wq Claudio



Re: 11n support for athn(4)

2017-03-04 Thread Stefan Sperling
On Tue, Jan 31, 2017 at 07:10:04AM +0200, Timo Myyrä wrote:
> 11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
> 11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps

I just committed a change which makes RTS optional in 11n mode.
The AP starts out with RTS enabled. Every 30 seconds the AP checks for
the presence of non-11n devices and enables/disables RTS accordingly.

Can you update to -current and measure again?
I would like to know if 11g and 11n performance still differs.