Skip to contentSkip to conversation

Preparing 2.4-beta1 upload to Debian (Experimental)

Openvpn-devel Superseded Alberto Gonzalez Iniesta 5 participants 15 messages Nov 21, 2016 – Jan 4, 2017

lore
Share & tools
lore

Alberto Gonzalez Iniesta

author
#0 lore raw

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10
Fixing this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Thanks,

Alberto

Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
#1 lore raw

Il 21/11/2016 11:10, Alberto Gonzalez Iniesta ha scritto:

Quoted 10 lines

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10
Fixing this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Quoted 4 lines

Thanks,

Alberto

That bug report is mighty old, from 2008. I wonder if the problem still persists at all?

Signature · 5 lines
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
#2 lore raw
Quoted 10 lines · Samuli Seppänen

Il 21/11/2016 11:10, Alberto Gonzalez Iniesta ha scritto:

Quoted 9 lines

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10

Fixing this:

Quoted 8 lines
Quoted 5 lines

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Thanks,

Alberto

That bug report is mighty old, from 2008. I wonder if the problem still persists at all?

I hope at least Arne can chime in on this one, as he has done tremendous work on the socket code. And I'd be surprised if this patch applies cleanly on top of our master branch.

Yes, it's an old issue. But from my brief 3 minutes look at socket.c, I'd say it looks like to me this is still needed. The explanation in the patch makes sense.

But lets hear what Arne and others who know these code paths have to say.

Signature · 4 lines
kind regards,

David Sommerseth
OpenVPN Technologies, Inc
author
#3 lore raw
Quoted 16 lines · David Sommerseth
Quoted 10 lines · Samuli Seppänen

Il 21/11/2016 11:10, Alberto Gonzalez Iniesta ha scritto:

Quoted 9 lines

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10

Fixing this:

Quoted 4 lines
Quoted 4 lines

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Thanks,

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

Alberto

That bug report is mighty old, from 2008. I wonder if the problem still persists at all?

I hope at least Arne can chime in on this one, as he has done tremendous work on the socket code. And I'd be surprised if this patch applies cleanly on top of our master branch.

No, I doesn't. But I updated it to 2.4. Find it attached.

Quoted 3 lines

Yes, it's an old issue. But from my brief 3 minutes look at socket.c, I'd say it looks like to me this is still needed. The explanation in the patch makes sense.

Yep, I think it's still needed.

Regards,

Alberto

Quoted 6 lines

------------------------------------------------------------------------------

_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Description: Set socket's FD_CLOEXEC flag before calling up script
Moving the set_cloexec() call from link_socket_init_phase2() to link_socket_init_phase1().
Author: Julien Cristau <[email protected]...>
Bug-Debian: http://bugs.debian.org/367716

src/openvpn/socket.c +4 -4
Index: openvpn/src/openvpn/socket.c
===================================================================
@@ -1625,6 +1625,10 @@
       }
       resolve_remote (sock, 1, NULL, NULL);
     }
+
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sock->sd);
 }
 
 static

@@ -1677,10 +1681,6 @@
   /* set socket to non-blocking mode */
   set_nonblock (sock->sd);
 
-  /* set socket file descriptor to not pass across execs, so that
-     scripts don't have access to it */
-  set_cloexec (sock->sd);
-
   if (socket_defined (sock->ctrl_sd))
     set_cloexec (sock->ctrl_sd);
#4 lore raw

PATCH 1/1 Refactor setting close-on-exec for socket FDs

In reply to Alberto Gonzalez Iniesta

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

Since different sockets get create at different times, just moving the set_cloexec() to link_socket_init_phase1() is not good enough - so move the call into create_socket_<family>(), so we will catch ALL socket creations, no matter when or under which conditions they will be created (SOCKS proxy socket, listening socket, ...).

--inetd gets an extra fd_cloexec() call, as socket FD is inherited.

URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Signed-off-by Gert Doering <[email protected]...>
---
 src/openvpn/socket.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)
src/openvpn/socket.c +15 -7
index c233f2b..d9d95fe 100644
@@ -771,6 +771,10 @@ create_socket_tcp (struct addrinfo* addrinfo)
   }
 #endif
 
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 

@@ -815,6 +819,11 @@ create_socket_udp (struct addrinfo* addrinfo, const unsigned int flags)
         }
     }
 #endif
+
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 

@@ -1617,6 +1626,7 @@ link_socket_init_phase1 (struct link_socket *sock,
       ASSERT (sock->info.proto != PROTO_TCP_CLIENT);
       ASSERT (socket_defined (inetd_socket_descriptor));
       sock->sd = inetd_socket_descriptor;
+      set_cloexec (sock->sd);		/* not created by create_socket*() */
     }
   else if (mode != LS_MODE_TCP_ACCEPT_FROM)
     {

@@ -1677,13 +1687,6 @@ phase2_set_socket_flags (struct link_socket* sock)
   /* set socket to non-blocking mode */
   set_nonblock (sock->sd);
 
-  /* set socket file descriptor to not pass across execs, so that
-     scripts don't have access to it */
-  set_cloexec (sock->sd);
-
-  if (socket_defined (sock->ctrl_sd))
-    set_cloexec (sock->ctrl_sd);
-
   /* set Path MTU discovery options on the socket */
   set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.af);
 

@@ -3476,6 +3479,11 @@ create_socket_unix (void)
 
   if ((sd = socket (PF_UNIX, SOCK_STREAM, 0)) < 0)
     msg (M_ERR, "Cannot create unix domain socket");
+
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
Signature · 1 line
2.7.3
#5 lore raw

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

Hi,

Quoted 3 lines · Gert Doering

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

I'm not sure if that patch is good enough yet.

Arne brought up "port-share" - where we fork processes, so it needs to be ensured that whatever that process needs is still working.

In addition to that, we have "TCP server" processes, which create new sockets not by calling socket() but by calling accept() on the listening socket, which is not in one of thew set_cloexec() paths - but watch out, *these* might be the ones needed for port-share.

gert

Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...
author
#6 lore raw

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

Quoted 12 lines · Gert Doering

Hi,

Quoted 3 lines · Gert Doering

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

I'm not sure if that patch is good enough yet.

Arne brought up "port-share" - where we fork processes, so it needs to be ensured that whatever that process needs is still working.

Quoted 6 lines

In addition to that, we have "TCP server" processes, which create new sockets not by calling socket() but by calling accept() on the listening socket, which is not in one of thew set_cloexec() paths - but watch out, *these* might be the ones needed for port-share.

gert

Hi,

The patch, after being adjusted to the new source, is not working anymore:

Mon Dec  5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9)
Mon Dec  5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9)
Mon Dec  5 19:39:34 2016 Exiting due to fatal error
Mon Dec  5 19:39:34 2016 Exiting due to fatal error

FAIL: t_cltsrv.sh
====================================================
1 of 2 tests failed
(1 test was not run)
Please report to [email protected]
====================================================

So I guess Debian's bug #367716 [1] will come back from the dead :-( with 2.4.

Regards,

Alberto

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
#7 lore raw

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

Hi,

Quoted 4 lines · Alberto Gonzalez Iniesta

The patch, after being adjusted to the new source, is not working anymore:

Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9) Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9)

This is with "the debian patch", or with my alternate suggestion?

(I'm not sure if my patch is actually good enough as I think it's not fixing TCP "after accept" sockets yet - but some sort of initial feedback would be good :) )

gert

Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...
author
#8 lore raw

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

Quoted 8 lines · Gert Doering

Hi,

Quoted 4 lines · Alberto Gonzalez Iniesta

The patch, after being adjusted to the new source, is not working anymore:

Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9) Mon Dec 5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad file descriptor (errno=9)

Quoted 7 lines

This is with "the debian patch", or with my alternate suggestion?

(I'm not sure if my patch is actually good enough as I think it's not fixing TCP "after accept" sockets yet - but some sort of initial feedback would be good :) )

gert

So sorry Gert, I didn't notice yours. I' try it and let you know about the result.

Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
#9 lore raw

PATCH v3 1/1 Refactor setting close-on-exec for socket FDs

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

Since different sockets get create at different times, just moving the set_cloexec() to link_socket_init_phase1() is not good enough - so move the call into create_socket_<family>(), so we will catch ALL socket creations, no matter when or under which conditions they will be created (SOCKS proxy socket, listening socket, ...).

--inetd gets an extra fd_cloexec() call, as socket FD is inherited.

URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

v2: remove set_cloexec() calls from manage.c

v3: add set_cloexec() calls to accept()ed TCP/unix child sockets

Signed-off-by Gert Doering <[email protected]...>
---
 src/openvpn/manage.c |  2 --
 src/openvpn/socket.c | 34 +++++++++++++++++++++++++++-------
 2 files changed, 27 insertions(+), 9 deletions(-)
src/openvpn/manage.c +0 -2
index 77a8006..e8ec442 100644
@@ -1499,7 +1499,6 @@ man_new_connection_post (struct management *man, const char *description)
   struct gc_arena gc = gc_new ();
 
   set_nonblock (man->connection.sd_cli);
-  set_cloexec (man->connection.sd_cli);
 
   man_connection_settings_reset (man);
 

@@ -1640,7 +1639,6 @@ man_listen (struct management *man)
        * Set misc socket properties
        */
       set_nonblock (man->connection.sd_top);
-      set_cloexec (man->connection.sd_top);
 
 #if UNIX_SOCK_SUPPORT
       if (man->settings.flags & MF_UNIX_SOCK)
src/openvpn/socket.c +27 -7
index c233f2b..ce53ee8 100644
@@ -771,6 +771,10 @@ create_socket_tcp (struct addrinfo* addrinfo)
   }
 #endif
 
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 

@@ -815,6 +819,11 @@ create_socket_udp (struct addrinfo* addrinfo, const unsigned int flags)
         }
     }
 #endif
+
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 

@@ -968,6 +977,12 @@ socket_do_accept (socket_descriptor_t sd,
       openvpn_close_socket (new_sd);
       new_sd = SOCKET_UNDEFINED;
     }
+  else
+    {
+      /* set socket file descriptor to not pass across execs, so that
+	 scripts don't have access to it */
+      set_cloexec (sd);
+    }
   return new_sd;
 }
 

@@ -1617,6 +1632,7 @@ link_socket_init_phase1 (struct link_socket *sock,
       ASSERT (sock->info.proto != PROTO_TCP_CLIENT);
       ASSERT (socket_defined (inetd_socket_descriptor));
       sock->sd = inetd_socket_descriptor;
+      set_cloexec (sock->sd);		/* not created by create_socket*() */
     }
   else if (mode != LS_MODE_TCP_ACCEPT_FROM)
     {

@@ -1677,13 +1693,6 @@ phase2_set_socket_flags (struct link_socket* sock)
   /* set socket to non-blocking mode */
   set_nonblock (sock->sd);
 
-  /* set socket file descriptor to not pass across execs, so that
-     scripts don't have access to it */
-  set_cloexec (sock->sd);
-
-  if (socket_defined (sock->ctrl_sd))
-    set_cloexec (sock->ctrl_sd);
-
   /* set Path MTU discovery options on the socket */
   set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.af);
 

@@ -3476,6 +3485,11 @@ create_socket_unix (void)
 
   if ((sd = socket (PF_UNIX, SOCK_STREAM, 0)) < 0)
     msg (M_ERR, "Cannot create unix domain socket");
+
+  /* set socket file descriptor to not pass across execs, so that
+     scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 

@@ -3516,6 +3530,12 @@ socket_accept_unix (socket_descriptor_t sd,
 
   CLEAR (*remote);
   ret = accept (sd, (struct sockaddr *) remote, &remote_len);
+  if ( ret >= 0 )
+    {
+      /* set socket file descriptor to not pass across execs, so that
+	 scripts don't have access to it */
+      set_cloexec (ret);
+    }
   return ret;
 }
Signature · 1 line
2.7.3
#10 lore raw

Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

Am 06.12.16 um 13:26 schrieb Gert Doering:

Quoted 9 lines

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

Since different sockets get create at different times, just moving the set_cloexec() to link_socket_init_phase1() is not good enough - so move the call into create_socket_<family>(), so we will catch ALL socket creations, no matter when or under which conditions they will be created (SOCKS proxy socket, listening socket, ...).

Patch looks good. ACK from me. I also looked at the port-share code path but that part isn't touched by this commit.

Arne

author
#11 lore raw

Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

Quoted 5 lines · Arne Schwabe

Am 06.12.16 um 13:26 schrieb Gert Doering:

Quoted 4 lines

The existing code can leak socket FDs to the "--up" script, which is not desired. Brought up by Alberto Gonzalez Iniesta, based on debian bug 367716.

Quoted 9 lines
Quoted 5 lines

Since different sockets get create at different times, just moving the set_cloexec() to link_socket_init_phase1() is not good enough - so move the call into create_socket_<family>(), so we will catch ALL socket creations, no matter when or under which conditions they will be created (SOCKS proxy socket, listening socket, ...).

Patch looks good. ACK from me. I also looked at the port-share code path but that part isn't touched by this commit.

Works for me (tm)

I'm just waiting for the pkcs11-helper maintainer [1] to upload 2.4~rc1 to Debian. If he decides to build against OpenSSL 1.1 I'd have to remove PKCS #11 support from Debian's package in Stretch.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828506

Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
#12 lore raw

[Openvpn-devel] [PATCH applied] Re: Refactor setting close-on-exec for socket FDs

In reply to Gert Doering

Thanks for the test reports (Agi per Mail, Thermi on IRC) and ACK from Arne.

Patch has been applied to the master branch ("this is a bugfix").

commit e35a788339497ec5c179a5d0a23f63824989ec3e

Author: Gert Doering
Date:   Tue Dec 6 13:26:02 2016 +0100
     Refactor setting close-on-exec for socket FDs

     URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716
     Signed-off-by: Gert Doering <[email protected]...>
     Acked-by: Arne Schwabe <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg13405.html
     Signed-off-by: Gert Doering <[email protected]...>

--
kind regards,

Gert Doering

#13 lore raw
In reply to Alberto Gonzalez Iniesta

Am 21.11.16 um 10:10 schrieb Alberto Gonzalez Iniesta:

Quoted 10 lines

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10
Fixing this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Quoted 4 lines

Thanks,

Alberto

One thing I noticed. Debian still includes a "route_default_nil.patch". That patch changes the man page to the command line help which is wrong.

The correct thing is to change the command line (patch attached).

Arne

From a88d8ba3e81ca34fc2675805a273cd85875c8973 Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Wed, 4 Jan 2017 19:18:46 +0100
Subject: [PATCH] Change command help to match man page and implementation

---
 src/openvpn/options.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
src/openvpn/options.c +1 -1
index bfedb6a..80143e6 100644
@@ -198,7 +198,7 @@ static const char usage_message[] =
     "                  is established.  Multiple routes can be specified.\n"
     "                  netmask default: 255.255.255.255\n"
     "                  gateway default: taken from --route-gateway or --ifconfig\n"
-    "                  Specify default by leaving blank or setting to \"nil\".\n"
+    "                  Specify default by leaving blank or setting to \"default\".\n"
     "--route-ipv6 network/bits [gateway] [metric] :\n"
     "                  Add IPv6 route to routing table after connection\n"
     "                  is established.  Multiple routes can be specified.\n"
Signature · 1 line
2.10.1 (Apple Git-78)
author
#14 lore raw

Thanks Arne!

I'll fix this in the next upload.

Quoted 45 lines · Arne Schwabe

Am 21.11.16 um 10:10 schrieb Alberto Gonzalez Iniesta:

Quoted 10 lines

Hi,

I'm preparing an upload to Debian Experimental of 2.4-beta1 in order to get the maximum exposition as possible. In the meantime I'd like to know your opinion on the following patch that I've been applying to Debian's package for some years:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=367716;filename=openvpn_367716.diff;msg=10
Fixing this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

Quoted 4 lines

Thanks,

Alberto

One thing I noticed. Debian still includes a "route_default_nil.patch". That patch changes the man page to the command line help which is wrong.

The correct thing is to change the command line (patch attached).

Arne

From a88d8ba3e81ca34fc2675805a273cd85875c8973 Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Wed, 4 Jan 2017 19:18:46 +0100
Subject: [PATCH] Change command help to match man page and implementation

---
 src/openvpn/options.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
src/openvpn/options.c +1 -1
index bfedb6a..80143e6 100644
@@ -198,7 +198,7 @@ static const char usage_message[] =
     "                  is established.  Multiple routes can be specified.\n"
     "                  netmask default: 255.255.255.255\n"
     "                  gateway default: taken from --route-gateway or --ifconfig\n"
-    "                  Specify default by leaving blank or setting to \"nil\".\n"
+    "                  Specify default by leaving blank or setting to \"default\".\n"
     "--route-ipv6 network/bits [gateway] [metric] :\n"
     "                  Add IPv6 route to routing table after connection\n"
     "                  is established.  Multiple routes can be specified.\n"
Signature · 5 lines
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: [email protected]... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55