[hipl-users] Re: Running MIPL/NEPL and HIPL at the same time?
- From: Miika Komu <miika@xxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Thu, 11 Jan 2007 10:46:44 +0200 (EET)
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/
- References:
- [hipl-users] Running MIPL/NEPL and HIPL at the same time?
- From: Väisänen Teemu
Other related posts:
- » [hipl-users] Running MIPL/NEPL and HIPL at the same time?
- » [hipl-users] Re: Running MIPL/NEPL and HIPL at the same time?
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?
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 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.
If someone is interested, I can give more details (and questions) I have found out.
- [hipl-users] Running MIPL/NEPL and HIPL at the same time?
- From: Väisänen Teemu