Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach

[Yasuyuki Tanaka <[e-mail]>]

Hi,

I'm an implementor of CPANA. I have two additions to your
analysis.

Firstly, you can add RADIUS support to CPANA by using FreeBSD's
libradius. For this purpose, we provide the option,
"--with-libradius", for the "configure" script of CPANA.

Secondly, you can also adapt third-party EAP implementations to
CPANA, though I've never tried.

Hope this helps.

Best regards,
Yasuyuki Tanaka

 >                                  CPANA
 >
 > See http://sf.net/projects/cpana
 >
 > At first glance, CPANA looks promising. It's designed as a library for
 > others to integrate PANA into their environments.
 > CPANA is distributed under the BSD license.
 >
 > Unfortunately, I quickly decided  that CPANA was not a credible start
 > point in my opinion. The project has received 11 code commits over its
 > entire lifetime; I think 1 or 2 commits this year.
 > Despite claims that "docs are coming soon," in 2010, I was able to find
 > no documentation. There doesn't seem to be good separation of what is a
 > public interface from what is an internal interface; cpana.h includes
 > all the internal header files.
 > The example applications don't separate example-specific functionality
 > like reading config files well from using the library, so I wasn't able
 > to get a feel for what it would be like to use the library in a
 > non-sample application.
 > On a positive note, there did seem to be an abstraction around where
 > responses went; it might be easier-than-expected to use CPANA in an
 > encapsulation or demultiplexing approach.

 > There's one additional huge problem with CPANA. It includes its own
 > rather limited EAP library which does not appear to support any of the
 > tunnel methods. On the server there appears to be no RADIUS support.
 > If I were writing a PANA library I planned to maintain for years, I'd
 > seriously evaluate taking chunks of code from CPANA.
 > If CPANA gets significant new development effort it may turn into
 > something interesting. I like the goal of separating library from 
application.