Fw: EAP-TLS problem

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

shantanu choudhary wrote:
> this same root.pem is used to sign both radius SERVER and 
> wpa_supplicant CLIENT certificate,

Oh.  Rats, that's not the problem then.  :-(

> and with EAP-TTLS i have configured my radius server accordingly and
> for server verification i am using those certificate only which  i 
> used in EAP-TLS.

So you're using the same cert; rats again.

> if more elaborate explanation is required i will post whole output 
> from client side. Please do let me know if u can point out anything 
> wrong and unusual.

I don't see anything that's obviously wrong (other than the segfault
itself) -- but is this the most current stable version of
wpa_supplicant?  I remember at least one segfault fix going in a few
months ago.

Other than that... not sure.  Posting the whole log may be helpful, but
it probably makes more sense to put it up on the web somewhere and
provide links.  (If that's possible, anyway.)  That way you don't go
over the list's message-size limit.

If you are using the current version, it might help to get a stack
backtrace of this segfault: Rebuild wpa_supplicant with debugging info
turned on, then run it under gdb ("gdb /path/to/wpa_supplicant", "set
args <the normal arguments>", then "run"), wait for the segfault to
happen, and get a backtrace ("bt").  If there are no function names in
the backtrace data, then somehow the debugging info got removed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcKCDS5vET1Wea5wRA/JAAKCwKbX8ZK/ZxiCBjPQLrNrmYaPJiACeIhTw
Gzatsf4R+64xQ7otGFZH4Uo=
=5a+M
-----END PGP SIGNATURE-----