freeradius-client-1.1.5
Hi Freeradius users, I have a question regarding the freeradius-client (1.1.5). There is an example in that archive that shows you how to embed radius into your application in 50 lines of code or so. This example does not seem to be compiling at all, and thus the API for rc_config_init() and rc_add_config() is absent from the freeradius-client.h. Studying the lib/config.c the implementation is missing too, and the only way that I can set the configuration options is by writing a temp file with the options and have the library actually read the options from there. If you are really thinking of embedding Radius into you application you really want a different way such as rc_add_config (handle, keyword, value). Would anyone be interested in a patch for this? - Eivind
I've always thought that if I select on a blocking UDP socket that I can assume that a read subsequent read will not block. Apparently that is not the case. select on linux can in fact lie, it is only a hint. They suggest that O_NONBLOCK should be used with select. I'm linking the _long_ thread if anyone is interested. This is not a new development, but it is new to me. Has this been discussed on the list? The reason I am asking is that I've recently come across a problem where my 1.1 freeradius deamon is blocking on recvfrom on port 1814. Do you guys consider it fundamentally wrong to select on blocking UDP sockets? Thanks, Ryan http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=479100;p...
Ryan Melendez wrote:
I've always thought that if I select on a blocking UDP socket that I can assume that a read subsequent read will not block. Apparently that is not the case. select on linux can in fact lie, it is only a hint. They suggest that O_NONBLOCK should be used with select.
Idiots. Standards exist for a reason. Sometimes they're wrong (witness what will be RFC 5080), but ignoring them is often a bad idea.
I'm linking the _long_ thread if anyone is interested.
Many Linux people don't understand networking, and many don't understand the benefits of application stability. (See the comments on O(1) scheduler: "it's only 15 steps for 32k processes, and 16 steps for 64k processes. Since 15 and 16 are both small numbers, it's O(1) in the number of processes, right?) The only sane response is: WTF? These people are allowed to code?
This is not a new development, but it is new to me. Has this been discussed on the list? The reason I am asking is that I've recently come across a problem where my 1.1 freeradius deamon is blocking on recvfrom on port 1814.
It appears to be new to 2.4, and more likely with 2.6. It's wrong. Their arguments are *nonsense*.
Do you guys consider it fundamentally wrong to select on blocking UDP sockets?
No, If Linux blocks on recv() after select() returns "data available" for a UDP socket, then Linux is broken. It doesn't follow Posix, as people in the thread point out. Many of the comments in the thread *for* this behavior talk about broken pthread applications. This says to me that they *know* their arguments are nonsense, so they have to invent even more nonsensical reasons why it's the application's fault. It looks like I'll have to update the code to set O_NONBLOCK. This requires a number of minor changes in some areas. But Linux is broken. I've been doing networking for a long time, on AIX, HP/UX, SunOS, Solaris, Windows (98, NT, XP), Mac, *BSD, Linux, and I know a number of the people who've developed the network specifications and implementations. Linux is broken. It does not follow Posix, and it does not follow decades of network practice. If the Linux children do not understand this, they need to be educated. Bluntly. Alan DeKok.
On Nov 6, 2007, at 1:07 PM, Eivind Naess wrote:
Hi Freeradius users,
I have a question regarding the freeradius-client (1.1.5). There is an example in that archive that shows you how to embed radius into your application in 50 lines of code or so. This example does not seem to be compiling at all, and thus the API for rc_config_init() and rc_add_config() is absent from the freeradius-client.h.
Studying the lib/config.c the implementation is missing too, and the only way that I can set the configuration options is by writing a temp file with the options and have the library actually read the options from there. If you are really thinking of embedding Radius into you application you really want a different way such as rc_add_config (handle, keyword, value).
Would anyone be interested in a patch for this?
That exists in CVS head version of the client. :) Please use the current CVS head version, as that has greatly expanded the embedding capabilities of the client library. If CVS head works well for you, please let us know, as it is due for a 1.1.6 release, since there's new functionality. It is just needed some additional external testing I think. Thanks! -Chris
participants (4)
-
Alan DeKok -
Chris Parker -
Eivind Naess -
Ryan Melendez