> You are right in regards to dynamic memory allocation. You're using
> static array allocation, defined by MAX_IPS_PER_HOSTNAME. This value is
> set to 100. Where did you take this number from? IMHO, that sounds to
> be fairly high.
Actually, I don't use static allocation but stack allocation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/02/10 04:18, Stefan Monnier wrote:
>> You are right in regards to dynamic memory allocation. You're using
>> static array allocation, defined by MAX_IPS_PER_HOSTNAME. This value is
>> set to 100. Where did you take this number from? IMHO, tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/02/10 23:23, Eric F Crist wrote:
> How is -devel being numbered, and how are we handling snapshots for
> propagation of -devel versions? I've spoken with Matthias Andree, the
> FreeBSD port maintainer, and he'll be handing maintainership to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys!
On 18/02/10 22:45, JuanJo Ciarlante wrote:
> On Wed, Feb 17, 2010 at 6:46 PM, JuanJo Ciarlante
wrote:
>
>> I still need to do some touches for allmerged, as
>> we conflict w/ Gert's IPv6 patch on a mroute.c chunk
>> IIRC.
>
Even though I kno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/02/10 22:45, JuanJo Ciarlante wrote:
> On Wed, Feb 17, 2010 at 6:46 PM, JuanJo Ciarlante wrote:
>> > Hi David,
>> >
>> > On Tue, Feb 16, 2010 at 7:49 PM, David Sommerseth
>> > wrote:
>
> Greetings all!
>
> I am now announcing the openvpn-test
Hey David,
On Fri, Feb 19, 2010 at 12:14 PM, David Sommerseth
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 18/02/10 22:45, JuanJo Ciarlante wrote:
>> On Wed, Feb 17, 2010 at 6:46 PM, JuanJo Ciarlante wrote:
>>> > Hi David,
>>> >
>>> > On Tue, Feb 16, 2010 at 7:49 PM, David Som
Hi
Karl O. Pinc wrote:
> So, unless you're pulling names out of /etc/hosts it's likely
> that randomization does nothing. And if the bind administrator
> has gone to the extra work to enable a fixed ordering of
> RR records then randomization destroys his work.
That's entirely dependent on the D
Hi,
Here's the summary of last week's meeting. The initial feature
deprecation process is described in it, as well as here:
http://www.secure-computing.net/wiki/index.php/OpenVPN/Developer_documentation
As we all need to follow the process, please let if there are any
problems with it. There's d
> Hi,
>
> Here's the summary of last week's meeting. The initial feature
> deprecation process is described in it, as well as here:
>
> http://www.secure-computing.net/wiki/index.php/OpenVPN/Developer_documentation
>
> As we all need to follow the process, please let if there are any
> problems wi
Hi,
On Fri, Feb 19, 2010 at 12:10:29PM +0100, David Sommerseth wrote:
> >> I still need to do some touches for allmerged, as
> >> we conflict w/ Gert's IPv6 patch on a mroute.c chunk
> >> IIRC.
>
> Even though I know you both have told me that there would be a merge
> conflict in mroute.c, I deci
David Sommerseth wrote:
> I believe there are som better ways to catch the last commit ID,
git rev-list HEAD -1
//Peter
On Fri, Feb 19, 2010 at 2:46 PM, Gert Doering wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 12:10:29PM +0100, David Sommerseth wrote:
>> >> I still need to do some touches for allmerged, as
>> >> we conflict w/ Gert's IPv6 patch on a mroute.c chunk
>> >> IIRC.
>>
>> Even though I know you both have tol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/02/10 14:46, Gert Doering wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 12:10:29PM +0100, David Sommerseth wrote:
I still need to do some touches for allmerged, as
we conflict w/ Gert's IPv6 patch on a mroute.c chunk
IIRC.
>>
>> Even t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/02/10 15:21, JuanJo Ciarlante wrote:
> On Fri, Feb 19, 2010 at 2:46 PM, Gert Doering wrote:
[...snip...]
>> The existing
>> code doesn't do reverse DNS lookups for IPv4 mroute printing, and so
>> the IPv6 code should behave similar to the IPv4 c
Hi,
On Fri, Feb 19, 2010 at 03:21:34PM +0100, JuanJo Ciarlante wrote:
> > JJO's patch does more than that, he does DNS lookups to print the
> > DNS name for the IPv6 address in question.
>
> Wrong.
> From getaddrinfo(3):
>"""
> If hints.ai_flags contains the AI_NUMERICHOST flag then the
Hi,
On Fri, Feb 19, 2010 at 03:34:41PM +0100, David Sommerseth wrote:
> So I lean towards JJO here, as far as possible, avoid using functions
> which are not thread safe.
I'm not yet convinced that inet_ntop() is actuall not thread-save -
but independent of that, it's not a tie-breaker here :-)
Hi,
On Fri, Feb 19, 2010 at 03:29:48PM +0100, David Sommerseth wrote:
> I'm fine with whichever path you choose. But just bear in mind, some
> systems might not have IPv6 support - which breaks portability ...
On the unixish side, there is no system which has tun/tap today but
does not have IPv
On Feb 19, 2010, at 08:56:23, Gert Doering wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 03:29:48PM +0100, David Sommerseth wrote:
>> I'm fine with whichever path you choose. But just bear in mind, some
>> systems might not have IPv6 support - which breaks portability ...
>
> On the unixish side, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiled the master branch from openvpn-testing.git on Fedora 12, and
noticed these warnings:
-
ssl.c: In function ‘verify_callback’:
ssl.c:944: warning: passing argument 1 of ‘
On 02/19/2010 06:25:10 AM, Siim Põder wrote:
> Hi
>
> Karl O. Pinc wrote:
> > So, unless you're pulling names out of /etc/hosts it's likely
> > that randomization does nothing. And if the bind administrator
> > has gone to the extra work to enable a fixed ordering of
> > RR records then randomiza
On 02/19/2010 06:48:44 AM, Samuli Seppänen wrote:
> Btw. what do you think about including the full IRC chatlog in these
> emails?
I like it. (And don't see the point in having a separate attachment
either. It's just one more thing to have to click on.)
Karl
Free Software: "You don't pay b
On 02/19/2010 03:02:40 AM, David Sommerseth wrote:
> On 19/02/10 04:18, Stefan Monnier wrote:
> >
> > If it's a config var, it could indeed just be a global var, so I
> don't
> > think it would be very complex. But that's really not something
> the
> > user should have to configure.
>
> That de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/02/10 17:05, Karl O. Pinc wrote:
> On 02/19/2010 03:02:40 AM, David Sommerseth wrote:
>> On 19/02/10 04:18, Stefan Monnier wrote:
>
>>>
>>> If it's a config var, it could indeed just be a global var, so I
>> don't
>>> think it would be very comp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
With --verb 5, openvpn logs a single letter (rwRW) for each package
received or sent. I recently ran into a problem with the tun device on
Linux where the read from that device returned 0. Unfortunately this was
also logged as "r", which made me assume
Hi,
On Fri, Feb 19, 2010 at 05:37:48PM +0100, David Sommerseth wrote:
> ACK
>
> Patch looks sensible, and applies cleanly to the master branch.
ACK. I can see the reason for doing so (as I'll have a device "soon"
that will return 0 from tun device reads under certain circumstances)
and it does
Hi,
On Fri, Feb 19, 2010 at 05:18:29PM +0100, David Sommerseth wrote:
> I initially meant a more dynamic approach, changing it via the config
> file at runtime - by modifying a global C variable. But I agree, doing
> it via the ./configure script should really be sufficient.
ACK.
gert
--
USE
>> I'm fine with whichever path you choose. But just bear in mind, some
>> systems might not have IPv6 support - which breaks portability ...
> On the unixish side, there is no system which has tun/tap today but
> does not have IPv6.
What about embedded systems using uclibc compiled "without ipv6
Hi,
On Fri, Feb 19, 2010 at 12:50:10PM -0500, Stefan Monnier wrote:
> >> I'm fine with whichever path you choose. But just bear in mind, some
> >> systems might not have IPv6 support - which breaks portability ...
> > On the unixish side, there is no system which has tun/tap today but
> > does no
Hi,
On Fri, Feb 19, 2010 at 02:48:44PM +0200, Samuli Seppänen wrote:
> Here's the summary of last week's meeting.
Thanks,
> Btw. what do you think about including the full IRC chatlog in these
> emails? It would make it much easier to see exactly what was discussed.
> After all, the summary is
Hi,
On Fri, Feb 19, 2010 at 08:33:04PM +0100, Gert Doering wrote:
> > [uclibc without UCLIBC_HAS_IPV6]
>
> I have to investigate.
And so I did. The impact of UCLIBC_HAS_IPV6=0 is fairly low:
- getaddrinfo() will not resolve IPv6 addresses (but *will* be available)
- the external globals in6
On 02/19/2010 04:42:49 PM, Gert Doering wrote:
> - the external globals in6addr_any and in6addr_loopback will not
>be compiled in (in6_addr.c).
>
>** I expect this to cause linking problems for my code **
> As said: I would welcome contact to someone who is using
> uClibc+OpenVPN
> and
From: David Sommerseth
(I'm withdrawing the first version, and suggesting this patch to be used
instead,
as this one follows the new feature deprecation process.)
Based on a discussion on the mailing list and in the IRC meeting Feb 18,
it was decided to remove get_random() from the getaddr() fu
On 02/19/2010 04:57:30 PM, David Sommerseth wrote:
Am I wrong or does using --disable-depr-random-resolv
not remove the random choice?
> From: David Sommerseth
> For now this feature is enabled by default, but can be disabled by
> running
> ./configure with --disable-depr-random-resolv. In th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/10 00:06, Karl O. Pinc wrote:
> On 02/19/2010 04:57:30 PM, David Sommerseth wrote:
>
> Am I wrong or does using --disable-depr-random-resolv
> not remove the random choice?
That is correct. According to the newly agreed feature removal proc
34 matches
Mail list logo
