From nmav at gnutls.org  Sun Feb  1 21:09:25 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Sun,  1 Feb 2004 22:09:25 +0200
Subject: [Help-gnutls] gnutls_bye(), return values, and looping
In-Reply-To: <1075488268.3272.21.camel@posthaste.boston.ximian.com>
References: <1075488268.3272.21.camel@posthaste.boston.ximian.com>
Message-ID: <1075666165.401d5cf57390b@mail.hellug.gr>

Quoting Joe Shaw <joe at ximian.com>:

> Hi,
> 
> I am a little confused about how exactly to handle the return values
> from gnutls_bye().  I have some code which does the following:
> 
>         do {
>         	ret = gnutls_bye (chan->session, GNUTLS_SHUT_RDWR);
>         } while (ret == GNUTLS_E_INTERRUPTED ||
>         	 ret == GNUTLS_E_AGAIN);
>         
> In almost every case, this works out just fine, and I can close the file
> descriptor after that.
> I'm running into a problem on one of our test machines, though, that
> gnutls_bye() always returns GNUTLS_E_AGAIN, causing an infinite loop and
> using 100% CPU.
[...]
> Perhaps more importantly, is there any steadfast reason why it'd always
> return AGAIN?  Could it be a bug in GnuTLS that removing my do-while
> would really just be papering over?  Any info would be helpful.

GNUTLS_E_AGAIN is returned because the underlying layer (recv or send)
returned EAGAIN. gnutls does not use this error value.

> Thanks,
> Joe


-- 
nmav at gnutls.org




From joe at ximian.com  Sun Feb  1 21:47:11 2004
From: joe at ximian.com (Joe Shaw)
Date: Sun, 01 Feb 2004 15:47:11 -0500
Subject: [Help-gnutls] gnutls_bye(), return values, and looping
In-Reply-To: <1075666165.401d5cf57390b@mail.hellug.gr>
References: <1075488268.3272.21.camel@posthaste.boston.ximian.com>
	<1075666165.401d5cf57390b@mail.hellug.gr>
Message-ID: <1075668430.9140.203.camel@cairn.cancerclam>

On Sun, 2004-02-01 at 15:09, Nikos Mavroyanopoulos wrote:
> GNUTLS_E_AGAIN is returned because the underlying layer (recv or send)
> returned EAGAIN. gnutls does not use this error value.

Ok, recv(2) says that EAGAIN would be returned if the socket was
nonblocking (which it is) and there are no messages to be read.  Is it
safe then to ignore the GNUTLS_E_AGAIN value (and therefore check only
GNUTLS_E_INTERRUPTED) and then close the file descriptor?  Are the
examples in the docs correct in ignoring the return values?

Thanks,
Joe





From nmav at gnutls.org  Mon Feb  2 16:47:23 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Mon,  2 Feb 2004 17:47:23 +0200
Subject: [Help-gnutls] gnutls_bye(), return values, and looping
In-Reply-To: <1075668430.9140.203.camel@cairn.cancerclam>
References: <1075488268.3272.21.camel@posthaste.boston.ximian.com>
	<1075666165.401d5cf57390b@mail.hellug.gr>
	<1075668430.9140.203.camel@cairn.cancerclam>
Message-ID: <1075736843.401e710ba464b@mail.hellug.gr>

Quoting Joe Shaw <joe at ximian.com>:

> On Sun, 2004-02-01 at 15:09, Nikos Mavroyanopoulos wrote:
> > GNUTLS_E_AGAIN is returned because the underlying layer (recv or send)
> > returned EAGAIN. gnutls does not use this error value.
> Ok, recv(2) says that EAGAIN would be returned if the socket was
> nonblocking (which it is) and there are no messages to be read.  Is it
> safe then to ignore the GNUTLS_E_AGAIN value (and therefore check only
> GNUTLS_E_INTERRUPTED) and then close the file descriptor?  Are the
> examples in the docs correct in ignoring the return values?
The examples in the documentation are with blocking servers
(and the error checking is almost inexistant). To avoid this
case you could use gnutls_bye() with _WR only and either
wait for an EOF from gnutls_recv() or just close the socket.

> Thanks,
> Joe

-- 
nmav at gnutls.org




From joe at ximian.com  Tue Feb  3 17:28:34 2004
From: joe at ximian.com (Joe Shaw)
Date: Tue, 03 Feb 2004 11:28:34 -0500
Subject: [Help-gnutls] gnutls_bye(), return values, and looping
In-Reply-To: <1075817786.401fad3a4ef1d@mail.hellug.gr>
References: <1075488268.3272.21.camel@posthaste.boston.ximian.com>
	<1075666165.401d5cf57390b@mail.hellug.gr>
	<1075668430.9140.203.camel@cairn.cancerclam>
	<1075736843.401e710ba464b@mail.hellug.gr>
	<1075817786.401fad3a4ef1d@mail.hellug.gr>
Message-ID: <1075825713.13825.3.camel@posthaste.boston.ximian.com>

On Tue, 2004-02-03 at 16:16 +0200, Nikos Mavroyanopoulos wrote:
> I just thought that if you wait for an EOF, you'll probably
> have the same E_AGAIN error condition as before. You should just
> close the socket after sending the bye.

Yeah, I am now ignoring the E_AGAIN error and just closing it after it
returns, as long as it's not E_INTERRUPTED and the loop appears to be
fixed.

Thanks for your help,
Joe





From subscript at free.fr  Sat Feb  7 22:36:12 2004
From: subscript at free.fr (wwp)
Date: Sat, 7 Feb 2004 22:36:12 +0100
Subject: [Help-gnutls] gnutls 0.9.90 compilation issues
Message-ID: <20040207223612.49052d1c@tethys.solarsys.org>

Hi there,


I'm trying to compile gnutls 0.9.90 against:
	gnupg 1.2.4,
	libgcrypt 1.1.91,
	libgpg-error 0.6 and
	opencdk 0.5.3
w/ gcc 3.2, glibc 2.2.5, and noticed that there are a few unresolved references to
	CDK_KBNODE
that I had to manually replace with
	cdk_knode_t

Also, a proto mismatch around libextra/opengpg/openpgp.{ch}, one declares:
	int gnutls_openpgp_key_get_pk_algorithm( gnutls_openpgp_key key, int *r_bits);
whereas the other one implements:
	int gnutls_openpgp_key_get_pk_algorithm( gnutls_openpgp_key key, unsigned int *r_bits);
which leads to a compilation error on my side.

But after, make fails in src, complaining about:
	../lib/.libs/libgnutls.so: undefined reference to `_gcry_generate_elg_prime'
whereas the right libgcrypt.so is included in make's gcc command and the libgcrypt.so
that corresponds defines this _gcry_generate_elg_prime symbol (from primegen.c).

Did I miss smth or tried w/ unsupported libs maybe?


Regards,

-- 
wwp




From bbp at via.ecp.fr  Fri Feb 13 19:38:14 2004
From: bbp at via.ecp.fr (Brieuc Jeunhomme)
Date: Fri, 13 Feb 2004 19:38:14 +0100
Subject: [Help-gnutls] exporting session information from one process to
	another
Message-ID: <20040213183814.GA16476@via.ecp.fr>

Hello,

I need to export session information from one process to another
process. Simply put, I have a first process that accept()s a
connection, allocates credentials, sets certificate information etc,
then fork()s.

The child process handles the handshake (it calls gnutls_handshake()),
but, once the handshake is complete, I would like the parent process to
use the connection, calling gnutls_record_send and gnutls_record_recv.

I have tryed this with 1.0.5, using gnutls_session_set_data and
gnutls_session_get_data to exchange the session information between the
two processes, but this doesn't seem to be enough (gnutls_record_send
works fine if called from the child process, but not from the parent
process. However, the goal is to have the child process exit after the
negociation and have the parent process use the established session).

Is there a way to do this with the current gnutls library ? If not,
would people here be interested in a patch for this ?

-- 
BBP




From nmav at gnutls.org  Fri Feb 13 22:22:24 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Fri, 13 Feb 2004 23:22:24 +0200
Subject: [Help-gnutls] exporting session information from one process to
	another
In-Reply-To: <20040213183814.GA16476@via.ecp.fr>
References: <20040213183814.GA16476@via.ecp.fr>
Message-ID: <20040213212224.GB1272@gnutls.org>

On Fri, Feb 13, 2004 at 07:38:14PM +0100, Brieuc Jeunhomme wrote:

> Hello,

> I need to export session information from one process to another
> process. Simply put, I have a first process that accept()s a
> connection, allocates credentials, sets certificate information etc,
> then fork()s.
> The child process handles the handshake (it calls gnutls_handshake()),
> but, once the handshake is complete, I would like the parent process to
> use the connection, calling gnutls_record_send and gnutls_record_recv.
This is not possible with the current API, and it's not easy to add.
It would probably need to copy the "ConnectionState" parameters, but I'm
not sure this is sufficient. Maybe using a thread instead of a process
would solve the problem easily.

> I have tryed this with 1.0.5, using gnutls_session_set_data and
> gnutls_session_get_data to exchange the session information between the
> two processes, but this doesn't seem to be enough (gnutls_record_send
> works fine if called from the child process, but not from the parent
> process. However, the goal is to have the child process exit after the
> negociation and have the parent process use the established session).
> Is there a way to do this with the current gnutls library ? If not,
> would people here be interested in a patch for this ?
I would be interested, but it seems like a difficult thing to do, and
might not worth the effort.  

> -- 
> BBP

-- 
Nikos Mavroyanopoulos




From nmav at gnutls.org  Thu Feb 26 08:37:52 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Thu, 26 Feb 2004 09:37:52 +0200
Subject: [Help-gnutls] Re: gnutls-1.0.6 configure bug
In-Reply-To: <20040225212423.GA24050@earthquake.boredom.org>
References: <20040225212423.GA24050@earthquake.boredom.org>
Message-ID: <20040226073752.GA11259@gnutls.org>

On Wed, Feb 25, 2004 at 04:24:23PM -0500, nk at earthquake.boredom.org wrote:

> gnutls doesn't seem to want to compile on redhat 9:
>  gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../ -I../minitasn1/ -I../../includes/ -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -pipe -I/opt/libgcrypt/include -I/opt/libgpg/include -MT verify.lo -MD -MP -MF .deps/verify.Tpo -c verify.c  -fPIC -DPIC -o .libs/verify.o
> In file included from ../auth_cert.h:6,
>                  from ../gnutls_sig.h:3,
>                  from verify.c:33:
> ../../libextra/openpgp/openpgp.h:8:21: opencdk.h: No such file or directory
> I don't see -I/opt/opencdk/include in the CFLAGS here, any idea why?  I even went as far as to add "-I"/opt/opencdk/include" to every CFLAGS declaration
> in the Makefile.
Which version of gnutls is that?

> /nk

-- 
Nikos Mavroyanopoulos