[hipl-users] Re: Running MIPL/NEPL and HIPL at the same time?

On Fri, 5 Jan 2007, Väisänen Teemu wrote:

(sorry for the delay in answering your email)

Hi all.

At first, sorry if I'm sending this message to wrong mailing lists..

My first question is: Has anyone tried using MIPL (mipd) or NEPL
(nepd) and HIPL (hipd) at the same time in the one machine?

There has been non-conclusive discussion on running MIPL, IKE, HIPL and ad-hoc routers on the same host. Just search the email archives with mentioned keywords.

If not, what do you think, how much work might it need to get a kernel
where them both work at the same time?

I would recommend upgrading the old MIPL/NEPL patches to the upcoming 2.6.20 to reduce conflict pain later on. If I understood correctly, the interfamily patch for tunnel mode is going to appear in 2.6.20. I am not sure if BEET interfamily support will be yet available in 2.6.20, but it should be a minor patch.

I believe that upgrading the MIPL/NEPL patches is quite a much of effort because the patches are quite huge and intrusive. Testing the changes will take even more time. Please check if MIPL/NEPL development teams are already doing this or if USAGI kernel has already included MIPL/NEPL source in the their (up-to-date?) kernels?

Although I see a lot value in upgrading the MIPL/NEPL patches, maybe you want to create a "small legacy hack" for your own project. The best way is to apply first NEPL and then HIPL patches to a 2.6.15.6 kernel as you seem to have done already. There are some conflicts to be resolved, but I guess this might be easier than upgrading the NEPL sources (even though it is _the_ right way to handle this).

How much and what kind of modifications might hipd and nepd applications need?

For the kernel integration, this seems to be one problem:

+enum {
+       XFRM_MODE_TRANSPORT = 0,
+       XFRM_MODE_TUNNEL = 1,
+       XFRM_MODE_ROUTEOPTIMIZATION = 2,
+       XFRM_MODE_ROUTEOPTIMIZATION_TRIGGER = 3,
+};

HIPL assumes that XFRM_MODE_BEET is three. For the userspace part, there are few potential problems:

* dummy0 is for HIT based routing
* hipd flushes all SP/SAs unless you use -N
* I believe that the raw sockets should not be a problem (hipd ignores
  non-HIP control packets)
* hipd should react to acquire messages with HIT prefix and ignore rest
* ESP is controlled by the kernel (we don't use userspace ESP), should not
  be a problem
* UDP-ESP does not use the port reserved for IKE, should not be a problem

Anyway, I don't believe any of these will be a problem, but I haven't really experimented.

I have compared NEPL and HIPL patches and tried to apply them both to
Linux kernels. Both NEPL and HIPL need to patch the same files, so
patching order certainly effects to the result. I do not know how much
it mixes things up, that NEPL and HIPL patches are not for the same
kernels (for example 2.6.16 in NEMO and 2.6.16.5 in HIP). IPsec BEET
mode is included to the kernel since 2.6.19, so this might help
integrating in the future..

One example problem occurs when patching XFRM related files:
If a original kernel file has code lines
  code_original...

NEPL patches modifies it to
#ifdef CONFIG_XFRM_ENHANCEMENT
  code_NEMO...
#else
  code_original...
#endif

and HIPL patches modifies it to
  code_HIP...

If HIPL patch is applied after NEPL patch, the result will be:
#ifdef CONFIG_XFRM_ENHANCEMENT
  code_NEMO...
#else
  code_HIP...
#endif

But if CONFIG_XFRM_ENHANCEMENT is defined, codeHIP are not executed.

It is of course possible to add HIPL patches (codeHIP) inside #ifdef's
that NEPL uses.

I don't have much knowlegde about XFRM and kernels, and at this point,
any ideas and help are welcome! Thank you.

HIPL patches are not really HIPL specific. They introduce new IPsec mode and interfamily support for beet and tunnel. They should be available for NEMO also. As a consequence, I think the pseudo code should as follows:

#ifdef CONFIG_XFRM_ENHANCEMENT
   code_NEMO_ADAPTED_TO_HIPL
#else
   code_HIPL
#endif

If someone is interested, I can give more details (and questions) I
have found out.

Well, I am not a MIPL/NEPL expert, but I can try to answer.

--
Miika Komu                                       http://www.iki.fi/miika/

Other related posts: