pfsync in rdomain

2013-11-14 Thread Erik Lax 
This patch seems to fix running pfsync in rdomains.

--- sys/net/if_pfsync.c.origThu Nov 14 15:58:00 2013
+++ sys/net/if_pfsync.c Thu Nov 14 16:51:30 2013
@@ -1682,6 +1682,8 @@
sc-sc_if.if_opackets++;
sc-sc_if.if_obytes += m-m_pkthdr.len;
 
+   m-m_pkthdr.rdomain = sc-sc_if.if_rdomain;
+
if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, sc-sc_imo, NULL) == 0)
pfsyncstats.pfsyncs_opackets++;
else

setpassent(1) not working

2013-11-14 Thread Erik Lax 
Hi,

I noticed that setpassent(1) probably doesn't work as intended, as this
program should open the spwd.db file once, not four times?

int main() {
setpassent(1);
getpwnam(root); getpwnam(root); getpwuid(0); getpwuid(0);
return 0;
}

It seems to be due to faulty logic in libc/gen/getpwent.c. In short

...
savedb = _pw_db;
if (!_pw_db  !__initdb())
...
_pw_db begin as NULL
so savedb is set to NULL
_pw_db is NULL and __initdb() is run, _pw_db is set
...
if (savedb != _pw_db || !_pw_stayopen) {
...
savedb is still NULL, _pwd_db is not, so the first condition is true
_pw_db get closed, and set to NULL

This following patch fixes this.

--- lib/libc/gen/getpwent.c.origThu Nov 14 21:06:13 2013
+++ lib/libc/gen/getpwent.c Thu Nov 14 21:18:45 2013
@@ -708,10 +708,8 @@
 {
struct passwd *pwret = NULL;
int flags = 0, *flagsp;
-   DB *savedb;

_THREAD_PRIVATE_MUTEX_LOCK(pw);
-   savedb = _pw_db;
if (!_pw_db  !__initdb())
goto fail;

@@ -728,7 +726,7 @@
if (!pwret)
pwret = _pwhashbyname(name, buf, buflen, pw, flagsp);

-   if (savedb != _pw_db || !_pw_stayopen) {
+   if (!_pw_stayopen) {
(void)(_pw_db-close)(_pw_db);
_pw_db = NULL;
}
@@ -755,10 +753,8 @@
 {
struct passwd *pwret = NULL;
int flags = 0, *flagsp;
-   DB *savedb;

_THREAD_PRIVATE_MUTEX_LOCK(pw);
-   savedb = _pw_db;
if (!_pw_db  !__initdb())
goto fail;

@@ -775,7 +771,7 @@
if (!pwret)
pwret = _pwhashbyuid(uid, buf, buflen, pw, flagsp);

-   if (savedb != _pw_db || !_pw_stayopen) {
+   if (!_pw_stayopen) {
(void)(_pw_db-close)(_pw_db);
_pw_db = NULL;
}

relayd: crash with two listen on (one is ssl)

2013-11-19 Thread Erik Lax 
Hi,

In relayd, if a relay is configured with two listen on directives, one
with ssl and one without. In the relay_inherit function the ssl pointers
(cert and key) are copied to the latter, and used/freed even if F_SSL is
not set. This causes a double free later in purge_relay.

relay http {
listen on 127.0.0.1 port 4433 ssl
listen on 127.0.0.1 port 8080
forward with ssl to 127.0.0.1 port 443
}

There following patch fixes this.

--- usr.sbin/relayd/parse.y.origTue Nov 19 22:10:48 2013
+++ usr.sbin/relayd/parse.y Tue Nov 19 22:09:41 2013
@@ -2809,6 +2809,12 @@
rb-rl_conf.port = rc.port;
rb-rl_conf.flags =
(ra-rl_conf.flags  ~F_SSL) | (rc.flags  F_SSL);
+   if (!(rb-rl_conf.flags  F_SSL)) {
+   rb-rl_ssl_cert = NULL;
+   rb-rl_conf.ssl_cert_len = 0;
+   rb-rl_ssl_key = NULL;
+   rb-rl_conf.ssl_key_len = 0;
+   }
TAILQ_INIT(rb-rl_tables);

rb-rl_conf.id = ++last_relay_id;

libpthread fork and malloc

2011-12-12 Thread Erik Lax 

Hi,

I recently encountered a similar bug like this one 
http://www.freebsd.org/cgi/query-pr.cgi?pr=76690 in openbsds pthread 
library. It seems that if the malloc lock is not obtained before the 
fork bad things may happen on following free's in the forked child. This 
is my take at fixing this bug.


Regards
Erik

Index: lib/libpthread/uthread/uthread_fork.c
===
RCS file: /cvs/src/lib/libpthread/uthread/uthread_fork.c,v
retrieving revision 1.22
diff -u -r1.22 uthread_fork.c
--- lib/libpthread/uthread/uthread_fork.c12 Jul 2010 03:52:52 - 
   1.22

+++ lib/libpthread/uthread/uthread_fork.c12 Dec 2011 07:58:17 -
@@ -95,8 +95,16 @@
 pid_t   ret;
 pthread_tpthread;

+/* Obtain the malloc lock before processing or else we may be in a
+ * inconsistent state when using malloc/free later on in the child.
+ */
+_thread_malloc_lock();
+
 /* Fork a new process and reset child's state */
 if ((ret = (vfork ? _thread_sys_vfork() : _thread_sys_fork())) == 0) {
+/* Release lock so we can do things again */
+_thread_malloc_unlock();
+
 /* Close the pthread kernel pipe: */
 _thread_sys_close(_thread_kern_pipe[0]);
 _thread_sys_close(_thread_kern_pipe[1]);
@@ -231,6 +239,9 @@
 }
 }
 }
+
+/* Release lock so we can do things again */
+_thread_malloc_unlock();

 /* Return the process ID: */
 return (ret);

tcpbench: setpgid

2012-01-31 Thread Erik Lax 

Hi,

I noticed that tcpbench tries to setpgid() for no obvious reason (to me) 
since it's not forked anymore. Previously, 2 years ago it was fork()ed 
and utilized killpg() etc. Could this be a leftover? I'm running into 
issues spawning tcpbench since my parent process uses setsid().


I attached a patch (against 5.0) to remove the code :)

Regards
Erik Lax

Index: usr.bin/tcpbench/tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.22
diff -u -r1.22 tcpbench.c
--- usr.bin/tcpbench/tcpbench.c 21 Jun 2011 17:31:07 -  1.22
+++ usr.bin/tcpbench/tcpbench.c 31 Jan 2012 10:27:50 -
@@ -703,9 +703,6 @@
struct event *ev;
nfds_t lnfds;

-   if (setpgid(0, 0) == -1)
-   err(1, setpgid);
-
lnfds = 0;
for (ai = aitop; ai != NULL; ai = ai-ai_next) {
saddr_ntop(ai-ai_addr, ai-ai_addrlen, tmp, sizeof(tmp));

relayd: statistics are broken

2012-03-07 Thread Erik Lax 

Hi,

There is a bug in relayd's handling of statistics collected from each 
prefork (0,1,2,3,4,..). Once received over IMSG, statistics should be 
saved in a rl_stats[RELAY_MAXPROC + 1] array per relay (rlay-rl_stats). 
However all ends up in rlay-rl_stats[0] overwriting other children's 
statistics in a holy mess.


So, fixing this bug, and you should start to see up to five times more 
statistics than before. :)


This is due to the unset variable proc_id which is used as if it were 
incremented for each forked child. This proc_id should be the same as 
p-p_instance and env-sc_ps-ps_instance. So I have two suggested fixes.


1. Use the big patch below, it removes the proc_id variable and imho. 
cleans up the current struct relayd* env confusion.
2. Use the small quick-fix patch below, it sets up proc_id properly. 
However env is NULL dereferenced for sc_timeout in relay_udp.c, thus 
crashing in a simple dns forward test. If the big patch is applied, 
env is always set in relay.c and relay_udp.c, so we should let this 
patch decide if another bug report is needed.


Regards
Erik

Two patched attached below.

-- cut --
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c21 Jan 2012 13:40:48 -1.144
+++ relay.c7 Mar 2012 10:24:57 -
@@ -332,6 +332,9 @@

 if (config_init(ps-ps_env) == -1)
 fatal(failed to initialize configuration);
+
+/* Set to current prefork id */
+proc_id = p-p_instance;

 /* We use a custom shutdown callback */
 p-p_shutdown = relay_shutdown;
-- cut --
Index: pfe.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe.c,v
retrieving revision 1.72
diff -u -r1.72 pfe.c
--- pfe.c21 Jan 2012 13:40:48 -1.72
+++ pfe.c7 Mar 2012 00:30:19 -
@@ -46,7 +46,7 @@
 int pfe_dispatch_hce(int, struct privsep_proc *, struct imsg *);
 int pfe_dispatch_relay(int, struct privsep_proc *, struct imsg *);

-static struct relayd*env = NULL;
+struct relayd *env = NULL;

 static struct privsep_proc procs[] = {
 { parent,PROC_PARENT,pfe_dispatch_parent },
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c21 Jan 2012 13:40:48 -1.144
+++ relay.c7 Mar 2012 00:30:20 -
@@ -135,8 +135,7 @@
 volatile sig_atomic_t relay_sessions;
 objid_t relay_conid;

-static struct relayd*env = NULL;
-int proc_id;
+extern struct relayd *env;

 static struct privsep_proc procs[] = {
 { parent,PROC_PARENT,relay_dispatch_parent },
@@ -305,7 +304,7 @@

 switch (rlay-rl_proto-type) {
 case RELAY_PROTO_DNS:
-relay_udp_privinit(env, rlay);
+relay_udp_privinit(rlay);
 break;
 case RELAY_PROTO_TCP:
 case RELAY_PROTO_HTTP:
@@ -367,7 +366,7 @@
 bzero(crs, sizeof(crs));
 resethour = resetday = 0;

-cur = rlay-rl_stats[proc_id];
+cur = rlay-rl_stats[env-sc_ps-ps_instance];
 cur-cnt += cur-last;
 cur-tick++;
 cur-avg = (cur-last + cur-avg) / 2;
@@ -390,7 +389,7 @@
 cur-last_day = 0;

 crs.id = rlay-rl_conf.id;
-crs.proc = proc_id;
+crs.proc = env-sc_ps-ps_instance;
 proc_compose_imsg(env-sc_ps, PROC_PFE, -1, IMSG_STATISTICS, -1,
crs, sizeof(crs));

@@ -2009,7 +2008,7 @@
 SPLAY_INSERT(session_tree, rlay-rl_sessions, con);

 /* Increment the per-relay session counter */
-rlay-rl_stats[proc_id].last++;
+rlay-rl_stats[env-sc_ps-ps_instance].last++;

 /* Pre-allocate output buffer */
 con-se_out.output = evbuffer_new();
@@ -2050,7 +2049,7 @@
 bzero(cnl, sizeof(*cnl));
 cnl-in = -1;
 cnl-id = con-se_id;
-cnl-proc = proc_id;
+cnl-proc = env-sc_ps-ps_instance;
 cnl-proto = IPPROTO_TCP;

 bcopy(con-se_in.ss, cnl-src, sizeof(cnl-src));
@@ -2236,7 +2235,7 @@

 bzero(bnd, sizeof(bnd));
 bnd.bnd_id = con-se_id;
-bnd.bnd_proc = proc_id;
+bnd.bnd_proc = env-sc_ps-ps_instance;
 bnd.bnd_port = port;
 bnd.bnd_proto = proto;
 bcopy(con-se_in.ss, bnd.bnd_ss, sizeof(bnd.bnd_ss));
@@ -2486,7 +2485,7 @@
 fatalx(relay_dispatch_pfe: invalid table id);

 DPRINTF(%s: [%d] state %d for 
-host %u %s, __func__, proc_id, st.up,
+host %u %s, __func__, env-sc_ps-ps_instance, st.up,
 host-conf.id, host-conf.name);

 if ((st.up == HOST_UNKNOWN  host-up == HOST_DOWN) ||
Index: relay_udp.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_udp.c,v
retrieving revision 1.24
diff -u -r1.24 relay_udp.c
--- relay_udp.c9 May 2011 12:08:47 -1.24

Re: relayd: statistics are broken [resend patches]

2012-03-09 Thread Erik Lax 
On 3/7/12 11:53 AM, Erik Lax wrote:

 ...

 Two patches attached below.

Sorry for the noise, apparently the patches got broken in transit,
blaming the MUA.

-- cut --
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c 21 Jan 2012 13:40:48 -  1.144
+++ relay.c 7 Mar 2012 10:24:57 -
@@ -332,6 +332,9 @@

if (config_init(ps-ps_env) == -1)
fatal(failed to initialize configuration);
+   
+   /* Set to current prefork id */
+   proc_id = p-p_instance;

/* We use a custom shutdown callback */
p-p_shutdown = relay_shutdown;
-- cut --

...or...

-- cut --
Index: pfe.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe.c,v
retrieving revision 1.72
diff -u -r1.72 pfe.c
--- pfe.c   21 Jan 2012 13:40:48 -  1.72
+++ pfe.c   7 Mar 2012 00:30:19 -
@@ -46,7 +46,7 @@
 int pfe_dispatch_hce(int, struct privsep_proc *, struct imsg *);
 int pfe_dispatch_relay(int, struct privsep_proc *, struct imsg *);

-static struct relayd   *env = NULL;
+struct relayd *env = NULL;

 static struct privsep_proc procs[] = {
{ parent, PROC_PARENT,pfe_dispatch_parent },
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c 21 Jan 2012 13:40:48 -  1.144
+++ relay.c 7 Mar 2012 00:30:20 -
@@ -135,8 +135,7 @@
 volatile sig_atomic_t relay_sessions;
 objid_t relay_conid;

-static struct relayd   *env = NULL;
-int proc_id;
+extern struct relayd *env;

 static struct privsep_proc procs[] = {
{ parent, PROC_PARENT,relay_dispatch_parent },
@@ -305,7 +304,7 @@

switch (rlay-rl_proto-type) {
case RELAY_PROTO_DNS:
-   relay_udp_privinit(env, rlay);
+   relay_udp_privinit(rlay);
break;
case RELAY_PROTO_TCP:
case RELAY_PROTO_HTTP:
@@ -367,7 +366,7 @@
bzero(crs, sizeof(crs));
resethour = resetday = 0;

-   cur = rlay-rl_stats[proc_id];
+   cur = rlay-rl_stats[env-sc_ps-ps_instance];
cur-cnt += cur-last;
cur-tick++;
cur-avg = (cur-last + cur-avg) / 2;
@@ -390,7 +389,7 @@
cur-last_day = 0;

crs.id = rlay-rl_conf.id;
-   crs.proc = proc_id;
+   crs.proc = env-sc_ps-ps_instance;
proc_compose_imsg(env-sc_ps, PROC_PFE, -1, IMSG_STATISTICS, -1,
crs, sizeof(crs));

@@ -2009,7 +2008,7 @@
SPLAY_INSERT(session_tree, rlay-rl_sessions, con);

/* Increment the per-relay session counter */
-   rlay-rl_stats[proc_id].last++;
+   rlay-rl_stats[env-sc_ps-ps_instance].last++;

/* Pre-allocate output buffer */
con-se_out.output = evbuffer_new();
@@ -2050,7 +2049,7 @@
bzero(cnl, sizeof(*cnl));
cnl-in = -1;
cnl-id = con-se_id;
-   cnl-proc = proc_id;
+   cnl-proc = env-sc_ps-ps_instance;
cnl-proto = IPPROTO_TCP;

bcopy(con-se_in.ss, cnl-src, sizeof(cnl-src));
@@ -2236,7 +2235,7 @@

bzero(bnd, sizeof(bnd));
bnd.bnd_id = con-se_id;
-   bnd.bnd_proc = proc_id;
+   bnd.bnd_proc = env-sc_ps-ps_instance;
bnd.bnd_port = port;
bnd.bnd_proto = proto;
bcopy(con-se_in.ss, bnd.bnd_ss, sizeof(bnd.bnd_ss));
@@ -2486,7 +2485,7 @@
fatalx(relay_dispatch_pfe: invalid table id);

DPRINTF(%s: [%d] state %d for 
-   host %u %s, __func__, proc_id, st.up,
+   host %u %s, __func__, env-sc_ps-ps_instance, st.up,
host-conf.id, host-conf.name);

if ((st.up == HOST_UNKNOWN  host-up == HOST_DOWN) ||
Index: relay_udp.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay_udp.c,v
retrieving revision 1.24
diff -u -r1.24 relay_udp.c
--- relay_udp.c 9 May 2011 12:08:47 -   1.24
+++ relay_udp.c 7 Mar 2012 00:30:20 -
@@ -49,10 +49,9 @@

 extern volatile sig_atomic_t relay_sessions;
 extern objid_t relay_conid;
-extern int proc_id;
 extern int debug;

-struct relayd *env = NULL;
+extern struct relayd *env;
 struct shuffle relay_shuffle;

 int relay_udp_socket(struct sockaddr_storage *, in_port_t,
@@ -70,11 +69,8 @@
 int relay_dns_cmp(struct rsession *, struct rsession *);

 void
-relay_udp_privinit(struct relayd *x_env, struct relay *rlay)
+relay_udp_privinit(struct relay *rlay)
 {
-   if (env == NULL)
-   env = x_env

tcpbench: crash with -n and -b

2012-05-04 Thread Erik Lax 
Hi,

I noticed that tcpbench sometimes crashes when using -n and -b combined,
this is because of a double-free in the client initialization loop.

See patch below 

Erik

Index: usr.bin/tcpbench/tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.34
diff -u -r1.34 tcpbench.c
--- usr.bin/tcpbench/tcpbench.c 13 Apr 2012 19:23:32 -  1.34
+++ usr.bin/tcpbench/tcpbench.c 4 May 2012 21:29:55 -
@@ -879,7 +879,6 @@
if (bind(sock, (struct sockaddr *)aib-ai_addr,
aib-ai_addrlen) == -1)
err(1, bind);
-   freeaddrinfo(aib);
}
if (ptb-Tflag != -1  ai-ai_family == AF_INET) {
if (setsockopt(sock, IPPROTO_IP, IP_TOS,
@@ -938,6 +937,8 @@
set_slice_timer(mainstats.nconns  0);
}
freeaddrinfo(aitop);
+   if (aib != NULL)
+   freeaddrinfo(aib);
 
if (ptb-vflag  nconn  1)
fprintf(stderr, %d connections established\n,

[patch] em: interrupt starvation

2012-05-10 Thread Erik Lax 
Hi,

I came across a real-world scenario where network traffic stopped due to
interrupt starvation with the em driver, tested with a few different
cards (on a network/interface where no packets were received). This is
what caused it. I had two computers with a cable directly connected on a
small network (192.168.1.1-2/24).

I cut the cable, and filled the send queue with broadcast traffic on
both ends (eg. ping -f 192.168.1.255) after a second I started to
get an error sendto: No buffer space available which is fine. However
when I attach the cable this queue is not processed (em_start) on
neither side.

So both units have their send queues filled, and no interrupts are
generated (from either TX or RX), consequently traffic stops. In order
to resolve this, I have to either disconnect and reconnect the cable
once more, or bring the interface up/down to generate a interrupt.

I fixed this problem by adding a em_start() call in em_intr() after the
link status has changed. Maybe the em_start() a few lines up could be
moved below the em_update_link_status(), however this fix was more
non-intrusive and worked for me. Ideas?

Erik

--- if_em.c.orig2012-02-15 05:06:27.0 +0100
+++ if_em.c 2012-05-10 14:26:02.0 +0200
@@ -889,6 +889,8 @@
sc-hw.get_link_status = 1;
em_check_for_link(sc-hw);
em_update_link_status(sc);
+   if (!IFQ_IS_EMPTY(ifp-if_snd))
+   em_start(ifp);
timeout_add_sec(sc-timer_handle, 1);
}

Re: [patch] em: interrupt starvation

2012-05-10 Thread Erik Lax 
On 5/10/12 3:41 PM, Mike Belopuhov wrote:
 That's a great find.  In fact, you're right, em_start() a few lines up
 should be done after em_update_link_status because of the link_active.
 The following diff makes it work the same way ix(4) does.  Please verify
 that it fixes the problem.

Thanks,

I run my testcase with your patch on two different em cards (82573L,
82583V) successfully.

Erik

relayd: statistics are broken [patches]

2012-07-10 Thread Erik Lax 
Hi,

There is a bug in relayd's handling of statistics collected from each
prefork (0,1,2,3,4,..). Once received over IMSG, statistics should be
saved in a rl_stats[RELAY_MAXPROC + 1] array per relay (rlay-rl_stats).

However all ends up in rlay-rl_stats[0] overwriting other children's
statistics in a holy mess. So, fixing this bug, and you should start to
see up to five times more statistics than before.

I have been running the large patch (which removes proc_id) in
production for a few months on multiple installations, and it all seems
fine.

Test case:

# cat relayd.conf
table local { 127.0.0.1 }
relay test {
listen on 0.0.0.0 port 
forward to local port 22 check tcp
}
# relayd -f relayd.conf
# for i in `echo 1 2 3 4 5 6 7 8 9 0`; do nc 127.0.0.1  
/dev/null  done; sleep 3; pkill -9 nc

(wait a minute for statistics to be summarized)

# relayctl show relays
Id  TypeNameAvlblty Status
1   relay   testactive
total: 7 sessions
last: 0/60s 7/h 7/d sessions
average: 1/60s 0/h 0/d sessions

7 sessions hit the first relay fork. We should expect 10 sessions.

This is due to the unset variable proc_id which is used as if it were
incremented for each forked child. This proc_id should be the same as
p-p_instance and env-sc_ps-ps_instance. So I have two suggested fixes.

1. Use the big patch below, it removes the proc_id variable and imho.
cleans up the current struct relayd* env confusion.

2. Use the small quick-fix patch below, it sets up proc_id properly.
However env is NULL dereferenced for sc_timeout in relay_udp.c, thus
crashing in a simple dns forward test. If the big patch is applied,
env is always set in relay.c and relay_udp.c, so we should let this
patch decide if another bug report is needed.

 (reported by Tom Knienieder: relayd UDP bug and patch ...)

Regards
Erik

Two patched attached below.

-- cut --
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c 21 Jan 2012 13:40:48 -  1.144
+++ relay.c 7 Mar 2012 10:24:57 -
@@ -332,6 +332,9 @@

if (config_init(ps-ps_env) == -1)
fatal(failed to initialize configuration);
+   
+   /* Set to current prefork id */
+   proc_id = p-p_instance;

/* We use a custom shutdown callback */
p-p_shutdown = relay_shutdown;
-- cut --

...or... (the large patch)

-- cut --
Index: pfe.c
===
RCS file: /cvs/src/usr.sbin/relayd/pfe.c,v
retrieving revision 1.72
diff -u -r1.72 pfe.c
--- pfe.c   21 Jan 2012 13:40:48 -  1.72
+++ pfe.c   7 Mar 2012 00:30:19 -
@@ -46,7 +46,7 @@
 int pfe_dispatch_hce(int, struct privsep_proc *, struct imsg *);
 int pfe_dispatch_relay(int, struct privsep_proc *, struct imsg *);

-static struct relayd   *env = NULL;
+struct relayd *env = NULL;

 static struct privsep_proc procs[] = {
{ parent, PROC_PARENT,pfe_dispatch_parent },
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.144
diff -u -r1.144 relay.c
--- relay.c 21 Jan 2012 13:40:48 -  1.144
+++ relay.c 7 Mar 2012 00:30:20 -
@@ -135,8 +135,7 @@
 volatile sig_atomic_t relay_sessions;
 objid_t relay_conid;

-static struct relayd   *env = NULL;
-int proc_id;
+extern struct relayd *env;

 static struct privsep_proc procs[] = {
{ parent, PROC_PARENT,relay_dispatch_parent },
@@ -305,7 +304,7 @@

switch (rlay-rl_proto-type) {
case RELAY_PROTO_DNS:
-   relay_udp_privinit(env, rlay);
+   relay_udp_privinit(rlay);
break;
case RELAY_PROTO_TCP:
case RELAY_PROTO_HTTP:
@@ -367,7 +366,7 @@
bzero(crs, sizeof(crs));
resethour = resetday = 0;

-   cur = rlay-rl_stats[proc_id];
+   cur = rlay-rl_stats[env-sc_ps-ps_instance];
cur-cnt += cur-last;
cur-tick++;
cur-avg = (cur-last + cur-avg) / 2;
@@ -390,7 +389,7 @@
cur-last_day = 0;

crs.id = rlay-rl_conf.id;
-   crs.proc = proc_id;
+   crs.proc = env-sc_ps-ps_instance;
proc_compose_imsg(env-sc_ps, PROC_PFE, -1, IMSG_STATISTICS, -1,
crs, sizeof(crs));

@@ -2009,7 +2008,7 @@
SPLAY_INSERT(session_tree, rlay-rl_sessions, con);

/* Increment the per-relay session counter */
-   rlay-rl_stats[proc_id].last++;
+   rlay-rl_stats[env-sc_ps-ps_instance].last++;

/* Pre-allocate output buffer */

httpd with fcgi send garbage after non-chunked response

2015-01-12 Thread Erik Lax 
Hi,

In the case where httpds fcgi module handles the end marker, it should
abort if fcgi_chunked is not true. Now it sends 8 bytes of garbage after
each request (it's often NUL terminated so it doesn't seem to show up in
browsers). This patched fixed it for me.

Index: usr.sbin/httpd/server_fcgi.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
retrieving revision 1.44
diff -u -p -u -4 -r1.44 server_fcgi.c
--- usr.sbin/httpd/server_fcgi.c4 Jan 2015 22:23:58 -   1.44
+++ usr.sbin/httpd/server_fcgi.c12 Jan 2015 14:42:27 -
@@ -674,9 +674,9 @@ server_fcgi_writechunk(struct client *cl
} else
len = EVBUFFER_LENGTH(evb);
 
/* If len is 0, make sure to write the end marker only once */
-   if (len == 0  clt-clt_fcgi_end++)
+   if (len == 0  (!clt-clt_fcgi_chunked || clt-clt_fcgi_end++))
return (0);
 
if (clt-clt_fcgi_chunked) {
if (server_bufferevent_printf(clt, %zx\r\n, len) == -1 ||

if_pfsync error counter

2015-06-22 Thread Erik Lax 
Hi,

I noticed by looking at the code that in sys/net/if_pfsync.c :
pfsync_sendout() a failed ip_output() does not increment
sc-sc_if.if_oerrors++ only pfsyncstats.pfsyncs_oerrors++. Similar
pattern do in eg. if_pflow.c. Should it?

Proxy ARP and npppd (tun)

2016-12-09 Thread Erik Lax 
Hi,

In previous OpenBSD versions (5.9 and eariler) it was possible to do
proxy-arp with the npppd server if the proxy-arp was setup before the
npppd connection was made. As of 6.0 (and todays snapshots) proxy arp
and npppd (tun interfaces) seems to be broken.

The behavior is now as such;

- if an proxy arp entry exists (on a given interface), then incoming
packets will be sent out again on the same interface (instead of
forwarded to the tun interface)

Setup.

1. Adding the proxy-arp entry 10.2.50.123 (the npppd/tun0 client ip)

arp -s 10.2.50.123 00:50:51:b2:e4:c1 permanent pub

2. Connect the client, send ping to host on em0, incoming icmp replys
are sent out on em0 again instead of tun0

A quirk?

If the arp entry is deleted (arp -d 10.2.50.124) on the openbsd host, it
starts to work temporarily (the packet is forwarded to the tun
interface) but only because the remote host has an arp cache.

Is there an other way of doing this?

Regards
Erik