freeradius-client updates
I've been making progress on the freeradius-client library. The CVS head now contains some additional config checks to help with some portability. Changed some 'unsigned int/int' to 'size_t'. Changed some 'bzero' to 'memset'. Added some casts to clear some warnings. I've removed most(all?) of the non-threadsafe calls, and replaced with appropriate threadsafe calls wherever I could. There is still some problem with 'gethostby_*' calls. I created a wrapper for those, but when I define hosts by name, instead of by address, I'm still seeing packets launch off into the stratosphere instead of to the defined host(s). This leads me to believe that there is still some sort of problem in the 'send_server()' logic. It works perfectly if the code defines the servers via dotted-quad ( which is certainly far preferred ). The library is now working as part of an embedded radiusclient built into the FreeSWITCH ( http://www.freeswitch.org/ ) server. Yay! It is doing accounting ( Start/Stop ) at this point. It is still a bit rough around the edges, and some additional cleanup still needs to be done, though it's definitely improved. I'm looking for some feedback/testing from others, to make sure the other programs which use the library ( radtest, radacct, radlogin, etc. ) are not broken. I've tested them as best I can, but want to have others with other build environments and usage scenarios confirm. :) Unless there's any major problems that anyone sees, I think we're ready to take another snapshot of CVS head and release an updated version. Anyone with feedback on the packages ( /debian, /rpm ) etc, would be welcome as I've not updated those yet. -Chris -- Chris Parker Director, Systems StarNet - US LEC, now a PAETEC Company (888)212-0099 Fax (847)963-1302 Wholesale Internet and VoIP Services http://www.megapop.net NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
On Thu 21 Jun 2007, Chris Parker wrote:
I've been making progress on the freeradius-client library.
The CVS head now contains some additional config checks to help with some portability.
Changed some 'unsigned int/int' to 'size_t'.
Changed some 'bzero' to 'memset'.
Added some casts to clear some warnings.
I've removed most(all?) of the non-threadsafe calls, and replaced with appropriate threadsafe calls wherever I could. There is still some problem with 'gethostby_*' calls. I created a wrapper for those, but when I define hosts by name, instead of by address, I'm still seeing packets launch off into the stratosphere instead of to the defined host(s). This leads me to believe that there is still some sort of problem in the 'send_server()' logic. It works perfectly if the code defines the servers via dotted-quad ( which is certainly far preferred ).
The library is now working as part of an embedded radiusclient built into the FreeSWITCH ( http://www.freeswitch.org/ ) server. Yay! It is doing accounting ( Start/Stop ) at this point.
It is still a bit rough around the edges, and some additional cleanup still needs to be done, though it's definitely improved.
I'm looking for some feedback/testing from others, to make sure the other programs which use the library ( radtest, radacct, radlogin, etc. ) are not broken. I've tested them as best I can, but want to have others with other build environments and usage scenarios confirm. :)
Unless there's any major problems that anyone sees, I think we're ready to take another snapshot of CVS head and release an updated version.
Anyone with feedback on the packages ( /debian, /rpm ) etc, would be welcome as I've not updated those yet.
I have updated the rpms on the openSUSE build service with last night's snapshot. Whats the chance of you setting up a "Automatic report from sources (radiusc)" btw? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Jun 21, 2007, at 12:38 PM, Peter Nixon wrote:
I have updated the rpms on the openSUSE build service with last night's snapshot.
Might want to update them again. I updated some files today. I seem to have missed a commit, which I caught while testing a fresh checkout today.
Whats the chance of you setting up a "Automatic report from sources (radiusc)" btw?
That should be setup now. :) -Chris -- Chris Parker Director, Systems StarNet - US LEC, now a PAETEC Company (888)212-0099 Fax (847)963-1302 Wholesale Internet and VoIP Services http://www.megapop.net NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
On Thu 21 Jun 2007, Chris Parker wrote:
On Jun 21, 2007, at 12:38 PM, Peter Nixon wrote:
I have updated the rpms on the openSUSE build service with last night's snapshot.
Might want to update them again. I updated some files today. I seem to have missed a commit, which I caught while testing a fresh checkout today.
Yep. The auto build failed. I have updated it to latest cvs and everything built fine this time around. Packages are on the usual mirrors. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Chris Parker wrote:
I've been making progress on the freeradius-client library.
Looks good. Could you also do "chmod -x *.c" in the CVS directory? Having executable C files is... odd. Many of the text files appear to be executable, too...
The CVS head now contains some additional config checks to help with some portability.
Changed some 'unsigned int/int' to 'size_t'.
Some should probably ssize_t, too. e.g. the return code from recvfrom(). I'd suggest also changing UINT4 to uint32_t, etc. It's 2007, C has moved on from where it was in 1996. :)
... There is still some problem with 'gethostby_*' calls. I created a wrapper for those, but when I define hosts by name, instead of by address, I'm still seeing packets launch off into the stratosphere instead of to the defined host(s). This leads me to believe that there is still some sort of problem in the 'send_server()' logic. It works perfectly if the code defines the servers via dotted-quad ( which is certainly far preferred ).
I'd check hp->h_addrtype && hp->h_length in the code, to be sure it's an IPv4 address. Maybe also memcpy() hp->h_addr into a temporary variable? Though h_addr should be aligned...
Unless there's any major problems that anyone sees, I think we're ready to take another snapshot of CVS head and release an updated version.
Sounds good to me. It's getting close to the point where we'll need to release the dictionaries as a separate package, I think. Alan DeKok.
On Fri 22 Jun 2007, Alan DeKok wrote:
Chris Parker wrote:
I've been making progress on the freeradius-client library.
Looks good. Could you also do "chmod -x *.c" in the CVS directory? Having executable C files is... odd. Many of the text files appear to be executable, too...
The CVS head now contains some additional config checks to help with some portability.
Changed some 'unsigned int/int' to 'size_t'.
Some should probably ssize_t, too. e.g. the return code from recvfrom().
I'd suggest also changing UINT4 to uint32_t, etc. It's 2007, C has moved on from where it was in 1996. :)
... There is still some problem with 'gethostby_*' calls. I created a wrapper for those, but when I define hosts by name, instead of by address, I'm still seeing packets launch off into the stratosphere instead of to the defined host(s). This leads me to believe that there is still some sort of problem in the 'send_server()' logic. It works perfectly if the code defines the servers via dotted-quad ( which is certainly far preferred ).
I'd check hp->h_addrtype && hp->h_length in the code, to be sure it's an IPv4 address. Maybe also memcpy() hp->h_addr into a temporary variable? Though h_addr should be aligned...
Unless there's any major problems that anyone sees, I think we're ready to take another snapshot of CVS head and release an updated version.
Sounds good to me.
It's getting close to the point where we'll need to release the dictionaries as a separate package, I think.
Yes. I think that is a good idea, especially given that the dictionaries are being added to basically every month. I think it would make sense for the dictionaries to have a different version scheme and be released on a much more regular basis than the other client and server code bases as they don't require much if any testing, and are very small in size. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
It's getting close to the point where we'll need to release the dictionaries as a separate package, I think.
Yes. I think that is a good idea, especially given that the dictionaries are being added to basically every month. I think it would make sense for the dictionaries to have a different version scheme and be released on a much more regular basis than the other client and server code bases as they don't require much if any testing, and are very small in size.
The one caveat is that the dictionaries are currently pretty incestuous with the server. So we need to ensure that the dictionaries *also* work with radiusclient, etc. too. And can we get whoever is using dictionary.sip to use VSA's? Having yet another group stomp on the RFC attribute space is narrow-minded and annoying. Alan DeKok.
On Fri 22 Jun 2007, Alan DeKok wrote:
Peter Nixon wrote:
It's getting close to the point where we'll need to release the dictionaries as a separate package, I think.
Yes. I think that is a good idea, especially given that the dictionaries are being added to basically every month. I think it would make sense for the dictionaries to have a different version scheme and be released on a much more regular basis than the other client and server code bases as they don't require much if any testing, and are very small in size.
The one caveat is that the dictionaries are currently pretty incestuous with the server. So we need to ensure that the dictionaries *also* work with radiusclient, etc. too.
Yes. That is not currently the case, but splitting the dictionaries into a different package would be the best place to start IMHO. Wichert may also be convinced to use them with pyrad then... (Not to mention the other radius server projects whom I am sure would like to leverage them)
And can we get whoever is using dictionary.sip to use VSA's? Having yet another group stomp on the RFC attribute space is narrow-minded and annoying.
Yes. The culprits are SER and openSER. The openSER guys how now registered their own enterprise number, although I not sure if the SER guys have. Now that chris has done the great work of making radiusclient work as an embedded library, and has FreeSWITCH using (which needs very similar attributes to SER) I think we can get the SER and openSER guys to rewrite their radius modules. The openSER guys in particular are very happy to do so, but would like some assistance from us, which I have unfortunately been unable to give so far (Chris, if you have time would you have a chat with the openSER and/or SER guys about your changes to radiusclient?) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Jun 22, 2007, at 7:30 AM, Peter Nixon wrote:
On Fri 22 Jun 2007, Alan DeKok wrote:
And can we get whoever is using dictionary.sip to use VSA's? Having yet another group stomp on the RFC attribute space is narrow- minded and annoying.
Yes. The culprits are SER and openSER. The openSER guys how now registered their own enterprise number, although I not sure if the SER guys have. Now that chris has done the great work of making radiusclient work as an embedded library, and has FreeSWITCH using (which needs very similar attributes to SER) I think we can get the SER and openSER guys to rewrite their radius modules. The openSER guys in particular are very happy to do so, but would like some assistance from us, which I have unfortunately been unable to give so far (Chris, if you have time would you have a chat with the openSER and/or SER guys about your changes to radiusclient?)
Sure. I'll be at cluecon next week, and I believe Daniel (of Openser fame) will be there. If he wants to talk then, that would be great. The best/easiest place to look would be how the library is used in the radius cdr module in FreeSWITCH. -Chris -- Chris Parker Director, Systems StarNet - US LEC, now a PAETEC Company (888)212-0099 Fax (847)963-1302 Wholesale Internet and VoIP Services http://www.megapop.net NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
Peter Nixon wrote:
Yes. That is not currently the case, but splitting the dictionaries into a different package would be the best place to start IMHO. Wichert may also be convinced to use them with pyrad then... (Not to mention the other radius server projects whom I am sure would like to leverage them)
Yes. Wireshark has already included the dictionaries verbatim, as have some commercial vendors. We'll need to have some processing of the dictionaries, to turn off FreeRADIUS-specific features, and make them more "Livingston" style. But that's not rocket science. The "format.pl" script already reads and re-writes the dictionaries, so adding some more re-writing is trivial. Alan DeKok.
On Jun 22, 2007, at 12:49 AM, Alan DeKok wrote:
Chris Parker wrote:
I've been making progress on the freeradius-client library.
Looks good. Could you also do "chmod -x *.c" in the CVS directory? Having executable C files is... odd. Many of the text files appear to be executable, too...
Ach. That was me getting the group permissions set correctly so that the changelog email script would work.
The CVS head now contains some additional config checks to help with some portability.
Changed some 'unsigned int/int' to 'size_t'.
Some should probably ssize_t, too. e.g. the return code from recvfrom().
I'd suggest also changing UINT4 to uint32_t, etc. It's 2007, C has moved on from where it was in 1996. :)
Yep, that's next on my cleanup list. :) -Chris -- Chris Parker Director, Systems StarNet - US LEC, now a PAETEC Company (888)212-0099 Fax (847)963-1302 Wholesale Internet and VoIP Services http://www.megapop.net NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
participants (3)
-
Alan DeKok -
Chris Parker -
Peter Nixon