Re: iscsid issues with Synology NAS
On 31.03., David Alten wrote:
> Hello,
>
> I???m having issues getting iscsid to work with my Synology NAS.
>
> The first issue was that the NAS was returning an error code. Turns out
> it didn???t like not?? missing the default SessionType=Normal.
>
> The second issue was that the login sequence never comleted. It seems we
> keep hardcoding MaxConnections and MaxRecvDataSegmentLength in
> connection.c:conn_gen_kvp() instead of negotiating to the lowest value.
> So I just bypassed that function entirely and hardcoded all the default
> settings in initiator.c.
>
> This makes the login step complete, but then nothing else happens after
> that. I would expect a new scsi device to be attached so I could use it.
>
> I did notice that MaxConnection shows as 0, but the NAS does show the
> connection as established.
>
> b1# iscsictl show?? ??
> Initiator: ISID base 80d3cf6f qalifier 6e7d
>
> Session 'disk2':
> ?? ?? SessionType: normal MaxConnections: 0
> ?? ?? TargetName: iqn.2000-01.com.synology:Target.02
> ?? ?? TargetAddr: 192.168.0.4:iscsi
> ?? ?? InitiatorName: iqn.1995-11.org.openbsd.iscsid:b1
> ?? ?? InitiatorAddr: 192.168.0.9
> command successful
>
> b1$ cat /etc/iscsi.conf?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> ?? ?? ?? ?? ?? ?? ??
> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> target disk2 {
> ?? ?? ?? ?? initiatoraddr 192.168.0.9
> ?? ?? ?? ?? targetaddr 192.168.0.4
> ?? ?? ?? ?? targetname "iqn.2000-01.com.synology:Target.02"
> }
> Any suggestions on where to go from here?
>
> Thanks,
>
> -David
>
Hi David,
I had the same problem some years ago when I tried to attach an iSCSI
LUN from my Synology to my APU box. I wrote the patch below which fixed
the problem for me. Maybe you can give it a try?
Cheers,
Bruno
Index: usr.sbin/iscsid/connection.c
===
RCS file: /cvs/src/usr.sbin/iscsid/connection.c,v
retrieving revision 1.21
diff -u -p -r1.21 connection.c
--- usr.sbin/iscsid/connection.c5 Dec 2015 06:38:18 - 1.21
+++ usr.sbin/iscsid/connection.c1 Apr 2021 05:18:29 -
@@ -316,44 +316,6 @@ log_debug("conn_parse_kvp: %s = %s", k->
#undef SET_NUM
#undef SET_BOOL
-int
-conn_gen_kvp(struct connection *c, struct kvp *kvp, size_t *nkvp)
-{
- struct session *s = c->session;
- size_t i = 0;
-
- if (s->mine.MaxConnections != iscsi_sess_defaults.MaxConnections) {
- if (kvp && i < *nkvp) {
- kvp[i].key = strdup("MaxConnections");
- if (kvp[i].key == NULL)
- return -1;
- if (asprintf(&kvp[i].value, "%hu",
- s->mine.MaxConnections) == -1) {
- kvp[i].value = NULL;
- return -1;
- }
- }
- i++;
- }
- if (c->mine.MaxRecvDataSegmentLength !=
- iscsi_conn_defaults.MaxRecvDataSegmentLength) {
- if (kvp && i < *nkvp) {
- kvp[i].key = strdup("MaxRecvDataSegmentLength");
- if (kvp[i].key == NULL)
- return -1;
- if (asprintf(&kvp[i].value, "%u",
- c->mine.MaxRecvDataSegmentLength) == -1) {
- kvp[i].value = NULL;
- return -1;
- }
- }
- i++;
- }
-
- *nkvp = i;
- return 0;
-}
-
void
conn_pdu_write(struct connection *c, struct pdu *p)
{
Index: usr.sbin/iscsid/initiator.c
===
RCS file: /cvs/src/usr.sbin/iscsid/initiator.c,v
retrieving revision 1.15
diff -u -p -r1.15 initiator.c
--- usr.sbin/iscsid/initiator.c 16 Jan 2015 15:57:06 - 1.15
+++ usr.sbin/iscsid/initiator.c 1 Apr 2021 05:18:29 -
@@ -250,39 +250,113 @@ initiator_nop_in_imm(struct connection *
conn_task_issue(c, t);
}
+#define WRITE_BOOL(k, v) \
+do { \
+ if (v) \
+ k = "Yes"; \
+ else\
+ k = "No"; \
+} while (0)
+
+#define WRITE_NUM(k, v)\
+do { \
+ if (asprintf(&k, "%hu", v) == -1) \
+ errors++; \
+} while (0)
+
+#define WRITE_INT(k, v)\
+do { \
+ if (asprintf(&k, "%u", v) == -1)\
+ errors++; \
+} while (0)
+
+#define WRITE_DIGEST(k, v) \
+do { \
+ if (v) \
+ k = "CRC32";\
+ else\
+ k = "None"; \
+} while (0)\
+
struct
Re: iscsid issues with Synology NAS
On 01.04., Claudio Jeker wrote:
> On Thu, Apr 01, 2021 at 07:27:10AM +0200, Bruno Flueckiger wrote:
> > On 31.03., David Alten wrote:
> > > Hello,
> > >
> > > I???m having issues getting iscsid to work with my Synology NAS.
> > >
> > > The first issue was that the NAS was returning an error code. Turns out
> > > it didn???t like not?? missing the default SessionType=Normal.
> > >
> > > The second issue was that the login sequence never comleted. It seems we
> > > keep hardcoding MaxConnections and MaxRecvDataSegmentLength in
> > > connection.c:conn_gen_kvp() instead of negotiating to the lowest value.
> > > So I just bypassed that function entirely and hardcoded all the default
> > > settings in initiator.c.
> > >
> > > This makes the login step complete, but then nothing else happens after
> > > that. I would expect a new scsi device to be attached so I could use it.
> > >
> > > I did notice that MaxConnection shows as 0, but the NAS does show the
> > > connection as established.
> > >
> > > b1# iscsictl show?? ??
> > > Initiator: ISID base 80d3cf6f qalifier 6e7d
> > >
> > > Session 'disk2':
> > > ?? ?? SessionType: normal MaxConnections: 0
> > > ?? ?? TargetName: iqn.2000-01.com.synology:Target.02
> > > ?? ?? TargetAddr: 192.168.0.4:iscsi
> > > ?? ?? InitiatorName: iqn.1995-11.org.openbsd.iscsid:b1
> > > ?? ?? InitiatorAddr: 192.168.0.9
> > > command successful
> > >
> > > b1$ cat /etc/iscsi.conf?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > > ?? ?? ?? ?? ?? ?? ?? ??
> > > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > > target disk2 {
> > > ?? ?? ?? ?? initiatoraddr 192.168.0.9
> > > ?? ?? ?? ?? targetaddr 192.168.0.4
> > > ?? ?? ?? ?? targetname "iqn.2000-01.com.synology:Target.02"
> > > }
> > > Any suggestions on where to go from here?
> > >
> > > Thanks,
> > >
> > > -David
> > >
> >
> > Hi David,
> >
> > I had the same problem some years ago when I tried to attach an iSCSI
> > LUN from my Synology to my APU box. I wrote the patch below which fixed
> > the problem for me. Maybe you can give it a try?
> >
>
> Can someone send me a full pcap file of the negotiation with the synology
> nas device? It seems there is something not quite right in the negotiation
> code but the proposed diffs don't look correct either.
>
> --
> :wq Claudio
>
This is the captures I've used four years ago to analyze the connection
problem between iscsid and my Synology device:
https://www.bsdhowto.ch/downloads/synology_target.pcap
My theory was that the target code expects a confirmation for the
paramters it sends during the login phase. But iscsid keeps responding
with the only two parameters it started the login. As a workaround I
added the "missing" parameters.
Cheers,
Bruno
Re: httpd(8): don't send HSTS headers over unencrypted connections
On 14.10.18 19:36, Anthony J. Bentley wrote:
> Hi,
>
> RFC 6797 says:
>
>An HSTS Host MUST NOT include the STS header field in HTTP responses
>conveyed over non-secure transport.
>
> Is this the correct check? With this I get what I expect: HSTS headers
> over TLS, and no HSTS headers over unencrypted HTTP.
>
If you don't want to send HSTS headers then don't set the option hsts in
httpd.conf(5). Why would you provide an option for the admin to choose
but restrict it to only encrypted connections?
Your change would break the scenario of running httpd behind relayd(8)
for TLS acceleaation, e. g. relayd on the public interface and httpd on
localhost.
Cheers,
Bruno
> Index: server_fcgi.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 server_fcgi.c
> --- server_fcgi.c 19 May 2018 13:56:56 - 1.76
> +++ server_fcgi.c 15 Oct 2018 01:30:28 -
> @@ -655,7 +655,7 @@ server_fcgi_header(struct client *clt, u
> return (-1);
>
> /* HSTS header */
> - if (srv_conf->flags & SRVFLAG_SERVER_HSTS) {
> + if (srv_conf->flags & SRVFLAG_SERVER_HSTS && clt->clt_tls_ctx != NULL) {
> if ((cl =
> kv_add(&resp->http_headers, "Strict-Transport-Security",
> NULL)) == NULL ||
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.125
> diff -u -p -r1.125 server_http.c
> --- server_http.c 11 Oct 2018 09:52:22 - 1.125
> +++ server_http.c 15 Oct 2018 01:30:28 -
> @@ -950,7 +950,7 @@ server_abort_http(struct client *clt, un
> goto done;
> }
>
> - if (srv_conf->flags & SRVFLAG_SERVER_HSTS) {
> + if (srv_conf->flags & SRVFLAG_SERVER_HSTS && clt->clt_tls_ctx != NULL) {
> if (asprintf(&hstsheader, "Strict-Transport-Security: "
> "max-age=%d%s%s\r\n", srv_conf->hsts_max_age,
> srv_conf->hsts_flags & HSTSFLAG_SUBDOMAINS ?
> @@ -1452,7 +1452,7 @@ server_response_http(struct client *clt,
> return (-1);
>
> /* HSTS header */
> - if (srv_conf->flags & SRVFLAG_SERVER_HSTS) {
> + if (srv_conf->flags & SRVFLAG_SERVER_HSTS && clt->clt_tls_ctx != NULL) {
> if ((cl =
> kv_add(&resp->http_headers, "Strict-Transport-Security",
> NULL)) == NULL ||
>
[PATCH] httpd: Write X-Forwarded-For to access.log
Hi
When I run httpd(8) behind relayd(8) the access log of httpd contains
the IP address of relayd, but not the IP address of the client. I've
tried to match the logs of relayd(8) and httpd(8) using some scripting
and failed.
So I've written a patch for httpd(8). It stores the content of the
X-Forwarded-For header in the third field of the log entry:
www.example.com 192.0.2.99 192.0.2.134 - [11/Nov/2018:09:28:48 ...
Cheers,
Bruno
Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.127
diff -u -p -r1.127 server_http.c
--- usr.sbin/httpd/server_http.c4 Nov 2018 05:56:45 - 1.127
+++ usr.sbin/httpd/server_http.c11 Nov 2018 08:41:18 -
@@ -1632,7 +1632,7 @@ server_log_http(struct client *clt, unsi
static char tstamp[64];
static char ip[INET6_ADDRSTRLEN];
time_t t;
- struct kvkey, *agent, *referrer;
+ struct kvkey, *agent, *referrer, *xff;
struct tm *tm;
struct server_config*srv_conf;
struct http_descriptor *desc;
@@ -1642,6 +1642,7 @@ server_log_http(struct client *clt, unsi
char*version = NULL;
char*referrer_v = NULL;
char*agent_v = NULL;
+ char*xff_v = NULL;
if ((srv_conf = clt->clt_srv_conf) == NULL)
return (-1);
@@ -1666,7 +1667,7 @@ server_log_http(struct client *clt, unsi
*
* httpd's format is similar to these Apache LogFormats:
* "%v %h %l %u %t \"%r\" %>s %B"
-* "%v %h %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-agent}i\""
+* "%v %h %a %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-agent}i\""
*/
switch (srv_conf->logformat) {
case LOG_FORMAT_COMMON:
@@ -1708,6 +1709,11 @@ server_log_http(struct client *clt, unsi
agent->kv_value == NULL)
agent = NULL;
+ key.kv_key = "X-Forwarded-For";
+ if ((xff = kv_find(&desc->http_headers, &key)) != NULL &&
+ xff->kv_value == NULL)
+ xff = NULL;
+
/* Use vis to encode input values from the header */
if (clt->clt_remote_user &&
stravis(&user, clt->clt_remote_user, HTTPD_LOGVIS) == -1)
@@ -1718,6 +1724,9 @@ server_log_http(struct client *clt, unsi
if (agent &&
stravis(&agent_v, agent->kv_value, HTTPD_LOGVIS) == -1)
goto done;
+ if (xff &&
+ stravis(&xff_v, xff->kv_value, HTTPD_LOGVIS) == -1)
+ goto done;
/* The following should be URL-encoded */
if (desc->http_path &&
@@ -1728,10 +1737,10 @@ server_log_http(struct client *clt, unsi
goto done;
ret = evbuffer_add_printf(clt->clt_log,
- "%s %s - %s [%s] \"%s %s%s%s%s%s\""
+ "%s %s %s %s [%s] \"%s %s%s%s%s%s\""
" %03d %zu \"%s\" \"%s\"\n",
- srv_conf->name, ip, clt->clt_remote_user == NULL ? "-" :
- user, tstamp,
+ srv_conf->name, ip, xff == NULL ? "-" : xff_v,
+ clt->clt_remote_user == NULL ? "-" : user, tstamp,
server_httpmethod_byid(desc->http_method),
desc->http_path == NULL ? "" : path,
desc->http_query == NULL ? "" : "?",
@@ -1762,6 +1771,7 @@ done:
free(version);
free(referrer_v);
free(agent_v);
+ free(xff_v);
return (ret);
}
Re: [PATCH] httpd: Write X-Forwarded-For to access.log
On 11.11.18 15:29, Florian Obser wrote:
> On Sun, Nov 11, 2018 at 01:46:06PM +0100, Sebastian Benoit wrote:
> > Bruno Flueckiger(inform...@gmx.net) on 2018.11.11 10:31:34 +0100:
> > > Hi
> > >
> > > When I run httpd(8) behind relayd(8) the access log of httpd contains
> > > the IP address of relayd, but not the IP address of the client. I've
> > > tried to match the logs of relayd(8) and httpd(8) using some scripting
> > > and failed.
> > >
> > > So I've written a patch for httpd(8). It stores the content of the
> > > X-Forwarded-For header in the third field of the log entry:
> > >
> > > www.example.com 192.0.2.99 192.0.2.134 - [11/Nov/2018:09:28:48 ...
> > >
> > > Cheers,
> > > Bruno
> >
> > I'm not sure we should do this unconditionally. With no relayd or other
> > proxy infront of httpd, this is (more) data the client controls.
>
> Isn't what httpd(8) currently logs apache's common log format? If
> people are shoving that through webalizer or something that will
> break. I don't think we can do this without a config option.
> Do we need LogFormat?
>
> >
> > Could this be a problem?
> >
> > code reads ok.
> >
> > /Benno
> >
I've extended my patch with an option to the log directive. Both log xff
and log combined must be set for a server to log the content of the
X-Forwarded-For header. If only log combined is set the log entries
remain in the well-known format.
This prevents clients from getting unwanted data in the log by default.
And it makes sure the log format remains default until one decides
actively to change it.
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.55
diff -u -p -r1.55 config.c
--- usr.sbin/httpd/config.c 20 Jun 2018 16:43:05 - 1.55
+++ usr.sbin/httpd/config.c 11 Nov 2018 14:45:47 -
@@ -427,6 +427,10 @@ config_getserver_config(struct httpd *en
if ((srv_conf->flags & f) == 0)
srv_conf->flags |= parent->flags & f;
+ f = SRVFLAG_XFF|SRVFLAG_NO_XFF;
+ if ((srv_conf->flags & f) == 0)
+ srv_conf->flags |= parent->flags & f;
+
f = SRVFLAG_AUTH|SRVFLAG_NO_AUTH;
if ((srv_conf->flags & f) == 0) {
srv_conf->flags |= parent->flags & f;
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.101
diff -u -p -r1.101 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101
+++ usr.sbin/httpd/httpd.conf.5 11 Nov 2018 14:45:47 -
@@ -455,6 +455,14 @@ If not specified, the default is
Enable or disable logging to
.Xr syslog 3
instead of the log files.
+.It Oo Ic no Oc Ic xff
+Enable or disable logging of the request header
+.Ar X-Forwarded-For
+if
+.Cm log combined
+is set. This header can be set by a reverse proxy like
+.Xr relayd 8
+and should contain the IP address of the client.
.El
.It Ic pass
Disable any previous
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.142
diff -u -p -r1.142 httpd.h
--- usr.sbin/httpd/httpd.h 11 Oct 2018 09:52:22 - 1.142
+++ usr.sbin/httpd/httpd.h 11 Nov 2018 14:45:47 -
@@ -400,6 +400,8 @@ SPLAY_HEAD(client_tree, client);
#define SRVFLAG_DEFAULT_TYPE 0x0080
#define SRVFLAG_PATH_REWRITE 0x0100
#define SRVFLAG_NO_PATH_REWRITE0x0200
+#define SRVFLAG_XFF0x0400
+#define SRVFLAG_NO_XFF 0x0800
#define SRVFLAG_BITS \
"\10\01INDEX\02NO_INDEX\03AUTO_INDEX\04NO_AUTO_INDEX" \
Index: usr.sbin/httpd/parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.107
diff -u -p -r1.107 parse.y
--- usr.sbin/httpd/parse.y 1 Nov 2018 00:18:44 - 1.107
+++ usr.sbin/httpd/parse.y 11 Nov 2018 14:45:47 -
@@ -139,7 +139,7 @@ typedef struct {
%token LISTEN LOCATION LOG LOGDIR MATCH MAXIMUM NO NODELAY OCSP ON PORT PREFORK
%token PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET STRIP STYLE SYSLOG TCP TICKET
%token TIMEOUT TLS TYPE TYPES HSTS MAXAGE SUBDOMAINS DEFAULT PRELOAD REQUEST
-%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE
+%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE XFF
%token CA CLIENT CRL OPTIONAL
%token STRING
%token
Re: [PATCH] httpd: Write X-Forwarded-For to access.log
On 11.11.18 18:43, Claudio Jeker wrote:
> On Sun, Nov 11, 2018 at 06:32:53PM +0100, Bruno Flueckiger wrote:
> > On 11.11.18 15:29, Florian Obser wrote:
> > > On Sun, Nov 11, 2018 at 01:46:06PM +0100, Sebastian Benoit wrote:
> > > > Bruno Flueckiger(inform...@gmx.net) on 2018.11.11 10:31:34 +0100:
> > > > > Hi
> > > > >
> > > > > When I run httpd(8) behind relayd(8) the access log of httpd contains
> > > > > the IP address of relayd, but not the IP address of the client. I've
> > > > > tried to match the logs of relayd(8) and httpd(8) using some scripting
> > > > > and failed.
> > > > >
> > > > > So I've written a patch for httpd(8). It stores the content of the
> > > > > X-Forwarded-For header in the third field of the log entry:
> > > > >
> > > > > www.example.com 192.0.2.99 192.0.2.134 - [11/Nov/2018:09:28:48 ...
> > > > >
> > > > > Cheers,
> > > > > Bruno
> > > >
> > > > I'm not sure we should do this unconditionally. With no relayd or other
> > > > proxy infront of httpd, this is (more) data the client controls.
> > >
> > > Isn't what httpd(8) currently logs apache's common log format? If
> > > people are shoving that through webalizer or something that will
> > > break. I don't think we can do this without a config option.
> > > Do we need LogFormat?
> > >
> > > >
> > > > Could this be a problem?
> > > >
> > > > code reads ok.
> > > >
> > > > /Benno
> > > >
> >
> > I've extended my patch with an option to the log directive. Both log xff
> > and log combined must be set for a server to log the content of the
> > X-Forwarded-For header. If only log combined is set the log entries
> > remain in the well-known format.
> >
> > This prevents clients from getting unwanted data in the log by default.
> > And it makes sure the log format remains default until one decides
> > actively to change it.
>
> From my experience with webservices is that today logging the IP is
> seldomly good enough. Please also include X-Forwarded-Port and maybe
> X-Forwarded-Proto.
> In general thanks to CG-NAT logging only IP is a bit pointless.
>
> --
> :wq Claudio
>
Thanks for the hint, Claudio.
This version of my diff includes the two headers X-Forwarded-For and
X-Forwarded-Port. Instead of using the third field of the log entry I
add two additional fileds to it. The first one contains the value of
X-Forwarded-For and the second one that of X-Forwarded-Port.
I think that appending two fields might do less harm than replacing one
field at the beginning of the log entry. I'm not sure that adding
X-Forwarded-Proto to the log really brings a benefit, so I left it away
in this diff.
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.55
diff -u -p -r1.55 config.c
--- usr.sbin/httpd/config.c 20 Jun 2018 16:43:05 - 1.55
+++ usr.sbin/httpd/config.c 12 Nov 2018 10:18:41 -
@@ -427,6 +427,10 @@ config_getserver_config(struct httpd *en
if ((srv_conf->flags & f) == 0)
srv_conf->flags |= parent->flags & f;
+ f = SRVFLAG_XFF|SRVFLAG_NO_XFF;
+ if ((srv_conf->flags & f) == 0)
+ srv_conf->flags |= parent->flags & f;
+
f = SRVFLAG_AUTH|SRVFLAG_NO_AUTH;
if ((srv_conf->flags & f) == 0) {
srv_conf->flags |= parent->flags & f;
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.101
diff -u -p -r1.101 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101
+++ usr.sbin/httpd/httpd.conf.5 12 Nov 2018 10:18:41 -
@@ -455,6 +455,16 @@ If not specified, the default is
Enable or disable logging to
.Xr syslog 3
instead of the log files.
+.It Oo Ic no Oc Ic xff
+Enable or disable logging of the request headers
+.Ar X-Forwarded-For
+and
+.Ar X-Forwarded-Port
+if
+.Cm log combined
+is set. These headers can be set by a reverse proxy like
+.Xr relayd 8
+and should contain the IP address and TCP port of the client.
.El
.It Ic pass
Disable any previous
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.142
diff -u -p
Re: [PATCH] httpd: Write X-Forwarded-For to access.log
On 12.11.18 12:40, Bruno Flueckiger wrote:
> On 11.11.18 18:43, Claudio Jeker wrote:
> > On Sun, Nov 11, 2018 at 06:32:53PM +0100, Bruno Flueckiger wrote:
> > > On 11.11.18 15:29, Florian Obser wrote:
> > > > On Sun, Nov 11, 2018 at 01:46:06PM +0100, Sebastian Benoit wrote:
> > > > > Bruno Flueckiger(inform...@gmx.net) on 2018.11.11 10:31:34 +0100:
> > > > > > Hi
> > > > > >
> > > > > > When I run httpd(8) behind relayd(8) the access log of httpd
> > > > > > contains
> > > > > > the IP address of relayd, but not the IP address of the client. I've
> > > > > > tried to match the logs of relayd(8) and httpd(8) using some
> > > > > > scripting
> > > > > > and failed.
> > > > > >
> > > > > > So I've written a patch for httpd(8). It stores the content of the
> > > > > > X-Forwarded-For header in the third field of the log entry:
> > > > > >
> > > > > > www.example.com 192.0.2.99 192.0.2.134 - [11/Nov/2018:09:28:48 ...
> > > > > >
> > > > > > Cheers,
> > > > > > Bruno
> > > > >
> > > > > I'm not sure we should do this unconditionally. With no relayd or
> > > > > other
> > > > > proxy infront of httpd, this is (more) data the client controls.
> > > >
> > > > Isn't what httpd(8) currently logs apache's common log format? If
> > > > people are shoving that through webalizer or something that will
> > > > break. I don't think we can do this without a config option.
> > > > Do we need LogFormat?
> > > >
> > > > >
> > > > > Could this be a problem?
> > > > >
> > > > > code reads ok.
> > > > >
> > > > > /Benno
> > > > >
> > >
> > > I've extended my patch with an option to the log directive. Both log xff
> > > and log combined must be set for a server to log the content of the
> > > X-Forwarded-For header. If only log combined is set the log entries
> > > remain in the well-known format.
> > >
> > > This prevents clients from getting unwanted data in the log by default.
> > > And it makes sure the log format remains default until one decides
> > > actively to change it.
> >
> > From my experience with webservices is that today logging the IP is
> > seldomly good enough. Please also include X-Forwarded-Port and maybe
> > X-Forwarded-Proto.
> > In general thanks to CG-NAT logging only IP is a bit pointless.
> >
> > --
> > :wq Claudio
> >
>
> Thanks for the hint, Claudio.
>
> This version of my diff includes the two headers X-Forwarded-For and
> X-Forwarded-Port. Instead of using the third field of the log entry I
> add two additional fileds to it. The first one contains the value of
> X-Forwarded-For and the second one that of X-Forwarded-Port.
>
> I think that appending two fields might do less harm than replacing one
> field at the beginning of the log entry. I'm not sure that adding
> X-Forwarded-Proto to the log really brings a benefit, so I left it away
> in this diff.
In the meantime I've run my diff on a webserver. In my experience
webalizer has no problem with the modified log format. GoAccess on the
other hand has troubles reading access.log, but that happens for me with
and without the diff applied.
I think that most admins would profit from the diff. The setting is
optional so it doesn't affect everybody rightaway. And I believe that
those who enable it are ready to reconfigure whatever log parser they
use.
Therefore I have reworked my diff so it applies to the -current tree.
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.55
diff -u -p -r1.55 config.c
--- usr.sbin/httpd/config.c 20 Jun 2018 16:43:05 - 1.55
+++ usr.sbin/httpd/config.c 12 Feb 2019 13:37:55 -
@@ -427,6 +427,10 @@ config_getserver_config(struct httpd *en
if ((srv_conf->flags & f) == 0)
srv_conf->flags |= parent->flags & f;
+ f = SRVFLAG_XFF|SRVFLAG_NO_XFF;
+ if ((srv_conf->flags & f) == 0)
+ srv_conf->flags |= parent->flags & f;
+
f = SRVFLAG_AUTH|SRVFLAG_NO_AUTH;
if ((srv_conf->flags & f) == 0) {
srv_conf->flags
httpd: New log format to log X-Forwarded-{For|Port} headers
Hi,
I've completely reworked my patch for httpd(8). The last patch broke the
log format combined. And the config option was ugly. This time I've
added another log format called forwarded. It appends two fields to the
log format combined: The first field contains the value of the header
X-Forwarded-For and the second one the value of X-Forwarded-Port. If
either of the headers is empty or missing a dash (-) is written.
The new log format is compatible with log analyzing tools like Webalizer
or GoAccess. If you run httpd(8) behind a proxy like relayd(8) the new
log format finally gives you a way to track the origin of the requests.
Cheers,
Bruno
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.103
diff -u -p -r1.103 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 19 Feb 2019 11:37:26 - 1.103
+++ usr.sbin/httpd/httpd.conf.5 27 Feb 2019 15:26:48 -
@@ -450,7 +450,8 @@ The
.Ar style
can be
.Cm common ,
-.Cm combined
+.Cm combined ,
+.Cm forwarded
or
.Cm connection .
The styles
@@ -459,6 +460,14 @@ and
.Cm combined
write a log entry after each request similar to the standard Apache
and nginx access log formats.
+The style
+.Cm forwarded
+extends the style
+.Cm combined
+by appending two fields containing the values of the headers
+.Ar X-Forwarded-For
+and
+.Ar X-Forwarded-Port .
The style
.Cm connection
writes a summarized log entry after each connection,
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.143
diff -u -p -r1.143 httpd.h
--- usr.sbin/httpd/httpd.h 19 Feb 2019 11:37:26 - 1.143
+++ usr.sbin/httpd/httpd.h 27 Feb 2019 15:26:48 -
@@ -437,7 +437,8 @@ SPLAY_HEAD(client_tree, client);
enum log_format {
LOG_FORMAT_COMMON,
LOG_FORMAT_COMBINED,
- LOG_FORMAT_CONNECTION
+ LOG_FORMAT_CONNECTION,
+ LOG_FORMAT_FORWARDED
};
struct log_file {
Index: usr.sbin/httpd/parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.110
diff -u -p -r1.110 parse.y
--- usr.sbin/httpd/parse.y 19 Feb 2019 11:37:26 - 1.110
+++ usr.sbin/httpd/parse.y 27 Feb 2019 15:26:48 -
@@ -140,7 +140,7 @@ typedef struct {
%token PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET STRIP STYLE SYSLOG TCP TICKET
%token TIMEOUT TLS TYPE TYPES HSTS MAXAGE SUBDOMAINS DEFAULT PRELOAD REQUEST
%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS REWRITE
-%token CA CLIENT CRL OPTIONAL PARAM
+%token CA CLIENT CRL OPTIONAL PARAM FORWARDED
%token STRING
%token NUMBER
%type port
@@ -1024,6 +1024,11 @@ logstyle : COMMON{
srv_conf->flags |= SRVFLAG_LOG;
srv_conf->logformat = LOG_FORMAT_CONNECTION;
}
+ | FORWARDED {
+ srv_conf->flags &= ~SRVFLAG_NO_LOG;
+ srv_conf->flags |= SRVFLAG_LOG;
+ srv_conf->logformat = LOG_FORMAT_FORWARDED;
+ }
;
filter : block RETURN NUMBER optstring {
@@ -1295,6 +1300,7 @@ lookup(char *s)
{ "ecdhe", ECDHE },
{ "error", ERR },
{ "fastcgi",FCGI },
+ { "forwarded", FORWARDED },
{ "hsts", HSTS },
{ "include",INCLUDE },
{ "index", INDEX },
Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.129
diff -u -p -r1.129 server_http.c
--- usr.sbin/httpd/server_http.c10 Feb 2019 13:41:27 - 1.129
+++ usr.sbin/httpd/server_http.c27 Feb 2019 15:26:49 -
@@ -1632,7 +1632,7 @@ server_log_http(struct client *clt, unsi
static char tstamp[64];
static char ip[INET6_ADDRSTRLEN];
time_t t;
- struct kvkey, *agent, *referrer;
+ struct kvkey, *agent, *referrer, *xff, *xfp;
struct tm *tm;
struct server_config*srv_conf;
struct http_descriptor *desc;
@@ -1642,6 +1642,8 @@ server_log_http(struct client *clt, unsi
char*version = NULL;
char*referrer_v = NULL;
char*agent_v = NULL;
+ char*xff_v = NULL;
+ char*xfp_v = NULL;
if ((srv_conf = clt->clt_srv_conf) == NULL)
return (-1);
@@ -1698,6 +1700,7 @@ server_log_http(struct client *clt, unsi
brea
Re: [patch] cwm: filter duplicate hostnames in ssh menu
On 01.05., Marcus MERIGHI wrote: > Hello, > > o...@demirmen.com (Okan Demirmen), 2019.04.29 (Mon) 16:19 (CEST): > > On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote: > > > Hi, > > > > > > The ssh menu of cwm(1) doesn't filter duplicated hostnames when reading > > > them from ~/.ssh/known_hosts. This patch makes sure each hostname is > > > only displayed once to the menu. > > > > Sure, maybe; but why again do we even have this inside a window manager? > > Really, the known_hosts parsing is incomplete at best; either the entire > > parsing code needs to be lifted from ssh or this (mis)feature should be > > removed from cwm. I prefer the latter. > > FWIW, i use "M-period" a lot... are there easy alternatives? > > Marcus > I use dmenu[1] from suckless.org as a replacement. The following script reads the host names from ~/.ssh/known_hosts, feeds them to dmenu and executes ssh to the host I choose in an xterm: #!/bin/ksh expr="s/^@[a-z-]* //;s/[, ].*//;s/\[//;s/\]//" file=~/.ssh/known_hosts host=$(cat $file | sed "$expr" | sort | uniq | dmenu) [[ -n "$host" ]] && xterm -T "[ssh] $host" -e ssh $host I store the script in ~/bin/sshmenu.sh and add the following line to my ~/.cwmrc: bind-key M-period bin/sshmenu.sh Works like a charm for me. Cheers, Bruno [1] https://suckless.org/dmenu/
Re: [patch] cwm: filter duplicate hostnames in ssh menu
On 29.04., Okan Demirmen wrote:
> On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote:
> > Hi,
> >
> > The ssh menu of cwm(1) doesn't filter duplicated hostnames when reading
> > them from ~/.ssh/known_hosts. This patch makes sure each hostname is
> > only displayed once to the menu.
>
> Sure, maybe; but why again do we even have this inside a window manager?
> Really, the known_hosts parsing is incomplete at best; either the entire
> parsing code needs to be lifted from ssh or this (mis)feature should be
> removed from cwm. I prefer the latter.
>
After trying some possible replacements from ports it turns out that
dmenu from suckless.org together with a small shell script works best
for me.
This patch removes menu-ssh completely from cwm.
Cheers,
Bruno
Index: app/cwm/calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.371
diff -u -p -r1.371 calmwm.h
--- app/cwm/calmwm.h7 Mar 2019 14:28:17 - 1.371
+++ app/cwm/calmwm.h9 May 2019 08:22:14 -
@@ -304,7 +304,6 @@ struct conf {
int xrandr;
int xrandr_event_base;
char*conf_file;
- char*known_hosts;
char*wm_argv;
int debug;
};
@@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void *, struct
c
voidkbfunc_menu_group(void *, struct cargs *);
voidkbfunc_menu_wm(void *, struct cargs *);
voidkbfunc_menu_exec(void *, struct cargs *);
-voidkbfunc_menu_ssh(void *, struct cargs *);
voidkbfunc_client_menu_label(void *, struct cargs *);
voidkbfunc_exec_cmd(void *, struct cargs *);
voidkbfunc_exec_lock(void *, struct cargs *);
Index: app/cwm/conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.249
diff -u -p -r1.249 conf.c
--- app/cwm/conf.c 7 Mar 2019 12:54:21 - 1.249
+++ app/cwm/conf.c 9 May 2019 08:22:14 -
@@ -179,7 +179,6 @@ static const struct {
{ FUNC_SC(menu-cmd, menu_cmd, 0) },
{ FUNC_SC(menu-group, menu_group, 0) },
- { FUNC_SC(menu-ssh, menu_ssh, 0) },
{ FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
{ FUNC_SC(menu-window-hidden, menu_client, CWM_MENU_WINDOW_HIDDEN) },
{ FUNC_SC(menu-exec, menu_exec, 0) },
@@ -210,7 +209,6 @@ static const struct {
{ "CM-Delete", "lock" },
{ "M-question", "menu-exec" },
{ "CM-w", "menu-exec-wm" },
- { "M-period", "menu-ssh" },
{ "M-Return", "window-hide" },
{ "M-Down", "window-lower" },
{ "M-Up", "window-raise" },
@@ -316,7 +314,6 @@ conf_init(struct conf *c)
home = "/";
}
xasprintf(&c->conf_file, "%s/%s", home, ".cwmrc");
- xasprintf(&c->known_hosts, "%s/%s", home, ".ssh/known_hosts");
}
void
@@ -363,7 +360,6 @@ conf_clear(struct conf *c)
free(c->color[i]);
free(c->conf_file);
- free(c->known_hosts);
free(c->font);
free(c->wmname);
}
Index: app/cwm/cwm.1
===
RCS file: /cvs/xenocara/app/cwm/cwm.1,v
retrieving revision 1.64
diff -u -p -r1.64 cwm.1
--- app/cwm/cwm.1 25 Feb 2019 18:07:48 - 1.64
+++ app/cwm/cwm.1 9 May 2019 08:22:14 -
@@ -140,15 +140,6 @@ Resize window by a large amount; see
Spawn
.Dq exec program
dialog.
-.It Ic M-period
-Spawn
-.Dq ssh to
-dialog.
-This parses
-.Pa $HOME/.ssh/known_hosts
-to provide host auto-completion.
-.Xr ssh 1
-will be executed via the configured terminal emulator.
.It Ic CM-w
Spawn
.Dq exec WindowManager
Index: app/cwm/cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.72
diff -u -p -r1.72 cwmrc.5
--- app/cwm/cwmrc.5 25 Feb 2019 16:40:49 - 1.72
+++ app/cwm/cwmrc.5 9 May 2019 08:22:14 -
@@ -280,10 +280,6 @@ menu.
Launch
.Dq exec WindowManager
menu.
-.It menu-ssh
-Launch
-.Dq ssh
-menu.
.It group-toggle-[n]
Toggle visibility of group n, where n is 1-9.
.It group-only-[n]
Index: app/cwm/kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.165
diff -u -p -r1.165 kbfunc.c
--- app/cwm/kbfunc.c7 Mar 2019 14:28:17 - 1.165
+++ app/cwm/kbfunc.c9 May 2019 08:22:14 -
@@ -644,72 +644,6 @@ out:
}
void
-kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
-{
- struct screen_ctx *sc = ctx;
- struct cmd_ctx *cmd;
- struct menu *mi;
- struct menu_qmenuq;
- F
[patch] relayd OCSP stapling for TLS server
Hi,
The patch below adds OCSP stapling to the TLS server in relayd(8). The
OCSP response is read from a binary encoded DER file that can be created
using ocspcheck(8).
If a file with the same name as the certificate and private key files is
found, its content is loaded and OCSP stapling is active. If there is no
file or loading its content fails, OCSP stapling remains disabled.
relayd(8) uses the same mechanism it uses to find the certificate file,
only the file name extension is different: .der instead of .pem
Cheers,
Bruno
Index: usr.sbin/relayd/config.c
===
RCS file: /cvs/src/usr.sbin/relayd/config.c,v
retrieving revision 1.39
diff -u -p -r1.39 config.c
--- usr.sbin/relayd/config.c1 Jun 2019 09:54:19 - 1.39
+++ usr.sbin/relayd/config.c20 Jun 2019 17:37:09 -
@@ -913,6 +913,14 @@ config_setrelay(struct relayd *env, stru
rlay->rl_conf.name);
return (-1);
}
+ if (cert->cert_ocsp_fd != -1 &&
+ config_setrelayfd(ps, id, n,
+ cert->cert_id, cert->cert_relayid,
+ RELAY_FD_OCSP, cert->cert_ocsp_fd) == -1) {
+ log_warn("%s: fd passing failed for "
+ "`%s'", __func__,
+ rlay->rl_conf.name);
+ }
}
}
@@ -992,6 +1000,10 @@ config_setrelay(struct relayd *env, stru
close(cert->cert_key_fd);
cert->cert_key_fd = -1;
}
+ if (cert->cert_ocsp_fd != -1) {
+ close(cert->cert_ocsp_fd);
+ cert->cert_ocsp_fd = -1;
+ }
}
return (0);
@@ -1113,6 +1125,7 @@ config_getrelayfd(struct relayd *env, st
switch (crfd.type) {
case RELAY_FD_CERT:
case RELAY_FD_KEY:
+ case RELAY_FD_OCSP:
if ((cert = cert_find(env, crfd.id)) == NULL) {
if ((cert = cert_add(env, crfd.id)) == NULL)
return (-1);
@@ -1139,6 +1152,9 @@ config_getrelayfd(struct relayd *env, st
break;
case RELAY_FD_CAFILE:
rlay->rl_tls_cacert_fd = imsg->fd;
+ break;
+ case RELAY_FD_OCSP:
+ cert->cert_ocsp_fd = imsg->fd;
break;
}
Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.247
diff -u -p -r1.247 relay.c
--- usr.sbin/relayd/relay.c 31 May 2019 15:15:37 - 1.247
+++ usr.sbin/relayd/relay.c 20 Jun 2019 17:37:09 -
@@ -2130,8 +2130,8 @@ relay_tls_ctx_create(struct relay *rlay)
struct relay_cert *cert;
const char *fake_key;
int fake_keylen, keyfound = 0;
- char*buf = NULL, *cabuf = NULL;
- off_tlen = 0, calen = 0;
+ char*buf = NULL, *cabuf = NULL, *ocspbuf = NULL;
+ off_tlen = 0, calen = 0, ocsplen = 0;
if ((tls_cfg = tls_config_new()) == NULL) {
log_warnx("unable to allocate TLS config");
@@ -2209,9 +2209,19 @@ relay_tls_ctx_create(struct relay *rlay)
goto err;
}
+ if (cert->cert_ocsp_fd == -1)
+ goto without;
+
+ if ((ocspbuf = relay_load_fd(cert->cert_ocsp_fd,
+ &ocsplen)) == NULL) {
+ log_warn("failed to load ocsp staple");
+ ocsplen = 0;
+ }
+
+ without:
if (keyfound == 1 &&
tls_config_set_keypair_ocsp_mem(tls_cfg, buf, len,
- fake_key, fake_keylen, NULL, 0) != 0) {
+ fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
log_warnx("failed to set tls certificate: %s",
tls_config_error(tls_cfg));
goto err;
@@ -2223,7 +2233,7 @@ relay_tls_ctx_create(struct relay *rlay)
goto err;
if (tls_config_add_keypair_ocsp_mem(tls_cfg, buf, len,
- fake_key, fake_keylen, NULL, 0) != 0) {
+ fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
log_warnx("failed to add tls certificate: %s",
tls_config_error(t
Re: [patch] relayd OCSP stapling for TLS server
On 22.06., Theo Buehler wrote: > On Fri, Jun 21, 2019 at 01:28:03PM +0200, Reyk Floeter wrote: > > On Thu, Jun 20, 2019 at 07:58:10PM +0200, Bruno Flueckiger wrote: > > > Hi, > > > > > > The patch below adds OCSP stapling to the TLS server in relayd(8). The > > > OCSP response is read from a binary encoded DER file that can be created > > > using ocspcheck(8). > > > > > > If a file with the same name as the certificate and private key files is > > > found, its content is loaded and OCSP stapling is active. If there is no > > > file or loading its content fails, OCSP stapling remains disabled. > > > > > > relayd(8) uses the same mechanism it uses to find the certificate file, > > > only the file name extension is different: .der instead of .pem > > > > > > > I had this diff finished more than a month ago, but it had to wait for > > the SNI diff to go in. It is suprisingly similar to your version > > except some minor difference in relay_tls_ctx_create(), the man page, > > and the fact that I've decided for using ".ocsp" instead of ".der" for > > the ending (as .der could be anything). > > > > OK? > > Reads fine. Would be nice to hear that this works for Bruno, but it is > > ok tb > I like ".ocsp" better than ".der". And I'm a bit proud that my diff turns out to be good, although late :-). It works for me. Bruno
[patch] azalia: Intel 300 Series HD Audio
Hi, My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series HD Audio device rev 0x11. The device shows up as not configured in the dmesg. The PCI config space of the device identifies its subclass as PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO The patch below makes the device work just fine on my laptop. Cheers, Bruno Index: sys/dev/pci/azalia.c === RCS file: /cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.255 diff -u -p -r1.255 azalia.c --- sys/dev/pci/azalia.c18 Apr 2020 21:55:56 - 1.255 +++ sys/dev/pci/azalia.c28 May 2020 13:48:10 - @@ -481,7 +481,8 @@ azalia_pci_match(struct device *parent, pa = aux; if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA - && PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO) + && (PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO + || PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_AUDIO)) return 1; return 0; }
Re: [patch] azalia: Intel 300 Series HD Audio
On 29.05., Jonathan Gray wrote:
> On Fri, May 29, 2020 at 11:25:44AM +0200, Bruno Flueckiger wrote:
> > Hi,
> >
> > My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series
> > HD Audio device rev 0x11. The device shows up as not configured in the
> > dmesg. The PCI config space of the device identifies its subclass as
> > PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO
> >
> > The patch below makes the device work just fine on my laptop.
> >
> > Cheers,
> > Bruno
>
> I think it would be better to match on the id in that case as non-azalia
> devices use the audio class.
>
> Index: azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> retrieving revision 1.255
> diff -u -p -r1.255 azalia.c
> --- azalia.c 18 Apr 2020 21:55:56 - 1.255
> +++ azalia.c 29 May 2020 09:51:06 -
> @@ -474,6 +474,10 @@ azalia_configure_pci(azalia_t *az)
> }
> }
>
> +const struct pci_matchid azalia_pci_devices[] = {
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA }
> +};
> +
> int
> azalia_pci_match(struct device *parent, void *match, void *aux)
> {
> @@ -483,7 +487,8 @@ azalia_pci_match(struct device *parent,
> if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA
> && PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO)
> return 1;
> - return 0;
> + return pci_matchbyid((struct pci_attach_args *)aux, azalia_pci_devices,
> + nitems(azalia_pci_devices));
> }
>
> void
>
Your patch works just fine on my laptop.
Cheers,
Bruno
Re: [patch] azalia: Intel 300 Series HD Audio
On 31.05., Benjamin Baier wrote: > On Fri, 29 May 2020 11:25:44 +0200 > Bruno Flueckiger wrote: > > > Hi, > > > > My brand new laptop HP EliteBook 850 G6 comes with an Intel 300 Series > > HD Audio device rev 0x11. The device shows up as not configured in the > > dmesg. The PCI config space of the device identifies its subclass as > > PCI_SUBCLASS_MULTIMEDIA_AUDIO instead of PCI_SUBCLASS_MULTIMEDIA_HDAUDIO > > > > The patch below makes the device work just fine on my laptop. > > > > Cheers, > > Bruno > > > > Index: sys/dev/pci/azalia.c > > === > > RCS file: /cvs/src/sys/dev/pci/azalia.c,v > > retrieving revision 1.255 > > diff -u -p -r1.255 azalia.c > > --- sys/dev/pci/azalia.c18 Apr 2020 21:55:56 - 1.255 > > +++ sys/dev/pci/azalia.c28 May 2020 13:48:10 - > > @@ -481,7 +481,8 @@ azalia_pci_match(struct device *parent, > > > > pa = aux; > > if (PCI_CLASS(pa->pa_class) == PCI_CLASS_MULTIMEDIA > > - && PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO) > > + && (PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_HDAUDIO > > + || PCI_SUBCLASS(pa->pa_class) == PCI_SUBCLASS_MULTIMEDIA_AUDIO)) > > return 1; > > return 0; > > } > > > > Hi. > > Does your Laptop run with the latest BIOS? There was one released on May 11th. > https://support.hp.com/de-de/drivers/selfservice/swdetails/hp-elitebook-850-g6-notebook-pc/26609805/swItemId/ob-251060-1 > The release notes state: Fixes an issue where the audio on the system stops > functioning after the Intel Active Management Technology (AMT) option is > disabled. > > The azalia patch is in but I would prefer HP to fix their BIOS instead. > > Greetings Ben > Hi Ben, I've upgraded the firmware to the latest available release, but the audio device still reports with the wrong subclass in its PCI config space. I agree that HP should rather fix their firmware. I still try to find out how to report this problem to HP in a way that doesn't get ignored. Cheers, Bruno
pchtemp add Intel 300 Series Thermal sensor
Hi,
My HP EliteBook 850 G6 comes with an Intel 300 Series Thermal sensor.
The patch below makes this sensor available as pchtemp(4) device.
Cheers,
Bruno
Index: sys/dev/pci/pchtemp.c
===
RCS file: /cvs/src/sys/dev/pci/pchtemp.c,v
retrieving revision 1.4
diff -u -p -r1.4 pchtemp.c
--- sys/dev/pci/pchtemp.c24 May 2016 07:59:24 -1.4
+++ sys/dev/pci/pchtemp.c2 Jun 2020 08:20:55 -
@@ -63,6 +63,7 @@ const struct pci_matchid pchtemp_devices
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_9SERIES_LP_THERM },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_100SERIES_THERM },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_100SERIES_LP_THERM },
+{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_THERM },
};
int
Re: monitor mode for iwm(4)
Works as expected on a 3165 device:
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x81, msi
iwm0: hw rev 0x210, fw ver 16.242414.0, address xx:xx:xx:xx:xx:xx
Cheers,
Bruno
On 23.05.18 12:31, Stefan Sperling wrote:
> This diff implements monitor mode for iwm(4).
>
> To use it, enable 11n mode, monitor mode, and configure a channel (e.g. 11):
>
> ifconfig iwm0 mode 11n mediaopt monitor
> ifconfig iwm0 chan 11
> ifconfig iwm0 up
>
> This command should now display wireless frames on the air:
>
> tcpdump -n -i iwm0 -y IEEE802_11_RADIO -v
>
> Record frames with tcpdump like this (pcap file can be viewed in wireshark):
>
> tcpdump -n -i iwm0 -s 4096 -y IEEE802_11_RADIO -w /tmp/iwm.pcap
>
> Note that 11n/11ac frames sent with >= 40 MHz channel width won't be
> captured. The hardware could do it but our stack is not passing the
> necessary configuration parameters to the driver, so the driver cannot
> configure the hardware appropriately (a similar problem as bwfm(4) has
> with our stack's incomplete 11n support).
> But the corresponding leading RTS and trailing BlockAck frames can be
> captured, which allows us to manually deduce the presence of such frames.
>
> Tested on a 7265 device.
>
> ok?
>
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.229
> diff -u -p -r1.229 if_iwm.c
> --- if_iwm.c 15 May 2018 19:48:23 - 1.229
> +++ if_iwm.c 23 May 2018 10:10:45 -
> @@ -426,7 +426,7 @@ uint8_t iwm_ridx2rate(struct ieee80211_r
> int iwm_rval2ridx(int);
> void iwm_ack_rates(struct iwm_softc *, struct iwm_node *, int *, int *);
> void iwm_mac_ctxt_cmd_common(struct iwm_softc *, struct iwm_node *,
> - struct iwm_mac_ctx_cmd *, uint32_t, int);
> + struct iwm_mac_ctx_cmd *, uint32_t);
> void iwm_mac_ctxt_cmd_fill_sta(struct iwm_softc *, struct iwm_node *,
> struct iwm_mac_data_sta *, int);
> int iwm_mac_ctxt_cmd(struct iwm_softc *, struct iwm_node *, uint32_t, int);
> @@ -4446,6 +4446,7 @@ void
> iwm_power_build_cmd(struct iwm_softc *sc, struct iwm_node *in,
> struct iwm_mac_power_cmd *cmd)
> {
> + struct ieee80211com *ic = &sc->sc_ic;
> struct ieee80211_node *ni = &in->in_ni;
> int dtim_period, dtim_msec, keep_alive;
>
> @@ -4467,7 +4468,8 @@ iwm_power_build_cmd(struct iwm_softc *sc
> keep_alive = roundup(keep_alive, 1000) / 1000;
> cmd->keep_alive_seconds = htole16(keep_alive);
>
> - cmd->flags = htole16(IWM_POWER_FLAGS_POWER_SAVE_ENA_MSK);
> + if (ic->ic_opmode != IEEE80211_M_MONITOR)
> + cmd->flags = htole16(IWM_POWER_FLAGS_POWER_SAVE_ENA_MSK);
> }
>
> int
> @@ -4494,13 +4496,15 @@ iwm_power_mac_update_mode(struct iwm_sof
> int
> iwm_power_update_device(struct iwm_softc *sc)
> {
> - struct iwm_device_power_cmd cmd = {
> - .flags = htole16(IWM_DEVICE_POWER_FLAGS_POWER_SAVE_ENA_MSK),
> - };
> + struct iwm_device_power_cmd cmd = { };
> + struct ieee80211com *ic = &sc->sc_ic;
>
> if (!(sc->sc_capaflags & IWM_UCODE_TLV_FLAGS_DEVICE_PS_CMD))
> return 0;
>
> + if (ic->ic_opmode != IEEE80211_M_MONITOR)
> + cmd.flags = htole16(IWM_DEVICE_POWER_FLAGS_POWER_SAVE_ENA_MSK);
> +
> return iwm_send_cmd_pdu(sc,
> IWM_POWER_TABLE_CMD, 0, sizeof(cmd), &cmd);
> }
> @@ -4562,7 +4566,12 @@ iwm_add_sta_cmd(struct iwm_softc *sc, st
> add_sta_cmd.tfd_queue_msk |=
> htole32(1 << iwm_ac_to_tx_fifo[ac]);
> }
> - IEEE80211_ADDR_COPY(&add_sta_cmd.addr, in->in_ni.ni_bssid);
> + if (ic->ic_opmode == IEEE80211_M_MONITOR)
> + IEEE80211_ADDR_COPY(&add_sta_cmd.addr,
> + etherbroadcastaddr);
> + else
> + IEEE80211_ADDR_COPY(&add_sta_cmd.addr,
> + in->in_ni.ni_bssid);
> }
> add_sta_cmd.add_modify = update ? 1 : 0;
> add_sta_cmd.station_flags_msk
> @@ -5230,7 +5239,7 @@ iwm_ack_rates(struct iwm_softc *sc, stru
>
> void
> iwm_mac_ctxt_cmd_common(struct iwm_softc *sc, struct iwm_node *in,
> -struct iwm_mac_ctx_cmd *cmd, uint32_t action, int assoc)
> +struct iwm_mac_ctx_cmd *cmd, uint32_t action)
> {
> #define IWM_EXP2(x) ((1 << (x)) - 1)/* CWmin = 2^ECWmin - 1 */
> struct ieee80211com *ic = &sc->sc_ic;
> @@ -5242,12 +5251,21 @@ iwm_mac_ctxt_cmd_common(struct iwm_softc
> in->in_color));
> cmd->action = htole32(action);
>
> - cmd->mac_type = htole32(IWM_FW_MAC_TYPE_BSS_STA);
> + if (ic->ic_opmode == IEEE80211_M_MONITOR)
> + cmd->mac_type = htole32(IWM_FW_MAC_TYPE_LISTENER);
> + else if (ic->ic_opmode == IEEE80211_M_STA)
> + cmd->mac_type = htole32(IWM_FW_MAC_TYPE_BSS_STA);
> + else
> + panic("unsu
Re: Test needed: Unlock 12 network-related syscalls
On 20.06.2018 13:13, Martin Pieuchot wrote:
Diff below unlocks the following syscalls:
recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2),
accept4(2), connect(2), bind(2), setsockopt(2), listen(2),
getsockopt(2), shutdown(2)
It doesn't mean that they won't run without the KERNEL_LOCK(). Instead
a lock will be picked based on the socket type. For Unix/pfkey/routing
sockets it is still the KERNEL_LOCK(). That means the KERNEL_LOCK()
will be taken a bit later in the syscall. But for TCP/UDP sockets it
will grab the NET_LOCK() instead, just like in sendto(2) and
sendmsg(2).
Tests & oks welcome!
Hi Martin,
I run your diff on my HP ProBook 450 G3 for some days now without
problems. The only thing to mention is that your diff seems to be
incompatible with the DRI3 diff from Mark Kettenis[1]. When I apply both
diffs to the -current kernel the kernel panics during boot:
root on sda2a (f0b2020d2a12099d.a) swap on sd2b dump on sd2b
iwm0: hw rev 0x210, fw ver 16.242414.0, address 01:23:45:67:89:ab
panic: rw_enter: fdlock locking against myself
Stopped at db_enter+0x12: popq%r11
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*451237 29199 0 0x1 00K init
db_enter() at db_enter+0x12
panic() at panic+0x138
_rw_enter(5cb404b46de93a98, ff041ffb0898,0,3) at _rw_enter+0x338
fdrelease(dd362798c66e5c5b,3) at fdrelease+0xfe
sys_close(359bdf7160fe01fb) at syscall+0x32a
Xsyscall_untramp(6,0,0,0,0,6) at Xsyscall_untramp+0xe4
end of kernel
end trace frame 0x7f7db9a0, count: 8
[1] https://marc.info/?l=openbsd-tech&m=152954666910012&w=2
Cheers,
Bruno
Index: kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.182
diff -u -p -r1.182 syscalls.master
--- kern/syscalls.master20 Jun 2018 10:52:49 - 1.182
+++ kern/syscalls.master20 Jun 2018 11:04:05 -
@@ -88,18 +88,18 @@
#else
26 UNIMPL ptrace
#endif
-27 STD { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
+27 STD NOLOCK { ssize_t sys_recvmsg(int s, struct msghdr *msg, \
int flags); }
28 STD NOLOCK { ssize_t sys_sendmsg(int s, \
const struct msghdr *msg, int flags); }
-29 STD { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
+29 STD NOLOCK { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
int flags, struct sockaddr *from, \
socklen_t *fromlenaddr); }
-30 STD { int sys_accept(int s, struct sockaddr *name, \
+30 STD NOLOCK { int sys_accept(int s, struct sockaddr *name, \
socklen_t *anamelen); }
-31 STD { int sys_getpeername(int fdes, struct sockaddr *asa, \
+31 STD NOLOCK { int sys_getpeername(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
-32 STD { int sys_getsockname(int fdes, struct sockaddr *asa, \
+32 STD NOLOCK { int sys_getsockname(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
33 STD { int sys_access(const char *path, int amode); }
34 STD { int sys_chflags(const char *path, u_int flags); }
@@ -205,7 +205,7 @@
91 STD { int sys_nanosleep(const struct timespec *rqtp, \
struct timespec *rmtp); }
92 STD { int sys_fcntl(int fd, int cmd, ... void *arg); }
-93 STD { int sys_accept4(int s, struct sockaddr *name, \
+93 STD NOLOCK { int sys_accept4(int s, struct sockaddr *name, \
socklen_t *anamelen, int flags); }
94 STD { int sys___thrsleep(const volatile void *ident, \
clockid_t clock_id, const struct timespec *tp, \
@@ -213,18 +213,18 @@
95 STD { int sys_fsync(int fd); }
96 STD { int sys_setpriority(int which, id_t who, int prio); }
97 STD NOLOCK { int sys_socket(int domain, int type, int protocol); }
-98 STD { int sys_connect(int s, const struct sockaddr *name, \
+98 STD NOLOCK { int sys_connect(int s, const struct sockaddr *name, \
socklen_t namelen); }
99 STD { int sys_getdents(int fd, void *buf, size_t buflen); }
100STD { int sys_getpriority(int which, id_t who); }
101STD { int sys_pipe2(int *fdp, int flags); }
102STD { int sys_dup3(int from, int to, int flags); }
103STD { int sys_sigreturn(struct sigcontext *sigcntxp); }
-104STD { int sys_bind(int s, const struct sockaddr *name, \
+104STD NOLOCK { int sys_bind(int s, const struct sockaddr *name, \
socklen_t namelen); }
-
Re: Test needed: Unlock 12 network-related syscalls
On 26.06.18 11:47, Martin Pieuchot wrote: > On 26/06/18(Tue) 10:46, Bruno Flueckiger wrote: > > On 20.06.2018 13:13, Martin Pieuchot wrote: > > > Diff below unlocks the following syscalls: > > > > > > recvmsg(2), recvfrom(2), accept(2), getpeername(2), getsockname(2), > > > accept4(2), connect(2), bind(2), setsockopt(2), listen(2), > > > getsockopt(2), shutdown(2) > > > > > > It doesn't mean that they won't run without the KERNEL_LOCK(). Instead > > > a lock will be picked based on the socket type. For Unix/pfkey/routing > > > sockets it is still the KERNEL_LOCK(). That means the KERNEL_LOCK() > > > will be taken a bit later in the syscall. But for TCP/UDP sockets it > > > will grab the NET_LOCK() instead, just like in sendto(2) and sendmsg(2). > > > > > > Tests & oks welcome! > > > > Hi Martin, > > > > I run your diff on my HP ProBook 450 G3 for some days now without problems. > > The only thing to mention is that your diff seems to be incompatible with > > the DRI3 diff from Mark Kettenis[1]. When I apply both diffs to the -current > > kernel the kernel panics during boot: > > I guess the diffs didn't apply cleanly. You can now update your source > -current an apply my diff only, do "make syscalls" and run the resulting > kernel. > Thanks for the info. This works now as expected. My system is running with your patch.
[patch] Make escape character in cu(1) configurable
Hi,
Whenever I use cu(1) I miss the possibility to configure the escape
character. Both ssh(1) and telnet(1) provide the option -e to change the
escape character.
So I created the diffs below to implement it. I think it's time to share
it with you and ask for your feedback.
Cheers,
Bruno
Index: usr.bin/cu/command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- usr.bin/cu/command.c5 Oct 2015 23:15:31 - 1.15
+++ usr.bin/cu/command.c3 Aug 2017 08:54:38 -
@@ -219,9 +219,29 @@ start_record(void)
cu_warnx("%s", file);
}
+struct escape_help_text {
+ const char *cmd;
+ const char *text;
+};
+
+static struct escape_help_text esc_txt[] = {
+ {".", "drop connection and exit"},
+ {"#", "send break"},
+ {"$", "pipe local command to remote host"},
+ {">", "send file to remote host"},
+ {"C", "connect program to remote host"},
+ {"D", "de-assert DTR line briefly"},
+ {"R", "start recording to file"},
+ {"S", "set speed"},
+ {"X", "send file with XMODEM"},
+ {"?", "get this summary"},
+};
+
void
do_command(char c)
{
+ int i;
+
switch (c) {
case '.':
case '\004': /* ^D */
@@ -260,21 +280,15 @@ do_command(char c)
sleep(1);
ioctl(line_fd, TIOCCBRK, NULL);
break;
- case '~':
- bufferevent_write(line_ev, "~", 1);
- break;
case '?':
- printf("\r\n"
- "~# send break\r\n"
- "~$ pipe local command to remote host\r\n"
- "~> send file to remote host\r\n"
- "~C connect program to remote host\r\n"
- "~D de-assert DTR line briefly\r\n"
- "~R start recording to file\r\n"
- "~S set speed\r\n"
- "~X send file with XMODEM\r\n"
- "~? get this summary\r\n"
- );
+ for (i = 0; i < sizeof(esc_txt) / sizeof(esc_txt[0]); i++) {
+ if (escape < 32)
+ printf("\r\n^%c", escape + 64);
+ else
+ printf("\r\n%c", escape);
+ printf("%s\t%s", esc_txt[i].cmd, esc_txt[i].text);
+ }
+ printf("\r\n");
break;
}
}
Index: usr.bin/cu/cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- usr.bin/cu/cu.1 18 May 2015 09:35:05 - 1.15
+++ usr.bin/cu/cu.1 11 May 2017 11:56:15 -
@@ -36,6 +36,7 @@
.Sh SYNOPSIS
.Nm
.Op Fl d
+.Op Fl e Ar char
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +56,13 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl e Ar char
+Sets the
+.Nm
+escape character to
+.Pa char .
+If not specified the escape character is the tilde
+.Pq Ql ~ .
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -95,8 +103,8 @@ utility ignores other capabilities found
.Pp
Typed characters are normally transmitted directly to the remote
machine (which does the echoing as well).
-A tilde
-.Pq Ql ~
+The escape character (by default:
+.Ql ~ )
appearing as the first character of a line is an escape signal; the
following are recognized:
.Bl -tag -offset indent -width Fl
Index: usr.bin/cu/cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.24
diff -u -p -r1.24 cu.c
--- usr.bin/cu/cu.c 16 Oct 2015 07:01:53 - 1.24
+++ usr.bin/cu/cu.c 3 Aug 2017 08:54:54 -
@@ -41,6 +41,7 @@ FILE *record_file;
struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
+u_char escape = '~';
int is_direct = -1;
const char *line_path = NULL;
int line_speed = -1;
@@ -52,7 +53,7 @@ struct event sighup_ev;
enum {
STATE_NONE,
STATE_NEWLINE,
- STATE_TILDE
+ STATE_ESCAPE
} last_state = STATE_NEWLINE;
__dead voidusage(void);
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-d] [-e char] [-l line] [-s speed |
-speed]\n",
__progname);
fprintf(stderr, " %s [host]\n", __progname);
exit(1);
@@ -100,11 +101,21 @@ main(int argc, char **argv)
errx(1,
Re: patch for httpd implementing clickjacking protection
On 07.02., Peter J. Philipp wrote:
> On Tue, Feb 07, 2023 at 10:41:34AM +, Stuart Henderson wrote:
> > On 2023/02/07 10:20, Peter J. Philipp wrote:
> > > Hi,
> > >
> > > Arslan Kabeer (on the Internet) made me aware of clickjacking being done
> > > on
> > > my site using OpenBSD httpd. This following patch implements a RFC 7034
> > > protection called "noiframe" which disallows other sites (but not the same
> > > site) to add an iframe to my site.
> > >
> > > The config change is like this:
> > >
> > > ->
> > > location "/" {
> > > directory index index.html
> > > noiframe
> >
> > Using a specific keyword for every site protection header that
> > somebody might want seems a bit much. (There are other settings for
> > x-frame-options, other headers like content-security-policy and
> > x-content-type-options, and various deprecated ones).
> >
> > Wouldn't a general-purpose "set header X with the value Y" make
> > more sense?
>
> Yes this makes more sense. Ignore my patch then, it was whipped up this
> morning when I got the vulnerability report from Arslan. I'm unable to
> look deeper and general purposely into this, though, I have other TODO's.
>
> It seems a mystery to me however how to add this header into httpd based
> off the manual page if that is the hint. Perhaps the maintainer of this
> program now has an idea what we need and can schedule programming for it.
>
> Best Regards,
> -peter
>
Using relayd(8) in front of httpd(8) you can easily handle any HTTP header
the way you like: add or remove headers from both requests and responses.
Cheers,
Bruno
Re: once again: iwm(4) multi-frame rx + monitor mode
On 30.08., Stefan Sperling wrote: > I would like to try this again: In iwm(4), process more than one frame > per Rx interrupt, and enable monitor mode. > > Monitor mode triggers "unhandled fimware response" errors without multi-Rx > support. We have seen these infamous errors in other contexts as well. > It is possible that the firmware decides to use multi-Rx in such cases > which would of course confuse our driver. > > The fact is that Linux has not used single-Rx mode for years. One of their > developers told me that Intel has stopped testing it entirely. The current > code isn't future-proof and is likely to break with newer versions of > firmware and/or hardware. > > These changes were attempted and reverted twice already. > Last time because they were causing throughput issues (and I now see why). > I have rebased my old diff and tweaked it slightly to avoid an unneeded > mbuf copy and reworked all the offset/length calculations once again. > > Works fine here against several APs with no observable drop in throughput. > > Please test this on as many iwm devices as possible. Thanks! > Your diff is working on my Intel Dual Band Wireless AC 3165 for three days now. I haven't encounter any problems so far. Please tell me if you need specific tests or more information about my setup. Cheers, Bruno
