openvpn-devel — OpenVPN developers list

[Openvpn-devel] Re: New beta available + progress update

[James Y. <ji...@yo...>]

Matthias Andree <mat...@gm...> said:

> > What the FRAGMENT_ENABLE code does is to add an extra 4 byte header to each
> > datagram that includes, among other things, feedback on the number of
> > datagrams received as well as the maximum datagram size received.  This
> > information can then be used by an OpenVPN peer to dynamically set the MTU
> > size as well as the datagram transmit rate independently of the OS and the
> > proper functioning of path MTU discovery.  Ultimately this code can make
> > OpenVPN more robust in situations where fragmentation is necessary (such as in
> > TAP-based bridged ethernets) when firewalls or routers in the path break PMTU
> > discovery.
> 
> How about compatibility? Does this need a FRAGMENT_ENABLEd OpenVPN on
> either side of the tunnel or will OpenVPN negotiate the fragment
> capability dynamically as well?

Negotiation of the fragment capability is similar to how other parameters are
negotiated, such as cipher algorithm, lzo compression, etc.  The option
(--mtu-dynamic) must be used on both ends of the connection.  In SSL mode,
both peers will complain if --mtu-dynamic is used on one end but not the
other.  In non-SSL mode, there is no negotiation, so each peer assumes that
the other is using compatible options.

> Does this FRAGMENT_ENABLE rely on SSL or
> will it work with preshared keys?

No, it doesn't rely on SSL or pre-shared keys.  It can work even on plaintext
tunnels.

I think the major issue still to be worked out is how to make it efficient. 
While I've written a simple heuristic (see fragment_adjust_mtu_bandwidth() in
fragment.c) that is a starting point for determining MTU and transmit throttle
levels based on feedback from the peer, I'm finding a big performance dropoff
once the fragmenting code kicks in.  A big reason for this is packet loss,
that can be seen if you run ftp over the tunnel.  When there is a one-to-one
correspondence between TUN/TAP packets and UDP datagrams (as there is in
non-FRAGMENT_ENABLE openvpn), then the TCP level does the heavy lifting in
terms of pushing packets at the optimal rate to avoid packet loss.  Once
openvpn starts doing its own fragmenting, then it also needs to take explicit
control over the transmit rate (as it can now do statically with --shaper).

A better alternative (orginally suggested by you) is to avoid fragmenting in
the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the TUN
device.  This won't work on TAP devices because the ethernet MTU is fixed at 1500.

Unfortunately (or fortunately depending on your perspective), my network
connections are not broken enough to benefit from the FRAGMENT_ENABLE stuff
just yet, so I can't really test it properly.

James

[Openvpn-devel] Re: New beta available + progress update

[Matthias A. <ma+...@dt...>]

> http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS)

I have a next round of patches to fix prototypes and types to quench
compiler warnings and get a more robust source code against changed
environments, to aid possible later debugging; it also includes GCC
extensions (only used when GCC is being used) that allow stricter msg()
and buf_printf() format string vs. argument checking, to avoid printing
bogus data when type sizes differ (think 64 bit).

One problem remains after applying the patch:
openvpn.c: In function `openvpn':
openvpn.c:470: warning: cast discards qualifiers from pointer target type

Other than that, we have unused parameter warnings (you said before
you're not fixing them), shadow parameter warnings (variable names being
the same as system functions, such as time or nice) and in particular,
aggregate (struct) values in function calls and function returns, these
are inefficient (as the compiler must toss the whole struct on the
stack, which involves copy overhead), and some of them (buffer.c in
particular) look pretty suspicious. Is there any C standard that
guarantees that returning an auto struct works and copies the return
value?

Index: buffer.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/buffer.c,v
retrieving revision 1.12
diff -u -r1.12 buffer.c
--- buffer.c	16 Mar 2003 08:34:12 -0000	1.12
+++ buffer.c	17 Apr 2003 10:51:16 -0000
@@ -111,7 +111,7 @@
  * printf append to a buffer with overflow check
  */
 void
-buf_printf (struct buffer *buf, char *format, ...)
+buf_printf (struct buffer *buf, const char *format, ...)
 {
   va_list arglist;
 
@@ -223,7 +223,7 @@
 
 char *
 format_hex_ex (const uint8_t *data, int size, int maxoutput,
-	       int space_break, char* separator)
+	       int space_break, const char* separator)
 {
   struct buffer out = alloc_buf_gc (maxoutput ? maxoutput :
 				    ((size * 2) + (size / space_break) + 2));
Index: buffer.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/buffer.h,v
retrieving revision 1.11
diff -u -r1.11 buffer.h
--- buffer.h	17 Apr 2003 07:12:04 -0000	1.11
+++ buffer.h	17 Apr 2003 10:51:16 -0000
@@ -47,7 +47,7 @@
 struct buffer alloc_buf (size_t size);
 struct buffer clone_buf (const struct buffer* buf);
 struct buffer alloc_buf_gc (size_t size);	/* allocate buffer with garbage collection */
-struct buffer clear_buf ();
+struct buffer clear_buf (void);
 void free_buf (struct buffer *buf);
 
 static inline bool
@@ -93,7 +93,7 @@
 
 /* Like strncpy but makes sure dest is always null terminated */
 static inline void
-strncpynt (char *dest, const char *src, int maxlen)
+strncpynt (char *dest, const char *src, size_t maxlen)
 {
   strncpy (dest, src, maxlen);
   if (maxlen > 0)
@@ -116,7 +116,11 @@
 /*
  * printf append to a buffer with overflow check
  */
-void buf_printf (struct buffer *buf, char *format, ...);
+void buf_printf (struct buffer *buf, const char *format, ...)
+#ifdef __GNUC__
+    __attribute__ ((format (printf, 2, 3)))
+#endif
+    ;
 
 /*
  * remove trailing newline
@@ -149,7 +153,7 @@
  */
 char *
 format_hex_ex (const uint8_t *data, int size, int maxoutput,
-	       int space_break, char* separator);
+	       int space_break, const char* separator);
 
 static inline char *
 format_hex (const uint8_t *data, int size, int maxoutput)
@@ -353,7 +357,7 @@
 void x_gc_free (void *p);
 
 static inline int
-gc_new_level ()
+gc_new_level (void)
 {
   struct gc_thread* thread = &x_gc_thread[thread_number()];
   return ++thread->gc_level;
Index: common.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/common.h,v
retrieving revision 1.14
diff -u -r1.14 common.h
--- common.h	17 Apr 2003 07:12:04 -0000	1.14
+++ common.h	17 Apr 2003 10:51:16 -0000
@@ -41,8 +41,12 @@
  */
 #define counter_format        "%10lu"
 #define ptr_format            "0x%08zx"
-#define time_format           "%u"
+#define time_format           "%lu"
 #define fragment_type_format  "0x%08x"
+
+/* these are used to cast the arguments
+ * and MUST match the formats above */
+typedef unsigned long time_type;
 
 /*
  * Functions used for circular buffer index arithmetic.
Index: configure.ac
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure.ac,v
retrieving revision 1.64
diff -u -r1.64 configure.ac
--- configure.ac	17 Apr 2003 07:12:04 -0000	1.64
+++ configure.ac	17 Apr 2003 10:51:17 -0000
@@ -223,6 +223,9 @@
 	[],
 	[#include "syshead.h"])
 
+AC_CHECK_SIZEOF(unsigned int)
+AC_CHECK_SIZEOF(unsigned long)
+
 AC_CACHE_SAVE
 
 dnl check for other types
Index: crypto.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/crypto.h,v
retrieving revision 1.11
diff -u -r1.11 crypto.h
--- crypto.h	21 Feb 2003 16:14:05 -0000	1.11
+++ crypto.h	17 Apr 2003 10:51:17 -0000
@@ -262,11 +262,11 @@
 
 void test_crypto (const struct crypto_options *co, struct frame* f);
 
-void show_available_ciphers ();
+void show_available_ciphers (void);
 
-void show_available_digests ();
+void show_available_digests (void);
 
-void init_crypto_lib ();
+void init_crypto_lib (void);
 
 #ifdef USE_SSL
 
Index: error.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.c,v
retrieving revision 1.17
diff -u -r1.17 error.c
--- error.c	17 Apr 2003 07:12:05 -0000	1.17
+++ error.c	17 Apr 2003 10:51:17 -0000
@@ -251,7 +251,7 @@
 }
 
 void
-become_inetd_server ()
+become_inetd_server (void)
 {
 #if defined(HAVE_OPENLOG) && defined(HAVE_SYSLOG)
   if (!msgfp)
Index: error.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.h,v
retrieving revision 1.14
diff -u -r1.14 error.h
--- error.h	16 Mar 2003 08:34:12 -0000	1.14
+++ error.h	17 Apr 2003 10:51:17 -0000
@@ -88,30 +88,34 @@
 
 #define MSG_TEST(flags) ((((unsigned int)flags) & M_DEBUG_LEVEL) < x_debug_level || ((flags) & M_FATAL))
 
-#if defined(HAVE_CPP_VARARG_MACRO_ISO)
+#if defined(HAVE_CPP_VARARG_MACRO_ISO) && !defined(__LCLINT__)
 #define HAVE_VARARG_MACROS
 #define msg(flags, ...) do { if (MSG_TEST(flags)) x_msg((flags), __VA_ARGS__); } while (false)
-#elif defined(HAVE_CPP_VARARG_MACRO_CPP)
+#elif defined(HAVE_CPP_VARARG_MACRO_CPP) && !defined(__LCLINT__)
 #define HAVE_VARARG_MACROS
 #define msg(flags, args...) do { if (MSG_TEST(flags)) x_msg((flags), args); } while (false)
 #else
 #define msg x_msg
 #endif
 
-void x_msg (unsigned int flags, const char *format, ...); /* should be called via msg above */
+void x_msg (unsigned int flags, const char *format, ...)
+#ifdef __GNUC__
+    __attribute__ ((format (printf, 2, 3)))
+#endif
+    ; /* should be called via msg above */
 
 /*
  * Function prototypes
  */
 
-void error_reset ();
+void error_reset (void);
 void set_debug_level (int level);
 void set_mute_cutoff (int cutoff);
 
 /*
  * File to print messages to before syslog is opened.
  */
-FILE *msg_fp();
+FILE *msg_fp(void);
 
 /* Fatal logic errors */
 #define ASSERT(x) do { if (!(x)) assert_failed(__FILE__, __LINE__); } while (false)
@@ -127,7 +131,7 @@
 }
 
 void become_daemon (const char *cd);
-void become_inetd_server ();
+void become_inetd_server (void);
 
 #include "errlevel.h"
 
Index: gremlin.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/gremlin.c,v
retrieving revision 1.9
diff -u -r1.9 gremlin.c
--- gremlin.c	17 Apr 2003 07:12:06 -0000	1.9
+++ gremlin.c	17 Apr 2003 10:51:17 -0000
@@ -103,7 +103,7 @@
  * Return false if we should drop a packet.
  */
 bool
-ask_gremlin()
+ask_gremlin(void)
 {
   struct timeval tv;
 
Index: gremlin.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/gremlin.h,v
retrieving revision 1.3
diff -u -r1.3 gremlin.h
--- gremlin.h	21 Feb 2003 16:14:06 -0000	1.3
+++ gremlin.h	17 Apr 2003 10:51:17 -0000
@@ -25,5 +25,5 @@
 
 #include "buffer.h"
 
-bool ask_gremlin();
+bool ask_gremlin(void);
 void corrupt_gremlin(struct buffer* buf);
Index: misc.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/misc.h,v
retrieving revision 1.13
diff -u -r1.13 misc.h
--- misc.h	17 Apr 2003 07:12:07 -0000	1.13
+++ misc.h	17 Apr 2003 10:51:17 -0000
@@ -51,8 +51,8 @@
 int openvpn_system (const char *command);
 
 /* interpret the status code returned by system() */
-bool system_ok(int stat);
-const char *system_error_message (int stat);
+bool system_ok(int);
+const char *system_error_message (int);
 
 /* run system() with error check, return true if success,
    false if error, exit if error and fatal==true */
@@ -62,11 +62,11 @@
 const char* time_string (time_t t);
 
 /* init random() function, only used as source for weak random numbers, when !USE_CRYPTO */
-void init_random_seed();
+void init_random_seed(void);
 
 /* an analogue to the random() function, but use OpenSSL functions if available */
 #ifdef USE_CRYPTO
-long int get_random();
+long int get_random(void);
 #else
 #define get_random random
 #endif
Index: options.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/options.c,v
retrieving revision 1.31
diff -u -r1.31 options.c
--- options.c	17 Apr 2003 07:12:10 -0000	1.31
+++ options.c	17 Apr 2003 10:51:19 -0000
@@ -491,7 +491,7 @@
 }
 
 static void
-usage ()
+usage (void)
 {
   struct options o;
   FILE *fp = msg_fp();
@@ -518,14 +518,14 @@
 }
 
 void
-usage_small ()
+usage_small (void)
 {
   msg (M_WARN, "Use --help for more information");
   exit (OPENVPN_EXIT_STATUS_USAGE); /* exit point */
 }
 
-void
-usage_version ()
+static void
+usage_version (void)
 {
   msg (M_INFO, "%s", TITLE);
   msg (M_INFO, "Copyright (C) 2002-2003 James Yonan <ji...@yo...>");
@@ -552,7 +552,7 @@
 }
 
 static void
-ping_rec_err ()
+ping_rec_err (void)
 {
   msg (M_WARN, "Options error: only one of --ping-exit or --ping-restart options may be specified");
   usage_small ();
Index: options.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/options.h,v
retrieving revision 1.23
diff -u -r1.23 options.h
--- options.h	17 Apr 2003 07:12:10 -0000	1.23
+++ options.h	17 Apr 2003 10:51:19 -0000
@@ -175,7 +175,7 @@
 
 void notnull (const char *arg, const char *description);
 
-void usage_small ();
+void usage_small (void);
 
 void init_options (struct options *o);
 void show_settings (const struct options *o);
Index: packet_id.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/packet_id.c,v
retrieving revision 1.13
diff -u -r1.13 packet_id.c
--- packet_id.c	17 Apr 2003 07:12:11 -0000	1.13
+++ packet_id.c	17 Apr 2003 10:51:19 -0000
@@ -86,7 +86,8 @@
 
   msg (D_PID_DEBUG,
        "PID TEST " time_format ":" packet_id_format " " time_format ":" packet_id_format "",
-       p->time, p->id, pin->time, pin->id);
+       (time_type)p->time, (packet_id_print_type)p->id, (time_type)pin->time,
+       (packet_id_print_type)pin->id);
 
   if (!pin->id)
     return false;
@@ -114,10 +115,10 @@
 packet_id_net_print (const struct packet_id_net *pin, bool print_timestamp)
 {
   struct buffer out = alloc_buf_gc (256);
-  
-  buf_printf (&out, "[ #" packet_id_format, pin->id);
+
+  buf_printf (&out, "[ #" packet_id_format, (packet_id_print_type)pin->id);
   if (print_timestamp && pin->time)
-      buf_printf (&out, " / time = (" packet_id_format ") %s", pin->time, time_string (pin->time));
+      buf_printf (&out, " / time = (" packet_id_format ") %s", (packet_id_print_type)pin->time, time_string (pin->time));
 
   buf_printf (&out, " ]");
   return BSTR (&out);
@@ -244,14 +245,14 @@
 packet_id_persist_print (const struct packet_id_persist *p)
 {
   struct buffer out = alloc_buf_gc (256);
-  
+
   buf_printf (&out, "[");
 
   if (packet_id_persist_enabled (p))
     {
-      buf_printf (&out, " #" packet_id_format, p->id);
+      buf_printf (&out, " #" packet_id_format, (packet_id_print_type)p->id);
       if (p->time)
-	buf_printf (&out, " / time = (" packet_id_format ") %s", p->time, time_string (p->time));
+	buf_printf (&out, " / time = (" packet_id_format ") %s", (packet_id_print_type)p->time, time_string (p->time));
     }
 
   buf_printf (&out, " ]");
Index: packet_id.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/packet_id.h,v
retrieving revision 1.13
diff -u -r1.13 packet_id.h
--- packet_id.h	17 Apr 2003 07:12:11 -0000	1.13
+++ packet_id.h	17 Apr 2003 10:51:19 -0000
@@ -93,7 +93,15 @@
 /*
  * Printf formats for special types
  */
+#if SIZEOF_UNSIGNED_LONG == 4
+#define packet_id_format "%lu"
+typedef unsigned long packet_id_print_type;
+#elif SIZEOF_UNSIGNED_INT == 4
 #define packet_id_format "%u"
+typedef unsigned int packet_id_print_type;
+#else
+#error "cannot figure proper format to print uint32_t"
+#endif
 
 /*
  * Maximum allowed backtrack in
Index: reliable.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/reliable.c,v
retrieving revision 1.12
diff -u -r1.12 reliable.c
--- reliable.c	17 Apr 2003 07:12:11 -0000	1.12
+++ reliable.c	17 Apr 2003 10:51:19 -0000
@@ -62,7 +62,7 @@
     {
       *pid = ntohpid (net_pid);
       msg (D_REL_DEBUG, "ACK read ID " packet_id_format " (buf->len=%d)",
-	   *pid, buf->len);
+	   (packet_id_print_type)*pid, buf->len);
       return true;
     }
 
@@ -78,12 +78,12 @@
     {
       ack->packet_id[ack->len++] = pid;
       msg (D_REL_DEBUG, "ACK acknowledge ID " packet_id_format " (ack->len=%d)",
-	   pid, ack->len);
+	   (packet_id_print_type)pid, ack->len);
       return true;
     }
 
   msg (D_REL_LOW, "ACK acknowledge ID " packet_id_format " FAILED (ack->len=%d)",
-       pid, ack->len);
+       (packet_id_print_type)pid, ack->len);
   return false;
 }
 
@@ -153,7 +153,7 @@
       packet_id_type pid = ack->packet_id[i];
       packet_id_type net_pid = htonpid (pid);
       ASSERT (buf_write (&sub, &net_pid, sizeof (net_pid)));
-      msg (D_REL_DEBUG, "ACK write ID " packet_id_format " (ack->len=%d, n=%d)", pid, ack->len, n);
+      msg (D_REL_DEBUG, "ACK write ID " packet_id_format " (ack->len=%d, n=%d)", (packet_id_print_type)pid, ack->len, n);
     }
   if (n)
     {
@@ -195,7 +195,7 @@
       if (!buf_read (buf, &pid, sizeof (pid)))
 	goto done;
       pid = ntohpid (pid);
-      buf_printf (&out, " " packet_id_format, pid);
+      buf_printf (&out, " " packet_id_format, (packet_id_print_type)pid);
     }
   if (n_ack)
     {
@@ -294,7 +294,7 @@
 	    {
 	      msg (D_REL_DEBUG,
 		   "ACK received for pid " packet_id_format ", deleting from send buffer",
-		   pid);
+		   (packet_id_print_type)pid);
 #if 0
 	      /* DEBUGGING -- how close were we timing out on ACK failure and resending? */
 	      {
@@ -316,12 +316,12 @@
   struct buffer out = alloc_buf_gc (512);
   int i;
 
-  buf_printf (&out, "[" packet_id_format "]", rel->packet_id);
+  buf_printf (&out, "[" packet_id_format "]", (packet_id_print_type)rel->packet_id);
   for (i = 0; i < rel->size; ++i)
     {
       const struct reliable_entry *e = &rel->array[i];
       if (e->active)
-	buf_printf (&out, " " packet_id_format, e->packet_id);
+	buf_printf (&out, " " packet_id_format, (packet_id_print_type)e->packet_id);
     }
   return BSTR (&out);
 }
@@ -357,7 +357,7 @@
   return true;
 
  bad:
-  msg (D_REL_DEBUG, "ACK " packet_id_format " is a replay: %s", id, reliable_print_ids (rel));
+  msg (D_REL_DEBUG, "ACK " packet_id_format " is a replay: %s", (packet_id_print_type)id, reliable_print_ids (rel));
   return false;
 }
 
@@ -372,7 +372,7 @@
   else
     {
       msg (D_REL_DEBUG, "ACK " packet_id_format " breaks sequentiality: %s",
-	   id, reliable_print_ids (rel));
+	   (packet_id_print_type)id, reliable_print_ids (rel));
       return false;
     }
 }
@@ -504,7 +504,7 @@
 #endif
       *opcode = best->opcode;
       msg (D_REL_DEBUG, "ACK reliable_send ID " packet_id_format " (size=%d to=%d)",
-	   best->packet_id, best->buf.len, (int) best->next_try - current);
+	   (packet_id_print_type)best->packet_id, best->buf.len, (int)(best->next_try - current));
       return &best->buf;
     }
   return NULL;
@@ -552,7 +552,7 @@
 	  e->opcode = opcode;
 	  e->next_try = 0;
 	  e->timeout = 0;
-	  msg (D_REL_DEBUG, "ACK mark active incoming ID " packet_id_format, e->packet_id);
+	  msg (D_REL_DEBUG, "ACK mark active incoming ID " packet_id_format, (packet_id_print_type)e->packet_id);
 	  return;
 	}
     }
@@ -582,7 +582,7 @@
 	  e->opcode = opcode;
 	  e->next_try = 0;
 	  e->timeout = rel->initial_timeout;
-	  msg (D_REL_DEBUG, "ACK mark active outgoing ID " packet_id_format, e->packet_id);
+	  msg (D_REL_DEBUG, "ACK mark active outgoing ID " packet_id_format, (packet_id_print_type)e->packet_id);
 	  return;
 	}
     }
Index: shaper.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/shaper.c,v
retrieving revision 1.6
diff -u -r1.6 shaper.c
--- shaper.c	17 Apr 2003 07:12:12 -0000	1.6
+++ shaper.c	17 Apr 2003 10:51:19 -0000
@@ -113,7 +113,7 @@
 	}
     }
   msg (D_SHAPER_DEBUG, "SHAPER shaper_soonest_event sec=%d usec=%d",
-       tv->tv_sec, tv->tv_usec);
+       (int)tv->tv_sec, (int)tv->tv_usec);
 }
 
 /*
@@ -138,7 +138,7 @@
       s->wakeup.tv_usec -= 1000000;
     }
   msg (D_SHAPER_DEBUG, "SHAPER shaper_wrote_bytes bytes=%d delay=%d sec=%d usec=%d",
-       nbytes, delay, s->wakeup.tv_sec, s->wakeup.tv_usec);
+       nbytes, delay, (int)s->wakeup.tv_sec, (int)s->wakeup.tv_usec);
 }
 
 /*
Index: socket.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/socket.h,v
retrieving revision 1.10
diff -u -r1.10 socket.h
--- socket.h	17 Apr 2003 07:12:15 -0000	1.10
+++ socket.h	17 Apr 2003 10:51:19 -0000
@@ -109,7 +109,7 @@
 extern unsigned int x_cs_info_level;
 extern unsigned int x_cs_verbose_level;
 
-void reset_check_status ();
+void reset_check_status (void);
 void set_check_status (unsigned int info_level, unsigned int verbose_level);
 void x_check_status (int status, const char *description, struct udp_socket *sock);
 
Index: ssl.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/ssl.c,v
retrieving revision 1.32
diff -u -r1.32 ssl.c
--- ssl.c	17 Apr 2003 07:12:15 -0000	1.32
+++ ssl.c	17 Apr 2003 10:51:21 -0000
@@ -1284,7 +1284,7 @@
        || (packet_id_close_to_wrapping (&ks->packet_id.send))))
     {
       msg (D_TLS_DEBUG_LOW, "TLS: soft reset sec=%d bytes=%d/%d pkts=%d/%d",
-	   (int) ks->established + session->opt->renegotiate_seconds - current,
+	   (int)(ks->established + session->opt->renegotiate_seconds - current),
 	   ks->n_bytes, session->opt->renegotiate_bytes,
 	   ks->n_packets, session->opt->renegotiate_packets);
       key_state_soft_reset (session, current);
@@ -1732,7 +1732,7 @@
  * Errors are fatal if they are of these types.
  */
 static inline bool
-local_sock_fatal ()
+local_sock_fatal (void)
 {
   return errno == ENOTCONN || errno == ECONNREFUSED;
 }
@@ -2487,7 +2487,7 @@
     if (!buf_read (&buf, &l, sizeof (l)))
       goto done;
     l = ntohpid (l);
-    buf_printf (&out, " pid=" packet_id_format, l);
+    buf_printf (&out, " pid=" packet_id_format, (packet_id_print_type)l);
   }
 
 print_data:
Index: ssl.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/ssl.h,v
retrieving revision 1.11
diff -u -r1.11 ssl.h
--- ssl.h	17 Apr 2003 07:12:16 -0000	1.11
+++ ssl.h	17 Apr 2003 10:51:21 -0000
@@ -331,8 +331,8 @@
   struct tls_session session[TM_SIZE];
 };
 
-void init_ssl_lib ();
-void free_ssl_lib ();
+void init_ssl_lib (void);
+void free_ssl_lib (void);
 
 /* Build master SSL_CTX object that serves for the whole of openvpn instantiation */
 SSL_CTX *init_ssl (bool server,
@@ -366,7 +366,7 @@
 
 void tls_post_encrypt (struct tls_multi *multi, struct buffer *buf);
 
-void show_available_tls_ciphers ();
+void show_available_tls_ciphers (void);
 void get_highest_preference_tls_cipher (char *buf, int size);
 
 int pem_password_callback (char *buf, int size, int rwflag, void *u);
Index: syshead.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/syshead.h,v
retrieving revision 1.16
diff -u -r1.16 syshead.h
--- syshead.h	15 Mar 2003 07:18:00 -0000	1.16
+++ syshead.h	17 Apr 2003 10:51:21 -0000
@@ -134,7 +134,7 @@
 #endif
 
 #ifdef HAVE_ARPA_INET_H
-#ifndef TARGET_OPENBSD
+#if !defined(TARGET_OPENBSD) && !defined(__LCLINT__)
 #include <arpa/inet.h>
 #endif
 #endif
@@ -145,7 +145,7 @@
 
 #ifdef TARGET_LINUX
 
-#ifdef HAVE_NETINET_IF_ETHER_H
+#if defined(HAVE_NETINET_IF_ETHER_H) && !defined(__LCLINT__)
 #include <netinet/if_ether.h>
 #endif
 
Index: thread.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/thread.c,v
retrieving revision 1.5
diff -u -r1.5 thread.c
--- thread.c	16 Mar 2003 08:34:12 -0000	1.5
+++ thread.c	17 Apr 2003 10:51:21 -0000
@@ -45,7 +45,7 @@
 static void
 ssl_pthreads_locking_callback (int mode, int type, char *file, int line)
 {
-  msg (D_OPENSSL_LOCK, "SSL LOCK thread=%4d mode=%s lock=%s %s:%d",
+  msg (D_OPENSSL_LOCK, "SSL LOCK thread=%4lu mode=%s lock=%s %s:%d",
 	   CRYPTO_thread_id (),
 	   (mode & CRYPTO_LOCK) ? "l" : "u",
 	   (type & CRYPTO_READ) ? "r" : "w", file, line);
@@ -83,8 +83,8 @@
       pthread_mutex_init (&(ssl_lock_cs[i]), NULL);
     }
 
-  CRYPTO_set_id_callback ((unsigned long (*)()) ssl_pthreads_thread_id);
-  CRYPTO_set_locking_callback ((void (*)()) ssl_pthreads_locking_callback);
+  CRYPTO_set_id_callback ((unsigned long (*)(void)) ssl_pthreads_thread_id);
+  CRYPTO_set_locking_callback ((void (*)(int, int, const char*, int)) ssl_pthreads_locking_callback);
 }
 
 static void
@@ -113,7 +113,7 @@
   ASSERT (x_main_thread_id);
   ASSERT (!x_work_thread_id);
   ASSERT (!pthread_create (&x_work_thread_id, NULL, start_routine, arg));
-  msg (D_THREAD_DEBUG, "CREATE THREAD ID=%d", x_work_thread_id);
+  msg (D_THREAD_DEBUG, "CREATE THREAD ID=%lu", (unsigned long)x_work_thread_id);
 }
 
 void
Index: thread.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/thread.h,v
retrieving revision 1.5
diff -u -r1.5 thread.h
--- thread.h	21 Feb 2003 16:14:06 -0000	1.5
+++ thread.h	17 Apr 2003 10:51:21 -0000
@@ -58,7 +58,7 @@
 #define MUTEX_UNLOCK(lock)         pthread_mutex_unlock (&lock)
 
 static inline int
-thread_number()
+thread_number(void)
 {
   return (!x_main_thread_id || pthread_self () == x_main_thread_id) ? MAIN_THREAD : WORK_THREAD;
 }
@@ -100,11 +100,11 @@
     }
 }
 
-void thread_init();
-void thread_cleanup();
+void thread_init(void);
+void thread_cleanup(void);
 
 void work_thread_create (void *(*start_routine) (void *), void* arg);
-void work_thread_join ();
+void work_thread_join (void);
 
 #else /* USE_PTHREAD */
 
Index: tun.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/tun.c,v
retrieving revision 1.28
diff -u -r1.28 tun.c
--- tun.c	17 Apr 2003 07:12:16 -0000	1.28
+++ tun.c	17 Apr 2003 10:51:22 -0000
@@ -417,7 +417,7 @@
 	  int		fd;
  
 	  if ((fd = socket(PF_INET, SOCK_DGRAM, 0)) < 0)
-	    msg (M_WARN, "Cannot open control_fd", dev);
+	    msg (M_WARN, "Cannot open control_fd");
 	  else
 	    {
 	      strncpynt (r.ifr_name, tt->actual, IFNAMSIZ);
Index: tun.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/tun.h,v
retrieving revision 1.20
diff -u -r1.20 tun.h
--- tun.h	17 Apr 2003 07:12:16 -0000	1.20
+++ tun.h	17 Apr 2003 10:51:22 -0000
@@ -88,7 +88,7 @@
 #define IFCONFIG_DEFAULT         1
 
 static inline int
-ifconfig_order()
+ifconfig_order(void)
 {
 #if defined(TARGET_LINUX)
   return IFCONFIG_AFTER_TUN_OPEN;

-- 
Matthias Andree

[Openvpn-devel] New beta available + progress update

[James Y. <ji...@yo...>]

OpenVPN continues to evolve, and I thought I would take this opportunity to
briefly describe some of the current directions in the project (which,
incidentally, has passed its 1 year milestone).

For one, a new OpenVPN beta is available and testing would be appreciated.

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS)

Thanks to the stability of 1.3.2, I've held off on making a new release that's
composed entirely of minor changes, and have instead focussed on some bigger
issues such as making the handling of MTU and fragmentation more dynamic and
automatic.  To this end, the new beta contains a number of improvements to
allow for dynamic MTU resizing.  This code is still experimental, and must be
explicitly enabled by defining FRAGMENT_ENABLE and rebuilding.

What the FRAGMENT_ENABLE code does is to add an extra 4 byte header to each
datagram that includes, among other things, feedback on the number of
datagrams received as well as the maximum datagram size received.  This
information can then be used by an OpenVPN peer to dynamically set the MTU
size as well as the datagram transmit rate independently of the OS and the
proper functioning of path MTU discovery.  Ultimately this code can make
OpenVPN more robust in situations where fragmentation is necessary (such as in
TAP-based bridged ethernets) when firewalls or routers in the path break PMTU
discovery.

My thinking right now is to make the next release 1.4.0 but leave the
FRAGMENT_ENABLE code off by default.  Even with the FRAGMENT_ENABLE code
disabled, there's enough new stuff here to justify a point release.

As well, there are a fair number of minor changes as well (see the ChangeLog
at the end of this message).

Looking post-1.4.0, the latest wishlist appears to be:

(1) Simplify configuration for setups that involve one server and numerous
roving clients (some of this has already been addressed by the --inetd option).

(2) Dynamic MTU support.  Ultimately, the FRAGMENT_ENABLE code will do this,
but it still needs testing and more developer input.

(3) Porting to Windows.  Judging by email I receive, there seems to be a lot
of demand for this.  In addition, a lot of developers have come forward who
are interested in working on a TUN/TAP driver for Windows (which is the
missing link), but so far I haven't seen much progress.  I may jump into the
fray and work on this myself, though due to the higher costs of developing for
Windows, I would need some corporate sponsorship to help defray costs.  Let me
know if you are interested in sponsoring such an undertaking.

If there are wishlist items I have missed, or if there is something you would
like to add, please let us know.

And also, please be reminded that the OpenVPN project is financially supported
by the user community.  Please consider donating to the project.  More info is
available here:

http://openvpn.sourceforge.net/donate.html

James

**************

ChangeLog:

$Id: ChangeLog,v 1.69 2003/04/17 07:12:02 jimyonan Exp $

Upcoming version 1.4.0

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.
* Added TUN/TAP open code to cycle dynamically
  through unit numbers until it finds a free
  unit (based on code from Thomas Gielfeldt
  and VTun).
* Added dynamic MTU and fragmenting infrastructure
  (Experimental).  Rebuild with FRAGMENT_ENABLE
  defined to enable.
* Minor changes to SSL/TLS negotiation, use
  exponential backoff on retransmits, and use
  a smaller MTU size (note that no protocol
  changes have been made which would break
  compatibility with 1.3.x).
* Added --enable-strict-options flag
  to ./configure.  This option will cause
  a more strict check for options compatibility
  between peers when SSL/TLS negotiation is used,
  but should only be used when both OpenVPN peers
  are of the same version.
* Reorganization of debugging levels >= 5.

Re: [Openvpn-devel] New pre-1.3.3 beta

[James Y. <ji...@yo...>]

Matthias,

Patch looks good, though why the dummy() functions?  They generate warnings on
gcc 2.96 if you build with --disable-lzo, --disable-crypto, etc.  Some
compiler that doesn't like empty source files?

James

Matthias Andree <ma+...@dt...> said:

> On Sat, 15 Mar 2003, James Yonan wrote:
> 
> > Yes, I think we should try to fix if it's only a trivial cast involved to
> > silence the warning.
> > 
> > I don't see them on gcc 2.96, even with "-Wall -W -Wpointer-arith
> > -Wsign-compare -Winline".
> 
> Indeed, it takes the sun compiler or the even more picky splint utility
> (www.splint.org) to see them.
> 
> The patch below doesn't fix
> "crypto.c", line 228: warning: end-of-loop code not reached
> 
> also on ll. 237 259 269 273 277 281 286 299 312 327.
> 
> Fixing that would require a rewrite of crypto.c, the issue is the
> 
> do { goto ...; } while(false);
> 
> I'm not fixing this and I don't recommend changing that at this time
> (after 1.3.3 maybe, if you're to fix that at all).
> 
> Here's the patch:
> 
> # buffer.c     |   14 +++++++-------
> # crypto.c     |   12 ++++++------
> # error.c      |    2 +-
> # lzo.c        |    2 ++
> # misc.c       |    2 +-
> # packet_id.c  |    4 ++--
> # reliable.c   |    2 ++
> # session_id.c |    2 ++
> # socket.c     |    4 ++--
> # ssl.c        |    6 ++++--
> # thread.c     |    2 ++
> # tun.c        |    4 ++--
> # 12 files changed, 33 insertions(+), 23 deletions(-)
> 
> Index: buffer.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/buffer.c,v
> retrieving revision 1.11
> diff -u -r1.11 buffer.c
> --- buffer.c	15 Mar 2003 07:18:00 -0000	1.11
> +++ buffer.c	15 Mar 2003 22:42:02 -0000
> @@ -115,14 +115,14 @@
>  {
>    va_list arglist;
>  
> -  char *ptr = BEND (buf);
> +  uint8_t *ptr = BEND (buf);
>    int cap = buf_forward_capacity (buf);
>  
>    va_start (arglist, format);
> -  vsnprintf (ptr, cap, format, arglist);
> +  vsnprintf ((char *)ptr, cap, format, arglist);
>    va_end (arglist);
>  
> -  buf->len += strlen (ptr);
> +  buf->len += strlen ((char *)ptr);
>  }
>  
>  /*
> @@ -137,7 +137,7 @@
>        int len = strlen (str) + 1;
>        if (len < buf_forward_capacity_total (buf))
>  	{
> -	  strncpynt (buf->data + buf->capacity - len, str, len);
> +	  strncpynt ((char *)(buf->data + buf->capacity - len), str, len);
>  	}
>      }
>  }
> @@ -148,7 +148,7 @@
>  void
>  convert_to_one_line (struct buffer *buf)
>  {
> -  char *cp = BPTR(buf);
> +  uint8_t *cp = BPTR(buf);
>    int len = BLEN(buf);
>    while (len--)
>      {
> @@ -185,7 +185,7 @@
>    struct gc_entry *e;
>    struct gc_thread* thread = &x_gc_thread[thread_number()];
>  
> -  while (e = thread->gc_stack)
> +  while ((e = thread->gc_stack))
>      {
>        if (e->level < level)
>  	break;
> @@ -235,5 +235,5 @@
>        buf_printf (&out, "%02x", data[i]);
>      }
>    buf_catrunc (&out, "[more...]");
> -  return out.data;
> +  return (char *)out.data;
>  }
> Index: crypto.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/crypto.c,v
> retrieving revision 1.14
> diff -u -r1.14 crypto.c
> --- crypto.c	21 Feb 2003 16:14:05 -0000	1.14
> +++ crypto.c	15 Mar 2003 22:42:03 -0000
> @@ -184,7 +184,7 @@
>  	  HMAC_Update (ctx->hmac, BPTR (&work), BLEN (&work));
>  	  output = buf_prepend (&work, HMAC_size (ctx->hmac));
>  	  ASSERT (output);
> -	  HMAC_Final (ctx->hmac, output, &hmac_len);
> +	  HMAC_Final (ctx->hmac, output, (unsigned int *)&hmac_len);
>  	  ASSERT (hmac_len == HMAC_size (ctx->hmac));
>  	}
>  
> @@ -229,7 +229,7 @@
>  
>  	  HMAC_Update (ctx->hmac, BPTR (buf) + hmac_len,
>  		       BLEN (buf) - hmac_len);
> -	  HMAC_Final (ctx->hmac, local_hmac, &in_hmac_len);
> +	  HMAC_Final (ctx->hmac, local_hmac, (unsigned int *)&in_hmac_len);
>  	  ASSERT (hmac_len == in_hmac_len);
>  
>  	  /* Compare locally computed HMAC with packet HMAC */
> @@ -883,9 +883,9 @@
>    if (fd == -1)
>      msg (M_ERR, "Cannot open shared secret file %s", filename);
>  
> -  while (size = read (fd, in.data, in.capacity))
> +  while ((size = read (fd, in.data, in.capacity)))
>      {
> -      const char *cp = in.data;
> +      const char *cp = (char *)in.data;
>        while (size)
>  	{
>  	  const char c = *cp;
> @@ -923,7 +923,7 @@
>  		    if (hb_index == 2)
>  		      {
>  			unsigned int u;
> -			ASSERT(sscanf(hex_byte, "%x", &u) == 1);
> +			ASSERT(sscanf((const char *)hex_byte, "%x", &u) == 1);
>  			*out++ = u;
>  			hb_index = 0;
>  			if (++count == keylen)
> @@ -982,7 +982,7 @@
>    buf_printf (&out, "%s\n", static_key_foot);
>  
>    /* write data to file */
> -  len = strlen (BPTR(&out));
> +  len = strlen ((char *)BPTR(&out));
>    size = write (fd, BPTR(&out), len);
>    if (size != len)
>      msg (M_ERR, "Write error on shared secret file %s", filename);
> Index: error.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/error.c,v
> retrieving revision 1.15
> diff -u -r1.15 error.c
> --- error.c	15 Mar 2003 07:18:00 -0000	1.15
> +++ error.c	15 Mar 2003 22:42:03 -0000
> @@ -177,7 +177,7 @@
>      {
>        int nerrs = 0;
>        int err;
> -      while (err = ERR_get_error ())
> +      while ((err = ERR_get_error ()))
>  	{
>  	  snprintf (m2, ERR_BUF_SIZE, "%s: %s", m1, ERR_error_string (err, NULL));
>  	  SWAP;
> Index: lzo.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/lzo.c,v
> retrieving revision 1.11
> diff -u -r1.11 lzo.c
> --- lzo.c	21 Feb 2003 16:14:06 -0000	1.11
> +++ lzo.c	15 Mar 2003 22:42:03 -0000
> @@ -239,4 +239,6 @@
>    msg (M_INFO, " post-decompress bytes:" counter_format,
lzo_compwork->post_decompress);
>  }
>  
> +#else
> +static void dummy(void) {}
>  #endif /* USE_LZO */
> Index: misc.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/misc.c,v
> retrieving revision 1.15
> diff -u -r1.15 misc.c
> --- misc.c	21 Feb 2003 16:14:06 -0000	1.15
> +++ misc.c	15 Mar 2003 22:42:03 -0000
> @@ -285,7 +285,7 @@
>        else
>  	buf_printf (&out, "shell command exited with error status: %d", cmd_ret);
>      }
> -  return out.data;
> +  return (const char *)out.data;
>  }
>  
>  /*
> Index: packet_id.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/packet_id.c,v
> retrieving revision 1.11
> diff -u -r1.11 packet_id.c
> --- packet_id.c	21 Feb 2003 16:14:06 -0000	1.11
> +++ packet_id.c	15 Mar 2003 22:42:03 -0000
> @@ -124,7 +124,7 @@
>      }
>  
>    buf_printf (&out, " ]");
> -  return out.data;
> +  return (char *)out.data;
>  }
>  
>  /* initialize the packet_id_persist structure in a disabled state */
> @@ -265,7 +265,7 @@
>      }
>  
>    buf_printf (&out, " ]");
> -  return out.data;
> +  return (char *)out.data;
>  }
>  
>  #ifdef PID_TEST
> Index: reliable.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/reliable.c,v
> retrieving revision 1.10
> diff -u -r1.10 reliable.c
> --- reliable.c	21 Feb 2003 16:14:06 -0000	1.10
> +++ reliable.c	15 Mar 2003 22:42:03 -0000
> @@ -500,4 +500,6 @@
>  
>  #endif
>  
> +#else
> +static void dummy(void) {}
>  #endif /* USE_CRYPTO && USE_SSL*/
> Index: session_id.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/session_id.c,v
> retrieving revision 1.4
> diff -u -r1.4 session_id.c
> --- session_id.c	21 Feb 2003 16:14:06 -0000	1.4
> +++ session_id.c	15 Mar 2003 22:42:03 -0000
> @@ -60,4 +60,6 @@
>    return format_hex (sid->id, SID_SIZE, 0);
>  }
>  
> +#else
> +static void dummy(void) {}
>  #endif /* USE_CRYPTO && USE_SSL*/
> Index: socket.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/socket.c,v
> retrieving revision 1.17
> diff -u -r1.17 socket.c
> --- socket.c	15 Mar 2003 07:18:00 -0000	1.17
> +++ socket.c	15 Mar 2003 22:42:04 -0000
> @@ -255,7 +255,7 @@
>  	    {
>  	      char command[256];
>  	      struct buffer out;
> -	      buf_set_write (&out, command, sizeof (command));
> +	      buf_set_write (&out, (uint8_t *)command, sizeof (command));
>  	      buf_printf (&out, "%s %s",
>  			  sock->ipchange_command,
>  			  print_sockaddr_ex (&usa->actual, true, " "));
> @@ -356,5 +356,5 @@
>  
>        buf_printf (&out, "%d", port);
>      }
> -  return out.data;
> +  return (char *)out.data;
>  }
> Index: ssl.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/ssl.c,v
> retrieving revision 1.30
> diff -u -r1.30 ssl.c
> --- ssl.c	15 Mar 2003 07:18:00 -0000	1.30
> +++ ssl.c	15 Mar 2003 22:42:05 -0000
> @@ -228,7 +228,7 @@
>  system_safe_string (char *cp)
>  {
>    int c;
> -  while (c = *cp)
> +  while ((c = *cp))
>      {
>        if (isalnum (c)
>  	  || c == '/'
> @@ -494,7 +494,7 @@
>  
>    printf ("Available TLS Ciphers,\n");
>    printf ("listed in order of preference:\n\n");
> -  while (cipher_name = SSL_get_cipher_list (ssl, priority++))
> +  while ((cipher_name = SSL_get_cipher_list (ssl, priority++)))
>      printf ("%s\n", cipher_name);
>    printf ("\n");
>  
> @@ -2491,4 +2491,6 @@
>    return out.data;
>  }
>  
> +#else
> +static void dummy(void) {}
>  #endif /* USE_CRYPTO && USE_SSL*/
> Index: thread.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/thread.c,v
> retrieving revision 1.4
> diff -u -r1.4 thread.c
> --- thread.c	21 Feb 2003 16:14:06 -0000	1.4
> +++ thread.c	15 Mar 2003 22:42:05 -0000
> @@ -175,4 +175,6 @@
>      }
>  }
>  
> +#else
> +static void dummy(void) {}
>  #endif
> Index: tun.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/tun.c,v
> retrieving revision 1.25
> diff -u -r1.25 tun.c
> --- tun.c	15 Mar 2003 07:18:00 -0000	1.25
> +++ tun.c	15 Mar 2003 22:42:05 -0000
> @@ -609,7 +609,7 @@
>  {
>    struct strbuf sbuf;
>    sbuf.len = len;
> -  sbuf.buf = buf;
> +  sbuf.buf = (char *)buf;
>    return putmsg (tt->fd, NULL, &sbuf, 0) >= 0 ? sbuf.len : -1;
>  }
>  
> @@ -620,7 +620,7 @@
>    int f = 0;
>  
>    sbuf.maxlen = len;
> -  sbuf.buf = buf;
> +  sbuf.buf = (char *)buf;
>    return getmsg (tt->fd, NULL, &sbuf, &f) >= 0 ? sbuf.len : -1;
>  }
>  
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] New pre-1.3.3 beta

[Matthias A. <ma+...@dt...>]

On Sat, 15 Mar 2003, James Yonan wrote:

> Yes, I think we should try to fix if it's only a trivial cast involved to
> silence the warning.
> 
> I don't see them on gcc 2.96, even with "-Wall -W -Wpointer-arith
> -Wsign-compare -Winline".

Indeed, it takes the sun compiler or the even more picky splint utility
(www.splint.org) to see them.

The patch below doesn't fix
"crypto.c", line 228: warning: end-of-loop code not reached

also on ll. 237 259 269 273 277 281 286 299 312 327.

Fixing that would require a rewrite of crypto.c, the issue is the

do { goto ...; } while(false);

I'm not fixing this and I don't recommend changing that at this time
(after 1.3.3 maybe, if you're to fix that at all).

Here's the patch:

# buffer.c     |   14 +++++++-------
# crypto.c     |   12 ++++++------
# error.c      |    2 +-
# lzo.c        |    2 ++
# misc.c       |    2 +-
# packet_id.c  |    4 ++--
# reliable.c   |    2 ++
# session_id.c |    2 ++
# socket.c     |    4 ++--
# ssl.c        |    6 ++++--
# thread.c     |    2 ++
# tun.c        |    4 ++--
# 12 files changed, 33 insertions(+), 23 deletions(-)

Index: buffer.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/buffer.c,v
retrieving revision 1.11
diff -u -r1.11 buffer.c
--- buffer.c	15 Mar 2003 07:18:00 -0000	1.11
+++ buffer.c	15 Mar 2003 22:42:02 -0000
@@ -115,14 +115,14 @@
 {
   va_list arglist;
 
-  char *ptr = BEND (buf);
+  uint8_t *ptr = BEND (buf);
   int cap = buf_forward_capacity (buf);
 
   va_start (arglist, format);
-  vsnprintf (ptr, cap, format, arglist);
+  vsnprintf ((char *)ptr, cap, format, arglist);
   va_end (arglist);
 
-  buf->len += strlen (ptr);
+  buf->len += strlen ((char *)ptr);
 }
 
 /*
@@ -137,7 +137,7 @@
       int len = strlen (str) + 1;
       if (len < buf_forward_capacity_total (buf))
 	{
-	  strncpynt (buf->data + buf->capacity - len, str, len);
+	  strncpynt ((char *)(buf->data + buf->capacity - len), str, len);
 	}
     }
 }
@@ -148,7 +148,7 @@
 void
 convert_to_one_line (struct buffer *buf)
 {
-  char *cp = BPTR(buf);
+  uint8_t *cp = BPTR(buf);
   int len = BLEN(buf);
   while (len--)
     {
@@ -185,7 +185,7 @@
   struct gc_entry *e;
   struct gc_thread* thread = &x_gc_thread[thread_number()];
 
-  while (e = thread->gc_stack)
+  while ((e = thread->gc_stack))
     {
       if (e->level < level)
 	break;
@@ -235,5 +235,5 @@
       buf_printf (&out, "%02x", data[i]);
     }
   buf_catrunc (&out, "[more...]");
-  return out.data;
+  return (char *)out.data;
 }
Index: crypto.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/crypto.c,v
retrieving revision 1.14
diff -u -r1.14 crypto.c
--- crypto.c	21 Feb 2003 16:14:05 -0000	1.14
+++ crypto.c	15 Mar 2003 22:42:03 -0000
@@ -184,7 +184,7 @@
 	  HMAC_Update (ctx->hmac, BPTR (&work), BLEN (&work));
 	  output = buf_prepend (&work, HMAC_size (ctx->hmac));
 	  ASSERT (output);
-	  HMAC_Final (ctx->hmac, output, &hmac_len);
+	  HMAC_Final (ctx->hmac, output, (unsigned int *)&hmac_len);
 	  ASSERT (hmac_len == HMAC_size (ctx->hmac));
 	}
 
@@ -229,7 +229,7 @@
 
 	  HMAC_Update (ctx->hmac, BPTR (buf) + hmac_len,
 		       BLEN (buf) - hmac_len);
-	  HMAC_Final (ctx->hmac, local_hmac, &in_hmac_len);
+	  HMAC_Final (ctx->hmac, local_hmac, (unsigned int *)&in_hmac_len);
 	  ASSERT (hmac_len == in_hmac_len);
 
 	  /* Compare locally computed HMAC with packet HMAC */
@@ -883,9 +883,9 @@
   if (fd == -1)
     msg (M_ERR, "Cannot open shared secret file %s", filename);
 
-  while (size = read (fd, in.data, in.capacity))
+  while ((size = read (fd, in.data, in.capacity)))
     {
-      const char *cp = in.data;
+      const char *cp = (char *)in.data;
       while (size)
 	{
 	  const char c = *cp;
@@ -923,7 +923,7 @@
 		    if (hb_index == 2)
 		      {
 			unsigned int u;
-			ASSERT(sscanf(hex_byte, "%x", &u) == 1);
+			ASSERT(sscanf((const char *)hex_byte, "%x", &u) == 1);
 			*out++ = u;
 			hb_index = 0;
 			if (++count == keylen)
@@ -982,7 +982,7 @@
   buf_printf (&out, "%s\n", static_key_foot);
 
   /* write data to file */
-  len = strlen (BPTR(&out));
+  len = strlen ((char *)BPTR(&out));
   size = write (fd, BPTR(&out), len);
   if (size != len)
     msg (M_ERR, "Write error on shared secret file %s", filename);
Index: error.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.c,v
retrieving revision 1.15
diff -u -r1.15 error.c
--- error.c	15 Mar 2003 07:18:00 -0000	1.15
+++ error.c	15 Mar 2003 22:42:03 -0000
@@ -177,7 +177,7 @@
     {
       int nerrs = 0;
       int err;
-      while (err = ERR_get_error ())
+      while ((err = ERR_get_error ()))
 	{
 	  snprintf (m2, ERR_BUF_SIZE, "%s: %s", m1, ERR_error_string (err, NULL));
 	  SWAP;
Index: lzo.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/lzo.c,v
retrieving revision 1.11
diff -u -r1.11 lzo.c
--- lzo.c	21 Feb 2003 16:14:06 -0000	1.11
+++ lzo.c	15 Mar 2003 22:42:03 -0000
@@ -239,4 +239,6 @@
   msg (M_INFO, " post-decompress bytes:" counter_format, lzo_compwork->post_decompress);
 }
 
+#else
+static void dummy(void) {}
 #endif /* USE_LZO */
Index: misc.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/misc.c,v
retrieving revision 1.15
diff -u -r1.15 misc.c
--- misc.c	21 Feb 2003 16:14:06 -0000	1.15
+++ misc.c	15 Mar 2003 22:42:03 -0000
@@ -285,7 +285,7 @@
       else
 	buf_printf (&out, "shell command exited with error status: %d", cmd_ret);
     }
-  return out.data;
+  return (const char *)out.data;
 }
 
 /*
Index: packet_id.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/packet_id.c,v
retrieving revision 1.11
diff -u -r1.11 packet_id.c
--- packet_id.c	21 Feb 2003 16:14:06 -0000	1.11
+++ packet_id.c	15 Mar 2003 22:42:03 -0000
@@ -124,7 +124,7 @@
     }
 
   buf_printf (&out, " ]");
-  return out.data;
+  return (char *)out.data;
 }
 
 /* initialize the packet_id_persist structure in a disabled state */
@@ -265,7 +265,7 @@
     }
 
   buf_printf (&out, " ]");
-  return out.data;
+  return (char *)out.data;
 }
 
 #ifdef PID_TEST
Index: reliable.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/reliable.c,v
retrieving revision 1.10
diff -u -r1.10 reliable.c
--- reliable.c	21 Feb 2003 16:14:06 -0000	1.10
+++ reliable.c	15 Mar 2003 22:42:03 -0000
@@ -500,4 +500,6 @@
 
 #endif
 
+#else
+static void dummy(void) {}
 #endif /* USE_CRYPTO && USE_SSL*/
Index: session_id.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/session_id.c,v
retrieving revision 1.4
diff -u -r1.4 session_id.c
--- session_id.c	21 Feb 2003 16:14:06 -0000	1.4
+++ session_id.c	15 Mar 2003 22:42:03 -0000
@@ -60,4 +60,6 @@
   return format_hex (sid->id, SID_SIZE, 0);
 }
 
+#else
+static void dummy(void) {}
 #endif /* USE_CRYPTO && USE_SSL*/
Index: socket.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/socket.c,v
retrieving revision 1.17
diff -u -r1.17 socket.c
--- socket.c	15 Mar 2003 07:18:00 -0000	1.17
+++ socket.c	15 Mar 2003 22:42:04 -0000
@@ -255,7 +255,7 @@
 	    {
 	      char command[256];
 	      struct buffer out;
-	      buf_set_write (&out, command, sizeof (command));
+	      buf_set_write (&out, (uint8_t *)command, sizeof (command));
 	      buf_printf (&out, "%s %s",
 			  sock->ipchange_command,
 			  print_sockaddr_ex (&usa->actual, true, " "));
@@ -356,5 +356,5 @@
 
       buf_printf (&out, "%d", port);
     }
-  return out.data;
+  return (char *)out.data;
 }
Index: ssl.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/ssl.c,v
retrieving revision 1.30
diff -u -r1.30 ssl.c
--- ssl.c	15 Mar 2003 07:18:00 -0000	1.30
+++ ssl.c	15 Mar 2003 22:42:05 -0000
@@ -228,7 +228,7 @@
 system_safe_string (char *cp)
 {
   int c;
-  while (c = *cp)
+  while ((c = *cp))
     {
       if (isalnum (c)
 	  || c == '/'
@@ -494,7 +494,7 @@
 
   printf ("Available TLS Ciphers,\n");
   printf ("listed in order of preference:\n\n");
-  while (cipher_name = SSL_get_cipher_list (ssl, priority++))
+  while ((cipher_name = SSL_get_cipher_list (ssl, priority++)))
     printf ("%s\n", cipher_name);
   printf ("\n");
 
@@ -2491,4 +2491,6 @@
   return out.data;
 }
 
+#else
+static void dummy(void) {}
 #endif /* USE_CRYPTO && USE_SSL*/
Index: thread.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/thread.c,v
retrieving revision 1.4
diff -u -r1.4 thread.c
--- thread.c	21 Feb 2003 16:14:06 -0000	1.4
+++ thread.c	15 Mar 2003 22:42:05 -0000
@@ -175,4 +175,6 @@
     }
 }
 
+#else
+static void dummy(void) {}
 #endif
Index: tun.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/tun.c,v
retrieving revision 1.25
diff -u -r1.25 tun.c
--- tun.c	15 Mar 2003 07:18:00 -0000	1.25
+++ tun.c	15 Mar 2003 22:42:05 -0000
@@ -609,7 +609,7 @@
 {
   struct strbuf sbuf;
   sbuf.len = len;
-  sbuf.buf = buf;
+  sbuf.buf = (char *)buf;
   return putmsg (tt->fd, NULL, &sbuf, 0) >= 0 ? sbuf.len : -1;
 }
 
@@ -620,7 +620,7 @@
   int f = 0;
 
   sbuf.maxlen = len;
-  sbuf.buf = buf;
+  sbuf.buf = (char *)buf;
   return getmsg (tt->fd, NULL, &sbuf, &f) >= 0 ? sbuf.len : -1;
 }
 

Re: [Openvpn-devel] New pre-1.3.3 beta

[Matthias A. <ma+...@dt...>]

On Sat, 15 Mar 2003, James Yonan wrote:

> If you have a chance, please test this beta.  I mostly use linux 2.4 for
> development, so I don't have much of a chance to test on linux 2.2 and
> non-linux OSes.

There are some warnings with Sun's compiler about uint8_t vs. char
clashes. Do you intend to silence the warnings or are you interested to
see them? I think they're harmless but annoying.

Other than that, it compiles on FreeBSD 4.8-RC x86 and Solaris 8 sparc
(32-bit mode), on the latter with Sun's compiler and gcc 2.95.

-- 
Matthias Andree

[Openvpn-devel] New pre-1.3.3 beta

[James Y. <ji...@yo...>]

If you have a chance, please test this beta.  I mostly use linux 2.4 for
development, so I don't have much of a chance to test on linux 2.2 and
non-linux OSes.

Since the last beta announcement on this list, there's been a bunch of changes
including build system portability fixes, --dev-name, and --mtu-disc.  The
latter gives access to a linux system call that allows some manual control
over how and whether Path MTU Discovery is implemented on the UDP socket.

You can download via CVS or from a tarball:

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.17.tar.gz

Change Log:
 
* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.

James

Re: [Openvpn-devel] [PATCH]: add config-variables to OpenVPN-1.3.2

[James Y. <ji...@yo...>]

Christian,

Rather than put a lot of scripting language infrastructure into OpenVPN's
config file parser, why not just use a shell script, i.e.:

  openvpn --dev-name vpn_${CUSTNO} \
          --port     5${CUSTNO} \
          --ifconfig 10.0.0.1 10.0.${CUSTNO}.1 \
          --dev-type tun \
          [ ... ]

After all, isn't this exactly the sort of problem that shell scripting
languages were supposed to solve?

James

ZLS Software GmbH <510...@t-...> said:

> Hi, Jim,
> 
> here is another one:
> 
> I've added variable-expandion to config-values and the keywords "set" and
"unset".
> With this technique you can easily split configuration of one peer across
two files:
> one with the specific and one with the common config values in a way that
can help to
> minimize the number of "configuration-knobs". 
> 
> 
> An example:
> 
>         /etc/openvpn/customer_123.conf:
> 
>         # specific configuration for customer #123
> 	set CUSTNO 123
>         config ./customers.common
> 
> 
>         /etc/openvpn/customer.common:
> 
>         # meta-configuration for all customers
>         dev-name vpn_$(CUSTNO)             # vpn_001 to vpn_255
>         port     5$(CUSTNO)                # 5001 to 5255
>         ifconfig 10.0.0.1 10.0.$(CUSTNO).1 # 10.0.001.1 to 10.0.255.1
>         dev-type tun                       # other stuff ...
>            .
>            .
>            .
> 
> These are the same variable-expansion routines I committed to the Snort-IDS
some time ago.
> 
> The syntax is  follows:
> 
>     set name value    define the variable "name" containing "value".
>     unset name        undefine the variable "name".
> 
>     $(name)           replace with the contents of variable "name".
> 
>     $(name:-default)  replace with the contents of the variable "name" or with
>                       "default" if "name" is undefined.
> 
>     $(name:?message)  replace with the contents of variable "name" or print out
>                       the error message "message" and exit.
> 
> 
> The next thing could be something like $(( expression or calculation )).
> 
> As before, the patch is quite young and certanly needs more testing :-)
> 
> 
> Regards,
> 
> Christian Lademann <lad...@zl...>
> 
> -- 
> *  Christian A. Lademann, ZLS Software GmbH          mailto:lad...@zl...
> *  ZLS Software GmbH
> *  Frankfurter Strasse 59       Postfach 1628             mailto:zl...@zl...
> *  D-65779 Kelkheim             D-65766 Kelkheim          http://www.zls.de
> *  Telefon +49-6195-9902-0      Telefax +49-6195-900600
> 
> 
> 



-- 

[Openvpn-devel] [PATCH]: add --dev-name - option to OpenVPN-1.3.2

[<510...@t-...>]

Hi, Jim,

attached I send you a patch for your kind review. It adds the capability to
change the devicename of the allocated tun device (so far on Linux, only).
For example:

    dev-type tun
    dev-name vpn_berlin

This helps administration a lot, at least from my point of view ;-)

Another bit I've changed is to make the ioctl(..., TUNSETIFF, ...) M_WARN
instead of M_ERR, because Linux 2.2 doesn't seem to support this ioctl.

The patch is quite young and certanly needs more testing.


Regards,

Christian Lademann <lad...@zl...>

-- 
*  Christian A. Lademann, ZLS Software GmbH          mailto:lad...@zl...
*  ZLS Software GmbH
*  Frankfurter Strasse 59       Postfach 1628             mailto:zl...@zl...
*  D-65779 Kelkheim             D-65766 Kelkheim          http://www.zls.de
*  Telefon +49-6195-9902-0      Telefax +49-6195-900600

[Openvpn-devel] [PATCH]: add config-variables to OpenVPN-1.3.2

[<510...@t-...>]

Hi, Jim,

here is another one:

I've added variable-expandion to config-values and the keywords "set" and "unset".
With this technique you can easily split configuration of one peer across two files:
one with the specific and one with the common config values in a way that can help to
minimize the number of "configuration-knobs". 


An example:

        /etc/openvpn/customer_123.conf:

        # specific configuration for customer #123
	set CUSTNO 123
        config ./customers.common


        /etc/openvpn/customer.common:

        # meta-configuration for all customers
        dev-name vpn_$(CUSTNO)             # vpn_001 to vpn_255
        port     5$(CUSTNO)                # 5001 to 5255
        ifconfig 10.0.0.1 10.0.$(CUSTNO).1 # 10.0.001.1 to 10.0.255.1
        dev-type tun                       # other stuff ...
           .
           .
           .

These are the same variable-expansion routines I committed to the Snort-IDS some time ago.

The syntax is  follows:

    set name value    define the variable "name" containing "value".
    unset name        undefine the variable "name".

    $(name)           replace with the contents of variable "name".

    $(name:-default)  replace with the contents of the variable "name" or with
                      "default" if "name" is undefined.

    $(name:?message)  replace with the contents of variable "name" or print out
                      the error message "message" and exit.


The next thing could be something like $(( expression or calculation )).

As before, the patch is quite young and certanly needs more testing :-)


Regards,

Christian Lademann <lad...@zl...>

-- 
*  Christian A. Lademann, ZLS Software GmbH          mailto:lad...@zl...
*  ZLS Software GmbH
*  Frankfurter Strasse 59       Postfach 1628             mailto:zl...@zl...
*  D-65779 Kelkheim             D-65766 Kelkheim          http://www.zls.de
*  Telefon +49-6195-9902-0      Telefax +49-6195-900600

Re: [Openvpn-devel] MTU

[James Y. <ji...@yo...>]

Jan Johansson <jan...@bi...> said:

> On Sun, 2003-02-23 at 17:10, James Yonan wrote:
> > Russ,
> > 
> > Have you tried the tracepath utility to attempt to measure the Path MTU?
> > 
> > Are the routers in the path properly forwarding ICMP code 3 (destination
> > unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit
set)?
> > 
> > Most MTU problems are caused by routers and firewalls which do not handle
> > these ICMP codes correctly, causing path MTU discovery to break.
> > 
> > The symptoms of this problem are as you show below...  Running an app over the
> >  tunnel works fine initially until the first large packet is sent, then the
> > app hangs.
> 
> I have a different theory here. 
> I am experiencing what I believe to be MTU problems, which have made me
> switch from RSA-auth to shared-key, just because the RSA auth stuff
> seems to trigger it also.

That's interesting, though it makes sense that if OpenVPN thinks the MTU is
higher than it really is, that this would occur.  That's because the SSL/TLS
handshake involves some relatively large exchanges (several K octets) that are
fragmented by OpenVPN to the udp-mtu packet size.  In this case, if OpenVPN
thinks that the udp-mtu is 1300 then it will attempt to send packets of
exactly 1300 octets in size, until it reaches the last fragment which will
probably be smaller.  So essentially, OpenVPN's current method of fragmenting
SSL/TLS handshakes guarantees that it will push the MTU parameter it's given
to the limit (udp_mtu in this case).

> My theory is that part of the problem lies in how the Linux kernel
> handles udp. I already got it into the README-file that openbsd firewall
> scrub rules will "kill" openvpn the same way it will kill Linux-nfs, but
> somehow other routers along the route probably do similar things.
> 
> One of the problems is that Linux sometimes (this is more a vague
> feeling and guesswork than the next part) sends fragments in reverse,
> meaning that the second half of the packet will be sent before the first
> part of a split packet. This is why, for instance, you can't netboot Sun
> boxes from Linux tftp-servers. The prom-code (bios sort of) in Sun
> machines can't reassemble fragged packets, at least not packets that
> arrive in reverse. This might make routers and firewalls along the way
> to behave badly, especially with the next part in mind:
> 
> The second part is that linux will tag all UDP (or at least all UDP from
> OpenVPN and NFS) as "Dont fragment". This is sort of ok. The problem is,
> they do get fragmented anyway. I can't prove that it isn't related to
> the transport in between me and the peers I have set up, but I find it
> likely that someone is fragmenting them anyway, perhaps even by the
> sending linux box itself. Since there is a *BSD box in between in my
> case, it will regard any fragmented UDP (or ip) packet with DF set as a
> bug, it silently and without mercy kills them. It may also mean that if
> the second half of a fragment comes first, with the DF flag on, it's
> even more suspicious.

Well actually what you are observing here is RFC 1191 ("Path MTU Discovery")
in action (or inaction as the case may be :)

http://www.faqs.org/rfcs/rfc1191.html

This process causes the DF bit to always be set on outgoing packets, but
assumes that other routers and firewalls in the path will play nice and return
an "ICMP need fragmentation but DF set message" if the packet is too big.

For linux at least, Path MTU discovery can be turned off for a given UDP
socket, causing all packets to be sent with DF cleared and no attempt by the
kernel to offer fragmentation or defragmentation services.

I already have a feature in the CVS under branch MTU_EXPERIMENTAL which gives
command line control over the Path MTU discovery settings on the UDP socket.
 
> As far as I can guess, this probably goes for lots of ISP's and other
> hardware involved in the transport of ip packets between me and my
> peers. 
> For some reason, I seem to get the feeling that RSA negotiation doesn't
> follow the udp-mtu (or tun-mtu-derived udp-mtu) settings, and send too
> large packets, and them getting fragmented leads to me having to revert
> back to precalced secrets.

I will check this, but I doubt that SSL/TLS could go over the udp-mtu (I would
expect lots of errors and/or assertion crashes in OpenVPN if this was the
case).  It seems more likely to me that the udp-mtu might be too large.

> It also means that I get the same error as you've described in the last
> mails. I have a remote-backup-over-rsync that is protected by both
> OpenVPN and ssh inside of that. It goes some 256k and then dies. It dies
> reliably every time, and almost always on the same byte, some 240506
> bytes into the RSYNC-stream. (whatever, the number isn't important).
> If I forego the openvpn and ssh straight into the machine, the rsync
> doesn't die.

I am considering adding a fragmenting feature to OpenVPN where it would
fragment packets using the very efficient RFC 815 algorithm in the event that
it received a packet on the TUN/TAP device that was bigger than the udp_mtu
could accomodate.  In essence, this feature would do fragmentation explicitly
rather than depending on the OS to do the fragmentation correctly.

See http://www.faqs.org/rfcs/rfc815.html for more info.

Matthias Andree suggested that OpenVPN might generate its own "Fragmentation
needed but DF set" ICMP messages and return them to the TUN/TAP device in this
case.

Adding to this, OpenVPN could set the udp_mtu dynamically, based on its
history of successfully transmitting packets of a range of sizes to its peer.

These changes, when taken as a whole, would take OpenVPN down the path of
becoming more like an intelligent router, and move away from the model of
relying on the OS to manage the transport protocol.
 
> So there definately exist some sort of issue with MTU's, which I can't
> seem to solve correctly. The question is, does the SSL-stuff really
> check the mtu's, and can you make the linux kernel not put DF's on UDP
> packets? (since they are ip packets, they can be fragmented and
> reassembled like any other packets I guess)
> 
> "man 7 udp" on RedHat says:
> 
> UDP fragments a packet when its total length  exceeds  the
>        interface MTU (Maximum Transmission Unit).  A more network
>        friendly alternative is  to  use  path  MTU  discovery  as
>        described in the IP_PMTU_DISCOVER section of ip(7).
> 
> From this text, I can't figure out why Linux puts DF on the packets,
> which tcpdump clearly shows it does.
> man 7 ip, udp, socket and friends have never shown me a way to stop DF,
> also none of them mention why Linux puts it there in the first place.

This code will stop Path MTU Discovery and the setting of the DF bit on a
particular UDP socket:

int mtu_type = IP_PMTUDISC_DONT;
setsockopt(udp_socket, SOL_IP, IP_MTU_DISCOVER, &mtu_type, sizeof (mtu_type)));

I know it works on linux, but I'm not sure about other OSes.

James

Re: [Openvpn-devel] MTU

[Jan J. <jan...@bi...>]

On Sun, 2003-02-23 at 17:10, James Yonan wrote:
> Russ,
>=20
> Have you tried the tracepath utility to attempt to measure the Path MTU?
>=20
> Are the routers in the path properly forwarding ICMP code 3 (destination
> unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bi=
t set)?
>=20
> Most MTU problems are caused by routers and firewalls which do not handle
> these ICMP codes correctly, causing path MTU discovery to break.
>=20
> The symptoms of this problem are as you show below...  Running an app ove=
r the
>  tunnel works fine initially until the first large packet is sent, then t=
he
> app hangs.

I have a different theory here.=20
I am experiencing what I believe to be MTU problems, which have made me
switch from RSA-auth to shared-key, just because the RSA auth stuff
seems to trigger it also.

My theory is that part of the problem lies in how the Linux kernel
handles udp. I already got it into the README-file that openbsd firewall
scrub rules will "kill" openvpn the same way it will kill Linux-nfs, but
somehow other routers along the route probably do similar things.

One of the problems is that Linux sometimes (this is more a vague
feeling and guesswork than the next part) sends fragments in reverse,
meaning that the second half of the packet will be sent before the first
part of a split packet. This is why, for instance, you can't netboot Sun
boxes from Linux tftp-servers. The prom-code (bios sort of) in Sun
machines can't reassemble fragged packets, at least not packets that
arrive in reverse. This might make routers and firewalls along the way
to behave badly, especially with the next part in mind:

The second part is that linux will tag all UDP (or at least all UDP from
OpenVPN and NFS) as "Dont fragment". This is sort of ok. The problem is,
they do get fragmented anyway. I can't prove that it isn't related to
the transport in between me and the peers I have set up, but I find it
likely that someone is fragmenting them anyway, perhaps even by the
sending linux box itself. Since there is a *BSD box in between in my
case, it will regard any fragmented UDP (or ip) packet with DF set as a
bug, it silently and without mercy kills them. It may also mean that if
the second half of a fragment comes first, with the DF flag on, it's
even more suspicious.

As far as I can guess, this probably goes for lots of ISP's and other
hardware involved in the transport of ip packets between me and my
peers.=20
For some reason, I seem to get the feeling that RSA negotiation doesn't
follow the udp-mtu (or tun-mtu-derived udp-mtu) settings, and send too
large packets, and them getting fragmented leads to me having to revert
back to precalced secrets.

It also means that I get the same error as you've described in the last
mails. I have a remote-backup-over-rsync that is protected by both
OpenVPN and ssh inside of that. It goes some 256k and then dies. It dies
reliably every time, and almost always on the same byte, some 240506
bytes into the RSYNC-stream. (whatever, the number isn't important).
If I forego the openvpn and ssh straight into the machine, the rsync
doesn't die.

So there definately exist some sort of issue with MTU's, which I can't
seem to solve correctly. The question is, does the SSL-stuff really
check the mtu's, and can you make the linux kernel not put DF's on UDP
packets? (since they are ip packets, they can be fragmented and
reassembled like any other packets I guess)

"man 7 udp" on RedHat says:

UDP fragments a packet when its total length  exceeds  the
       interface MTU (Maximum Transmission Unit).  A more network
       friendly alternative is  to  use  path  MTU  discovery  as
       described in the IP_PMTU_DISCOVER section of ip(7).

=46rom this text, I can't figure out why Linux puts DF on the packets,
which tcpdump clearly shows it does.
man 7 ip, udp, socket and friends have never shown me a way to stop DF,
also none of them mention why Linux puts it there in the first place.
8-(

--=20
Jan Johansson
IT Coordinator

jan...@bi...

---------------------------------------------------------------------=20
BioMat System AB
Klarabergsgatan 37, III
S-111 21 STOCKHOLM
SWEDEN

Phone: +46-(0)8-23 35 00
Fax: +46-(0)70-387 39 52
---------------------------------------------------------------------
THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR
ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS
PRIVILIGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
LAW. IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH
in...@bi...
---------------------------------------------------------------------

Re: [Openvpn-devel] MTU

[James Y. <ji...@yo...>]

Aaron Sethman <and...@ra...> said:

> 
> On Sat, 22 Feb 2003, James Yonan wrote:
> >  This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1,
> > where the openvpn daemon would essentially restart if the MTU size changed.
> > This would be effective if path MTU changes are infrequent but still creates
> > problems when --user/--group nobody is used, since the openvpn daemon will
> > lack sufficient privilege to reopen and re-ifconfig the TUN/TAP device.
> >
> 
> One option to deal with the --user/--group stuff is to keep a parent
> process running as root with the real work being done by the child with
> dropped privledges.  The parent just waits around waiting for a signal
> regarding the child, and then let the parent start a new child.  Of course
> if you are going to go down the IPC route, there is other fun things you
> can do like passing sockets via AF_UNIX sockets.  It really depends on how
> you want to do it.
> 
> Regards,
> 
> Aaron

Aaron,

Actually OpenVPN has some of this right now.  If built with pthread support,
it will negotiate SSL/TLS keys in a background thread and communicate with the
foreground via a pair of AF_UNIX sockets (this helps tunnel latency a lot). 
The split-privilege model is a good idea, and has been implemented with some
success in OpenSSH, but is arguably overkill for OpenVPN given that up till
now, OpenVPN has been able to do all of its privileged work at startup, then
downgrade to nobody with little loss of flexibility.  IMHO, the alternative is
more complex and prone to becoming a bug-magnet.

James

Re: [Openvpn-devel] MTU

[James Y. <ji...@yo...>]

Russ,

Have you tried the tracepath utility to attempt to measure the Path MTU?

Are the routers in the path properly forwarding ICMP code 3 (destination
unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit set)?

Most MTU problems are caused by routers and firewalls which do not handle
these ICMP codes correctly, causing path MTU discovery to break.

The symptoms of this problem are as you show below...  Running an app over the
 tunnel works fine initially until the first large packet is sent, then the
app hangs.

Right now OpenVPN relies on Path MTU Discovery (a service provided by the
kernel) to get the MTU right, so in the short run the best thing you can do is
to try to get Path MTU working.

You could also try to lower --udp-mtu by trial and error until you find
something that works (essentially a manual approach to MTU discovery).

If you are running tunnels over tunnels, the lower-level (more nested) tunnels
will need lower --udp-mtu settings. 

Longer-term, I hope to put some intelligence in OpenVPN to do this automatically.

James

R P Herrold <he...@ow...> said:

> On Sat, 22 Feb 2003, James Yonan wrote:
> 
> > Recently I've been taking a new look at MTU issues.  It seems that some people
> > are having problems lately that are related to MTU or PMTU discovery.
> > 
> > I was trying to think up some ways to make OpenVPN's handling of MTU a bit
> > less opaque, more automatic, and also give more manual control to those who
> > know what they're doing.
> 
> If it is any help, I can replicate the error on demand.  Coing 
> frm my host 'couch', through two openvpn legs, once of which 
> is running encryption, the other not, I get:
> 
> [root@couch ORC]# scp ftp.victim.lan:/etc/ORC/* .
> ro...@ft...'s password:
> Permission denied, please try again.
> ro...@ft...'s password:
> ORCsetPXE              0% |                             |     
> 0       --:-- ETAKilled by signal 2.
> 
>    **** it is locked up and hung here.
> 
> [root@couch ORC]# ssh ftp.victim.lan
> ro...@ft...'s password:
> Last login: Sat Feb 22 15:21:51 2003 from router.victim.lan
> [root@ftp root]# cd /etc/ORC
> [root@ftp ORC]# scp * couch.basement.lan:/etc/ORC
> The authenticity of host 'couch.basement.lan (10.16.33.101)' can't be
established.
> RSA1 key fingerprint is 38:d4:69:9e:cb:96:81:68:d2:2b:6b:6f:b9:33:c2:39.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'couch.basement.lan,10.16.33.101' 
> (RSA1) to the list of known hosts.
> ro...@co...'s password:
> ORCsetPXE            100% |*****************************|  3032       00:00
> ORCsetPXE~           100% |*****************************|  2955       00:00
> installCDrc          100% |*****************************|   234       00:00
> installCDrc-80       100% |*****************************|   227       00:00
> installCDrc-8094     100% |*****************************|   234       00:00
> installCDrc-LTSP     100% |*****************************|   188       00:00
> installCDrc-template 100% |*****************************|   565       00:00
> [root@ftp ORC]#
> [root@ftp ORC]# dmesg
> Linux version 2.4.18-17.8.0 (bhc...@da...) 
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue 
> Oct 8 13:51:08 EDT 2002
> 
>      **** it is locked up and hung here.
> 
> 
> going to another host in that same remote subnet, but behind 
> the router I also get:
> 
> (from 10.16.33.101 - host: couch )
> 
> bash-2.05b$ ssh ftp.victim.lan
> he...@ft...'s password:
> [herrold@ftp herrold]$ dmesg
> Linux version 2.4.18-17.8.0 (bhc...@da...) 
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Oct 8 13:51:08
EDT 2002
> 
>       **** it is locked up and hung here.
> 
> 
> lots of these on ftp.victim.lan:
> 
> ISO 9660 Extensions: RRIP_1991A
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> ICMP: 10.16.33.101: fragmentation needed and DF set.
> 
> but no 'noise; attributable to the tun device or openvpn in 
> the router:
> 
> 
> eth0: Promiscuous mode enabled.
> device eth0 entered promiscuous mode
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> divert: not allocating divert_blk for non-ethernet device tun0ip_conntrack
(2047 buckets, 16376 max)
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> TCP: Treason uncloaked! Peer 10.1.2.30:515/692 shrinks window
2141696489:2141697513. Repaired.
> divert: no divert_blk to free, tun0 not ethernet
> divert: not allocating divert_blk for non-ethernet device tun0
> [herrold@router herrold]$ 
> 
>    ...   10.1.2.30 is a printservice device, not relebant 
> here, I think
> 
> =================
> 
> General layout
> 
> 10.16.33.101 --- clear tunnel to hub -- 
>   hub in the internet-- encrypted tunnel to hub -- 10.0.1.x 
> 
> The subnet 'victim.lan' is doubly masg'd -- behind two
> iptables based NATting.  This may be affecting things.
> 
> 
>   0.0.0.0 --- public-10.1.2.x --- 10.1.2.y-10.250.0.x --- 
>  internet            |        dmz          |         victim.lan
>                    NAT 1                 NAT 2
> 
> -- Russ Herrold
> 



-- 

Re: [Openvpn-devel] MTU

[Aaron S. <and...@ra...>]

On Sat, 22 Feb 2003, James Yonan wrote:
>  This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1,
> where the openvpn daemon would essentially restart if the MTU size changed.
> This would be effective if path MTU changes are infrequent but still creates
> problems when --user/--group nobody is used, since the openvpn daemon will
> lack sufficient privilege to reopen and re-ifconfig the TUN/TAP device.
>

One option to deal with the --user/--group stuff is to keep a parent
process running as root with the real work being done by the child with
dropped privledges.  The parent just waits around waiting for a signal
regarding the child, and then let the parent start a new child.  Of course
if you are going to go down the IPC route, there is other fun things you
can do like passing sockets via AF_UNIX sockets.  It really depends on how
you want to do it.

Regards,

Aaron

[Openvpn-devel] MTU

[James Y. <ji...@yo...>]

Recently I've been taking a new look at MTU issues.  It seems that some people
are having problems lately that are related to MTU or PMTU discovery.

I was trying to think up some ways to make OpenVPN's handling of MTU a bit
less opaque, more automatic, and also give more manual control to those who
know what they're doing.

I have some preliminary code in the CVS (under branch MTU_EXPERIMENTAL) that
adds an option (--mtu-disc) that gives manual control over whether path MTU
discovery is performed on the UDP link.  I also borrowed some code from
tracepath to print the discovered PMTU size on UDP read/write errors. 
Unfortunately, I'm not sure whether this code will work on non-Linux OSes. 
See mtu.c for more info.

I've also considered ways of making OpenVPN's MTU calculation more automatic
without relying on PMTU which is often broken due to over-restrictive
firewalls in the path that block ICMP messages.  PMTU also lacks DoS
resilience.  One way might be to do our own PMTU discovery by transmitting
various sized packets over the UDP channel and having the remote peer report
back on the largest packet it received.  One problem is that MTU size could
change during a session, necessitating a re-ifconfig of the TUN/TAP device,
which may not be possible on some platforms and breaks --user/--group nobody.
 This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1,
where the openvpn daemon would essentially restart if the MTU size changed. 
This would be effective if path MTU changes are infrequent but still creates
problems when --user/--group nobody is used, since the openvpn daemon will
lack sufficient privilege to reopen and re-ifconfig the TUN/TAP device.

Comments?

James

Re: [Openvpn-devel] First half of macro-vs-function hacks (was: Pre-1.3.3 beta available for testing)

[Matthias A. <ma+...@dt...>]

[resend, first send went to James but not the list]

Hi,

after the merge, I got some rejects for minor differences, usually
coding style.

My coding style is: add parentheses without space for function and macro
calls, add a space for control constructs:

printf("something");
if (test == true) { ... }
while (1) { munch_cpu(); }

On Wed, 19 Feb 2003, James Yonan wrote:

> Still to do:
> (1) _* name renaming

I'm not pressing towards this before 1.3.3, if 1.3.3 ships with the
_names in place, that's fine with me.

> (2) merge your warnings quencher #1
> (3) the removal of install-sh seems to have broken rpmbuild -tb [tarball]

I don't have rpmbuild (rpm 3.0.x here, SuSE Linux 8.1), but I can
successfully build a binary rpm by: (the same i586 target is used for
any other SuSE Linux 8.1 package)

make dist
rpm --target=i586 -tb openvpn-1.3.2.10.tar.gz

> (4) reconcile macro vararg approaches

Leaving the acinclude.m4/configure.ac aside for a moment, how about this
patch to reduce special casing in the preprocessor, rename _msg to x_msg
and fix warnings?

# error.h |   25 ++++++++++++-------------
# error.c |   20 ++++++++------------
# 2 files changed, 20 insertions(+), 25 deletions(-)

Index: error.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.h,v
retrieving revision 1.9
diff -u -r1.9 error.h
--- error.h	20 Feb 2003 05:02:38 -0000	1.9
+++ error.h	20 Feb 2003 12:03:52 -0000
@@ -34,9 +34,9 @@
  * These globals should not be accessed directly,
  * but rather through macros or inline functions defined below.
  */
-extern int _debug_level;
-extern int _cs_info_level;
-extern int _cs_verbose_level;
+extern unsigned int _debug_level;
+extern unsigned int _cs_info_level;
+extern unsigned int _cs_verbose_level;
 
 extern int msg_line_num;
 
@@ -85,25 +85,24 @@
 
 #if defined(HAVE_VARARG_MACROS_ISO)
 #define HAVE_VARARG_MACROS
-#define msg(flags, ...) do { if (MSG_TEST(flags)) _msg((flags), __VA_ARGS__); } while (false)
+#define msg(flags, ...) do { if (MSG_TEST(flags)) x_msg((flags), __VA_ARGS__); } while (false)
 #elif defined(HAVE_VARARG_MACROS_GCC)
 #define HAVE_VARARG_MACROS
-#define msg(flags, args...) do { if (MSG_TEST(flags)) _msg((flags), args); } while (false)
-#endif
-
-#ifdef HAVE_VARARG_MACROS
-void _msg (unsigned int flags, const char *format, ...); /* should be called via msg above */
+#define msg(flags, args...) do { if (MSG_TEST(flags)) x_msg((flags), args); } while (false)
 #else
-void msg (unsigned int flags, const char *format, ...);
+#define x_msg msg
+#undef HAVE_VARARG_MACROS
 #endif
 
+void x_msg (unsigned int flags, const char *format, ...);
+
 /*
  * Function prototypes
  */
 
 void error_reset ();
-void set_check_status (int info_level, int verbose_level);
-void set_debug_level (int level);
+void set_check_status (unsigned int info_level, unsigned int verbose_level);
+void set_debug_level (unsigned int level);
 void set_mute_cutoff (int cutoff);
 
 /*
@@ -119,7 +118,7 @@
 /* Inline functions */
 
 static inline bool
-check_debug_level (int level)
+check_debug_level (unsigned int level)
 {
   return (level & M_DEBUG_LEVEL) < _debug_level;
 }
Index: error.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.c,v
retrieving revision 1.11
diff -u -r1.11 error.c
--- error.c	20 Feb 2003 05:02:38 -0000	1.11
+++ error.c	20 Feb 2003 12:03:52 -0000
@@ -39,9 +39,9 @@
 #include "memdbg.h"
 
 /* Globals */
-int _debug_level;
-int _cs_info_level;
-int _cs_verbose_level;
+unsigned int _debug_level;
+unsigned int _cs_info_level;
+unsigned int _cs_verbose_level;
 
 /* Mute state */
 static int mute_cutoff;
@@ -55,7 +55,7 @@
 static FILE *msgfp;
 
 void
-set_debug_level (int level)
+set_debug_level (unsigned int level)
 {
   _debug_level = level;
 }
@@ -87,7 +87,7 @@
 }
 
 void
-set_check_status (int info_level, int verbose_level)
+set_check_status (unsigned int info_level, unsigned int verbose_level)
 {
   _cs_info_level = info_level;
   _cs_verbose_level = verbose_level;
@@ -113,11 +113,7 @@
 
 int msg_line_num;
 
-#ifdef HAVE_VARARG_MACROS
-void _msg (unsigned int flags, const char *format, ...)
-#else
-void msg (unsigned int flags, const char *format, ...)
-#endif
+void x_msg (unsigned int flags, const char *format, ...)
 {
   va_list arglist;
   int level;
@@ -187,8 +183,8 @@
   if (flags & M_SSL)
     {
       int nerrs = 0;
-      int err;
-      while (err = ERR_get_error ())
+      unsigned long err;
+      while ((err = ERR_get_error ()))
 	{
 	  snprintf (m2, ERR_BUF_SIZE, "%s: %s", m1, ERR_error_string (err, NULL));
 	  SWAP;

> Question: What's the best way to generate a tarball that has ./configure 
> already generated, so that openvpn can be built and installed with the 
> usual "./configure && make && make install"?

The canonical way is:

make distcheck

If you're absolutely confident it works, because you just changed
documentation, "make dist" will suffice.

-- 
Matthias Andree

Re: [Openvpn-devel] First half of macro-vs-function hacks (was: Pre-1.3.3 beta available for testing)

[James Y. <ji...@yo...>]

Matthias,

Okay, I just put a bunch of stuff in the CVS:

(1) your earlier patch (pre-variable argument macro fix)
(2) some warning removals
(3) my own vararg stuff (we'll have to reconcile our versions)
(4) removed generated files from CVS
(5) fixed --disable-crypto
(6) a better undefined TUNNEWPPA error for Solaris

Still to do:
(1) _* name renaming
(2) merge your warnings quencher #1
(3) the removal of install-sh seems to have broken rpmbuild -tb [tarball]
(4) reconcile macro vararg approaches

Question: What's the best way to generate a tarball that has ./configure 
already generated, so that openvpn can be built and installed with the 
usual "./configure && make && make install"?

James

On Wed, 19 Feb 2003, Matthias Andree wrote:

> Jim,
> 
> this is the configure.ac part of the variadic macro test patch, it seems
> to work OK and cache the results.
> 
> I have added also some unrelated AC_CACHE_SAVE (supported since autoconf
> 2.13) to checkpoint the cache should some later test fail, so the user
> can more quickly pick up when she typed "./configure -C".
> 
> This patch is against my previous one, so if it fails, try patch -F1 or
> -F2 to narrow the context patch looks at. If that doesn't help, I can
> send the whole file or a patch against current CVS.
> 
> Feel free to try it. To my astonishment, the SUNpro WorkShop compiler
> seems to know ISO C99 but not the GCC-style variadic macros. I'll
> investigate some more and might refine this test.
> 
> diff -u configure.ac configure.ac
> --- configure.ac	19 Feb 2003 15:04:00 -0000
> +++ configure.ac	19 Feb 2003 20:39:54 -0000
> @@ -148,6 +148,38 @@
>  AC_TYPE_UID_T
>  AC_HEADER_TIME
>  
> +dnl See if the compiler supports variadic macros
> +dnl GCC-style
> +AC_MSG_CHECKING(if your preprocessor supports GCC-style variadic macros)
> +AC_CACHE_VAL(openvpn_cv_c_varmac_gcc,
> +AC_COMPILE_IFELSE([[
> +		   #include <stdio.h>
> +		   #define mymac(first, second...) printf(first, ## second)
> +		   main() { mymac("%s", "test"); }
> +		   ]],
> +		   [openvpn_cv_c_varmac_gcc=yes],
> +		   [openvpn_cv_c_varmac_gcc=no]))
> +AC_MSG_RESULT($openvpn_cv_c_varmac_gcc)
> +if test $openvpn_cv_c_varmac_gcc = yes ; then
> +    AC_DEFINE(OPENVPN_VARMAC_GCC, [1], [Define to 1 if your preprocessor supports GCC-style variadic macros.])
> +fi
> +
> +dnl ISO C99-style
> +AC_MSG_CHECKING(if your preprocessor supports ISO C99 variadic macros)
> +AC_CACHE_VAL(openvpn_cv_c_varmac_isoc99,
> +AC_COMPILE_IFELSE([[
> +		   #include <stdio.h>
> +		   #define mymac(first, ...) printf(first, __VA_ARGS__)
> +		   main() { mymac("%s", "test"); }
> +		   ]],
> +		   [openvpn_cv_c_varmac_isoc99=yes],
> +		   [openvpn_cv_c_varmac_isoc99=no]))
> +AC_MSG_RESULT($openvpn_cv_c_varmac_isoc99)
> +if test $openvpn_cv_c_varmac_isoc99 = yes ; then
> +    AC_DEFINE(OPENVPN_VARMAC_ISOC99, [1], [Define to 1 if your preprocessor supports ISO C99 variadic macros.])
> +fi
> +AC_CACHE_SAVE
> +
>  dnl Check for more header files.
>  AC_HEADER_SYS_WAIT
>  AC_CHECK_HEADERS(sys/time.h)
> @@ -184,6 +216,7 @@
>  AC_CHECK_HEADERS(netdb.h)
>  AC_CHECK_HEADERS(sys/uio.h)
>  AC_CHECK_HEADERS(linux/if_tun.h)
> +AC_CACHE_SAVE
>  
>  dnl check that in_addr_t is defined
>  AC_CHECK_TYPE(
> @@ -220,6 +253,7 @@
>  	[AC_DEFINE(HAVE_IOVEC, 1, [struct iovec needed for IPv6 support])],
>  	[],
>  	[#include "syshead.h"])
> +AC_CACHE_SAVE
>  
>  dnl check for other types
>  TYPE_SOCKLEN_T
> @@ -257,6 +291,7 @@
>  AC_CHECK_FUNCS(readv)
>  AC_CHECK_FUNCS(writev)
>  AC_CHECK_FUNCS(setsockopt)
> +AC_CACHE_SAVE
>  
>  dnl Required library functions
>  AC_FUNC_MEMCMP
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 

[Openvpn-devel] warnings quencher #1

[Matthias A. <ma+...@dt...>]

against current CVS:

Index: thread.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/thread.h,v
retrieving revision 1.3
diff -u -r1.3 thread.h
--- thread.h	25 Jun 2002 06:56:16 -0000	1.3
+++ thread.h	19 Feb 2003 21:21:03 -0000
@@ -136,6 +136,8 @@
 static inline void
 work_thread_create (void *(*start_routine) (void *), void* arg)
 {
+    (void)start_routine;
+    (void)arg;
 }
 
 static inline void
@@ -146,16 +148,19 @@
 static inline void
 mutex_lock (int type)
 {
+    (void)type;
 }
 
 static inline void
 mutex_unlock (int type)
 {
+    (void)type;
 }
 
 static inline void
 mutex_cycle (int type)
 {
+    (void)type;
 }
 
 #endif /* USE_PTHREAD */

Second half of variadic macro fix (was: [Openvpn-devel] Pre-1.3.3 beta available for testing)

[Matthias A. <ma+...@dt...>]

Dear Jim,

this second patch completes the varargs stuff. Tested on all machines I
listed last time, and SUNpro 6 is very happy with the ISO C99 stuff and
uses the macro (rather than the function). I tried to force the function
underneath gcc 2.95 (edited config.cache, ran ./config.status --recheck,
./config.status, remade stuff), seems fine here.

Please give it a try (sorry for listing the files in the wrong reading
order, shell globbed .c before .h).

Cheers,
Matthias

Index: error.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.c,v
retrieving revision 1.10
diff -u -r1.10 error.c
--- error.c	9 Dec 2002 15:40:34 -0000	1.10
+++ error.c	19 Feb 2003 21:13:27 -0000
@@ -113,10 +113,24 @@
 
 int msg_line_num;
 
-void
-_msg (unsigned int flags, const char *format, ...)
+#if !MSGMACRO
+void msg(unsigned int flags, const char *format, ...) {
+    va_list ap;
+    va_start(ap, format);
+    _msg(flags, format, ap);
+    va_end(ap);
+}
+#endif
+
+#if MSGMACRO
+void _msg (unsigned int flags, const char *format, ...)
+#else
+void _msg (unsigned int flags, const char *format, va_list arglist)
+#endif
 {
+#if MSGMACRO
   va_list arglist;
+#endif
   int level;
   char msg1[ERR_BUF_SIZE];
   char msg2[ERR_BUF_SIZE];
@@ -161,9 +175,13 @@
   m1 = msg1;
   m2 = msg2;
 
+#if MSGMACRO
   va_start (arglist, format);
+#endif
   vsnprintf (m1, ERR_BUF_SIZE, format, arglist);
+#if MSGMACRO
   va_end (arglist);
+#endif
 
   if ((flags & M_ERRNO) && e)
     {
@@ -180,7 +198,7 @@
     {
       int nerrs = 0;
       int err;
-      while (err = ERR_get_error ())
+      while ((err = ERR_get_error ()))
 	{
 	  snprintf (m2, ERR_BUF_SIZE, "%s: %s", m1, ERR_error_string (err, NULL));
 	  SWAP;
Index: error.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/error.h,v
retrieving revision 1.8
diff -u -r1.8 error.h
--- error.h	9 Dec 2002 15:40:34 -0000	1.8
+++ error.h	19 Feb 2003 21:13:27 -0000
@@ -76,11 +76,26 @@
  */
 #define LOGLEV(log_level, mute_level, other) (((log_level)-1) | ENCODE_MUTE_LEVEL(mute_level) | other)
 
+#if OPENVPN_VARMAC_ISOC99
+#define msg(flags, ...) \
+    do { if (((flags) & M_DEBUG_LEVEL) < _debug_level || ((flags) & M_FATAL)) \
+    _msg((flags), __VA_ARGS__); } while (false)
+#define MSGMACRO 1
+#elif OPENVPN_VARMAC_GCC
 #define msg(flags, args...) \
     do { if (((flags) & M_DEBUG_LEVEL) < _debug_level || ((flags) & M_FATAL)) \
     _msg((flags), args); } while (false)
+#define MSGMACRO 1
+#else
+#define MSGMACRO 0
+    void msg(unsigned int flags, const char *format, ...);
+#endif
 
-void _msg (unsigned int flags, const char *format, ...); /* should be called via msg above */
+#if MSGMACRO
+void _msg(unsigned int flags, const char *format, ...); /* should be called via msg above */
+#else
+void _msg(unsigned int flags, const char *format, va_list ap);
+#endif
 
 void error_reset ();
 void set_check_status (int info_level, int verbose_level);

[Openvpn-devel] First half of macro-vs-function hacks (was: Pre-1.3.3 beta available for testing)

[Matthias A. <ma+...@dt...>]

Jim,

this is the configure.ac part of the variadic macro test patch, it seems
to work OK and cache the results.

I have added also some unrelated AC_CACHE_SAVE (supported since autoconf
2.13) to checkpoint the cache should some later test fail, so the user
can more quickly pick up when she typed "./configure -C".

This patch is against my previous one, so if it fails, try patch -F1 or
-F2 to narrow the context patch looks at. If that doesn't help, I can
send the whole file or a patch against current CVS.

Feel free to try it. To my astonishment, the SUNpro WorkShop compiler
seems to know ISO C99 but not the GCC-style variadic macros. I'll
investigate some more and might refine this test.

diff -u configure.ac configure.ac
--- configure.ac	19 Feb 2003 15:04:00 -0000
+++ configure.ac	19 Feb 2003 20:39:54 -0000
@@ -148,6 +148,38 @@
 AC_TYPE_UID_T
 AC_HEADER_TIME
 
+dnl See if the compiler supports variadic macros
+dnl GCC-style
+AC_MSG_CHECKING(if your preprocessor supports GCC-style variadic macros)
+AC_CACHE_VAL(openvpn_cv_c_varmac_gcc,
+AC_COMPILE_IFELSE([[
+		   #include <stdio.h>
+		   #define mymac(first, second...) printf(first, ## second)
+		   main() { mymac("%s", "test"); }
+		   ]],
+		   [openvpn_cv_c_varmac_gcc=yes],
+		   [openvpn_cv_c_varmac_gcc=no]))
+AC_MSG_RESULT($openvpn_cv_c_varmac_gcc)
+if test $openvpn_cv_c_varmac_gcc = yes ; then
+    AC_DEFINE(OPENVPN_VARMAC_GCC, [1], [Define to 1 if your preprocessor supports GCC-style variadic macros.])
+fi
+
+dnl ISO C99-style
+AC_MSG_CHECKING(if your preprocessor supports ISO C99 variadic macros)
+AC_CACHE_VAL(openvpn_cv_c_varmac_isoc99,
+AC_COMPILE_IFELSE([[
+		   #include <stdio.h>
+		   #define mymac(first, ...) printf(first, __VA_ARGS__)
+		   main() { mymac("%s", "test"); }
+		   ]],
+		   [openvpn_cv_c_varmac_isoc99=yes],
+		   [openvpn_cv_c_varmac_isoc99=no]))
+AC_MSG_RESULT($openvpn_cv_c_varmac_isoc99)
+if test $openvpn_cv_c_varmac_isoc99 = yes ; then
+    AC_DEFINE(OPENVPN_VARMAC_ISOC99, [1], [Define to 1 if your preprocessor supports ISO C99 variadic macros.])
+fi
+AC_CACHE_SAVE
+
 dnl Check for more header files.
 AC_HEADER_SYS_WAIT
 AC_CHECK_HEADERS(sys/time.h)
@@ -184,6 +216,7 @@
 AC_CHECK_HEADERS(netdb.h)
 AC_CHECK_HEADERS(sys/uio.h)
 AC_CHECK_HEADERS(linux/if_tun.h)
+AC_CACHE_SAVE
 
 dnl check that in_addr_t is defined
 AC_CHECK_TYPE(
@@ -220,6 +253,7 @@
 	[AC_DEFINE(HAVE_IOVEC, 1, [struct iovec needed for IPv6 support])],
 	[],
 	[#include "syshead.h"])
+AC_CACHE_SAVE
 
 dnl check for other types
 TYPE_SOCKLEN_T
@@ -257,6 +291,7 @@
 AC_CHECK_FUNCS(readv)
 AC_CHECK_FUNCS(writev)
 AC_CHECK_FUNCS(setsockopt)
+AC_CACHE_SAVE
 
 dnl Required library functions
 AC_FUNC_MEMCMP

Re: [Openvpn-devel] Pre-1.3.3 beta available for testing

[Matthias A. <ma+...@dt...>]

On Wed, 19 Feb 2003, James Yonan wrote:

> > Please also note that _* names are reserved name space. Don't use them
> > for your functions if you can avoid it, for portability -- they might
> > screw some linker.
> 
> Are __* names reserved?  What's the recommended form for naming "private"  
> variables (I'm coming from C++/Python where _* names are a common naming
> style for class-private variables to avoid collisions with similarly named
> public member functions)?

Mostly anything that starts with _ is reserved. There are some
exceptions, you may name auto variables _[a-z]*, but not functions.

You could use x_ as prefix though.

I've googled a little and found
http://oakroadsystems.com/tech/c-predef.htm#Groups to be a very useful
resource (and it's concise as well).

-- 
Matthias Andree

Re: [Openvpn-devel] Pre-1.3.3 beta available for testing

[James Y. <ji...@yo...>]

> There were more warnings that I haven't reported because I think they
> didn't warrant fixes at this time, some "unused parameter" warnings. Try
> 
> make clean
> make CFLAGS="-W -Wall"
> 
> to see more warnings :-)

Yes, also ./configure --enable-strict does something like this.

Most of the warnings that are left (such as unused function call 
parameters, unused static functions, etc.) would create more obfuscation 
if they were fixed.  In principle, warnings should direct your attention 
to possible bugs or things that need to be cleaned up, but I don't believe 
in making the code harder to read just to fix a warning.  For example, I 
wouldn't bracket a static function with a complex #if just to 
eliminate warnings about its non-use (as in tun.c).

> I have no profiles, sorry, neither of the function call overhead
> incurred or avoided, nor of the compilers.
> 
> Hum. <BRAINSTORMING>
> 
> ## idea #1:
> One thing commonly used to hide prototypes away from compilers that
> don't support them is enclosing the whole function call in a macro, say:
> 
> #ifdef SUPPORT_PROTOS
> #define D(p) p
> #else
> #define D(p) ()
> #endif
> 
> void myfunc D((int name, char name2));
> 
> The important thing is that you pass double parentheses here.
> 
> However, the "flags" you use probably prevents us from using this approach.
> 
> 
> ## idea #2:
> Convert the msg macro that you have now to an __inline
> function and compile with -finline-functions or -O3 and let the global
> optimizer inline the if (debuglevel high enough) checks. I fear though
> that the varargs breaks this as well and prevents inlining.
> 
> 
> ## idea #3:
> Use a fixed-argument msg macro big enough to hold all arguments and fill
> the unused with NULL (rather than doing a dozen macros on your own).
> 
> 
> ## idea #4:
> profile if calling the function really slows down things that much.
> 
> </BRAINSTORMING>

How about we add a new configure option such as --no-vararg-macros that
makes msg() into a function (as you do in your patch) to pacify older
compilers?

Even better, is there an autoconf macro which will automatically test 
whether or not vararg macros are supported?

Then we only take the msg-as-function route if we need to.

James

Re: [Openvpn-devel] Pre-1.3.3 beta available for testing

[James Y. <ji...@yo...>]

> Please also note that _* names are reserved name space. Don't use them
> for your functions if you can avoid it, for portability -- they might
> screw some linker.

Are __* names reserved?  What's the recommended form for naming "private"  
variables (I'm coming from C++/Python where _* names are a common naming
style for class-private variables to avoid collisions with similarly named
public member functions)?

James

Re: [Openvpn-devel] Pre-1.3.3 beta available for testing

[Matthias A. <ma+...@dt...>]

On Wed, 19 Feb 2003, James Yonan wrote:

> Hey, thanks for the patch and all the testing work on different platforms. 

You're welcome. I thought if I give it a whirl, I'd spin it until it was
dizzy :-)

> You raise a number of good points which I will address below:

There were more warnings that I haven't reported because I think they
didn't warrant fixes at this time, some "unused parameter" warnings. Try

make clean
make CFLAGS="-W -Wall"

to see more warnings :-)

> (3) On the issue of including generated files in the CVS -- it seemed in the
> early days of OpenVPN that people wanted the CVS to mirror a tarball and build
> without the required dependencies of automake/autoconf.  But I would have to
> agree with you that eliminating these files makes a lot of sense and nicely
> simplifies things.
> 
> (4) pre-touch -- a bit of a kludge which was added because cvs was not
> committing files which had a later modification date but null diffs (as one
> might argue is correct behaviour).  Because of this there were some
> automake/autoconf problems.  This is probably no longer an issue if generated
> files are removed from the CVS.

Shipping generated files will usually break things one way or another. I
found a few issues in many packages by doing

make distclean
mkdir ../openvpn-build
cd ../openvpn-build
../openvpn/configure -C
make check

or something. I bit myself by accidentally shipping a file I'd think was
generated with leafnode, so I have got some first-hand burn marks ;-)

> (6) Solaris net/if_tun.h missing produces undefined TUNNEWPPA -- will add a
> check to configure.ac.

Thanks.

> (7) Problems with variadic msg() macros on some compilers --  Writing msg() as
> a macro is important for efficiency, to avoid a function call during the vast
> majority of cases where msg() is a noop.  Do you think many people use
> compilers which do not support this?  I suppose one could replace with msg1,
> msg2, msg3, etc. based on the number of arguments, but that would be terribly
> ugly.  I am inclined to leave this as-is, unless you can think of a better way.

I have no profiles, sorry, neither of the function call overhead
incurred or avoided, nor of the compilers.

Hum. <BRAINSTORMING>

## idea #1:
One thing commonly used to hide prototypes away from compilers that
don't support them is enclosing the whole function call in a macro, say:

#ifdef SUPPORT_PROTOS
#define D(p) p
#else
#define D(p) ()
#endif

void myfunc D((int name, char name2));

The important thing is that you pass double parentheses here.

However, the "flags" you use probably prevents us from using this approach.


## idea #2:
Convert the msg macro that you have now to an __inline
function and compile with -finline-functions or -O3 and let the global
optimizer inline the if (debuglevel high enough) checks. I fear though
that the varargs breaks this as well and prevents inlining.


## idea #3:
Use a fixed-argument msg macro big enough to hold all arguments and fill
the unused with NULL (rather than doing a dozen macros on your own).


## idea #4:
profile if calling the function really slows down things that much.

</BRAINSTORMING>

> (9) The Patch -- looks good, I will test and let you know if I see any
> problems.  BTW, does your changes to the automake/autoconf scripts raise the
> required version number for automake/autoconf from 1.6/2.50?

Not that I'm aware of.

I tested aclocal/automake 1.6.3, they look fine on my machine. (I
usually use 1.7.2 though).

autoconf 2.50 should be fine as well, all the relevant checks I added
are documented in autoconf's ChangeLog.2 which "ends" (topmost entry)
with the release of 2.50. I'm using 2.57.

However, I've found that later software (automake 1.7.x and autoconf
2.5x) usually give less bogus warnings and are more robust.