Re: Patch to fix PPTP CHAP failure due to unknown-attribute problem
You can find the current freeradius dictionaries at https://github.com/alandekok/freeradius-server/tree/v2.1.x/share You can see that dictionary.microsoft and dictionary.merit are there.... ... It includes attributes 11 (MS-CHAP-Challenge) and 25 (MS-CHAP2-Response).
Thank you for your prompt reply! It turns out that the dictionary files for *radiusclient* are different from those for freeradius *server* in subtle ways. Specifically, the server version uses the type "octet" while radiusclient recognizes only "string", "integer", "ipaddr", and "date" (see radiusclient's lib/dict.c, which is what parses the dictionaries). You are completely correct that the freeradius server distribution comes with a whole bunch of dictionaries, and that the dictionary.microsoft one does define the attributes 11 and 25. Unfortunately, radiusclient does not read these and cannot process them correctly if it did read them. The radiusclient distribution (even the latest development version at cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout radiusclient (c/o http://wiki.freeradius.org/Radiusclient) does not include any dictionary files other than "dictionary". Hence the problem. It certainly would be helpful to include radiusclient versions of dictionary.microsoft (and, I suppose, dictionary.merit) with the radiusclient distribution. Also, the current source of the radiusclient versions of dictionary.microsoft and dictionary.merit at http://wiki.freeradius.org/PopTop which is the source of the buggy version of dictionary.microsoft that has a space at the start of each line, could be updated to remove the spaces, and text could be inserted that explains that the errors rc_avpair_new: unknown attribute 11 rc_avpair_new: unknown attribute 25 may go away if these files are replaced with the revised versions. A good place for the text to be updated would be at the paragraph beginning, "That's not working. Ok, so you've followed the above steps and it's still not working. So lets double check things before you post to FreeRADIUS mailing lists: ...." I was hoping that my patches could be accepted in any case because there may be people who won't notice the changes in the web page above, and/or may have troubles with new dictionaries that they are developing. Another approach would be to modify radiusclient so that it reads the dictionaries used by freeradius server. That would make a lot of sense, and would be easy to do. Please let me know if you would like me to do that. Please let me know if I need to patch up the style in the patches. I tried to mimic the C-style of the original code, but may have missed spacing and such here and there. Thanks again for maintaining this important project. Please let me know how I can help. - Larry Widman
On Tue, Jul 05, 2011 at 12:20:30PM -0500, freeradius developer/user identity wrote:
Thank you for your prompt reply! It turns out that the dictionary files for *radiusclient* are different from those for freeradius *server* in subtle ways. ... (c/o http://wiki.freeradius.org/Radiusclient)
Oh I see. Sorry, I wasn't even aware of that, and I've no idea if it's even supported any more. I notice that the 'snapshots' link on that page points to an ftp server in Turkey which doesn't have any content: ftp> cd pub/freeradius 550 Can't change directory to pub/freeradius: No such file or directory All freeradius (server) development has moved to git - it's currently at version 2.1.11. Regards, Brian.
Brian Candler wrote:
I notice that the 'snapshots' link on that page points to an ftp server in Turkey which doesn't have any content:
ftp> cd pub/freeradius 550 Can't change directory to pub/freeradius: No such file or directory
Yeah, that needs to be fixed.
All freeradius (server) development has moved to git - it's currently at version 2.1.11.
I'll move the freeradius-client code to git, too. Part of the reason it's been hard to integrate patches is CVS. Alan DeKok.
Alan DeKok at Wed Jul 6 17:21:38 CEST 2011 wrote:
Sounds like a maintainer is needed under the auspices of the freeradius project: (from http://wiki.freeradius.org/Radiusclient) Yes... Please help. :) If a maintainer is needed, I am willing to volunteer at least for now. Great. I'll send you a whack of patches. .... Would it make sense to include radiusclient in the freeradius server source tree? No. That code is *terrible*. ... .... I've pushed the code to github
<whine> I unsubscribed to the freeradius-user mailing list and since then nothing from the developer mailing list has arrived either. I just resubscribed to freeradius-devel and got email stating that it was a duplicate enrollment. So I'm copying the above from the archive at freeradius.org</whine> OK, I'll take on maintenance of radiusclient, although I don't know much about it except what I fixed. Can you help me understand in what way the code is terrible and what would need to be corrected to bring it up to snuff? I've forked freeradius-client on github as user "cecst". I was thinking that as a first step I would apply the patches I've developed so far and then ask you to review and commit them. Is this the usual way things are done? Is there a specific coding style that you would like to enforce, for example with astyle? If so, do you have a handy style guide? Thanks - Larry Widman
freeradius developer/user identity wrote:
<whine> I unsubscribed to the freeradius-user mailing list and since then nothing from the developer mailing list has arrived either. I just resubscribed to freeradius-devel and got email stating that it was a duplicate enrollment. So I'm copying the above from the archive at freeradius.org</whine>
The list has worked for me...
OK, I'll take on maintenance of radiusclient, although I don't know much about it except what I fixed. Can you help me understand in what way the code is terrible and what would need to be corrected to bring it up to snuff?
Pretty much all of it, unfortunately. I expect to be releasing some BSD licensed RADIUS code in the next few months. It uses a completely different API, but is much simpler to understand and use.
I've forked freeradius-client on github as user "cecst". I was thinking that as a first step I would apply the patches I've developed so far and then ask you to review and commit them. Is this the usual way things are done? Is there a specific coding style that you would like to enforce, for example with astyle? If so, do you have a handy style guide?
Use the same style as the rest of the code. That's about it. I'll try to find the other patches in my queue and send them to you. Until any potential new code comes out, the current code still needs maintenance and fixes. Alan DeKok.
Hi,
I expect to be releasing some BSD licensed RADIUS code in the next few months. It uses a completely different API, but is much simpler to understand and use.
That code would support IPv6, right? Our pam_radius module auth (not the same, I know, but related) is one of the last services which don't work on IPv6. Any RADIUS client code to fix that would be cool. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
That code would support IPv6, right?
Uh... sure. IPv6 is just another simple transport layer.
Our pam_radius module auth (not the same, I know, but related) is one of the last services which don't work on IPv6. Any RADIUS client code to fix that would be cool.
http://networkradius.com/clientapi/ That version covers pretty much everything a client needs, including documentation and examples. Alan DeKok.
participants (4)
-
Alan DeKok -
Brian Candler -
freeradius developer/user identity -
Stefan Winter