Hi Martin, On Fri, Oct 17, 2014 at 4:43 AM, Martin Willi <[email protected]> wrote:
> Hi Avesh, > > > strongswan's openssl plugin is deigned for multi-threaded environment, > whereas > > wpa_supplicant uses non-threaded architecture. Both of these, > strongswan's > > openssl pluging and wpa_supplicant uses openssl as their crypto and > > TLS library. > > True, but unless you run these libraries in the same process, how is > this a problem? Isn't it the way it works when wpa_supplicant's tnc client loads any imc (.so) so everything runs in the same process space? > I'd guess for a different process each OpenSSL libcrypto > instance should be usable independently? > There is only one wpa_supplicant process. > > Or is there some non-mainline code involved that uses wpa_supplicant > from within strongSwan? > There is nothing ususal. wpa_supplicant loads strongswan's imcs from /etc/tnc_config file. strongswan imc runs within wpa_supplicant process space not the other way around. It might happen with other third party tnc clients if they use strongswan's imc with a design similar to wpa_supplicant. > > > I have created a very simple patch to address this issue which basically > allows > > disabling mult-thread uses in strongswan's openssl plugin when > > wpa_supplicant is used. > > Disabling that multi-threading setup on strongSwan definitely will break > the openssl plugin, It does not disable mult-threading by default. In the patch, by default it is true so strongswan operations are not affected at all. When someone uses wpa_supplicant, one might disable multi-threading in openssl plugin by configuring it. > so I don't think this is an option, even as a > work-around. > > As I said above, by default it is enabled and does not affect strongswan at all, so might work as a work around. Regards Avesh > Regards > Martin > >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
