vtun-devel Mailing List for VTun - Virtual Tunnels

Hey Folks,

My earlier message was eaten by the SF.net list manager, so here's a
re-send.

 - ..

-------- Forwarded Message --------
Subject: Sourceforge Changing its Mailing Lists and SCM
Date: Wed, 1 Nov 2017 21:52:15 -0700
From: bishop <bi...@pl...>
To: vtu...@li...

Hey folks,

I'm reading that Sourceforge wants to shutter most of the mailing lists
(by asking you to agree to spam or so) and other migrations. This is
going to give us some changes, I'm sure.

The first change is that the mailing lists, as idle as they are, will
probably get more idle, and see below. With people unsubscribing for
either the spam worry or the low volume, it almost makes sense to close
them up. Most of our traffic I'm seeing is in bug reports anyway, and
other options are a better bet for this kind of thing.

Secondly, SF wants us to move from CVS to SVN or Git; and with the love
Git sees today, I'd easily suggest the latter. And I'd recommend moving
on to GitHub, even though it's a huge move. But there's a wrinkle: the
obvious URL is taken by an anonymous rip of the CVS repo under the
official name, and I'm not sure it'd be a good idea to move to GitHub
under another name because of the confusion.  People click in a hurry,
after all.

There's a final wrinkle. I've worked two jobs for almost the entirety
of the time I've been aware of vtun, like most of you after 2000, and I
know I'm stretched thin for important, wonderful reasons that don't help
VTun. Is it a good time for someone new to pick up the project who can
actually run with it?

I'm thinking that with some guidance, the answer to the GitHub issue can
be the answer to the other issue, but I have no guarantees that
compatibility and safety will be the goals of the day in this new
millennium of 'fail fast' coding, nor the keys to enforce any kind of
rule like that.

I've put this on the dev list because it's more a dev issue than a user
issue. We have a month to talk about it, so there's no rush.

Let's decide what's happening, because it's important.

 - bish

Hey Bish,

Attached is a patch I cooked up to build against the new openssl-1.1
which caused the build on Fedora-26 to fail earlier.

I'm still working on figuring out how to actually *test* the whole
thing (I'm not running the F26 alpha anywhere yet), so I just blindly
followed some of the examples shown here:

    https://github.com/patch-exchange/openssl-1.1-transition

While it got the errors to go away, I'm still getting a ton of
warnings from building lfd_encrypt.c (things like "pointer targets
differ in signedness", "iv_buf|key defined but not used", "implicit
declaration of function 'read'", etc.). But I think they must have
been there before, and are orthogonal to the openssl thing :)

Anyhow, here's the patch for your consideration. Thanks again,
  -- Gabe


diff -NarU5 a/lfd_encrypt.c b/lfd_encrypt.c
--- a/lfd_encrypt.c	2016-10-01 17:27:51.000000000 -0400
+++ b/lfd_encrypt.c	2017-03-20 08:43:48.013308435 -0400
@@ -93,15 +93,15 @@
 static int dec_init_first_time;
 static unsigned long sequence_num;
 static char * pkey;
 static char * iv_buf;
 
-static EVP_CIPHER_CTX ctx_enc;	/* encrypt */
-static EVP_CIPHER_CTX ctx_dec;	/* decrypt */
+static EVP_CIPHER_CTX *ctx_enc;	/* encrypt */
+static EVP_CIPHER_CTX *ctx_dec;	/* decrypt */
 
-static EVP_CIPHER_CTX ctx_enc_ecb;	/* sideband ecb encrypt */
-static EVP_CIPHER_CTX ctx_dec_ecb;	/* sideband ecb decrypt */
+static EVP_CIPHER_CTX *ctx_enc_ecb;	/* sideband ecb encrypt */
+static EVP_CIPHER_CTX *ctx_dec_ecb;	/* sideband ecb decrypt */
 
 static int send_msg(int len, char *in, char **out);
 static int recv_msg(int len, char *in, char **out);
 static int send_ib_mesg(int *len, char **in);
 static int recv_ib_mesg(int *len, char **in);
@@ -180,37 +180,37 @@
       case VTUN_ENC_AES256CBC:
          blocksize = 16;
          keysize = 32;
          sb_init = 1;
          cipher_type = EVP_aes_256_ecb();
-         pctx_enc = &ctx_enc_ecb;
-         pctx_dec = &ctx_dec_ecb;
+         pctx_enc = ctx_enc_ecb;
+         pctx_dec = ctx_dec_ecb;
       break;
       
       case VTUN_ENC_AES256ECB:
          blocksize = 16;
          keysize = 32;
-         pctx_enc = &ctx_enc;
-         pctx_dec = &ctx_dec;
+         pctx_enc = ctx_enc;
+         pctx_dec = ctx_dec;
          cipher_type = EVP_aes_256_ecb();
          strcpy(cipher_name,"AES-256-ECB");
       break;      
       case VTUN_ENC_AES128OFB:
       case VTUN_ENC_AES128CFB:
       case VTUN_ENC_AES128CBC:
          blocksize = 16;
          keysize = 16;
          sb_init=1;
          cipher_type = EVP_aes_128_ecb();
-         pctx_enc = &ctx_enc_ecb;
-         pctx_dec = &ctx_dec_ecb;
+         pctx_enc = ctx_enc_ecb;
+         pctx_dec = ctx_dec_ecb;
       break;
       case VTUN_ENC_AES128ECB:
          blocksize = 16;
          keysize = 16;
-         pctx_enc = &ctx_enc;
-         pctx_dec = &ctx_dec;
+         pctx_enc = ctx_enc;
+         pctx_dec = ctx_dec;
          cipher_type = EVP_aes_128_ecb();
          strcpy(cipher_name,"AES-128-ECB");
       break;
 
       case VTUN_ENC_BF256OFB:
@@ -219,20 +219,20 @@
          blocksize = 8;
          keysize = 32;
          var_key = 1;
          sb_init = 1;
          cipher_type = EVP_bf_ecb();
-         pctx_enc = &ctx_enc_ecb;
-         pctx_dec = &ctx_dec_ecb;
+         pctx_enc = ctx_enc_ecb;
+         pctx_dec = ctx_dec_ecb;
       break;
 
       case VTUN_ENC_BF256ECB:
          blocksize = 8;
          keysize = 32;
          var_key = 1;
-         pctx_enc = &ctx_enc;
-         pctx_dec = &ctx_dec;
+         pctx_enc = ctx_enc;
+         pctx_dec = ctx_dec;
          cipher_type = EVP_bf_ecb();
          strcpy(cipher_name,"Blowfish-256-ECB");
       break;
 
       case VTUN_ENC_BF128OFB:
@@ -241,26 +241,28 @@
          blocksize = 8;
          keysize = 16;
          var_key = 1;
          sb_init = 1;
          cipher_type = EVP_bf_ecb();
-         pctx_enc = &ctx_enc_ecb;
-         pctx_dec = &ctx_dec_ecb;
+         pctx_enc = ctx_enc_ecb;
+         pctx_dec = ctx_dec_ecb;
       break;
       case VTUN_ENC_BF128ECB: /* blowfish 128 ecb is the default */
       default:
          blocksize = 8;
          keysize = 16;
          var_key = 1;
-         pctx_enc = &ctx_enc;
-         pctx_dec = &ctx_dec;
+         pctx_enc = ctx_enc;
+         pctx_dec = ctx_dec;
          cipher_type = EVP_bf_ecb();
          strcpy(cipher_name,"Blowfish-128-ECB");
       break;
    } /* switch(host->cipher) */
 
    if (prep_key(&pkey, keysize, host) != 0) return -1;
+   pctx_enc = EVP_CIPHER_CTX_new();
+   pctx_dec = EVP_CIPHER_CTX_new();
    EVP_CIPHER_CTX_init(pctx_enc);
    EVP_CIPHER_CTX_init(pctx_dec);
    EVP_EncryptInit_ex(pctx_enc, cipher_type, NULL, NULL, NULL);
    EVP_DecryptInit_ex(pctx_dec, cipher_type, NULL, NULL, NULL);
    if (var_key)
@@ -292,14 +294,14 @@
    free_key(pkey); pkey = NULL;
 
    lfd_free(enc_buf); enc_buf = NULL;
    lfd_free(dec_buf); dec_buf = NULL;
 
-   EVP_CIPHER_CTX_cleanup(&ctx_enc);
-   EVP_CIPHER_CTX_cleanup(&ctx_dec);
-   EVP_CIPHER_CTX_cleanup(&ctx_enc_ecb);
-   EVP_CIPHER_CTX_cleanup(&ctx_dec_ecb);
+   EVP_CIPHER_CTX_free(ctx_enc);
+   EVP_CIPHER_CTX_free(ctx_dec);
+   EVP_CIPHER_CTX_free(ctx_enc_ecb);
+   EVP_CIPHER_CTX_free(ctx_dec_ecb);
 
    return 0;
 }
 
 static int encrypt_buf(int len, char *in, char **out)
@@ -321,11 +323,11 @@
    
    memset(in_ptr+len, pad, pad);
    outlen=len+pad;
    if (pad == blocksize)
       RAND_bytes(in_ptr+len, blocksize-1);
-   EVP_EncryptUpdate(&ctx_enc, out_ptr, &outlen, in_ptr, len+pad);
+   EVP_EncryptUpdate(ctx_enc, out_ptr, &outlen, in_ptr, len+pad);
    *out = enc_buf;
 
    sequence_num++;
 
    return outlen+msg_len;
@@ -341,11 +343,11 @@
    in = *out;
    in_ptr = in;
 
    outlen=len;
    if (!len) return 0;
-   EVP_DecryptUpdate(&ctx_dec, out_ptr, &outlen, in_ptr, len);
+   EVP_DecryptUpdate(ctx_dec, out_ptr, &outlen, in_ptr, len);
    recv_ib_mesg(&outlen, &out_ptr);
    if (!outlen) return 0;
    tmp_ptr = out_ptr + outlen; tmp_ptr--;
    pad = *tmp_ptr;
    if (pad < 1 || pad > blocksize) {
@@ -429,17 +431,18 @@
       /* if we're here, something weird's going on */
          return -1;
       break;
    } /* switch(cipher) */
 
-   EVP_CIPHER_CTX_init(&ctx_enc);
-   EVP_EncryptInit_ex(&ctx_enc, cipher_type, NULL, NULL, NULL);
+   ctx_enc = EVP_CIPHER_CTX_new();
+   EVP_CIPHER_CTX_init(ctx_enc);
+   EVP_EncryptInit_ex(ctx_enc, cipher_type, NULL, NULL, NULL);
    if (var_key)
-      EVP_CIPHER_CTX_set_key_length(&ctx_enc, keysize);
-   EVP_EncryptInit_ex(&ctx_enc, NULL, NULL, pkey, NULL);
-   EVP_EncryptInit_ex(&ctx_enc, NULL, NULL, NULL, iv);
-   EVP_CIPHER_CTX_set_padding(&ctx_enc, 0);
+      EVP_CIPHER_CTX_set_key_length(ctx_enc, keysize);
+   EVP_EncryptInit_ex(ctx_enc, NULL, NULL, pkey, NULL);
+   EVP_EncryptInit_ex(ctx_enc, NULL, NULL, NULL, iv);
+   EVP_CIPHER_CTX_set_padding(ctx_enc, 0);
    if (enc_init_first_time)
    {
       sprintf(tmpstr,"%s encryption initialized", cipher_name);
       vtun_syslog(LOG_INFO, tmpstr);
       enc_init_first_time = 0;
@@ -519,17 +522,18 @@
       /* if we're here, something weird's going on */
          return -1;
       break;
    } /* switch(cipher) */
 
-   EVP_CIPHER_CTX_init(&ctx_dec);
-   EVP_DecryptInit_ex(&ctx_dec, cipher_type, NULL, NULL, NULL);
+   ctx_dec = EVP_CIPHER_CTX_new();
+   EVP_CIPHER_CTX_init(ctx_dec);
+   EVP_DecryptInit_ex(ctx_dec, cipher_type, NULL, NULL, NULL);
    if (var_key)
-      EVP_CIPHER_CTX_set_key_length(&ctx_dec, keysize);
-   EVP_DecryptInit_ex(&ctx_dec, NULL, NULL, pkey, NULL);
-   EVP_DecryptInit_ex(&ctx_dec, NULL, NULL, NULL, iv);
-   EVP_CIPHER_CTX_set_padding(&ctx_dec, 0);
+      EVP_CIPHER_CTX_set_key_length(ctx_dec, keysize);
+   EVP_DecryptInit_ex(ctx_dec, NULL, NULL, pkey, NULL);
+   EVP_DecryptInit_ex(ctx_dec, NULL, NULL, NULL, iv);
+   EVP_CIPHER_CTX_set_padding(ctx_dec, 0);
    if (dec_init_first_time)
    {
       sprintf(tmpstr,"%s decryption initialized", cipher_name);
       vtun_syslog(LOG_INFO, tmpstr);
       dec_init_first_time = 0;
@@ -557,11 +561,11 @@
          memset(iv,0,blocksize); free(iv); iv = NULL;
          RAND_bytes(in_ptr, in - in_ptr);
 
          in_ptr = in - blocksize*2;
          outlen = blocksize*2;
-         EVP_EncryptUpdate(&ctx_enc_ecb, in_ptr, 
+         EVP_EncryptUpdate(ctx_enc_ecb, in_ptr, 
             &outlen, in_ptr, blocksize*2);
          *out = in_ptr;
          len = outlen;
          cipher_enc_state = CIPHER_SEQUENCE;
       break;
@@ -584,11 +588,11 @@
    {
       case CIPHER_INIT:
          in_ptr = in;
          iv = malloc(blocksize);
          outlen = blocksize*2;
-         EVP_DecryptUpdate(&ctx_dec_ecb, in_ptr, &outlen, in_ptr, blocksize*2);
+         EVP_DecryptUpdate(ctx_dec_ecb, in_ptr, &outlen, in_ptr, blocksize*2);
          
          if ( !strncmp(in_ptr, "ivec", 4) )
          {
             memcpy(iv, in_ptr+4, blocksize);
             cipher_dec_init(iv);
@@ -627,11 +631,11 @@
                   "Max. gibberish threshold reached");
 #endif
                if (cipher_enc_state != CIPHER_INIT)
                {
                   cipher_enc_state = CIPHER_INIT;
-                  EVP_CIPHER_CTX_cleanup(&ctx_enc);
+                  EVP_CIPHER_CTX_free(ctx_enc);
 #ifdef LFD_ENCRYPT_DEBUG
                   vtun_syslog(LOG_INFO, 
                      "Forcing local encryptor re-init");
 #endif
                }
@@ -708,11 +712,11 @@
          *len -= blocksize;
 
          if (cipher_enc_state != CIPHER_INIT)
          {
             cipher_enc_state = CIPHER_INIT;
-            EVP_CIPHER_CTX_cleanup(&ctx_enc);
+            EVP_CIPHER_CTX_free(ctx_enc);
          }
 #ifdef LFD_ENCRYPT_DEBUG
          vtun_syslog(LOG_INFO, "Remote requests encryptor re-init");
 #endif
       }
@@ -722,11 +726,11 @@
 
          if (cipher_dec_state != CIPHER_INIT &&
              cipher_enc_state != CIPHER_REQ_INIT &&
              cipher_enc_state != CIPHER_INIT)
          {
-            EVP_CIPHER_CTX_cleanup (&ctx_dec);
+            EVP_CIPHER_CTX_free (ctx_dec);
             cipher_dec_state = CIPHER_INIT;
             cipher_enc_state = CIPHER_REQ_INIT;
          }
 #ifdef LFD_ENCRYPT_DEBUG
          vtun_syslog(LOG_INFO, "Local decryptor out of sync");

Hi,

What would be the best practices for configuring vtun client on Android
mobile phone?

I haven't found official support or documentation that would provide more
details.

Kind Regards,
Vladimir Stankovic

Hey Gabe,

An array of RHBZs;  yeesh!  But they still look to stem from the one
issue reported on the debian fork, which is itself without any
assessment.  And the CVE application jammed after review.

Caution's good, to be sure, and the patch is appealingly simple.  But
I'm not sure its affect is so wide, and I want to leave it as-is unless
we can get something closer to stock source.
https://sourceforge.net/p/vtun/bugs/58/ .

I'm going to push 304, I think.  Then let's talk about shrinking the
aftermarket, if the $DayJob lets ya (and I understand only so well!)

 - bish
   eRancher by day, Janitor and Fishmonger by night.

Gabriel L. Somlo wrote:
> Bish,
> 
> check out https://bugzilla.redhat.com/show_bug.cgi?id=1319858
> 
> (particularly the way the reporter closed the bug at the very end --
> after I already applied the out-of-tree patch, out of "an excess of
> caution" :)
> 
> If the links in the closing message confirm your suspicion (that this
> is an unlikely thing to become a *real* problem), that's OK with me.
> This all happened after I had originally emailed you, and meanwhile
> $DAYJOB caught up with me and I stopped closely following the issue...
> 
> I'd be happy to upgrade to 3.0.4 and drop all current "aftermarket"
> patches when you finally get around to doing a release.
> 
> Thanks again for following up,
> --Gabe
> 
> On Sat, Sep 17, 2016 at 04:48:33PM -0400, bishop wrote:
>> Hi Gabriel,
>>
>> Any DOS implications are due to some loop in the client() code or the
>> calling init scaffolding.  The #FridgeArt isn't that robust, but let's
>> assume it's in the client() routine instead.  The log messages - really,
>> anything at all - would be a huge help.
>>
>> I'm looking at the patch, and I'm not sure it's not killing the persist
>> behaviour.
>>
>> Have you seen this happen on a stock+systemd vtun install?  I'm worried
>> that the behaviour's restricted to some code hack that's not present on
>> the upstream.
>>
>> Toss me a link to the project on fedora?  I'd like to know more before
>> 304 goes out.
>>
>>  - bish
>>
>>
>>
>>> Hi,
>>>
>>> I maintain the vtun package in Fedora, and I just had a bug
>>> opened against it (with potential security implications), pointing
>>> at the following Debian bug report:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818489
>>>
>>> Allegedly, under certain conditions, sending a SIGHUP to a client-mode
>>> vtund process can peg the CPU, and generate large amounts of log data
>>> (which is where the security angle comes from, I think).
>>>
>>> The Debian link above contains a patch as well.
>>>
>>> Is this something that could/should be applied upstream
>>> (i.e., in sourceforge CVS) ?
>>>
>>> Thanks much,
>>> --Gabriel
>>>
> 
>> pub  1024D/B6187995 2008-07-25 Bishop (LC957) <bi...@pl...>
>> uid                            Bishop Clark (hpas) <bis...@hp...>
>> uid                            Bishop Clark <bis...@gm...>
>> uid                            Bishop Clark <bis...@gm...>
>> uid                            Bishop Clark (old work) <bis...@hp...>
>> uid                            Bishop Clark (old work) <bis...@hp...>
>> uid                            Bishop Clark (old work) <bc...@ha...>
>> uid                            Bishop Clark (old work) <bis...@go...>
>> uid                            Bishop Clark (work) <bis...@hp...>
>> uid                            Bishop Clark (old work) <bi...@sc...>
>> sub  1024g/F0E863B7 2008-07-25 [expires: 2018-06-11]
>> sub  4096R/0DF6635B 2016-08-27 [expires: 2021-08-26]
>> sub  4096R/400FB98C 2016-08-27 [expires: 2021-08-26]

Hi Gabriel,

Any DOS implications are due to some loop in the client() code or the
calling init scaffolding.  The #FridgeArt isn't that robust, but let's
assume it's in the client() routine instead.  The log messages - really,
anything at all - would be a huge help.

I'm looking at the patch, and I'm not sure it's not killing the persist
behaviour.

Have you seen this happen on a stock+systemd vtun install?  I'm worried
that the behaviour's restricted to some code hack that's not present on
the upstream.

Toss me a link to the project on fedora?  I'd like to know more before
304 goes out.

 - bish



> Hi,
> 
> I maintain the vtun package in Fedora, and I just had a bug
> opened against it (with potential security implications), pointing
> at the following Debian bug report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818489
> 
> Allegedly, under certain conditions, sending a SIGHUP to a client-mode
> vtund process can peg the CPU, and generate large amounts of log data
> (which is where the security angle comes from, I think).
> 
> The Debian link above contains a patch as well.
> 
> Is this something that could/should be applied upstream
> (i.e., in sourceforge CVS) ?
> 
> Thanks much,
> --Gabriel
> 

Bish,

check out https://bugzilla.redhat.com/show_bug.cgi?id=1319858

(particularly the way the reporter closed the bug at the very end --
after I already applied the out-of-tree patch, out of "an excess of
caution" :)

If the links in the closing message confirm your suspicion (that this
is an unlikely thing to become a *real* problem), that's OK with me.
This all happened after I had originally emailed you, and meanwhile
$DAYJOB caught up with me and I stopped closely following the issue...

I'd be happy to upgrade to 3.0.4 and drop all current "aftermarket"
patches when you finally get around to doing a release.

Thanks again for following up,
--Gabe

On Sat, Sep 17, 2016 at 04:48:33PM -0400, bishop wrote:
> Hi Gabriel,
> 
> Any DOS implications are due to some loop in the client() code or the
> calling init scaffolding.  The #FridgeArt isn't that robust, but let's
> assume it's in the client() routine instead.  The log messages - really,
> anything at all - would be a huge help.
> 
> I'm looking at the patch, and I'm not sure it's not killing the persist
> behaviour.
> 
> Have you seen this happen on a stock+systemd vtun install?  I'm worried
> that the behaviour's restricted to some code hack that's not present on
> the upstream.
> 
> Toss me a link to the project on fedora?  I'd like to know more before
> 304 goes out.
> 
>  - bish
> 
> 
> 
> > Hi,
> > 
> > I maintain the vtun package in Fedora, and I just had a bug
> > opened against it (with potential security implications), pointing
> > at the following Debian bug report:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818489
> > 
> > Allegedly, under certain conditions, sending a SIGHUP to a client-mode
> > vtund process can peg the CPU, and generate large amounts of log data
> > (which is where the security angle comes from, I think).
> > 
> > The Debian link above contains a patch as well.
> > 
> > Is this something that could/should be applied upstream
> > (i.e., in sourceforge CVS) ?
> > 
> > Thanks much,
> > --Gabriel
> > 

> pub  1024D/B6187995 2008-07-25 Bishop (LC957) <bi...@pl...>
> uid                            Bishop Clark (hpas) <bis...@hp...>
> uid                            Bishop Clark <bis...@gm...>
> uid                            Bishop Clark <bis...@gm...>
> uid                            Bishop Clark (old work) <bis...@hp...>
> uid                            Bishop Clark (old work) <bis...@hp...>
> uid                            Bishop Clark (old work) <bc...@ha...>
> uid                            Bishop Clark (old work) <bis...@go...>
> uid                            Bishop Clark (work) <bis...@hp...>
> uid                            Bishop Clark (old work) <bi...@sc...>
> sub  1024g/F0E863B7 2008-07-25 [expires: 2018-06-11]
> sub  4096R/0DF6635B 2016-08-27 [expires: 2021-08-26]
> sub  4096R/400FB98C 2016-08-27 [expires: 2021-08-26]

My question is as follows: I can create a TUN-device from my C++
program. Works all fine. Also setting the line encapsulation to ax25
succeeds. But setting the hardware address always fails with not
supported. I think one needs to set the hardware address so that the
kernel knows it should process the packets as if they came in through a
regular route (e.g. a packet radio modem).

Can you enlighten me?
Thanks in advance.


Folkert van Heusden

p.s. I've also asked this at the stackoverflow.com forum:
http://stackoverflow.com/questions/22465138/creating-a-tun-network-device-with-ax-25-encapsulation

http://kyokushin-kctl.com/work.at.home.n.php?ID=467

http://afdfrance.fr/facebook.com.weightdropn.php?ID=338

Dear all,

I am working with 6LowPAN network where i have edge router and sensor
nodes. The edge router provides tun0 interfacec using the SLIP program
at the PC side. Using this it is possible to forward the packets to
any node and also recieve from them at tun0 interface. I wrote a UDP
application that forwards packets between nodes and the router. When I
open wireshark I can see the packets. Now I want to create a tunnel
between the UDP IPV6 packets arriving and send them to ethernet
interface. Can anyone tell how I can do this??I am happy both way IPv4
to IP6 or IPv6 to IPv4

http://exxon.dtiltas.lt/www.foxnews.report.news24.php

Hi Sergey,
Sergey Popov wrote:
> No, i did not file a ticket. Please do,

I've filed artifact 3540779.

> if it is necessary

What an odd question.  Unless only gentoo gets a bug tracker, then of 
course it's necessary!  ;-)

Thanks for the patch.  I know I would've missed that one for sure.

  - bish

05.07.2012 05:34, bishop wrote:
> Hey Sergey,
> 
> Did you file a ticket with the patch yet?  I can if you haven't.
> 
>  - bish
> 
> 
> Sergey Popov wrote:
>> It's a some kind of racing condition on cfg_file.tab.h file, that can be
>> needed when it's not built yet. That's why - compilation fails with such
>> error:
>>
>> cfg_file.l:30:26: fatal error: cfg_file.tab.h: No such file or directory
>>
>> More details(and patch for fixing this problem) -
>> https://bugs.gentoo.org/show_bug.cgi?id=364923
>>

No, i did not file a ticket. Please do, if it is necessary

Hey Sergey,

Did you file a ticket with the patch yet?  I can if you haven't.

  - bish


Sergey Popov wrote:
> It's a some kind of racing condition on cfg_file.tab.h file, that can be
> needed when it's not built yet. That's why - compilation fails with such
> error:
>
> cfg_file.l:30:26: fatal error: cfg_file.tab.h: No such file or directory
>
> More details(and patch for fixing this problem) -
> https://bugs.gentoo.org/show_bug.cgi?id=364923
>
> ------------------------------------------------------------------------------
> 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/
> _______________________________________________
> VTun-devel mailing list
> VTu...@li...
> https://lists.sourceforge.net/lists/listinfo/vtun-devel
>

It's a some kind of racing condition on cfg_file.tab.h file, that can be
needed when it's not built yet. That's why - compilation fails with such
error:

cfg_file.l:30:26: fatal error: cfg_file.tab.h: No such file or directory

More details(and patch for fixing this problem) -
https://bugs.gentoo.org/show_bug.cgi?id=364923

Hi

I am not sure where else to report this, but I would like to report a problem.

1. I create a tap device using "tunctl -t tap-test".

2. I then configure it with an ip address using "ifconfig tap-test
10.0.0.1 up".

3. Next. I start "arping -I tap-test 10.0.0.5" on one terminal and

4. I run "tcpdump -i tap-test" on another terminal to see if I can see
the ARP packets on the tap interface tap-test

I tried the above steps on two separate machines one where the linux
kernel version (determined by uname -r) says 3.0.0-17-generic and
another one where it says 2.6.32-5-amd64 . I am wondering if something
changed in the driver between the kernel versions or whether some
kernel variable is filtering out these ARP messages.


Anirudh

Hello,

I made a patch to fix a bug against persistant dev and to add keepalive on client side.

How can i submit it ?

-- 

        Bert.

Hi again,

I have not reached very far. I just started in my early networking-days
with vtun and i like it because i think it is straight forward for
routed widearea wireless networks, where pppoe has a lot of
limitations. 

We have several hundred clients connected via vtun and what i really need is a simple database integration, which allows us to add/remove users with speed-option, allow/deny access (or just automatic kill removed users), serve ips  dinamically and get states and traffic statistics like the stats option gives. 
I think vtund only lacks a feature for passing dhcp-ips to client like it does with the speed option. 
Reading config from a textfile or db and log stats to textfile or db shouldn't be  
a big challenge, i think. As a dirty hack we can even parse db to vtund.conf after every change, reload 
config if there are changes and parse stats to db.

 


El lun, 12-04-2010 a las 14:58 -0700, bishop escribió:
> Hi Christian,
> 
> Are you planning to build a module for VTun that will provide AAA 
> integration like this?  It currently works on a shared key, as you know, 
> which a lot like PPP's history.  Without the path already charted by 
> PPP's addition of external modules, I'd expect the migration to an 
> external PWDB to be a lot more challenging than it is now.
> 
> It sounds like an itch that you've been wanting to scratch for a while, 
> now.  How far have you reached?
> 
>   - bish
> 
> Christian Rodler wrote:
> > Hi
> > i want to ask if anyone is interested in adding "some" features  to vtund.
> >
> > We are using vtun for years in a comunity-based wireless internet
> > provider to connect the clients.
> > There are several advantages over the generally used pppoe for us like
> > built-in traffic shaping  and  more important udp  tunnels.
> > Thanks to packet aggregation,  long range wireless links  serve much
> > higher throuput  for udp  traffic  then  connection-oriented protocols.
> >
> >
> > Now the other side:
> > The file-based config goes something unhandy when you have to manage
> > several hundreds of clients. Accounting via stats  and
> > dhcp for client side tunnel-ip  isn't easy.
> >
> > So here comes the wishlist:
> >
> > server integration with radius like  rp-pppoe  with attributes for
> > speed  and acounting.
> >
> >
> > Anybody interested in this vtun-ng ?
> 

Hi Christian,

Are you planning to build a module for VTun that will provide AAA 
integration like this?  It currently works on a shared key, as you know, 
which a lot like PPP's history.  Without the path already charted by 
PPP's addition of external modules, I'd expect the migration to an 
external PWDB to be a lot more challenging than it is now.

It sounds like an itch that you've been wanting to scratch for a while, 
now.  How far have you reached?

  - bish

Christian Rodler wrote:
> Hi
> i want to ask if anyone is interested in adding "some" features  to vtund.
>
> We are using vtun for years in a comunity-based wireless internet
> provider to connect the clients.
> There are several advantages over the generally used pppoe for us like
> built-in traffic shaping  and  more important udp  tunnels.
> Thanks to packet aggregation,  long range wireless links  serve much
> higher throuput  for udp  traffic  then  connection-oriented protocols.
>
>
> Now the other side:
> The file-based config goes something unhandy when you have to manage
> several hundreds of clients. Accounting via stats  and
> dhcp for client side tunnel-ip  isn't easy.
>
> So here comes the wishlist:
>
> server integration with radius like  rp-pppoe  with attributes for
> speed  and acounting.
>
>
> Anybody interested in this vtun-ng ?

Hi
i want to ask if anyone is interested in adding "some" features  to vtund.

We are using vtun for years in a comunity-based wireless internet 
provider to connect the clients.
There are several advantages over the generally used pppoe for us like 
built-in traffic shaping  and  more important udp  tunnels.
Thanks to packet aggregation,  long range wireless links  serve much 
higher throuput  for udp  traffic  then  connection-oriented protocols.


Now the other side:
The file-based config goes something unhandy when you have to manage 
several hundreds of clients. Accounting via stats  and
dhcp for client side tunnel-ip  isn't easy.

So here comes the wishlist:

server integration with radius like  rp-pppoe  with attributes for 
speed  and acounting. 


Anybody interested in this vtun-ng ?

Hi Guys,

Vladimir's post was eaten by the list server and me.

This should be it, though.  Any comments?

   - bish

Hello, VTUN developers,

Does VTUN have the plan to support IPv6?

In environment of only IPv6, IPSec seems to become a
standard VPN technology. However, VTUN is very
convenient in the dual stack environment of IPv6 and
IPv4, if VTUN supports both.

I implemented my poor patches, though development for
IPv6 of VTUN may be started already.

  1. vtun-3.0.1-ipv6bone.patch

     This patch enables that VPN connection via IPv6
     bone.

  2. vtun-3.0.1-ipv6linuxtun.patch

     This patch enables that the IPv6 packet can be
     passed in VPN tunnel of Linux TUN (not TAP)
     device. I referred OpenVPN code.

But there are the following problems still in my poor
patches...

  - Only "getaddrinfo()" (POSIX.1-2001) is used for
    name resolution. Therefore OS which doesn't support
    IPv6 can't compile and use VTUN.
    It's better to support both of old gethostbyname()
    and new getaddrinfo() by using GNU autoconf.

  - In IPv6, the option "bindaddr{ iface ... }" doesn't
    work well. Because one network device has two or
    more IPv6 addresses. 

  - The function to pass IPv6 via TUN is implemented for
    only Linux because of the limitation of my test
    environment.

Please refer the attacted patch file. If this patch can
be useful even a little for official IPv6 development,
I'm very glad.

Thanks,

--
Yasuyuki

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

Hi,

as vtun 3.x uses a new encryption module, vtun 2.6 clients
fails to connect to a v3.x server.

For 3.x clients that connects to a 2.6 server, there is a fall-back 
solution, but not for 2.6 clients to a 3.x server.

Attached is a patch that allows 2.6 clients to connect to a 3.2 server.
Use oldblowfish128ecb as encryption method.

Kind regards,
 	Ingo Flaschberger

On Mon, Mar 16, 2009 at 09:16:51PM +0000, Nick Martin wrote:
> Is there anything special you need to do to a tun device for the traffic 
> coming from it to be forwarded? I have some traffic coming in from a tun 
> device (the traffic has the same source address as my eth1 device, is 
> this a problem?), that should be forwarded, but it seems to be getting 
> dropped.
> 
> cat /proc/sys/net/ipv4/ip_forward gives 1. I think I have the routing 
> table set up properly. I have a separate table for traffic coming in on 
> the device which I use by: ip rule add iif tun1 table tun_table

 Check your routes with "ip route get <to> from <from> iif tun1".

> By setting up iptables rules with target LOG in the mangle table, I can 
> see the traffic coming in to PREROUTE, but it never gets to FORWARD and 
> I can't figure out why.

 Probably your packets are dropped by the reverse path filters.

 Try to set log_martians=1 on every interface to catch (see kernel log)
 and rp_filter=0 to overcome this. However, reverse path problems
 are hints that there is some configuration error, so you should
 inspect your setup, looking for better routing scheme.
-- 
 Eugene Berdnikov

Hi,

Is there anything special you need to do to a tun device for the traffic 
coming from it to be forwarded? I have some traffic coming in from a tun 
device (the traffic has the same source address as my eth1 device, is 
this a problem?), that should be forwarded, but it seems to be getting 
dropped.

cat /proc/sys/net/ipv4/ip_forward gives 1. I think I have the routing 
table set up properly. I have a separate table for traffic coming in on 
the device which I use by: ip rule add iif tun1 table tun_table

By setting up iptables rules with target LOG in the mangle table, I can 
see the traffic coming in to PREROUTE, but it never gets to FORWARD and 
I can't figure out why.

Thanks for any help.

Nick M.