Fabian Knittel | 1 Jul 2012 14:43
Picon

Re: [PATCH] Repair "tap server" mode brokenness caused by <stdbool.h> fallout

Hi everyone,

2012/6/30 Gert Doering <gert <at> greenie.muc.de>:
> diff --git a/src/openvpn/mroute.c b/src/openvpn/mroute.c
> index aecb702..850e336 100644
> --- a/src/openvpn/mroute.c
> +++ b/src/openvpn/mroute.c
>  <at>  <at>  -52,7 +52,7  <at>  <at>  mroute_addr_init (struct mroute_addr *addr)
>  static inline bool
>  is_mac_mcast_addr (const uint8_t *mac)
>  {
> -  return (bool) mac[0] & 1;
> +  return (bool) (mac[0] & 1);
>  }
>
>  static inline bool

ACK. In the context of is_mac_mcast_addr, the check now looks obviously correct.

Cheers
Fabian

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-devel mailing list
(Continue reading)

David Sommerseth | 2 Jul 2012 09:57

Build issues on ScientificLinux 6.2


Hi Alon & al,

Just tried to do a scratch build on SL6.2 from the git tree.

-------------------------------------------------------------
$ autoreconf -vi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:380: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
      If this token and others are legitimate, please use
m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:381: error: possibly undefined macro: AC_LIBTOOL_RC
configure.ac:382: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: /usr/bin/autoconf failed with exit status: 1
$
-------------------------------------------------------------

autoconf-2.63-5.1.el6.noarch
automake-1.11.1-1.2.el6.noarch

Can we please fix this?  The workaround currently is to do 'make dist'
on box where autoreconf can complete.

kind regards,
(Continue reading)

David Sommerseth | 2 Jul 2012 10:42

Re: Build issues on ScientificLinux 6.2


On 02/07/12 09:57, David Sommerseth wrote:
> 
> Hi Alon & al,
> 
> Just tried to do a scratch build on SL6.2 from the git tree.
> 
> ------------------------------------------------------------- $
> autoreconf -vi autoreconf: Entering directory `.' autoreconf:
> configure.ac: not using Gettext autoreconf: running: aclocal -I m4 
> autoreconf: configure.ac: tracing autoreconf: configure.ac: not
> using Libtool autoreconf: running: /usr/bin/autoconf 
> configure.ac:380: error: possibly undefined macro:
> AC_LIBTOOL_WIN32_DLL If this token and others are legitimate,
> please use m4_pattern_allow. See the Autoconf documentation. 
> configure.ac:381: error: possibly undefined macro: AC_LIBTOOL_RC 
> configure.ac:382: error: possibly undefined macro: AC_PROG_LIBTOOL 
> autoreconf: /usr/bin/autoconf failed with exit status: 1 $ 
> -------------------------------------------------------------
> 
> autoconf-2.63-5.1.el6.noarch automake-1.11.1-1.2.el6.noarch
> 
> Can we please fix this?  The workaround currently is to do 'make
> dist' on box where autoreconf can complete.

Duh! Never mind!  I realised now that I was lacking libtool.
Installing that, and it works just fine.  Sorry about the noise!

kind regards,

(Continue reading)

Alon Bar-Lev | 2 Jul 2012 10:45
Picon
Gravatar

Re: Build issues on ScientificLinux 6.2

Libtool version please.
Thanks

On 7/2/12, David Sommerseth <openvpn.list <at> topphemmelig.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Alon & al,
>
> Just tried to do a scratch build on SL6.2 from the git tree.
>
> - -------------------------------------------------------------
> $ autoreconf -vi
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal -I m4
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /usr/bin/autoconf
> configure.ac:380: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
>       If this token and others are legitimate, please use
> m4_pattern_allow.
>       See the Autoconf documentation.
> configure.ac:381: error: possibly undefined macro: AC_LIBTOOL_RC
> configure.ac:382: error: possibly undefined macro: AC_PROG_LIBTOOL
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> $
> - -------------------------------------------------------------
>
(Continue reading)

David Sommerseth | 2 Jul 2012 10:54

Re: Build issues on ScientificLinux 6.2


On 02/07/12 10:45, Alon Bar-Lev wrote:
> Libtool version please. Thanks

As I noticed a few minutes ago, I didn't have libtool installed.  All
builds fine when installing libtool-2.2.6-15.5.el6.x86_64.

kind regards,

David Sommerseth

> On 7/2/12, David Sommerseth <openvpn.list <at> topphemmelig.net> wrote:
> 
> Hi Alon & al,
> 
> Just tried to do a scratch build on SL6.2 from the git tree.
> 
> ------------------------------------------------------------- $
> autoreconf -vi autoreconf: Entering directory `.' autoreconf:
> configure.ac: not using Gettext autoreconf: running: aclocal -I m4 
> autoreconf: configure.ac: tracing autoreconf: configure.ac: not
> using Libtool autoreconf: running: /usr/bin/autoconf 
> configure.ac:380: error: possibly undefined macro:
> AC_LIBTOOL_WIN32_DLL If this token and others are legitimate,
> please use m4_pattern_allow. See the Autoconf documentation. 
> configure.ac:381: error: possibly undefined macro: AC_LIBTOOL_RC 
> configure.ac:382: error: possibly undefined macro: AC_PROG_LIBTOOL 
> autoreconf: /usr/bin/autoconf failed with exit status: 1 $ 
> -------------------------------------------------------------
> 
(Continue reading)

David Sommerseth | 2 Jul 2012 11:28

Re: [PATCH] Repair "tap server" mode brokenness caused by <stdbool.h> fallout

On 30/06/12 22:50, Gert Doering wrote:
> Operator/Cast precedence wrong: casting mac[0] to (bool) first - giving
> "1" for "any mac address that does not start with 00:" - and only then
> bit-anding with "1" - thus always returning "true".  Which, in turn,
> leads to "reject all incoming packets with 'bad source address'".
> 
> OpenVPN bug #216.
> 
> Signed-off-by: Gert Doering <gert <at> greenie.muc.de>
> ---
>  src/openvpn/mroute.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 

Applied to master.

commit 8df08de6f84d224c6a79ab6c74ba73c33a47735d
Author: Gert Doering <gert <at> greenie.muc.de>
Date:   Sat Jun 30 22:50:43 2012 +0200

    Repair "tap server" mode brokenness caused by <stdbool.h> fallout

    Signed-off-by: Gert Doering <gert <at> greenie.muc.de>
    Acked-by: Fabian Knittel <fabian.knittel <at> lettink.de>
    Message-Id: 1341089443-2287-1-git-send-email-gert <at> greenie.muc.de
    URL: http://article.gmane.org/gmane.network.openvpn.devel/6817
    Signed-off-by: David Sommerseth <dazo <at> users.sourceforge.net>

kind regards,

(Continue reading)

samuli | 2 Jul 2012 16:27
Favicon

[PATCH] Incrementing version number of tap-windows to 9.9.1

From: Samuli Seppänen <samuli <at> openvpn.net>

Tap-windows driver is now built using it's own buildsystem, whereas earlier it
was built using the Python-based buildsystem in OpenVPN. Incrementing release
date and version number in tap-windows/version.m4 to help differentiate these
new drivers from the old ones.

Signed-off-by: Samuli Seppänen <samuli <at> openvpn.net>
---
 version.m4 |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/version.m4 b/version.m4
index 2d21396..4ac0561 100644
--- a/version.m4
+++ b/version.m4
 <at>  <at>  -1,6 +1,6  <at>  <at> 
 dnl define the TAP version
 define([PRODUCT_NAME], [TAP-Windows])
-define([PRODUCT_VERSION], [9.9.0_master])
+define([PRODUCT_VERSION], [9.9.1])
 define([PRODUCT_VERSION_RESOURCE], [9,0,0,9])
 define([PRODUCT_TAP_WIN_COMPONENT_ID], [tap0901])
 define([PRODUCT_TAP_WIN_MAJOR], [9])
 <at>  <at>  -8,4 +8,4  <at>  <at>  define([PRODUCT_TAP_WIN_MINOR], [9])
 define([PRODUCT_TAP_WIN_PROVIDER], [TAP-Windows Provider V9])
 define([PRODUCT_TAP_WIN_CHARACTERISTICS], [0x81])
 define([PRODUCT_TAP_WIN_DEVICE_DESCRIPTION], [TAP-Windows Adapter V9])
-define([PRODUCT_TAP_WIN_RELDATE], [04/19/2010])
+define([PRODUCT_TAP_WIN_RELDATE], [07/02/2012])
(Continue reading)

Alon Bar-Lev | 2 Jul 2012 16:33
Picon
Gravatar

Re: [PATCH] Incrementing version number of tap-windows to 9.9.1

Hi,

If you are not going to release, you should keep the _master or _beta
or any other suffix.

Alon.

On Mon, Jul 2, 2012 at 5:27 PM,  <samuli <at> openvpn.net> wrote:
> From: Samuli Seppänen <samuli <at> openvpn.net>
>
> Tap-windows driver is now built using it's own buildsystem, whereas earlier it
> was built using the Python-based buildsystem in OpenVPN. Incrementing release
> date and version number in tap-windows/version.m4 to help differentiate these
> new drivers from the old ones.
>
> Signed-off-by: Samuli Seppänen <samuli <at> openvpn.net>
> ---
>  version.m4 |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/version.m4 b/version.m4
> index 2d21396..4ac0561 100644
> --- a/version.m4
> +++ b/version.m4
>  <at>  <at>  -1,6 +1,6  <at>  <at> 
>  dnl define the TAP version
>  define([PRODUCT_NAME], [TAP-Windows])
> -define([PRODUCT_VERSION], [9.9.0_master])
> +define([PRODUCT_VERSION], [9.9.1])
>  define([PRODUCT_VERSION_RESOURCE], [9,0,0,9])
(Continue reading)

David Sommerseth | 2 Jul 2012 16:39

Re: [PATCH] Incrementing version number of tap-windows to 9.9.1


On 02/07/12 16:33, Alon Bar-Lev wrote:
> Hi,
> 
> If you are not going to release, you should keep the _master or
> _beta or any other suffix.

We're shipping this updated code base with the 2.3-alpha2 release ...
so it's just to prepare the tree for that.

We're aware of the code itself shouldn't have changed much.  But as
the complete build tool is replaced, it's just to make sure all
updates goes properly.  And we want this new code base tested.

I'll make sure we switch back to the a _master tag when we this tree
is tagged properly.

kind regards,

David Sommerseth

> On Mon, Jul 2, 2012 at 5:27 PM,  <samuli <at> openvpn.net> wrote:
>> From: Samuli Seppänen <samuli <at> openvpn.net>
>> 
>> Tap-windows driver is now built using it's own buildsystem,
>> whereas earlier it was built using the Python-based buildsystem
>> in OpenVPN. Incrementing release date and version number in
>> tap-windows/version.m4 to help differentiate these new drivers
>> from the old ones.
>> 
(Continue reading)

Seth Mos | 2 Jul 2012 22:18
Picon
Favicon
Gravatar

Android ICS openvpn client

Hi Everyone,

We just did some tests with the Android OpenVPN client against the OpenVPN 2.2 with IPv6 patches we have in
pfSense 2.1 and IPv4 and IPv6 tunneling from the phone and/or tablet works. Yay! (Windows 7 already worked)

We also added some wits for the inline format so you can just mail yourself one file and the Android OpenVPN
client will just import it and go from there. Excellent work.

Forward!

How about fixing them Mac OS clients, I feel poor. Plus my dual stack servers at work break because my
Viscosity is just v4 and I have v6 on my LAN at home breaking a lot because it's trying to send all the traffic
over the internet instead of a tunnel.

Cheers,

Seth
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Gmane