With a clean checkout ./configure make ...fails with: CC src/modules/rlm_eap/libeap/eap_tls.c src/modules/rlm_eap/libeap/eap_tls.c: In function ‘eaptls_success’: src/modules/rlm_eap/libeap/eap_tls.c:202: warning: implicit declaration of function ‘eaptls_gen_eap_key’ src/modules/rlm_eap/libeap/eap_tls.c:202: warning: nested extern declaration of ‘eaptls_gen_eap_key’ CC src/modules/rlm_eap/libeap/mppe_keys.c src/modules/rlm_eap/libeap/mppe_keys.c: In function ‘eapttls_gen_challenge’: src/modules/rlm_eap/libeap/mppe_keys.c:184: error: ‘EAPTLS_PRF_CHALLENGE’ undeclared (first use in this function) src/modules/rlm_eap/libeap/mppe_keys.c:184: error: (Each undeclared identifier is reported only once src/modules/rlm_eap/libeap/mppe_keys.c:184: error: for each function it appears in.) src/modules/rlm_eap/libeap/mppe_keys.c: At top level: src/modules/rlm_eap/libeap/mppe_keys.c:201: warning: no previous prototype for ‘eaptls_gen_eap_key’ src/modules/rlm_eap/libeap/mppe_keys.c: In function ‘eaptls_gen_eap_key’: src/modules/rlm_eap/libeap/mppe_keys.c:209: error: ‘PW_EAP_SESSION_ID’ undeclared (first use in this function) make: *** [build/objs/src/modules/rlm_eap/libeap/mppe_keys.lo] Error 1
Phil Mayers wrote:
With a clean checkout
./configure make
...fails with:
Dang. There's no excuse for not doing builds... the new system is just so much nicer than the old one. $ git pull Oh, and re-run configure, too. I just nuked the old build system. There were some minor changes to the Make.inc file, which won't get picked up unless you re-run configure. Alan DeKok.
On 20/02/13 14:44, Alan DeKok wrote:
Phil Mayers wrote:
With a clean checkout
./configure make
...fails with:
Dang. There's no excuse for not doing builds... the new system is just so much nicer than the old one.
$ git pull
Oh, and re-run configure, too. I just nuked the old build system. There were some minor changes to the Make.inc file, which won't get picked up unless you re-run configure.
Builds, but now bombs out with gtc { challenge = "Password: " auth_type = "PAP" } rlm_eap_gtc: Unknown Auth-Type PAP rlm_eap: Failed to initialize type gtc Does this with the default config, as well as my local/stock.
On 20/02/13 15:15, Phil Mayers wrote:
Does this with the default config, as well as my local/stock.
...and then if you comment "gtc" out: Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes type 'string' is not supported in the configuration files } rlm_eap: Failed to initialize type tls ...again with the default config.
On 20/02/13 15:17, Phil Mayers wrote:
On 20/02/13 15:15, Phil Mayers wrote:
Does this with the default config, as well as my local/stock.
...and then if you comment "gtc" out:
Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes type 'string' is not supported in the configuration files
Seems to be choking on "rsa_key_length" as far as gdb can tell;
Phil Mayers wrote:
...and then if you comment "gtc" out:
Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes type 'string' is not supported in the configuration files } rlm_eap: Failed to initialize type tls
Arg. Arran has a Centos system which reproduces this. He's looking at it now. Valgrind doesn't find anything. This is weird as hell. Alan DeKok.
On 20/02/13 15:46, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Arg. Arran has a Centos system which reproduces this. He's looking at it now.
cool, I like reproducability
Valgrind doesn't find anything. This is weird as hell.
not cool. things just not working is wierd.
Well, based on the discrepancy between the source file and gdb line counts, I wonder if it's a gcc-ism - maybe inline behaviour or something? - that's also screwing things up. Also: is the intent of the various "const" in conffile.c to avoid mutating the CONF_PARSER objects? Because if so, I think they're the wrong way round - shouldn't they be: CONF_PARSER const* x ...rather than const CONF_PARSER *x ?
Phil Mayers wrote:
Well, based on the discrepancy between the source file and gdb line counts, I wonder if it's a gcc-ism - maybe inline behaviour or something? - that's also screwing things up.
Maybe. If it's a compiler issue, I'll be annoyed.
Also: is the intent of the various "const" in conffile.c to avoid mutating the CONF_PARSER objects? Because if so, I think they're the wrong way round - shouldn't they be:
CONF_PARSER const* x
...rather than
const CONF_PARSER *x
For "normal" types, const order doesn't matter. "const int foo" is the same as "int const foo". I put const to the left, to highlight the fact that the variable declarations are parsed right to left: X is a pointer to a CONF_PARSER which is const which is the same as: X is a pointer to a const CONF_PARSER which is not the same as CONF_PARSER * const x X is a const pointer to a CONF_PARSER i.e. you can't change X, but you can change what it points t.=o. Alan DeKok.
On 20/02/13 16:43, Alan DeKok wrote:
I put const to the left, to highlight the fact that the variable declarations are parsed right to left:
X is a pointer to a CONF_PARSER which is const
which is the same as:
X is a pointer to a const CONF_PARSER
Really? I read the first as: (x is a pointer to a conf parser) which is const i.e. "x", the pointer, is const. Not what is pointed to. I'm going by this: http://www.parashift.com/c++-faq-lite/const-ptr-vs-ptr-const.html ...which sits in my bookmarks. But I freely admit to finding const in C confusing. However - there is now some evidence that my build was screwed, and the 3.0.0 server was somehow loading an older 3.0.0 build from /usr/local, despite --prefix being set and "libdir" being set in the radiusd.conf So I think my problem is different.
On 20/02/13 17:38, Phil Mayers wrote:
On 20/02/13 16:43, Alan DeKok wrote:
I put const to the left, to highlight the fact that the variable declarations are parsed right to left:
X is a pointer to a CONF_PARSER which is const
which is the same as:
X is a pointer to a const CONF_PARSER
Really? I read the first as:
(x is a pointer to a conf parser) which is const
i.e. "x", the pointer, is const. Not what is pointed to.
I'm going by this:
http://www.parashift.com/c++-faq-lite/const-ptr-vs-ptr-const.html
...which sits in my bookmarks. But I freely admit to finding const in C confusing.
However - there is now some evidence that my build was screwed, and the 3.0.0 server was somehow loading an older 3.0.0 build
...sorry, "an older rlm_eap_tls"
On Wed, Feb 20, 2013 at 05:38:38PM +0000, Phil Mayers wrote:
I freely admit to finding const in C confusing.
The most frequently seen example which helps me remember this: const char *p; // equivalently: char const *p; Read right-to-left: "p is a pointer to constant char". You can change p (e.g. p++ is OK) but you cannot change the char which p points to (*p = '\0' is verboten) The less common one is char *const p; "p is a constant pointer to char". That is, p itself is a constant and cannot change, but the thing pointed to by p can be changed.
On 20 Feb 2013, at 10:15, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 20/02/13 14:44, Alan DeKok wrote:
Phil Mayers wrote:
With a clean checkout
./configure make
...fails with:
Dang. There's no excuse for not doing builds... the new system is just so much nicer than the old one.
$ git pull
Oh, and re-run configure, too. I just nuked the old build system. There were some minor changes to the Make.inc file, which won't get picked up unless you re-run configure.
Builds, but now bombs out with
gtc { challenge = "Password: " auth_type = "PAP" } rlm_eap_gtc: Unknown Auth-Type PAP rlm_eap: Failed to initialize type gtc
Does this with the default config, as well as my local/stock.
Yes, I see this now on Centos 5.9 32bit, but not Centos 6.3 32/64bit. Will investigate. -Arran
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Brian Candler -
Phil Mayers