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
To: vtun-devel@lists.sourceforge.net
Hey folks,
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 a
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
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.
- b
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 er
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
exter
Hi Guys,
Vladimir's post was eaten by the list server and me.
This should be it, though. Any comments?
- bish
--- Begin Message ---
Hi, all.
It my the new year holiday work with vtund 3.0.1 :)
IPv4+TCP/UDP/ICMP header compressor for a tun-device only IPv4 packets.
Typical size less is 2
Hello Nick,
tun.c:460: case TUNSETNOCSUM:
tun.c:461: /* Disable/Enable checksum */
tun.c:462: if (arg)
tun.c:463: tun->flags |= TUN_NOCHECKSUM;
tun.c:464: else
tun.c:465: tun->flags &= ~TUN_NOCHECKSUM;
tun.c:466:
Hey Dragos,
That's a great patch, and it looks like you've spent a lot of work on
it. I'll try and get some time to merge it in this weekend.
Thanks for doing all the hard work.
- bish
Dragos Vingarzan wrote:
> Hi bish,
>
> attached you have a new patch:
> - this time against the CVS HEAD
Hi Roderick,
With the version of vtun in openwrt (WR on 54GLs and 500GPs here), I'm
surprised you can do very much at all!
A new UDP method sounds like a new protocol, really, more than a
modification to an existing one. I'm disappointed we don't have a good
framework for add-on modules for vtun
Hi Dragos,
I think your patch has definite value, as it can help overcome a
potential problem when traversing firewalls. There is value in keeping
this code in the codebase, so that further development won't prevent you
from using this method to navigate this somewhat broken kind of NAT.
I wo
Hi Noam,
The minimum speed of 8k is set in lfd_shaper.c:
> 50: max_speed = host->spd_out / 8 * 1024;
It's primitive, but that's the number. It could be (hacked out to a
#define and then) tuned to a lower number, if you wanted, but it would
be a compilation you'd have to build and support o
12 matches
Mail list logo
