Porting Racoon2, the reworked strategy…

First, I got a good Racoon2 friendly environment with all the support software running. This included : 1. gcc, 2. GNUmake, 3. openssl, 4. zlib, and so on. NOTE:- openssl package from sunfreeware.com didnot help, I had to use the source openssl-0.9.6 using the command ./Configure –prefix=/usr no-threads solaris-x86-gcc (the problem is with Racoon2, it does not have any option like –with-openssl-includedir=/usr/local/ssl/include/ )

Also, before using the autotools or any other shell command or running make (for openssl), we need to set the environment variables, CC=gcc and PATH=$PATH:/usr/local/bin:/usr/css/bin:/usr/sbin:/usr/css/bin/as

So, here are the steps I have followed there after:

First, try to compile the source code in gcc environment on OSol. While configuring, try to see if all the libraries are getting linked, and the script is identifying third party libraries (especially), like openssl and kerberos. (It is to be noted here that the Linux glibc vs. OSol’s libc might be tricky to combat. The two libraries are different in implementation, and the scope of my project does not include making changes to the libc.)

Once this is complete, we can try to build the source. At this stage numerous coding differences caused compile errors. Since I installed gcc-3.4.6, which works fine on linux for compiling Racoon2, the differences were mostly from the way data types are declared in the two OSes. Here are examples of some types of changes made:

#define __P(x) x
:to relplace old style K&R Compiler coding
u_int16_t -->  uint16_t
:different ways of declaring

Next, we need to look into errors due to different names of libraries and their functions. For example, the source is looking for <netinet6/ipsec.h>. On solaris, this is different, and identifiers like SADB_X_SATYPE_IPCOMP and IPSEC_POLICY_NONE are not implemented as it is. Therfore a mapping of Linux-specific functions to Solaris style, has to be completed here. This sounds like a critical task, and the biggest challenge here is not doing the actual mapping, but finding out what to map to. A single header file with function mapping is enough to solve this problem, but my lack of knowledge about the OpenSolaris internals has slowed me down here.

As a reworked strategy, I am planning to use some help from both my mentor and some people from the main Racoon2 mailing list. As all of these errors are arising from one single file from the racoon2 source (lib/rc_type.c) which takes care of all such calls, I believe the racoon2 guys must already be aware of a solution, hence getting to the next step will not be all that impossible.

Once this is over, I am sure the build will not throw many errors. We have however, not got anywhere yet, in terms of project goals. We havent even looked into System calls, and threading differences in the two OSes. While I can get a list of System calls and signals for the two OSes and compare them, fixing the differences in threading (should the need arise) will be much more difficult. I am hoping a function mapping will again solve the issue.

This will have covered bulk of the project’s objectives and issues, at the moment. The later stages are too far away to be planned right now. Also to be noted is that, I am far away from my deliverable of getting IKE to function by mid-term, but then again, that way was not possible. We cannot work one daemon at a time. So I am not unhappy with the amount of work completed and knowledge gained.

Advertisements

One response to “Porting Racoon2, the reworked strategy…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s