Dear Thorsten Wystrychowski,
I've corrected the problem you noticed and commited changes in CVS. You
can get patched version from CVS (there are few more minor problems not
affecting functionality fixed). To fix only problem in question you can
simply change
- for (n=len ; n ; n--) passwd[n+3] = passwd[n];
+ for (n=len ; n>=0 ; n--) passwd[n+3] = passwd[n];
--Monday, April 15, 2002, 3:19:39 AM, you wrote to [EMAIL PROTECTED]:
TW> Thanks a lot 3APA3A!
TW> I've tested your patch.
TW> I would say it's pretty close to a solution. But it's not 100% correct.
TW> In general the Tunnel-Password encryption and decoding is close to work with
TW> your patch. But the first character of the decoded string of the encrypted
TW> password is wrong:
TW> "decoding issue"
TW> -----------------
TW> An original Tunnel-Password "p123" will be decoded as "3123".
TW> At least encoding and decoding is much better with your bugfix. I would appreciate
TW> if you have another look at this.
TW> I've attached a file with information about:
TW> * radius profile
TW> * output of Lucent MAX TNT radius trace showing the "decoding issue".
TW> - Thorsten
TW> -----Original Message-----
TW> From: 3APA3A <[EMAIL PROTECTED]>
TW> To: Thorsten Wystrychowski <[EMAIL PROTECTED]>
TW> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
TW> Date: Saturday, April 13, 2002 5:06 PM
TW> Subject: Re[2]: Problem with Tunnel-Password
>>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, �� � �� ��� ���� ��������. (���)
--
~/ZARAZA
...��� ������� ������� �� ���������� �� �� ����������������. (���)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
