Thanks a lot 3APA3A! I've tested your patch.
I would say it's pretty close to a solution. But it's not 100% correct.
In general the Tunnel-Password encryption and decoding is close to work with
your patch. But the first character of the decoded string of the encrypted
password is wrong:
"decoding issue"
-----------------
An original Tunnel-Password "p123" will be decoded as "3123".
At least encoding and decoding is much better with your bugfix. I would appreciate
if you have another look at this.
I've attached a file with information about:
* radius profile
* output of Lucent MAX TNT radius trace showing the "decoding issue".
- Thorsten
-----Original Message-----
From: 3APA3A <[EMAIL PROTECTED]>
To: Thorsten Wystrychowski <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, April 13, 2002 5:06 PM
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, да и то при этом ошибаясь. (Лем)
telnet-pub-fixed.log
Description: Binary data
