Rafiqul Ahsan wrote:
> Ok, I tried as follows :
...
> Still "ldd /usr/local/sbin/radiusd" shows the shared object from
> /usr/sfw/lib/*0.9.7
Then the issue is that the linker is linking against "libssl.so", and
not "libssl.so.0.9.8". This means that at run-time, /usr/sfw/lib is
found *before* /
Ok, I tried as follows :
1. chmod a-rx /usr/sfw
2. As before I kept below FLAGS on :
CFLAGS=-I/usr/local/ssl/include/openssl
CPPFLAGS=-I/usr/local/ssl/include/openssl
LDFLAGS='-L/usr/local/ssl/lib -R/usr/local/ssl/lib'
export CFLAGS CPPFLAGS LDFLAGS
3. ./configure
4. make
5. make install
Still
Rafiqul Ahsan wrote:
> Looks like I Freeradius still built with openssl 0.9.7 at
> /usr/swf...here is the ldd output :
Follow instructions. If you "chmod a-rx /usr/swf", the linker CANNOT
and WILL NOT pick up OpenSSL from that directory.
If that causes too many problems, then "chmod a-r
/usr
Looks like I Freeradius still built with openssl 0.9.7 at
/usr/swf...here is the ldd output :
# ldd /usr/local/sbin/radiusd
libfreeradius-radius-2.0.5.so => /usr/local/lib/libfreeradius-ra
dius-2.0.5.so
libnsl.so.1 => /lib/libnsl.so.1
libresolv.so.2 =>/lib
Here is the output. Not sure if this ensures the Freeradius built with
/usr/local/ssl/lib (0.9.8h), or /usr/sfw (0.9.7). My objective is to
build with 0.9.8h (but below output shows libgcc_s.sp.1 located at
/usr/sfw/lib). Can you please confirm from below output :
# ldd /usr/local/lib/libltdl.so.3
Rafiqul Ahsan wrote:
> It is Solaris 10 (V210). Now I have added below Flags (as per your
> previous email) :
>
> CFLAGS=-I/usr/local/ssl/include/openssl
> CPPFLAGS=-I/usr/local/ssl/include/openssl
> LDFLAGS='-L/usr/local/ssl/lib -R/usr/local/ssl/lib'
> export CFLAGS CPPFLAGS LDFLAGS
>
> How else
It is Solaris 10 (V210). Now I have added below Flags (as per your
previous email) :
CFLAGS=-I/usr/local/ssl/include/openssl
CPPFLAGS=-I/usr/local/ssl/include/openssl
LDFLAGS='-L/usr/local/ssl/lib -R/usr/local/ssl/lib'
export CFLAGS CPPFLAGS LDFLAGS
How else to verify that my Frerradius 2.0.5 was
Maurizio Cimaschi wrote:
> OK. So the rlm_mschap will look for the internal check-Item
> "Cleartext-Password" and it will use that value for authentication.
>
> From share/freeradius/dictionary.freeradius.internal
Can I ask you to stop quoting the documentation and configuration to
me? I wrote
Alan DeKok wrote:
Because User-Password is the password as entered by the user.
Cleartext-Password is the "known good" password on the server. They are
*not* the same.
When you do EAP, there is *no* User-Password attribute in the packets.
So doing "User-Password == ..." is *wrong*. There'
Maurizio Cimaschi wrote:
> Venkata LK Mula wrote:
>> The 'Code: Access-challenge (11)' frame from server to the
>> client is showing 'Checksum: 0x921e [incorrect, should be
>> 0x206c]' error. please find the ethereal log as attached as
>> 'eap-failure1'.
>
> All the packets from your server have t
Maurizio Cimaschi wrote:
> Alan DeKok wrote:
>> The *client* has to supply the MS-CHAP magic using the LAN-manager
>> password. Since the client always chooses NT-hashed passwords... using
>> LAN manager passwords is not possible.
>
> From the README is src/modules/rlm_mschap
...
> So it seems
Maurizio Cimaschi wrote:
> I checked the example, but it's not clear to me why it is so.
Because User-Password is the password as entered by the user.
Cleartext-Password is the "known good" password on the server. They are
*not* the same.
When you do EAP, there is *no* User-Password attribut
Alan DeKok wrote:
The *client* has to supply the MS-CHAP magic using the LAN-manager
password. Since the client always chooses NT-hashed passwords... using
LAN manager passwords is not possible.
From the README is src/modules/rlm_mschap
*
The method just described is called NT-encryptio
Alan DeKok wrote:
test100 User-Password == "venkat",
No. Use Cleartext-Password := ...
This is given in the example in the FAQ.
I checked the example, but it's not clear to me why it is so.
In my envirnoment I authenticate against an LDAP server, so according to
the ldap.attrmap file th
Venkata LK Mula wrote:
The 'Code: Access-challenge (11)' frame from server to the
client is showing 'Checksum: 0x921e [incorrect, should be
0x206c]' error.
please find the ethereal log as attached as 'eap-failure1'.
All the packets from your server have that problems; so it's probably a
bug i
15 matches
Mail list logo