Dear Thorsten Wystrychowski, Try this file. Reply if it will works (don't forget to tag Tunnel-Password, like Tunnel-Password:1 etc). I'll commit the changes if everything's OK.
--Saturday, April 13, 2002, 4:23:32 PM, you wrote to [EMAIL PROTECTED]:
TW> Hi,
TW> we have a lot of L2TP customers in production and in the loop.
TW> All customers who tried to use freeradius for L2TP purposes
TW> failed. At least without fixing the freeradius code.
TW> Most of them migrated to cistron 1.6.5 which does support
TW> Tunnel-Password encryption.
TW> Some weeks ago I've heard from a customer that new freeradius
TW> versions are better now with regard to L2TP Tunnel-Password
TW> encryption.
TW> But it was a mistake to believe this. Lately we run some tests
TW> with freeradius 0.5 with the result that L2TP Tunnel-Password
TW> encryption is still very buggy.
TW> The bug of freeradius 0.5 we are seeing is the following.
TW> The length field value of attribute 69 seems to be OK.
TW> But the content of the string field (the encrypted password) is
TW> rubbish. It is looking that the encrypted password is too short,
TW> since the end of the string is filled with data of the next radius
TW> attribute.
TW> On Thu, 11 Apr 2002, Chris Parker wrote:
>> Ahh, then possibly the NAS has not implemented the RFC standard
>> tunnel encryption.
TW> No, we see this in the snoop of the radius packets. So this is really
TW> independent of the NAS/LAC or of any proxy.
TW> Comparing freeradius pieces of code from 0.4 and 0.5, it's easy to
TW> discover relevant differences. The code changes are related to the
TW> password length!
TW> freeradius-snapshot-20011205 (0.4)
TW> ----------------------------------
TW> in radius.c:
TW> int rad_tunnel_pwencode ...
TW> ...
TW> char salt[2];
TW> int i, n, secretlen;
TW> int len;
TW> if(pwlen < 2) {
TW> return 0;
TW> }
TW> salt[0] = passwd[0];
TW> salt[1] = passwd[1];
TW> /* Advance pointer past the salt, which is first two chars of passwd */
TW> passwd = passwd + 2;
TW> /*
TW> * Padd password to multiple of AUTH_PASS_LEN bytes.
TW> */
TW> len = strlen(passwd);
TW> ...
TW> freeradius 0.5
TW> --------------
TW> in radius.c
TW> int rad_tunnel_pwencode ...
TW> ...
TW> char salt[2];
TW> int i, n, secretlen;
TW> int len;
TW> len = *pwlen;
TW> if (len < 3) {
TW> return 0;
TW> }
TW> salt[0] = passwd[0];
TW> salt[1] = passwd[1];
TW> /* Advance pointer past the salt, which is first two chars of passwd */
TW> passwd = passwd + 2;
TW> len -= 2;
TW> *passwd = len;
TW> /*
TW> * Padd password to multiple of AUTH_PASS_LEN bytes.
TW> */
TW> if (len > 128) len = 128;
TW> ---------------------------------------------------------------
TW> On Wed, 10 Apr 2002, Chris Parker wrote:
>> > > I know that it is working at least with Funk
>> > > SteelBelted Radius in terms of interoperability.
>> > > FreeRADIUS also works with cisco and Ascend NAS that
>> > > I've tested with ( in setting up L2TP via radius ).
TW> 1) Freeradius 0.5 packet snoops prove that freeradius is
TW> sending buggy attribute 69 packets.
TW> 2) Freeradius Tunnel-Password encryption code of version 0.4
TW> and version 0.5 has been changed.
TW> We have a lot of customers in the loop who are interested in L2TP services.
TW> Cistron 1.6.5 (http://www.radius.cistron.nl) has been certified for L2TP.
TW> Other radius as well, such as radiator (http://www.open.com.au/radiator).
TW> It has been always a little bit painful to migrate all of them from freeradius
TW> to another radius server.
TW> It might be that there is a specific (snapshot) version between 0.4 and 0.5 which
TW> is OK. If so, which one?
TW> If not, when could we expect to get a freeradius version which does support Tunnel-
TW> Password encryption correctly?
TW> I would volunteer to test this version.
TW> Regards,
TW> Thorsten Wystrychowski
TW> -
TW> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
~/ZARAZA
������ ��������� ��������� � ������������� ��������,
� ������ ��������� 2x2, �� � �� ��� ���� ��������. (���)
radius.c
Description: Binary data
