> My understanding of dhcp is that the client is supposed to
> automatically reconfigure on lease expiration
Yes.
> or whenever the link goes up and down.
Not necessarily, and that's the problem.
> I suppose it's possible that there are dhcp clients
> that exit when the link goes down and must
On 03/09/2010 11:27:13 AM, David Sommerseth wrote:
> On 09/03/10 17:41, Karl O. Pinc wrote:
> > On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> >
> >>> Over-automating things will cause people headaches.
> >>> You don't want to willy-nilly startup a dhcp client
> >>> and have all your interfac
Karl O. Pinc wrote:
> I'm not at all sure it solves the core issues, which is that
> an already running dhcp client won't have auto-detected
> the tap interface that OpenVPN creates -- iff OpenVPN is
> started after the dhcp client.
Note that several DHCP clients only handle one interface per DHC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/10 17:41, Karl O. Pinc wrote:
> On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
>
>>> Over-automating things will cause people headaches.
>>> You don't want to willy-nilly startup a dhcp client
>>> and have all your interfaces configured w
Perhaps allow me to provide an example to give you a better picture.
I extracted the following information:
Data
Channel Encrypt: HMAC KEY: 7bc9e462
32dd2b4c 3c8a3108 39d1b38e d58bf293
Data Channel Decrypt: HMAC KEY: 5c6e268f addae698 8728b25d bc0fb5cd d84f4729
ENCRYPT IV:
a947f77f 0db28c61 8
On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> > Over-automating things will cause people headaches.
> > You don't want to willy-nilly startup a dhcp client
> > and have all your interfaces configured with dhcp without
> > your consent.
>
> Exactly! Which again moves it more in the directi
Dear all,
I was trying to run some tests on OpenVPN
implementation. Realise HMAC computation for Data and Control channel
does not match my computation. I have use the same computation on
TLS-PRF's HMAC and it matches perfectly. Anyone has any idea what this
problem could be? Is it a bug?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/10 16:34, James Yonan wrote:
>> looking at the multitude of DHCP clients available for unix, the completely
>> different handling of DHCP on MacOS, and the issues that most unix clients
>> seem to have with "DHCP active on two different interf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/10 16:58, Karl O. Pinc wrote:
> On 03/09/2010 08:05:17 AM, David Sommerseth wrote:
>
>> On the other hand, ./configure
>> could try to detect which DHCP client the system got and could use
>> that
>> as a default client to kick off.
>
> I t
On 03/09/2010 08:01:32 AM, Stefan Monnier wrote:
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
>
> That is a misconfiguration in my book. The only correct
> configuration
> is when the dhcp client is triggered from the interfa
On 03/09/2010 08:05:17 AM, David Sommerseth wrote:
> On the other hand, ./configure
> could try to detect which DHCP client the system got and could use
> that
> as a default client to kick off.
I think this might cause more problems than it solves because
there's no guarantee that build hosts w
On 03/09/2010 12:47:36 AM, Peter Stuge wrote:
> Karl O. Pinc wrote:
> > The boot order that makes sense to me is:
> >
> > bring the interfaces up
> > start dhcp client (if not triggered directly from the interfaces)
> > start openvpn
> >
> > The problem is that if the dhcp client is started befor
looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...
On Mon, Mar 08, 2010 at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/03/10 15:34, David Sommerseth wrote:
> From: Vladimir I. Kobylyanskiy
>
> We (Ltd. LISSI, http://www.lissi.ru, info at lissi.ru),
> are trying to use OpenVPN with stream ciphers,
> including Russian cipher GOST
> 28147-89(ALLOW_NON_CBC_CIPHERS
From: Vladimir I. Kobylyanskiy
We (Ltd. LISSI, http://www.lissi.ru, info at lissi.ru),
are trying to use OpenVPN with stream ciphers,
including Russian cipher GOST
28147-89(ALLOW_NON_CBC_CIPHERS flag is set).
And we found the bug:
function EVP_CipherFinal() returns 0, when cipher has
block_size
hi
the debug test codes in OpenVPN are as follow, but the HMAC output is wrong.
Did I missed out anything?
regards
Frances
static void init_hmac (HMAC_CTX *ctx, const EVP_MD *digest,
struct key *key, const struct key_type *kt, const char *prefix)
{
struct gc_arena gc = gc_new ();
HMA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/03/10 17:14, Karl O. Pinc wrote:
> On 03/08/2010 09:21:35 AM, James Yonan wrote:
>> OpenVPN 2.1 has a relatively recent feature that allows a TAP-based
>> OpenVPN session to be established where the client gets its IP
>> address
>>
[...snip...]
> bring the interfaces up
> start dhcp client (if not triggered directly from the interfaces)
> start openvpn
That is a misconfiguration in my book. The only correct configuration
is when the dhcp client is triggered from the interface. After all,
openvpn may take half an hour to get the connect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/03/10 15:47, James Yonan wrote:
> I believe this has been discussed before, but I noticed recently that a
> Linux-based OpenVPN client (Linux 2.6.24, OpenVPN 2.1.1) spends a lot
> more CPU time in kernel space than in user space. This is surpr
hi Jan
Thanks.
yes, the keys file was generated using the openvpn genkey function. The
display was generated during the OpenVPN keys establishment phase. The keys
are verified to be correct. Just that the HMAC generation output does not
tally. In fact, I found that only the TLS PRF HMAC generati
Hi Frances,
froggu 21 wrote:
hi all
May I know whether you have successfully verified the HMAC generated
by OpenVPN? I found that the HMAC value generated by the OpenVPN does
not tally with the HMAC value generated from the OpenSSL directly. I
wonder is there any incorrect implementation of
Karl O. Pinc wrote:
> The boot order that makes sense to me is:
>
> bring the interfaces up
> start dhcp client (if not triggered directly from the interfaces)
> start openvpn
>
> The problem is that if the dhcp client is started before openvpn
> and openvpn is creating the tap interface then it'
hi all
May I know whether you have successfully verified the HMAC generated by
OpenVPN? I found that the HMAC value generated by the OpenVPN does not tally
with the HMAC value generated from the OpenSSL directly. I wonder is there
any incorrect implementation of HMAC by OpenVPN?
please see result
hi all
May I know whether you have successfully verified the HMAC generated by
OpenVPN? I found that the HMAC value generated by the OpenVPN does not tally
with the HMAC value generated from the OpenSSL directly. I wonder is there
any incorrect implementation of HMAC by OpenVPN?
please see result
On 03/08/2010 05:09:49 PM, Stefan Monnier wrote:
> >> I think if the user just starts the dhcp client on an interface
> >> independently from the moment the interface goes up (or down),
> this
>
> >> is simply a misconfiguration.
> > I'm not sure I understand. Are you saying that manually starti
25 matches
Mail list logo
