diff options
| author | David Sommerseth <dazo@users.sourceforge.net> | 2010-02-19 17:32:56 +0100 |
|---|---|---|
| committer | David Sommerseth <dazo@users.sourceforge.net> | 2010-04-29 20:22:07 +0200 |
| commit | 4b19afc33765fd0fb338765324e904ab978f9ad3 (patch) | |
| tree | 64ffaa39088f92bf8c184620073bf575a843efe6 | |
| parent | [PATCH] Change verify-cn so cn is no longer hardcoded in openvpn's config file (diff) | |
| download | openvpn-4b19afc33765fd0fb338765324e904ab978f9ad3.tar.xz | |
verb 5 logging wrongly reports received bytes
With --verb 5, openvpn logs a single letter (rwRW) for each package
received or sent. I recently ran into a problem with the tun device on
Linux where the read from that device returned 0. Unfortunately this was
also logged as "r", which made me assume that openvpn had received
something, while it actually hadn't.
(See https://dev.openwrt.org/ticket/6650 for the bug that made me find out
about this problem with openvpn.)
I'm attaching a patch which prevents openvpn from logging "r" or "R" when
it didn't actually read anything. This is against openvpn 2.1-rc20, but
probably still applies to the most recent version.
This patch was received anonymously via the sf.net bug tracker:
<http://sourceforge.net/tracker/?func=detail&atid=454719&aid=2951003&group_id=48978>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: David Sommerseth <dazo@users.sourceforge.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
| -rw-r--r-- | forward.c | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -755,7 +755,7 @@ process_incoming_link (struct context *c) /* log incoming packet */ #ifdef LOG_RW - if (c->c2.log_rw) + if (c->c2.log_rw && c->c2.buf.len > 0) fprintf (stderr, "R"); #endif msg (D_LINK_RW, "%s READ [%d] from %s: %s", @@ -965,7 +965,7 @@ process_incoming_tun (struct context *c) c->c2.tun_read_bytes += c->c2.buf.len; #ifdef LOG_RW - if (c->c2.log_rw) + if (c->c2.log_rw && c->c2.buf.len > 0) fprintf (stderr, "r"); #endif |