Hi, Michael Richardson <mcr <at> sandelman.ca> writes: > I also have patches to the radius module to use the latest (and maintained) > radcli client library at: https://github.com/nmav/radcli I'm the original author of the patch. Alarig sent it here in the hope it would be useful (and furthermore, as upstream is not very active, it could serve better here…). > What is your application? As I read your patches, they just make ppp ignore > the attributes. Do you intend to do more with the data? It makes ppp "handle" more attributes types, so that we can give ppp an "enhanced" dictionnary with these types for IPv6-specific attributes. > I have patches on both radcli and pppd sides, which haven't all settled yet, > so I haven't pushed them anywhere yet. > > I'm not sure what the ultimate point of your patches are though. > Non-LL IPv6 addresses are not assigned through IP6CP, but rather through RA > and/or DHCPv6. I have a daemon, called rfc6204d, which does this at scale, > but it is not yet sufficiently field tested to release. Our goal is to dump all the RADIUS attributes pppd got through the "radattr.so" plugin. Without this patch, it ignores them and output empty values in /var/run/radattr.pppN (from memory; maybe it ignores them altogether). Then we can through the ipv6-up/down scripts know what prefix is to be advertised on what interface. We get the values from radattr's file, optionnaly set the ifid, change radvd's config file with the new interface, and reload it. I forgot to mention that we made this from a pppd *server* point of view. Hope it clarifies our intent. For me, there are not a lot of other ways to do that "cleanly". -- benjamin��.n��������+%������w��{.n�����{���i�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
