Todo list for l2tpd

These are things that I would like to see improved, fixed, or added to l2tpd. Feel free to send me more ideas on things that you would like to see done.

We need a better control mechanism

We currently use a named pipe (/var/run/l2tp-control) to send simple commands (ie, 'echo "t 204.255.233.225" > /var/run/l2tp-control) to l2tpd. Not only is this just an ugly control mechanism, there is no feedback to the user if the action suceeded, nor is there an easy way for the software to generate any sort of output to the user. I believe that our control mechanism should be a socket of some type (probably UNIX domain socket, but a TCP socket might work too). This would involve defining some sort of protocol for a utility to use to control l2tpd and to receive data back from it, as well as implementing a utility to actually use that protocol, and adapting l2tpd to use that protocol.

Clean up issues with memory alignments

There are many places in l2tpd where the code assumes that it is dealing with x86 memory alignment rules. Stuff like taking a buffer and casting it as an in memory data structure. While this works OK (but certainly isn't clean) for the x86 architecture, its one of the things that causes problems when trying to compile l2tpd on other architectures.

Fix to use more appropriate variable types

Many of the variables in l2tpd use inappropriate variable types. The example that was more recently dealing with that exemplifies this is the tunnel id variable types, which are all type "int" which is typically a 4 byte variable. The tunnel id field is only a 2 byte field, so this should probably use a 2 byte long unsigned int (this is architecture dependant, but typically "unsigned short int"). Ideally, we should have "l2tpd specific" variable types (something like tid_t) that is mapped by headers and/or the build process (autoconf?) to the most appropriate native type. This is a lot of cleanup work, and touches many parts of the code, so it will take some time to clean up each of these inappropriate variable types as we'll have to go throught he code and find each place where that variable is used and fix it.

De-obfuscate or replace parse_config() in file.c

The code that parses the config file into keywords and values is painful. It makes use of lot's of 1 letter variables (t, s, d...what do these stand for? string, token, and data? Just a shot in the dark), lots of variable increments (s++) and the like with little or no indication of what's being incremented or why. Replacement of the 1 letter variables with more descriptive variable names would be a good starting point, along with extensive in-line commenting about what the code is doing. Better yet, just rip out the parse_config() function and replace it with another function that is cleaner, better documented, and uses the same call. parse_config() is only called from one place (init_config()), with a single arguement (a pointer to the config file descriptor), so the task shouldn't be all that difficult. I would not consider backward compatibility of the file format to be of any significant concern, particularly as I'm not particularly enamored of the current config file format anyway. :)

l2tpd home