Dear Thorsten Wystrychowski,
Do you mean problem with FreeRADIUS encoding (rad_tunnel_pwencode) or
decoding (rad_tunnel_pwdecode)?
--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
