HACKING file for libradsec (in Emacs -*- org -*- mode).
-Status as of libradsec-0.0.2-dev (2011-03-24).
+Status as of libradsec-0.2.0.dev (2013-05-06).
* Build instructions
-cd libradsec/lib
sh autogen.sh
./configure #--enable-tls
make
examples/client -r examples/client.conf blocking-tls; echo $?
-* Design of the API
-- There are three usage modes
- - You use the send and receive calls (blocking mode)
- - You register callbacks and run the libevent dispatch loop (user
- dispatch mode)
- - You run your own event loop, using fd's for select and do the I/O
- using the libradsec send/receive calls (on-your-own mode)
-- Fully reentrant (FIXME: any issues with libfreeradius-radius?)
-
* Dependencies
-The details below apply to Ubuntu 10.10.
+Details (within parentheses) apply to Debian Wheezy.
-- libfreeradius-radius (2.1.9+dfsg-1ubuntu1)
- sudo apt-get install libfreeradius-dev libfreeradius2
-- libconfuse (2.7-1)
+- libconfuse (2.7-4)
sudo apt-get install libconfuse-dev libconfuse0
-- libevent from source (release-2.0.10-stable)
- git clone --branch release-2.0.10-stable git://levent.git.sourceforge.net/gitroot/levent/levent
- cd levent; sh autogen.sh && ./configure --enable-openssl
- make && sudo make install
-- OpenSSL (optional, for TLS and DTLS support)
- sudo apt-get install libssl-dev
+- libevent2 (2.0.19-stable-3)
+ sudo apt-get install libevent-dev libevent-2.0-5
+- OpenSSL (1.0.1c-4) -- optional, for TLS and DTLS support
+ sudo apt-get install libssl-dev libssl1.0.0
-* Functionality and quality
+* Functionality and quality in 0.2.x
** Not well tested
- reading config file
- [TCP] short read
- [TCP] short write
- [TLS] basic tls support
+- [TLS] preshared key support
+- [TLS] verification of CN
+
** Known issues
+- error handling when server can't bind to given listen_addr+port
+- configuration of listen_addr/service is per realm
- error stack is only one entry deep
+- custom allocation scheme is not used in all places
+
** Not implemented
-- custom allocation scheme used in all places
- issue: libfreeradius-radius
-- server failover
-- [TLS] verification of CN
-- [TLS] preshared key support
+- dispatch mode (planned for 0.1)
+- [client] server failover / RFC3539 watchdog (planned for 0.1)
+- [server] support (planned for 0.2)
+- [client] TCP keepalive
+- on-your-own mode
- [DTLS] support
* Found a bug?
-If possible, please build the library with DEBUG defined
-(CFLAGS=-DDEBUG) and reproduce the problem. With DEBUG defined, lots
-of asserts are enabled which might give a hint about what's gone
-wrong.
+Please report it. That is how we improve the quality of the code.
+
+If possible, please build the library with DEBUG defined (CFLAGS="-g
+-DDEBUG") and reproduce the problem. With DEBUG defined, lots of
+asserts are enabled which might give a hint about what's gone wrong.
-Running the library under gdb is another good idea. If you experience
-a crash, catching that in gdb and providing a backtrace is highly
+Running the library under gdb is another good idea. If you experience
+a crash, catching the crash in gdb and providing a backtrace is highly
valuable for debugging.
Contact: mailto:linus+libradsec@nordu.net
+
+
+* Design of the API
+- There are three usage modes:
+
+ - Application uses blocking send and receive calls (blocking
+ mode). This is typically fine for a simple client.
+
+ - Application registers callbacks with libradsec and runs the
+ libevent dispatch loop (a.k.a. user dispatch mode). This would
+ probably be how one would implement a server or a proxy.
+
+ - Application runs its own event loop, using fd's for select and
+ performs I/O using libradsec send/receive functions
+ (a.k.a. on-your-own mode). Might be useful for an application
+ which already has an event loop that wants to add RadSec
+ functionality.
+
+- Apart from configuration and error handling, an application
+ shouldn't need to handle TCP and UDP connections
+ differently. Similarly, the use of TLS/DTLS or not shouldn't
+ influence the libradsec calls made by the application.
+
+- Configuration is done either by using the API or by pointing at a
+ configuration file which is parsed by libradsec.
+
+- Fully reentrant.
+
+- Application chooses allocation regime.
+
+Note that as of 0.0.2.dev libradsec suffers from way too much focus on
+the behaviour of a blocking client and is totally useless as a server.
+Not only does it lack most of the functions needed for writing a
+server but it also contains at least one architectural mishap which
+kills the server idea -- a connection timeout (TCP) or a retransmit
+timeout (UDP) will result in the event loop being broken. The same
+thing will happen if there's an error on a TCP connection, f.ex. a
+failing certificate validation (TLS).
+
+* Notes on internals
+** How to connect an outgoing connection?
+Connecting is not done explicitly by the application but implicitly by
+rs_message_send(). The application can treat connections in the same
+way regardless of whether they're connection-oriented (i.e. TCP) or
+not (UDP).
+
+rs_message_send(msg)
+ if msg->conn is open: mesasge_do_send(msg)
+ else:
+ -> _conn_open(conn, msg)
+ pick configured peer
+ event_init_socket(peer)
+ if TCP or TLS:
+ init tcp timers
+ event_init_bufferevent(conn, peer)
+ else:
+ init udp timers
+ if not connected and not connecting:
+ event_do_connect(conn)
+
+ if TCP:
+ bufferevent_setcb()
+ bufferevent_enable()
+ else:
+ event_assign(write_ev) ; libevent func?
+ event_add(write_ev)
+
+ if not in user-dispatch-mode:
+ event_base_dispatch()
+** How to bind a listener and start listening for incoming connections?
+
projects / libradsec.git / blobdiff