Hi Alexey,
We have been working with MIPL to further split the patch as you had suggested. The patch I am sending breaks this into Correspondent Node, Mobile Node and Home Agent functionalities. This patch is against 2.5.45. As part of integrating with 2.5.45 as well as due to the splitting done, there is one outstanding issue with the patch : at module unload time, some memory allocated during module_init is not freed up. However this is a small issue and we are confident of submitting a patch in a couple of days to fix this. The code base is the same that was submitted a few days ago, so the only new thing is the further splitting work and integrating with 2.5.45.
The patch is in two parts, you need to first install the following patch :
http://traci.mipl.mediapoli.com/patches/mipl-2.5.45.patch
After that, please apply the patch at the end of this mail (created as part of 2.5.45 cleanup) to create the final tree. Once the two patches are applied, you will see separate files for the client and the agent parts.
Please let us know if you need any clarification on this patch.
Thanks,
- KK
---------------------------- Patch 2 ------------------------------------------
diff -ruN linux-2.5.45.org/net/ipv6/ipv6_syms.c linux-2.5.45/net/ipv6/ipv6_syms.c
--- linux-2.5.45.org/net/ipv6/ipv6_syms.c Thu Oct 31 18:00:41 2002
+++ linux-2.5.45/net/ipv6/ipv6_syms.c Thu Oct 31 15:07:47 2002
@@ -54,6 +54,7 @@
EXPORT_SYMBOL(ip6_rt_addr_del);
EXPORT_SYMBOL(ip6_routing_table);
EXPORT_SYMBOL(ip6_route_add);
+EXPORT_SYMBOL(ip6_route_del);
EXPORT_SYMBOL(ip6_del_rt);
EXPORT_SYMBOL(fib6_clean_tree);
EXPORT_SYMBOL(rt6_lock);
diff -ruN linux-2.5.45.org/net/ipv6/route.c linux-2.5.45/net/ipv6/route.c
--- linux-2.5.45.org/net/ipv6/route.c Thu Oct 31 17:52:04 2002
+++ linux-2.5.45/net/ipv6/route.c Thu Oct 31 13:07:03 2002
@@ -788,7 +788,7 @@
return err;
}
-static int ip6_route_del(struct in6_rtmsg *rtmsg)
+int ip6_route_del(struct in6_rtmsg *rtmsg)
{
struct fib6_node *fn;
struct rt6_info *rt;
diff -ruN linux-2.5.45.org/net/ipv6/ipv6_tunnel.c linux-2.5.45/net/ipv6/ipv6_tunnel.c
--- linux-2.5.45.org/net/ipv6/ipv6_tunnel.c Thu Oct 31 18:00:41 2002
+++ linux-2.5.45/net/ipv6/ipv6_tunnel.c Thu Oct 31 12:53:23 2002
@@ -1202,16 +1202,16 @@
t->parms.name);
goto tx_err_dst_release;
}
- mtu = dst->pmtu - sizeof (*ipv6h);
+ mtu = dst->metrics[RTAX_MTU-1] - sizeof (*ipv6h);
if (opt) {
mtu -= (opt->opt_nflen + opt->opt_flen);
}
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
- if (skb->dst && mtu < skb->dst->pmtu) {
+ if (skb->dst && mtu < skb->dst->metrics[RTAX_MTU-1]) {
struct rt6_info *rt6 = (struct rt6_info *) skb->dst;
rt6->rt6i_flags |= RTF_MODIFIED;
- rt6->u.dst.pmtu = mtu;
+ rt6->u.dst.metrics[RTAX_MTU-1] = mtu;
}
if (skb->len > mtu) {
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev);
diff -ruN linux-2.5.45.org/net/ipv6/exthdrs.c linux-2.5.45/net/ipv6/exthdrs.c
--- linux-2.5.45.org/net/ipv6/exthdrs.c Thu Oct 31 18:00:41 2002
+++ linux-2.5.45/net/ipv6/exthdrs.c Thu Oct 31 12:44:06 2002
@@ -80,7 +80,7 @@
/* An unknown option is detected, decide what to do */
-static int ip6_tlvopt_unknown(struct sk_buff *skb, int optoff)
+int ip6_tlvopt_unknown(struct sk_buff *skb, int optoff)
{
switch ((skb->nh.raw[optoff] & 0xC0) >> 6) {
case 0: /* ignore */
diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/ha.h linux-2.5.45/net/ipv6/mobile_ip6/ha.h
--- linux-2.5.45.org/net/ipv6/mobile_ip6/ha.h Thu Oct 31 18:00:42 2002
+++ linux-2.5.45/net/ipv6/mobile_ip6/ha.h Thu Oct 31 15:43:25 2002
@@ -258,6 +258,13 @@
if (*lifetime > MAX_RR_BINDING_LIFE)
*lifetime = MAX_RR_BINDING_LIFE;
}
+
+static __inline__ int mipv6_del_tnl_to_mn(struct in6_addr *coa,
+ struct in6_addr *ha_addr, struct in6_addr *home_addr)
+{
+ return 0;
+}
+
#endif /* CONFIG_IPV6_MOBILITY_HA */
#endif
diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/hashlist.c linux-2.5.45/net/ipv6/mobile_ip6/hashlist.c
--- linux-2.5.45.org/net/ipv6/mobile_ip6/hashlist.c Thu Oct 31 18:00:42 2002
+++ linux-2.5.45/net/ipv6/mobile_ip6/hashlist.c Thu Oct 31 16:21:08 2002
@@ -115,7 +115,9 @@
}
if (hashlist->kmem) {
+#if 0
kmem_cache_destroy(hashlist->kmem);
+#endif
hashlist->kmem = NULL;
}
diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/bcache.c linux-2.5.45/net/ipv6/mobile_ip6/bcache.c
--- linux-2.5.45.org/net/ipv6/mobile_ip6/bcache.c Thu Oct 31 18:00:42 2002
+++ linux-2.5.45/net/ipv6/mobile_ip6/bcache.c Thu Oct 31 16:31:47 2002
@@ -905,7 +905,7 @@
del_timer(&bcache->callback_timer);
while ((entry = (struct mipv6_bcache_entry *)
- hashlist_get_first(bcache->entries)) != NULL) {
+ hashlist_get_first(bcache->entries)) != NULL) {
hashkey.a1 = &entry->home_addr;
hashkey.a2 = &entry->our_addr;
diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/halist.c linux-2.5.45/net/ipv6/mobile_ip6/halist.c
--- linux-2.5.45.org/net/ipv6/mobile_ip6/halist.c Thu Oct 31 18:00:42 2002
+++ linux-2.5.45/net/ipv6/mobile_ip6/halist.c Thu Oct 31 16:59:17 2002
@@ -472,7 +472,9 @@
DEBUG(DBG_INFO, "Stopping the timer");
del_timer(&home_agents->expire_timer);
+#if 0
mipv6_halist_gc(1);
+#endif
hashlist_destroy(home_agents->entries);
proc_net_remove("mip6_home_agents");
diff -ruN linux-2.5.45.org/include/net/ip6_route.h linux-2.5.45/include/net/ip6_route.h
--- linux-2.5.45.org/include/net/ip6_route.h Thu Oct 31 18:00:41 2002
+++ linux-2.5.45/include/net/ip6_route.h Thu Oct 31 15:09:50 2002
@@ -37,6 +37,7 @@
extern int ipv6_route_ioctl(unsigned int cmd, void *arg);
extern int ip6_route_add(struct in6_rtmsg *rtmsg);
+extern int ip6_route_del(struct in6_rtmsg *rtmsg);
extern int ip6_del_rt(struct rt6_info *);
extern int ip6_rt_addr_add(struct in6_addr *addr,
diff -ruN linux-2.5.45.org/include/linux/sysctl.h linux-2.5.45/include/linux/sysctl.h
--- linux-2.5.45.org/include/linux/sysctl.h Thu Oct 31 18:00:41 2002
+++ linux-2.5.45/include/linux/sysctl.h Thu Oct 31 12:32:08 2002
@@ -359,7 +359,7 @@
NET_IPV6_NEIGH=17,
NET_IPV6_ROUTE=18,
NET_IPV6_ICMP=19,
- NET_IPV6_BINDV6ONLY=20
+ NET_IPV6_BINDV6ONLY=20,
NET_IPV6_MOBILITY=21
};
---------------------------- End of Patch -------------------------------------
Why isn't the home agent code being done in userspace? That is
where it belongs. It's huge.
In article <[email protected]> (at Thu, 31 Oct 2002 18:17:08 -0800 (PST)), "David S. Miller" <[email protected]> says:
>
> Why isn't the home agent code being done in userspace? That is
> where it belongs. It's huge.
I think core part of HA belongs to kernel (forwarding etc.)
Registration process should live in user space.
--yoshfuji
> Registration process should live in user space.
I believe even the registration part should belong to kernel and
here are the reasons why.
The Home Agent needs to consult the Binding Cache, which is stored
upon successful completion of Binding updates registration, for
tunnelling the packets belonging to the mobile nodes away from home.
In addition, as part of the registration process but before caching
the binding updates, the Home Agent may need to perform duplicate address
detection (DAD), if needed, through ND protocol messages. And also,
IPSec is mandated for Home Agent registration and so, Home Agent
must use IPSec for responding to Binding updates from Mobile Nodes.
Thanks,
Venkat
----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
[email protected]
Tel: (503) 578 3430 T/L 775-3430
From: "Venkata Jagana" <[email protected]>
Date: Thu, 31 Oct 2002 22:51:13 -0800
I believe even the registration part should belong to kernel and
here are the reasons why.
The Home Agent needs to ...
None of the things you've listed make it desirable to put the home
agent registration into the kernel. All of the operations you
describe could be invoked by the userland home agent daemon using very
minimal glue logic in the kernel (invoked, for example, via netlink
messages).
(Hint: this glue logic could even be useful for other things)
Look, it is bad enough we have to put pfkey2 security database into
the kernel (and that most IKE daemons duplicate the whole database in
the user process as well), so let's not continue with such disasters.
Just like a router changes and monitors routes, a home agent daemon
would change and monitor mipv6 state. So for the same reason we don't
put OSPF routing databases into the kernel, we do not put the home
agent registration into the kernel :-)
Hello Dave,
>Just like a router changes and monitors routes, a home agent daemon
>would change and monitor mipv6 state. So for the same reason we don't
>put OSPF routing databases into the kernel, we do not put the home
>agent registration into the kernel :-)
I absolutely understand your concerns about keeping the Home Agent
registration in the kernel. However, I still believe that keeping
this code in userspace would cause problems for handoffs. (btw, this
code will never get executed on a regular host - only routers configured
as Home Agents would be running this code as a module).
Currently, when a Home Agent receives a registration request during the
Mobile Node's handoff mechanism, it needs to respond in a reasonably
quick time period so that the sessions on the MN can continue without
experiencing delays. Longer delays could be harmful for applications
such as VoIP, for which the latencies are quite critical.
By moving this registration process to userspace, we have no control
over when the home registration would complete, since there are no
guarantees when the home agent daemon would run. BTW, according to
ongoing discussions at Mobile IP WG, it is believed that even few
hundred millisecs of latencies are not acceptable to critical apps,
during which time the IP packet transfer is completely stopped.
With such latency issues, I still believe that moving the registration
to userspace would create issues for the MN.
Thanks,
Venkat
----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
[email protected]
Tel: (503) 578 3430 T/L 775-3430
David S. Miller wrote :
>
> Why isn't the home agent code being done in userspace? That is
> where it belongs. It's huge.
6 years ago (an eternity), a friend of mine did a full
implementation of Mobile IPv4 for Linux in user space (url below).
Of course, it needed some kernel support, such as IP/IP
tunneling, raw sockets, IP forwarding, gratuitous ARP and routing, but
there was no additional code added in the kernel. And this was Home
Agent, Foreign agent, Client and all their friends. And it was
interoprating successfully with other MIP implementations of that
time.
This was not the final draft of Mobile-IPv4 (they changed it
after that), and Mobile-IPv6 is different (for example, it is much
more integrated with IPsec), so the situation is not exactly the same.
But in the meantime, the kernel has gained powerful new
facilities, such as tun/tap and netfilters, which make very complex
things possible in user space.
But I fully aggree that having your code in the kernel is
infinitely more sexy than maintaining some user space package ;-)
Have fun...
Jean
The URL :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/MobileIP/index.html
Hi Dave,
> None of the things you've listed make it desirable to put the home
> agent registration into the kernel. All of the operations you
> describe could be invoked by the userland home agent daemon using very
> minimal glue logic in the kernel (invoked, for example, via netlink
> messages).
I had a couple of comments about putting the registration part in
userspace.
When the HA gets a registration request, it needs to perform the following
actions :
1. perform DAD
2. get the list of prefixes supported on the home link of the MN.
3. create a tunnel between the HA and the MN
4. join the solicited node multicast group of the MN's home
address.
5. add the MN's home address to the list of proxy neigh cache entry
for the HA.
6. Send NA on behalf of the MN
7. add the new location of the MN in the binding cache.
8. and finally send the Binding Registration Success/Failure
message.
In the above list, the only activities which can be done in userspace are
#7 and #8 (that I am aware of). The rest of the items can only be done in
the
kernel, atleast we need to move the support to kernel. If the HA
registration
is completely moved to userspace, it would still need these facilities (#1
to #6) in the kernel to perform the actions for registration. So even with
netlink
we still need the infrastructure in the kernel.
We can move the #7 and #8 pieces to userspace, but that is a relatively
small code, and is it worth doing that ?
Overall I feel that this should still be part of the kernel...
Thanks,
- KK
In article <[email protected]> (at Fri, 1 Nov 2002 17:15:09 -0800), "Krishna Kumar" <[email protected]> says:
> When the HA gets a registration request, it needs to perform the following
> actions :
> 1. perform DAD
> 2. get the list of prefixes supported on the home link of the MN.
> 3. create a tunnel between the HA and the MN
> 4. join the solicited node multicast group of the MN's home
> address.
> 5. add the MN's home address to the list of proxy neigh cache entry
> for the HA.
> 6. Send NA on behalf of the MN
> 7. add the new location of the MN in the binding cache.
> 8. and finally send the Binding Registration Success/Failure
> message.
>
> In the above list, the only activities which can be done in userspace are
> #7 and #8 (that I am aware of). The rest of the items can only be done in
> the
> kernel, atleast we need to move the support to kernel. If the HA
> registration
> is completely moved to userspace, it would still need these facilities (#1
> to #6) in the kernel to perform the actions for registration. So even with
> netlink
> we still need the infrastructure in the kernel.
1: True: we need some interface (and small code)
2: FALSE: you CAN listen icmp6 message via raw socket.
3: FALSE: you CAN create tunnel using raw socket;
however, we think this is implemented in kernel.
4,5,6: True: we need some interface to generate proxy ND.
(proxy ND is already in kernel.)
For 1,4,5,6: "proxy address" on a device would be a solution.
--yoshfuji
Krishna Kumar wrote:
>Hi Dave,
>
>
>
>>None of the things you've listed make it desirable to put the home
>>agent registration into the kernel. All of the operations you
>>describe could be invoked by the userland home agent daemon using very
>>minimal glue logic in the kernel (invoked, for example, via netlink
>>messages).
>>
>>
>
>I had a couple of comments about putting the registration part in
>userspace.
>When the HA gets a registration request, it needs to perform the following
>actions :
> 1. perform DAD
> 2. get the list of prefixes supported on the home link of the MN.
> 3. create a tunnel between the HA and the MN
> 4. join the solicited node multicast group of the MN's home
>address.
> 5. add the MN's home address to the list of proxy neigh cache entry
>for the HA.
> 6. Send NA on behalf of the MN
> 7. add the new location of the MN in the binding cache.
> 8. and finally send the Binding Registration Success/Failure
>message.
>
>In the above list, the only activities which can be done in userspace are
>#7 and #8 (that I am aware of). The rest of the items can only be done in
>the
>kernel, atleast we need to move the support to kernel. If the HA
>registration
>is completely moved to userspace, it would still need these facilities (#1
>to #6) in the kernel to perform the actions for registration. So even with
>netlink
>we still need the infrastructure in the kernel.
>
>
Heck no -- the list you sent only further enforces the notion that most
of this can be in userspace.
Sure, some of the facilities you list are completely in the kernel --
but it is best IMO to control them from userspace. That allows for
flexibility when it comes to policy decisions being made (if any) as
well as increased cleanliness of kernel code.
Jeff
I believe there could be more hooks in the kernel to let userspace do
certain tasks, for example, sending router solicitations and processing
the responses -- sure, this can be done in the userspace but means code
duplication. If the code in the kernel could also be called from the
userspace, there might be less need for duplication (though this would
result in portability issues of course).
Similar would appear to be the case some other features listed here.
On Sat, 2 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 1 Nov 2002 17:15:09 -0800), "Krishna Kumar" <[email protected]> says:
>
> > When the HA gets a registration request, it needs to perform the following
> > actions :
> > 1. perform DAD
> > 2. get the list of prefixes supported on the home link of the MN.
> > 3. create a tunnel between the HA and the MN
> > 4. join the solicited node multicast group of the MN's home
> > address.
> > 5. add the MN's home address to the list of proxy neigh cache entry
> > for the HA.
> > 6. Send NA on behalf of the MN
> > 7. add the new location of the MN in the binding cache.
> > 8. and finally send the Binding Registration Success/Failure
> > message.
> >
> > In the above list, the only activities which can be done in userspace are
> > #7 and #8 (that I am aware of). The rest of the items can only be done in
> > the
> > kernel, atleast we need to move the support to kernel. If the HA
> > registration
> > is completely moved to userspace, it would still need these facilities (#1
> > to #6) in the kernel to perform the actions for registration. So even with
> > netlink
> > we still need the infrastructure in the kernel.
>
> 1: True: we need some interface (and small code)
> 2: FALSE: you CAN listen icmp6 message via raw socket.
> 3: FALSE: you CAN create tunnel using raw socket;
> however, we think this is implemented in kernel.
> 4,5,6: True: we need some interface to generate proxy ND.
> (proxy ND is already in kernel.)
>
> For 1,4,5,6: "proxy address" on a device would be a solution.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
I agree with Pekka, hence the response to Jeff's and Yoshifuji's mail is
the same - what you are suggestting is feasible but we need more work in
the kernel either way. We can do many/most of these things in userspace
provided we either duplicate a lot of the code from kernel to user space
(leading to maintainability issues), or modularize exisiting kernel
routines (eg a different interface to DAD) and provide hooks for the same
to user (portability?). To clean up and provide more hooks in the kernel to
support common user activities means a major over write, but I agree it is
a good idea in the long run.
Another concern to think about is whether an integral part of the HA
functionality should be kept separate in user space, and whether making the
break in the HA to have a user process and kernel component makes sense.
Also other things to worry about when integral components are kept in
userspace - what happens when signals (KILL) are sent to that process ? We
don't want the home agent functionality to stop in that case, even if it is
a system admin error. This part is very critical to supporting possibly
hundreds of mobile devices in the future.
Thanks,
- KK
Pekka Savola
<[email protected] To: YOSHIFUJI Hideaki / $B5HF#1QL@(B <[email protected]>
i> cc: Krishna Kumar/Beaverton/IBM@IBMUS, <[email protected]>,
<[email protected]>, <[email protected]>,
11/02/2002 12:36 <[email protected]>, <[email protected]>,
AM <[email protected]>, <[email protected]>, Venkata
Jagana/Beaverton/IBM@IBMUS
Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45
I believe there could be more hooks in the kernel to let userspace do
certain tasks, for example, sending router solicitations and processing
the responses -- sure, this can be done in the userspace but means code
duplication. If the code in the kernel could also be called from the
userspace, there might be less need for duplication (though this would
result in portability issues of course).
Similar would appear to be the case some other features listed here.
On Sat, 2 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] !
!
[ Cc: trimmed ]
Krishna Kumar wrote:
> userspace - what happens when signals (KILL) are sent to that process ?
They die, as they should.
> We don't want the home agent functionality to stop in that case, even
> if it is a system admin error.
So what makes the home agent so much more important than, say, named,
pppd, gated, portmap, inetd, sendmail, sshd, etc. ?
A much more common admin mistake would be to reboot the wrong box, or
to disconnect the wrong cable, and you're powerless against this too.
If all else fails, add this to ~root/.bashrc:
alias kill='echo "Sorry, you'\''re too dumb for this"; false'
:-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/