[support] Kernel compilation errors (with the MCoA patch)

[ibrahim sulaiman]

Dear,

When compiling kernal 3.8.2 after patching the MCoA patch and following the
steps in sections "building mobility-ready kernel" and "building a DSMIPv6
and MCoA-ready kernel", I got these errors:

net/core/skbuff.c: In function ?__copy_skb_header?:
net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named
?udp_encap_info?
net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member named
?udp_encap_info?
net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named
?udp_encap_info?
net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member named
?udp_encap_info?
make[2]: *** [net/core/skbuff.o] Error 1
make[1]: *** [net/core] Error 2
make: *** [net] Error 2

Could you please help?


Thank you

Ibrahim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130514/b9efa5bb/attachment.html>

[Romain KUNTZ]

Hello Ibrahim,

Thank you for this report. It seems that the kernel patch provided on umip.org is not correct.
Let me create a new patch, I will upload it tomorrow. I will let you know when it is done.

Sorry for the inconvenience,
Romain

On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com> wrote:

> Dear,
>
> When compiling kernal 3.8.2 after patching the MCoA patch and following the steps in sections "building mobility-ready kernel" and "building a DSMIPv6 and MCoA-ready kernel", I got these errors:
>
> net/core/skbuff.c: In function ?__copy_skb_header?:
> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
> make[2]: *** [net/core/skbuff.o] Error 1
> make[1]: *** [net/core] Error 2
> make: *** [net] Error 2
>
> Could you please help?
>
>
> Thank you
>
> Ibrahim
> _______________________________________________
> Support mailing list
> Support at ml.nautilus6.org
> http://ml.nautilus6.org/mailman/listinfo/support

[Romain KUNTZ]

Hello Ibrahim,

I have updated the kernel patch. The new version is located at the same place as before:
http://umip.org/contrib/patchs/linux-3.8.2-mcoa-dsmip6.patch

Can you give it a try and report any issues on this mailing list?

Thank you,
Romain


On May 14, 2013, at 21:23 , Romain KUNTZ <r.kuntz at gmail.com> wrote:

> Hello Ibrahim,
>
> Thank you for this report. It seems that the kernel patch provided on umip.org is not correct.
> Let me create a new patch, I will upload it tomorrow. I will let you know when it is done.
>
> Sorry for the inconvenience,
> Romain
>
> On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com> wrote:
>
>> Dear,
>>
>> When compiling kernal 3.8.2 after patching the MCoA patch and following the steps in sections "building mobility-ready kernel" and "building a DSMIPv6 and MCoA-ready kernel", I got these errors:
>>
>> net/core/skbuff.c: In function ?__copy_skb_header?:
>> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
>> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
>> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
>> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
>> make[2]: *** [net/core/skbuff.o] Error 1
>> make[1]: *** [net/core] Error 2
>> make: *** [net] Error 2
>>
>> Could you please help?
>>
>>
>> Thank you
>>
>> Ibrahim
>> _______________________________________________
>> Support mailing list
>> Support at ml.nautilus6.org
>> http://ml.nautilus6.org/mailman/listinfo/support
>

[ibrahim sulaiman]

Hello Romain,

Thank you very much for updating the patch. I will give it a try today and
let you know of any issue if there is any.

Kind regards

Ibrahim


On Wed, May 15, 2013 at 8:51 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:

> Hello Ibrahim,
>
> I have updated the kernel patch. The new version is located at the same
> place as before:
> http://umip.org/contrib/patchs/linux-3.8.2-mcoa-dsmip6.patch
>
> Can you give it a try and report any issues on this mailing list?
>
> Thank you,
> Romain
>
>
> On May 14, 2013, at 21:23 , Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
> > Hello Ibrahim,
> >
> > Thank you for this report. It seems that the kernel patch provided on
> umip.org is not correct.
> > Let me create a new patch, I will upload it tomorrow. I will let you
> know when it is done.
> >
> > Sorry for the inconvenience,
> > Romain
> >
> > On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com> wrote:
> >
> >> Dear,
> >>
> >> When compiling kernal 3.8.2 after patching the MCoA patch and following
> the steps in sections "building mobility-ready kernel" and "building a
> DSMIPv6 and MCoA-ready kernel", I got these errors:
> >>
> >> net/core/skbuff.c: In function ?__copy_skb_header?:
> >> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named
> ?udp_encap_info?
> >> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member
> named ?udp_encap_info?
> >> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named
> ?udp_encap_info?
> >> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member
> named ?udp_encap_info?
> >> make[2]: *** [net/core/skbuff.o] Error 1
> >> make[1]: *** [net/core] Error 2
> >> make: *** [net] Error 2
> >>
> >> Could you please help?
> >>
> >>
> >> Thank you
> >>
> >> Ibrahim
> >> _______________________________________________
> >> Support mailing list
> >> Support at ml.nautilus6.org
> >> http://ml.nautilus6.org/mailman/listinfo/support
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130515/b664de52/attachment.html>

[ibrahim sulaiman]

Hello Romain,

I have tried the updated kernel patch and it works for me, thank you!

I also tried the MCoA patch with kernel 3.9.2 but did not work as it seems
that this patch only works for kernel 3.8.2 (which it is not very stable
for me), so I am wondering if there is another patch for that kernel (or
the newer ones) or if there is going to be one.

Another issue is that I am only interested in running MCoA without DSMIPv6
and wondering how the configuration file should look like (I have tried
some possibilities but did not work for me).

Following the instructions in the example explained at the umip.org website
and configuring the HA and MR to enable MCoA, I got everything working fine
until a few seconds after I execute the script enforcing the routing
policies, that is the tunnels were deleted by the HA and no cache entries
exist

This is what I have got at the HA side just seconds after applying the
routing policies (see the last 13 lines):


Mon May 20 15:13:20 mh_bu_parse: Binding Update Received
Mon May 20 15:13:21 ndisc_do_dad: Dad success
Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
Mon May 20 15:13:21 __tunnel_add: MCOA_DFLT_TNL_ADD for BID 10
Mon May 20 15:13:21 __tunnel_add: created tunnel 7 from 2001:db8:444::1 to
2001:db8:1:0:6670:2ff:feec:ccd6 user count 1
Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
Mon May 20 15:13:21 mh_send: sending MH type 6
from 2001:db8:444:0:0:0:0:1
to 2001:db8:444:0:0:0:0:2
Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
Mon May 20 15:13:21 ha_recv_bu_worker: BID option (BID = 10), and HA is
configured for MCoA.
Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
Mon May 20 15:13:21 tunnel_mod: modifying tunnel 7 end points with from
2001:db8:444::1 to 2001:db8:1:0:6670:2ff:feec:ccd6
Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
Mon May 20 15:13:21 mh_send: sending MH type 6
from 2001:db8:444:0:0:0:0:1
to 2001:db8:444:0:0:0:0:2
Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
Mon May 20 15:13:36 mh_bu_parse: Binding Update Received
Mon May 20 15:13:36 ha_recv_bu_worker: BID option (BID = 20), and HA is
configured for MCoA.
Mon May 20 15:13:36 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
Mon May 20 15:13:36 __tunnel_add: MCOA_DFLT_TNL_UPDATE from BID 10 to BID 20
Mon May 20 15:13:36 __tunnel_add: created tunnel 7 from 2001:db8:444::1 to
2001:db8:6:0:a2f3:c1ff:fe70:717c user count 1
Mon May 20 15:13:36 mh_send_ba: status Binding Update accepted (0)
Mon May 20 15:13:36 mh_send: sending MH type 6
from 2001:db8:444:0:0:0:0:1
to 2001:db8:444:0:0:0:0:2
Mon May 20 15:13:36 mh_send: remote CoA 2001:db8:6:0:a2f3:c1ff:fe70:717c
Mon May 20 15:14:21 xfrm_del_bce_dsmip: No need to remove UDP encaps.
policies and states
Mon May 20 15:14:21 __tunnel_del: tunnel 7 from 2001:db8:444::1 to
2001:db8:1:0:6670:2ff:feec:ccd6 user count decreased to 0
Mon May 20 15:14:21 __tunnel_del: Not the default tunnel, no default
policies to clean
Mon May 20 15:14:21 __tunnel_del: XFRM tunnel deleted
Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
XFRM output policy for the MPA
Mon May 20 15:14:36 xfrm_del_bce: Last entry for the peer, deleting XFRM
output policy for the BA
Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
XFRM RH2 state for the BA
Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
XFRM input policy for the BU
Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
XFRM Dest. Opt. state for the BU
Mon May 20 15:14:36 xfrm_del_bce_dsmip: No need to remove UDP encaps.
policies and states
Mon May 20 15:14:36 __tunnel_del: tunnel 7 from 2001:db8:444::1 to
2001:db8:6:0:a2f3:c1ff:fe70:717c user count decreased to 0
Mon May 20 15:14:36 __tunnel_del: Last tunnel for peer: deleting XFRM dflt
policy for BID 20
Mon May 20 15:14:36 __tunnel_del: XFRM tunnel deleted


could you please help?


Thank you


Ibrahim


On Wed, May 15, 2013 at 10:10 AM, ibrahim sulaiman <isukity at gmail.com>wrote:

> Hello Romain,
>
> Thank you very much for updating the patch. I will give it a try today and
> let you know of any issue if there is any.
>
> Kind regards
>
> Ibrahim
>
>
> On Wed, May 15, 2013 at 8:51 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
>> Hello Ibrahim,
>>
>> I have updated the kernel patch. The new version is located at the same
>> place as before:
>> http://umip.org/contrib/patchs/linux-3.8.2-mcoa-dsmip6.patch
>>
>> Can you give it a try and report any issues on this mailing list?
>>
>> Thank you,
>> Romain
>>
>>
>> On May 14, 2013, at 21:23 , Romain KUNTZ <r.kuntz at gmail.com> wrote:
>>
>> > Hello Ibrahim,
>> >
>> > Thank you for this report. It seems that the kernel patch provided on
>> umip.org is not correct.
>> > Let me create a new patch, I will upload it tomorrow. I will let you
>> know when it is done.
>> >
>> > Sorry for the inconvenience,
>> > Romain
>> >
>> > On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> >
>> >> Dear,
>> >>
>> >> When compiling kernal 3.8.2 after patching the MCoA patch and
>> following the steps in sections "building mobility-ready kernel" and
>> "building a DSMIPv6 and MCoA-ready kernel", I got these errors:
>> >>
>> >> net/core/skbuff.c: In function ?__copy_skb_header?:
>> >> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named
>> ?udp_encap_info?
>> >> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member
>> named ?udp_encap_info?
>> >> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named
>> ?udp_encap_info?
>> >> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member
>> named ?udp_encap_info?
>> >> make[2]: *** [net/core/skbuff.o] Error 1
>> >> make[1]: *** [net/core] Error 2
>> >> make: *** [net] Error 2
>> >>
>> >> Could you please help?
>> >>
>> >>
>> >> Thank you
>> >>
>> >> Ibrahim
>> >> _______________________________________________
>> >> Support mailing list
>> >> Support at ml.nautilus6.org
>> >> http://ml.nautilus6.org/mailman/listinfo/support
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130520/b3165621/attachment.html>

[Romain KUNTZ]

Hello Ibrahim,

On May 20, 2013, at 18:52 , ibrahim sulaiman <isukity at gmail.com> wrote:
> Hello Romain,
>
> I have tried the updated kernel patch and it works for me, thank you!
>
> I also tried the MCoA patch with kernel 3.9.2 but did not work as it seems that this patch only works for kernel 3.8.2 (which it is not very stable for me), so I am wondering if there is another patch for that kernel (or the newer ones) or if there is going to be one.

At the moment there are no patches for kernel 3.9.2 but it should not be too hard to port the current patch to a new kernel version. On my side, I don't have much time to dedicate to this task at the moment.

> Another issue is that I am only interested in running MCoA without DSMIPv6 and wondering how the configuration file should look like (I have tried some possibilities but did not work for me).

Can you send your configuration file ?

If you plan to use only MCoA, it should look like this on the HA side:

######################################
# Sample UMIP configuration file for a
# NEMO and MCoA-enabled Home Agent
NodeConfig HA;

# Set DebugLevel to 0 if you do not want debug messages
DebugLevel 10;

# Replace eth0 with the interface connected to the home link
Interface "eth0";

# Accept registrations from Mobile Routers
HaAcceptMobRtr enabled;

# Accept MCoA and DSMIPv6 registrations
HaAcceptMCoA enabled;

# Binding informations
BindingAclPolicy 2001:db8:ffff:0::1 (2001:db8:ffff:ff01::/64) MCoA allow;
DefaultBindingAclPolicy allow;

# Disable IPsec. It is not compatible with MCoA
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;
######################################

And on the MR side:

######################################
# Sample UMIP configuration file for a
# NEMO and MCoA-enabled Mobile Router
NodeConfig MN;

# Set DebugLevel to 0 if you do not want debug messages
DebugLevel 10;

# Enable the optimistic handovers
OptimisticHandoff enabled;

# The Binding Lifetime (in sec.)
MnMaxHaBindingLife 60;

# Disable RO
DoRouteOptimizationCN disabled;
DoRouteOptimizationMN disabled;
UseCnBuAck disabled;
MnDiscardHaParamProb enabled;

# Use NEMO Explicit Mode
MobRtrUseExplicitMode enabled;

# List here the interfaces that you will use
# on your mobile node. All of the interfaces will
# be used at the same time (with MCoA).
Interface "eth0" {
MnIfPreference 1;
# BID of the interface
Bid 10;
}
Interface "wlan0" {
MnIfPreference 2;
# BID of the interface
Bid 20;
}

# Replace eth0 with one of your interface used on
# your mobile node.
MnHomeLink "eth0" {
IsMobRtr enabled;
HomeAgentAddress 2001:db8:ffff:0::1000;
HomeAddress 2001:db8:ffff:0::1/64 (2001:db8:ffff:ff01::/64);

# Enable MCoA and register the interfaces used for MCoA
# Replace eth0 and wlan0 with your egress interface names.
MCoAReg enabled;
MCoAIface "eth0", "wlan0";
}

# Disable IPsec. It is not compatible with MCoA
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;
######################################


> Following the instructions in the example explained at the umip.org website and configuring the HA and MR to enable MCoA, I got everything working fine until a few seconds after I execute the script enforcing the routing policies, that is the tunnels were deleted by the HA and no cache entries exist\

What is the content of the script? Is it the same as the one provided in the documentation?

> This is what I have got at the HA side just seconds after applying the routing policies (see the last 13 lines):
>
> Mon May 20 15:13:20 mh_bu_parse: Binding Update Received
> Mon May 20 15:13:21 ndisc_do_dad: Dad success
> Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> Mon May 20 15:13:21 __tunnel_add: MCOA_DFLT_TNL_ADD for BID 10
> Mon May 20 15:13:21 __tunnel_add: created tunnel 7 from 2001:db8:444::1 to 2001:db8:1:0:6670:2ff:feec:ccd6 user count 1
> Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
> Mon May 20 15:13:21 mh_send: sending MH type 6
> from 2001:db8:444:0:0:0:0:1
> to 2001:db8:444:0:0:0:0:2
> Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
> Mon May 20 15:13:21 ha_recv_bu_worker: BID option (BID = 10), and HA is configured for MCoA.
> Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> Mon May 20 15:13:21 tunnel_mod: modifying tunnel 7 end points with from 2001:db8:444::1 to 2001:db8:1:0:6670:2ff:feec:ccd6
> Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
> Mon May 20 15:13:21 mh_send: sending MH type 6
> from 2001:db8:444:0:0:0:0:1
> to 2001:db8:444:0:0:0:0:2
> Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
> Mon May 20 15:13:36 mh_bu_parse: Binding Update Received
> Mon May 20 15:13:36 ha_recv_bu_worker: BID option (BID = 20), and HA is configured for MCoA.
> Mon May 20 15:13:36 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> Mon May 20 15:13:36 __tunnel_add: MCOA_DFLT_TNL_UPDATE from BID 10 to BID 20
> Mon May 20 15:13:36 __tunnel_add: created tunnel 7 from 2001:db8:444::1 to 2001:db8:6:0:a2f3:c1ff:fe70:717c user count 1
> Mon May 20 15:13:36 mh_send_ba: status Binding Update accepted (0)
> Mon May 20 15:13:36 mh_send: sending MH type 6
> from 2001:db8:444:0:0:0:0:1
> to 2001:db8:444:0:0:0:0:2
> Mon May 20 15:13:36 mh_send: remote CoA 2001:db8:6:0:a2f3:c1ff:fe70:717c
> Mon May 20 15:14:21 xfrm_del_bce_dsmip: No need to remove UDP encaps. policies and states
> Mon May 20 15:14:21 __tunnel_del: tunnel 7 from 2001:db8:444::1 to 2001:db8:1:0:6670:2ff:feec:ccd6 user count decreased to 0
> Mon May 20 15:14:21 __tunnel_del: Not the default tunnel, no default policies to clean
> Mon May 20 15:14:21 __tunnel_del: XFRM tunnel deleted
> Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting XFRM output policy for the MPA
> Mon May 20 15:14:36 xfrm_del_bce: Last entry for the peer, deleting XFRM output policy for the BA
> Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting XFRM RH2 state for the BA
> Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting XFRM input policy for the BU
> Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting XFRM Dest. Opt. state for the BU
> Mon May 20 15:14:36 xfrm_del_bce_dsmip: No need to remove UDP encaps. policies and states
> Mon May 20 15:14:36 __tunnel_del: tunnel 7 from 2001:db8:444::1 to 2001:db8:6:0:a2f3:c1ff:fe70:717c user count decreased to 0
> Mon May 20 15:14:36 __tunnel_del: Last tunnel for peer: deleting XFRM dflt policy for BID 20
> Mon May 20 15:14:36 __tunnel_del: XFRM tunnel deleted


The tunnel are deleted because the MR does not send any new binding update. If you have set "MnMaxHaBindingLife" to 60 in the MR configuration file, it is supposed to send a refresh BU every 60 seconds. From the above logs, it does not seem to be the case. Please check the MR logs in order to see why the MR does not send the refresh BU.

Best,
Romain


>
>
> could you please help?
>
>
> Thank you
>
>
> Ibrahim
>
>
> On Wed, May 15, 2013 at 10:10 AM, ibrahim sulaiman <isukity at gmail.com> wrote:
> Hello Romain,
>
> Thank you very much for updating the patch. I will give it a try today and let you know of any issue if there is any.
>
> Kind regards
>
> Ibrahim
>
>
> On Wed, May 15, 2013 at 8:51 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> Hello Ibrahim,
>
> I have updated the kernel patch. The new version is located at the same place as before:
> http://umip.org/contrib/patchs/linux-3.8.2-mcoa-dsmip6.patch
>
> Can you give it a try and report any issues on this mailing list?
>
> Thank you,
> Romain
>
>
> On May 14, 2013, at 21:23 , Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
> > Hello Ibrahim,
> >
> > Thank you for this report. It seems that the kernel patch provided on umip.org is not correct.
> > Let me create a new patch, I will upload it tomorrow. I will let you know when it is done.
> >
> > Sorry for the inconvenience,
> > Romain
> >
> > On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com> wrote:
> >
> >> Dear,
> >>
> >> When compiling kernal 3.8.2 after patching the MCoA patch and following the steps in sections "building mobility-ready kernel" and "building a DSMIPv6 and MCoA-ready kernel", I got these errors:
> >>
> >> net/core/skbuff.c: In function ?__copy_skb_header?:
> >> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
> >> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
> >> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named ?udp_encap_info?
> >> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member named ?udp_encap_info?
> >> make[2]: *** [net/core/skbuff.o] Error 1
> >> make[1]: *** [net/core] Error 2
> >> make: *** [net] Error 2
> >>
> >> Could you please help?
> >>
> >>
> >> Thank you
> >>
> >> Ibrahim
> >> _______________________________________________
> >> Support mailing list
> >> Support at ml.nautilus6.org
> >> http://ml.nautilus6.org/mailman/listinfo/support
> >
>
>
>

[ibrahim sulaiman]

Hello Romain,



On Wed, May 22, 2013 at 7:32 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
> Hello Ibrahim,
>
> On May 20, 2013, at 18:52 , ibrahim sulaiman <isukity at gmail.com> wrote:
> > Hello Romain,
> >
> > I have tried the updated kernel patch and it works for me, thank you!
> >
> > I also tried the MCoA patch with kernel 3.9.2 but did not work as it
> > seems that this patch only works for kernel 3.8.2 (which it is not very
> > stable for me), so I am wondering if there is another patch for that
kernel
> > (or the newer ones) or if there is going to be one.
>
> At the moment there are no patches for kernel 3.9.2 but it should not be
> too hard to port the current patch to a new kernel version. On my side, I
> don't have much time to dedicate to this task at the moment.
>

All right, I will try myself to port it to the new kernel as soon I have
time for that, if this is going to be fine with you.

> > Another issue is that I am only interested in running MCoA without
> > DSMIPv6 and wondering how the configuration file should look like (I
have
> > tried some possibilities but did not work for me).
>
> Can you send your configuration file ?
>
> If you plan to use only MCoA, it should look like this on the HA side:
>
> ######################################
> # Sample UMIP configuration file for a
> # NEMO and MCoA-enabled Home Agent
> NodeConfig HA;
>
> # Set DebugLevel to 0 if you do not want debug messages
> DebugLevel 10;
>
> # Replace eth0 with the interface connected to the home link
> Interface "eth0";
>
> # Accept registrations from Mobile Routers
> HaAcceptMobRtr enabled;
>
> # Accept MCoA and DSMIPv6 registrations
> HaAcceptMCoA enabled;
>
> # Binding informations
> BindingAclPolicy 2001:db8:ffff:0::1 (2001:db8:ffff:ff01::/64) MCoA allow;
> DefaultBindingAclPolicy allow;
>
> # Disable IPsec. It is not compatible with MCoA
> UseMnHaIPsec disabled;
> KeyMngMobCapability disabled;
> ######################################
>

I have the same config file but when I run mipv6 I had this message:
Error in configuration file /usr/local/etc/mip6d.conf at line 18: syntax
error at 'MCoA'


> And on the MR side:
>
> ######################################
> # Sample UMIP configuration file for a
> # NEMO and MCoA-enabled Mobile Router
> NodeConfig MN;
>
> # Set DebugLevel to 0 if you do not want debug messages
> DebugLevel 10;
>
> # Enable the optimistic handovers
> OptimisticHandoff enabled;
>
> # The Binding Lifetime (in sec.)
> MnMaxHaBindingLife 60;
>
> # Disable RO
> DoRouteOptimizationCN disabled;
> DoRouteOptimizationMN disabled;
> UseCnBuAck disabled;
> MnDiscardHaParamProb enabled;
>
> # Use NEMO Explicit Mode
> MobRtrUseExplicitMode enabled;
>
> # List here the interfaces that you will use
> # on your mobile node. All of the interfaces will
> # be used at the same time (with MCoA).
> Interface "eth0" {
> MnIfPreference 1;
> # BID of the interface
> Bid 10;
> }
> Interface "wlan0" {
> MnIfPreference 2;
> # BID of the interface
> Bid 20;
> }
>
> # Replace eth0 with one of your interface used on
> # your mobile node.
> MnHomeLink "eth0" {
> IsMobRtr enabled;
> HomeAgentAddress 2001:db8:ffff:0::1000;
> HomeAddress 2001:db8:ffff:0::1/64 (2001:db8:ffff:ff01::/64);
>
> # Enable MCoA and register the interfaces used for MCoA
> # Replace eth0 and wlan0 with your egress interface names.
> MCoAReg enabled;
> MCoAIface "eth0", "wlan0";
> }
>
> # Disable IPsec. It is not compatible with MCoA
> UseMnHaIPsec disabled;
> KeyMngMobCapability disabled;
> ######################################
>
>
> > Following the instructions in the example explained at the umip.org
> > website and configuring the HA and MR to enable MCoA, I got everything
> > working fine until a few seconds after I execute the script enforcing
the
> > routing policies, that is the tunnels were deleted by the HA and no
cache
> > entries exist\
>
> What is the content of the script? Is it the same as the one provided in
> the documentation?
>

Yes, it is the same as the one provided in the documentation.

> > This is what I have got at the HA side just seconds after applying the
> > routing policies (see the last 13 lines):
> >
> > Mon May 20 15:13:20 mh_bu_parse: Binding Update Received
> > Mon May 20 15:13:21 ndisc_do_dad: Dad success
> > Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> > Mon May 20 15:13:21 __tunnel_add: MCOA_DFLT_TNL_ADD for BID 10
> > Mon May 20 15:13:21 __tunnel_add: created tunnel 7 from 2001:db8:444::1
> > to 2001:db8:1:0:6670:2ff:feec:ccd6 user count 1
> > Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
> > Mon May 20 15:13:21 mh_send: sending MH type 6
> > from 2001:db8:444:0:0:0:0:1
> > to 2001:db8:444:0:0:0:0:2
> > Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
> > Mon May 20 15:13:21 ha_recv_bu_worker: BID option (BID = 10), and HA is
> > configured for MCoA.
> > Mon May 20 15:13:21 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> > Mon May 20 15:13:21 tunnel_mod: modifying tunnel 7 end points with from
> > 2001:db8:444::1 to 2001:db8:1:0:6670:2ff:feec:ccd6
> > Mon May 20 15:13:21 mh_send_ba: status Binding Update accepted (0)
> > Mon May 20 15:13:21 mh_send: sending MH type 6
> > from 2001:db8:444:0:0:0:0:1
> > to 2001:db8:444:0:0:0:0:2
> > Mon May 20 15:13:21 mh_send: remote CoA 2001:db8:1:0:6670:2ff:feec:ccd6
> > Mon May 20 15:13:36 mh_bu_parse: Binding Update Received
> > Mon May 20 15:13:36 ha_recv_bu_worker: BID option (BID = 20), and HA is
> > configured for MCoA.
> > Mon May 20 15:13:36 ha_recv_bu_worker: retrieved 1 IPv4 MNPs
> > Mon May 20 15:13:36 __tunnel_add: MCOA_DFLT_TNL_UPDATE from BID 10 to
> > BID 20
> > Mon May 20 15:13:36 __tunnel_add: created tunnel 7 from 2001:db8:444::1
> > to 2001:db8:6:0:a2f3:c1ff:fe70:717c user count 1
> > Mon May 20 15:13:36 mh_send_ba: status Binding Update accepted (0)
> > Mon May 20 15:13:36 mh_send: sending MH type 6
> > from 2001:db8:444:0:0:0:0:1
> > to 2001:db8:444:0:0:0:0:2
> > Mon May 20 15:13:36 mh_send: remote CoA 2001:db8:6:0:a2f3:c1ff:fe70:717c
> > Mon May 20 15:14:21 xfrm_del_bce_dsmip: No need to remove UDP encaps.
> > policies and states
> > Mon May 20 15:14:21 __tunnel_del: tunnel 7 from 2001:db8:444::1 to
> > 2001:db8:1:0:6670:2ff:feec:ccd6 user count decreased to 0
> > Mon May 20 15:14:21 __tunnel_del: Not the default tunnel, no default
> > policies to clean
> > Mon May 20 15:14:21 __tunnel_del: XFRM tunnel deleted
> > Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
> > XFRM output policy for the MPA
> > Mon May 20 15:14:36 xfrm_del_bce: Last entry for the peer, deleting XFRM
> > output policy for the BA
> > Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
> > XFRM RH2 state for the BA
> > Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
> > XFRM input policy for the BU
> > Mon May 20 15:14:36 xfrm_del_bce: Last IPv6 entry for the peer, deleting
> > XFRM Dest. Opt. state for the BU
> > Mon May 20 15:14:36 xfrm_del_bce_dsmip: No need to remove UDP encaps.
> > policies and states
> > Mon May 20 15:14:36 __tunnel_del: tunnel 7 from 2001:db8:444::1 to
> > 2001:db8:6:0:a2f3:c1ff:fe70:717c user count decreased to 0
> > Mon May 20 15:14:36 __tunnel_del: Last tunnel for peer: deleting XFRM
> > dflt policy for BID 20
> > Mon May 20 15:14:36 __tunnel_del: XFRM tunnel deleted
>
>
> The tunnel are deleted because the MR does not send any new binding
> update. If you have set "MnMaxHaBindingLife" to 60 in the MR configuration
> file, it is supposed to send a refresh BU every 60 seconds. From the above
> logs, it does not seem to be the case. Please check the MR logs in order
to
> see why the MR does not send the refresh BU.

Yes, it seems that the MR fails to send the refresh BU but what do you
think the problem behind that?
here is the MR logs:

Sun May 26 16:51:49 bu_refresh: BU refresh type: 0
Sun May 26 16:51:49 mn_get_home_lifetime: CoA lifetime 86395 s, HoA
lifetime 84864 s, BU lifetime 60 s
Sun May 26 16:51:49 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:49 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:49 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:49 mh_send: local CoA 2001:db8:6:0:6670:2ff:feec:cce5
Sun May 26 16:51:49 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:49 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:49 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:6:0:6670:2ff:feec:cce5
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 1000
BID = 20
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR
Sun May 26 16:51:50 bu_resend: BU resend type 0
Sun May 26 16:51:50 mn_get_home_lifetime: CoA lifetime 86394 s, HoA
lifetime 84863 s, BU lifetime 60 s
Sun May 26 16:51:50 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:50 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:50 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:50 mh_send: local CoA 2001:db8:6:0:6670:2ff:feec:cce5
Sun May 26 16:51:50 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:50 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:50 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:6:0:6670:2ff:feec:cce5
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 2000
BID = 20
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR
Sun May 26 16:51:51 md_update_router_stats: Adding CoA
2001:db8:6:0:6670:2ff:feec:cce5 on interface (6)
Sun May 26 16:51:51 mcoa_mn_chk_ho_verdict: Verdict 4 for iface 6
Sun May 26 16:51:51 mcoa_mn_chk_ho_verdict: Verdict 5 for iface 6
Sun May 26 16:51:51 bu_refresh: BU refresh type: 0
Sun May 26 16:51:51 mn_get_home_lifetime: CoA lifetime 86395 s, HoA
lifetime 84861 s, BU lifetime 60 s
Sun May 26 16:51:51 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:51 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:51 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:51 mh_send: local CoA 2001:db8:1:0:a2f3:c1ff:fe70:717c
Sun May 26 16:51:51 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:51 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:51 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:1:0:a2f3:c1ff:fe70:717c
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 1000
BID = 10
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR
Sun May 26 16:51:52 bu_resend: BU resend type 0
Sun May 26 16:51:52 mn_get_home_lifetime: CoA lifetime 86398 s, HoA
lifetime 84861 s, BU lifetime 60 s
Sun May 26 16:51:52 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:52 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:52 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:52 mh_send: local CoA 2001:db8:6:0:6670:2ff:feec:cce5
Sun May 26 16:51:52 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:52 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:52 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:6:0:6670:2ff:feec:cce5
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 4000
BID = 20
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR
Sun May 26 16:51:52 bu_resend: BU resend type 0
Sun May 26 16:51:52 mn_get_home_lifetime: CoA lifetime 86394 s, HoA
lifetime 84860 s, BU lifetime 60 s
Sun May 26 16:51:52 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:52 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:52 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:52 mh_send: local CoA 2001:db8:1:0:a2f3:c1ff:fe70:717c
Sun May 26 16:51:52 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:52 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:52 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:1:0:a2f3:c1ff:fe70:717c
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 2000
BID = 10
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR
Sun May 26 16:51:54 bu_resend: BU resend type 0
Sun May 26 16:51:54 mn_get_home_lifetime: CoA lifetime 86392 s, HoA
lifetime 84858 s, BU lifetime 60 s
Sun May 26 16:51:54 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
Sun May 26 16:51:54 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
Sun May 26 16:51:54 mh_send: sending MH type 5
from 2001:db8:444:0:0:0:0:2
to 2001:db8:444:0:0:0:0:1
Sun May 26 16:51:54 mh_send: local CoA 2001:db8:1:0:a2f3:c1ff:fe70:717c
Sun May 26 16:51:54 mh_send: sendmsg: Operation not permitted
Sun May 26 16:51:54 mn_send_bu_msg: mh_send failed ret: -1
Sun May 26 16:51:54 bul_update_timer: Updating timer
== BUL_ENTRY ==
IPv6 Home address 2001:db8:444:0:0:0:0:2
IPv4 Home address 10.10.10.100
Care-of address 2001:db8:1:0:a2f3:c1ff:fe70:717c
CN address 2001:db8:444:0:0:0:0:1
lifetime = 60, delay = 4000
BID = 10
flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_MR




Kind regards

Ibrahim

>
> Best,
> Romain
>
>
> >
> >
> > could you please help?
> >
> >
> > Thank you
> >
> >
> > Ibrahim
> >
> >
> > On Wed, May 15, 2013 at 10:10 AM, ibrahim sulaiman <isukity at gmail.com>
> > wrote:
> > Hello Romain,
> >
> > Thank you very much for updating the patch. I will give it a try today
> > and let you know of any issue if there is any.
> >
> > Kind regards
> >
> > Ibrahim
> >
> >
> > On Wed, May 15, 2013 at 8:51 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> > Hello Ibrahim,
> >
> > I have updated the kernel patch. The new version is located at the same
> > place as before:
> > http://umip.org/contrib/patchs/linux-3.8.2-mcoa-dsmip6.patch
> >
> > Can you give it a try and report any issues on this mailing list?
> >
> > Thank you,
> > Romain
> >
> >
> > On May 14, 2013, at 21:23 , Romain KUNTZ <r.kuntz at gmail.com> wrote:
> >
> > > Hello Ibrahim,
> > >
> > > Thank you for this report. It seems that the kernel patch provided on
> > > umip.org is not correct.
> > > Let me create a new patch, I will upload it tomorrow. I will let you
> > > know when it is done.
> > >
> > > Sorry for the inconvenience,
> > > Romain
> > >
> > > On May 14, 2013, at 14:08 , ibrahim sulaiman <isukity at gmail.com>
> > > wrote:
> > >
> > >> Dear,
> > >>
> > >> When compiling kernal 3.8.2 after patching the MCoA patch and
> > >> following the steps in sections "building mobility-ready kernel" and
> > >> "building a DSMIPv6 and MCoA-ready kernel", I got these errors:
> > >>
> > >> net/core/skbuff.c: In function ?__copy_skb_header?:
> > >> net/core/skbuff.c:709:5: error: ?struct sk_buff? has no member named
> > >> ?udp_encap_info?
> > >> net/core/skbuff.c:709:33: error: ?const struct sk_buff? has no member
> > >> named ?udp_encap_info?
> > >> net/core/skbuff.c:710:5: error: ?struct sk_buff? has no member named
> > >> ?udp_encap_info?
> > >> net/core/skbuff.c:710:33: error: ?const struct sk_buff? has no member
> > >> named ?udp_encap_info?
> > >> make[2]: *** [net/core/skbuff.o] Error 1
> > >> make[1]: *** [net/core] Error 2
> > >> make: *** [net] Error 2
> > >>
> > >> Could you please help?
> > >>
> > >>
> > >> Thank you
> > >>
> > >> Ibrahim
> > >> _______________________________________________
> > >> Support mailing list
> > >> Support at ml.nautilus6.org
> > >> http://ml.nautilus6.org/mailman/listinfo/support
> > >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130526/c8761796/attachment-0001.html>

[Romain KUNTZ]

Hello Ibrahim,

On May 26, 2013, at 18:43 , ibrahim sulaiman <isukity at gmail.com> wrote:
> On Wed, May 22, 2013 at 7:32 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> > On May 20, 2013, at 18:52 , ibrahim sulaiman <isukity at gmail.com> wrote:
> > > Hello Romain,
> > >
> > > I have tried the updated kernel patch and it works for me, thank you!
> > >
> > > I also tried the MCoA patch with kernel 3.9.2 but did not work as it
> > > seems that this patch only works for kernel 3.8.2 (which it is not very
> > > stable for me), so I am wondering if there is another patch for that kernel
> > > (or the newer ones) or if there is going to be one.
> >
> > At the moment there are no patches for kernel 3.9.2 but it should not be
> > too hard to port the current patch to a new kernel version. On my side, I
> > don't have much time to dedicate to this task at the moment.
> >
>
> All right, I will try myself to port it to the new kernel as soon I have time for that, if this is going to be fine with you.

Yes, feel free to contribute the patch to the mailing list.


> > > Another issue is that I am only interested in running MCoA without
> > > DSMIPv6 and wondering how the configuration file should look like (I have
> > > tried some possibilities but did not work for me).
> >
> > Can you send your configuration file ?
> >
> > If you plan to use only MCoA, it should look like this on the HA side:
> >
> > ######################################
> > # Sample UMIP configuration file for a
> > # NEMO and MCoA-enabled Home Agent
> > NodeConfig HA;
> >
> > # Set DebugLevel to 0 if you do not want debug messages
> > DebugLevel 10;
> >
> > # Replace eth0 with the interface connected to the home link
> > Interface "eth0";
> >
> > # Accept registrations from Mobile Routers
> > HaAcceptMobRtr enabled;
> >
> > # Accept MCoA and DSMIPv6 registrations
> > HaAcceptMCoA enabled;
> >
> > # Binding informations
> > BindingAclPolicy 2001:db8:ffff:0::1 (2001:db8:ffff:ff01::/64) MCoA allow;
> > DefaultBindingAclPolicy allow;
> >
> > # Disable IPsec. It is not compatible with MCoA
> > UseMnHaIPsec disabled;
> > KeyMngMobCapability disabled;
> > ######################################
> >
>
> I have the same config file but when I run mipv6 I had this message:
> Error in configuration file /usr/local/etc/mip6d.conf at line 18: syntax error at 'MCoA'

My mistake, the IPv4 HoA address is mandatory in the configuration file (even if you do not use it). You can actually set it to whatever you want, but it must be set. Try this instead:

BindingAclPolicy 2001:db8:ffff:0::1 (2001:db8:ffff:ff01::/64) 10.10.10.100 MCoA allow;


> > > Mon May 20 15:14:36 __tunnel_del: Last tunnel for peer: deleting XFRM
> > > dflt policy for BID 20
> > > Mon May 20 15:14:36 __tunnel_del: XFRM tunnel deleted
> >
> >
> > The tunnel are deleted because the MR does not send any new binding
> > update. If you have set "MnMaxHaBindingLife" to 60 in the MR configuration
> > file, it is supposed to send a refresh BU every 60 seconds. From the above
> > logs, it does not seem to be the case. Please check the MR logs in order to
> > see why the MR does not send the refresh BU.
>
> Yes, it seems that the MR fails to send the refresh BU but what do you think the problem behind that?
> here is the MR logs:
>
> Sun May 26 16:51:49 bu_refresh: BU refresh type: 0
> Sun May 26 16:51:49 mn_get_home_lifetime: CoA lifetime 86395 s, HoA lifetime 84864 s, BU lifetime 60 s
> Sun May 26 16:51:49 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0 IPv4)
> Sun May 26 16:51:49 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
> Sun May 26 16:51:49 mh_send: sending MH type 5
> from 2001:db8:444:0:0:0:0:2
> to 2001:db8:444:0:0:0:0:1
> Sun May 26 16:51:49 mh_send: local CoA 2001:db8:6:0:6670:2ff:feec:cce5
> Sun May 26 16:51:49 mh_send: sendmsg: Operation not permitted
> Sun May 26 16:51:49 mn_send_bu_msg: mh_send failed ret: -1

It seems that the MR does not manage to send the BU (mh_send fails with status code -1). Does this happen when you apply the routing policies, or does it happen even without the routing policies?

Best,
Romain

[ibrahim sulaiman]

Hello Romain,

>
> BindingAclPolicy 2001:db8:ffff:0::1 (2001:db8:ffff:ff01::/64) 10.10.10.100
> MCoA allow;
>
>
> > > > Mon May 20 15:14:36 __tunnel_del: Last tunnel for peer: deleting
> > > > XFRM
> > > > dflt policy for BID 20
> > > > Mon May 20 15:14:36 __tunnel_del: XFRM tunnel deleted
> > >
> > >
> > > The tunnel are deleted because the MR does not send any new binding
> > > update. If you have set "MnMaxHaBindingLife" to 60 in the MR
> > > configuration
> > > file, it is supposed to send a refresh BU every 60 seconds. From the
> > > above
> > > logs, it does not seem to be the case. Please check the MR logs in
> > > order to
> > > see why the MR does not send the refresh BU.
> >
> > Yes, it seems that the MR fails to send the refresh BU but what do you
> > think the problem behind that?
> > here is the MR logs:
> >
> > Sun May 26 16:51:49 bu_refresh: BU refresh type: 0
> > Sun May 26 16:51:49 mn_get_home_lifetime: CoA lifetime 86395 s, HoA
> > lifetime 84864 s, BU lifetime 60 s
> > Sun May 26 16:51:49 xfrm_pre_bu_add_bule: total BULE: 2 (2 IPv6 - 0
> > IPv4)
> > Sun May 26 16:51:49 xfrm_pre_bu_add_bule: Adding Dest. Opt. state
> > Sun May 26 16:51:49 mh_send: sending MH type 5
> > from 2001:db8:444:0:0:0:0:2
> > to 2001:db8:444:0:0:0:0:1
> > Sun May 26 16:51:49 mh_send: local CoA 2001:db8:6:0:6670:2ff:feec:cce5
> > Sun May 26 16:51:49 mh_send: sendmsg: Operation not permitted
> > Sun May 26 16:51:49 mn_send_bu_msg: mh_send failed ret: -1
>
> It seems that the MR does not manage to send the BU (mh_send fails with
> status code -1). Does this happen when you apply the routing policies, or
> does it happen even without the routing policies?
>

Everything works fine until I apply the routing policies on the MR
side and the time for the refresh BU comes, then the tunnels are
deleted. This only happens when the routing policies are applied on
the MR whereas it works fine when applied on the HA!!

Thank you

Ibrahim

[Romain KUNTZ]

Hello,

On May 27, 2013, at 15:03 , ibrahim sulaiman <isukity at gmail.com> wrote:
>>> Sun May 26 16:51:49 mh_send: sendmsg: Operation not permitted
>>> Sun May 26 16:51:49 mn_send_bu_msg: mh_send failed ret: -1
>>
>> It seems that the MR does not manage to send the BU (mh_send fails with
>> status code -1). Does this happen when you apply the routing policies, or
>> does it happen even without the routing policies?
>>
>
> Everything works fine until I apply the routing policies on the MR
> side and the time for the refresh BU comes, then the tunnels are
> deleted. This only happens when the routing policies are applied on
> the MR whereas it works fine when applied on the HA!!

Ok, so the problem may come from the routing policies. I've just checked the online documentation and the examples might need a bit more tuning. I suspect that the ones with the "${HOA}" argument are problematic because they also include the signalling messages (BU/BA), which is not good. You probably need to specify more specific routing policies (using destination addresses or protocols/port numbers).

For example, you can try to add the "-p icmpv6" parameter to your policies in order to test the rules only for the ICMPv6 (i.e. ping6) traffic.

I have updated the example on the online documentation (as a side note, there was a also a typo in the document: all the rules were using the BID 20 whereas the ones with the HoA were supposed to use the BID 10), in the section "Routing Policies":
http://umip.org/contrib/umip-mcoa-dsmipv6.html



Romain

[ibrahim sulaiman]

Hello Romain,


On Mon, May 27, 2013 at 3:46 PM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> Hello,
>
> On May 27, 2013, at 15:03 , ibrahim sulaiman <isukity at gmail.com> wrote:
>>>> Sun May 26 16:51:49 mh_send: sendmsg: Operation not permitted
>>>> Sun May 26 16:51:49 mn_send_bu_msg: mh_send failed ret: -1
>>>
>>> It seems that the MR does not manage to send the BU (mh_send fails with
>>> status code -1). Does this happen when you apply the routing policies, or
>>> does it happen even without the routing policies?
>>>
>>
>> Everything works fine until I apply the routing policies on the MR
>> side and the time for the refresh BU comes, then the tunnels are
>> deleted. This only happens when the routing policies are applied on
>> the MR whereas it works fine when applied on the HA!!
>
> Ok, so the problem may come from the routing policies. I've just checked the online documentation and the examples might need a bit more tuning. I suspect that the ones with the "${HOA}" argument are problematic because they also include the signalling messages (BU/BA), which is not good. You probably need to specify more specific routing policies (using destination addresses or protocols/port numbers).
>
> For example, you can try to add the "-p icmpv6" parameter to your policies in order to test the rules only for the ICMPv6 (i.e. ping6) traffic.
>
> I have updated the example on the online documentation (as a side note, there was a also a typo in the document: all the rules were using the BID 20 whereas the ones with the HoA were supposed to use the BID 10), in the section "Routing Policies":
> http://umip.org/contrib/umip-mcoa-dsmipv6.html
>

Now the tunnels are not deleted but still nothing changes when
applying the routing policies on the MR, all the traffic coming out of
the MR (ping replies) still goes via one tunnel (the same interface
before applying the policies)!!!!
At the HA side, when applying the policies, I get the traffic (ping
requests) split between the tunnels according to the policies and no
problem with that!!!

Thank you

Ibrahim

[Romain KUNTZ]

Hello Ibrahim,

On May 27, 2013, at 20:29 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> I have updated the example on the online documentation (as a side note, there was a also a typo in the document: all the rules were using the BID 20 whereas the ones with the HoA were supposed to use the BID 10), in the section "Routing Policies":
>> http://umip.org/contrib/umip-mcoa-dsmipv6.html
>>
>
> Now the tunnels are not deleted but still nothing changes when
> applying the routing policies on the MR, all the traffic coming out of
> the MR (ping replies) still goes via one tunnel (the same interface
> before applying the policies)!!!!
> At the HA side, when applying the policies, I get the traffic (ping
> requests) split between the tunnels according to the policies and no
> problem with that!!!

Can you explain a bit more the scenario: how many interfaces do you have? are they both correctly registered to the HA? what is their BIDs? what address you are pinging? Is the source/destination the HoA or the MNP? what policies have you applied exactly?

Thank you,
Romain

[ibrahim sulaiman]

Hello Romain,

On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
> Hello Ibrahim,
>
> On May 27, 2013, at 20:29 , ibrahim sulaiman <isukity at gmail.com> wrote:
> >> I have updated the example on the online documentation (as a side note, there was a also a typo in the document: all the rules were using the BID 20 whereas the ones with the HoA were supposed to use the BID 10), in the section "Routing Policies":
> >> http://umip.org/contrib/umip-mcoa-dsmipv6.html
> >>
> >
> > Now the tunnels are not deleted but still nothing changes when
> > applying the routing policies on the MR, all the traffic coming out of
> > the MR (ping replies) still goes via one tunnel (the same interface
> > before applying the policies)!!!!
> > At the HA side, when applying the policies, I get the traffic (ping
> > requests) split between the tunnels according to the policies and no
> > problem with that!!!
>
> Can you explain a bit more the scenario: how many interfaces do you have? are they both correctly registered to the HA? what is their BIDs? what address you are pinging? Is the source/destination the HoA or the MNP? what policies have you applied exactly?
>
>

Here is the testbed setup I am having (see the figure and the details
below please). I started with connecting the MR using wlan0 (the first
Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
HA. And then I connected it to the AN provided by the AR
(2001:db8:1::/64) and after that I connect the second Egress interface
(wlan2: BID20) to the same AN. Up to this point I have everything
working fine, the BU/BA messaged were exchanged and the two tunnels
were established.
After that and before applying the policies, I started pinging at the
CN both the HoA of the MR (2001:db8:444::2) and the address of its
ingress interface (2001:db8:444:1::1). The HA sent both ping requests
over the second tunnel (wlan2-HA) and the MR returned both ping
replies over the first tunnel (wlan0-HA). After applying the following
routing policies on the HA only

#!/bin/sh

# Flush the mangle table
ip6tables -F -t mangle

# MNP and HOA information
MNP=2001:db8:444:1::/64
HOA=2001:db8:4444::2

# Send all traffic to the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20

# Send all traffic to the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10

nothing changed, still I have the requests over wlan2 and the replies
over wlan0. But swapping the BIDs like this

# Send all traffic to the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10

# Send all traffic to the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20

then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
requests for (2001:db8:444::2) are sent to wlan2. The replies are
still sent by the MR over wlan0 even after applying the routing
policies and swapping the BIDs.



___ _______
___ ___
| |__________ | |__________ |
| | |
|___| |______ |
|___| |___|
HA Sw|itch
AR MR
|
_|__
| |
|___|
CN
HA:
HA address: 2001:db8:444::1
Home prefix: 2001:db8:444::/64

AR:
Access prefix: 2001:db8:1::/64

MR:
HoA: 2001:db8:444::2
CoA: 2001:db8:1::2
MNP: 2001:db8:444:1::/64
Ingress Interface (wlan1): 2001:db8:444:1::1
It has 2 Egress interfaces: wlnn0 and wlan2

The HA's configuration file

# Sample UMIP configuration file for a MIPv6 Home Agent
NodeConfig HA;

# Set DebugLevel to 0 if you do not want debug messages
DebugLevel 10;

# Replace eth0 with the interface connected to the home link
Interface "br0";

# Accept registrations from Mobile Routers
HaAcceptMobRtr enabled;

# Accept MCoA and DSMIPv6 registrations
HaAcceptMCoA enabled;
HaAcceptDsmip6 enabled;

# Accept IPv4 traffic from the MR
HaAcceptIPv4Traffic enabled;

# Binding information
BindingAclPolicy 2001:db8:444:0::2 (2001:db8:444:1::/64)
10.10.10.100 (10.10.100.0/24) MCoA allow;
DefaultBindingAclPolicy allow;

# Enable IPsec static keying
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;

The routing policies script enabled on the HA:

#!/bin/sh

# Flush the mangle table
ip6tables -F -t mangle

# MNP and HOA information
MNP=2001:db8:444:1::/64
HOA=2001:db8:4444::2

# Send all traffic to the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20

# Send all traffic to the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10

The MR's configuration file

# Sample UMIP configuration file for a Mobile Router
NodeConfig MN;

# Set DebugLevel to 0 if you do not want debug messages
DebugLevel 10;

# Enable the optimistic handovers
OptimisticHandoff enabled;

# Disable RO with other MNs (it is not compatible
# with IPsec Tunnel Payload)
DoRouteOptimizationCN disabled;
DoRouteOptimizationMN disabled;
UseCnBuAck disabled;
MnDiscardHaParamProb enabled;


# The Binding Lifetime (in sec.)
MnMaxHaBindingLife 60;

# Enable DSMIPv6
MnUseDsmip6 enabled;

# Enable the use of IPv4 traffic
# inside the mobile network.
MnUseIPv4Traffic enabled;

# Use NEMO Explicit Mode
MobRtrUseExplicitMode enabled;

# List here the interfaces that you will use
# on your mobile node. The available one with
# the smallest preference number will be used.

Interface "wlan0" {
MnIfPreference 1;
Bid 10;
}

Interface "wlan2" {
MnIfPreference 2;
Bid 20;
}

# Replace eth0 with one of your interface used on
# your mobile node
MnHomeLink "wlan0" {
IsMobRtr enabled;
HomeAgentAddress 2001:db8:444:0::1;
HomeAddress 2001:db8:444:0::2/64 (2001:db8:444:1::/64);

# Enable MCoA and register the interfaces used for MCoA
# Replace eth0 and wlan0 with your egress interface names.
MCoAReg enabled;
MCoAIface "wlan0", "wlan2";

# DSMIPv6 - The IPv4 parameters must be statically set. Put
# here the IPv4 HoA and IPv4 MNP if any.
HomeV4Address 10.10.10.100/24 (10.10.100.0/24);
}

# Enable IPsec static keying
UseMnHaIPsec disabled;
KeyMngMobCapability disabled;


The routing policies script enabled on the MR:

#!/bin/sh
# Flush the mangle table
ip6tables -F -t mangle

# MNP and HOA information
MNP=2001:db8:444:1::/64
HOA=2001:db8:444::2


# Send all traffic from the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
--set-mark 20

# Send all traffic from the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
--set-mark 10


Thank you

Ibrahim

[ibrahim sulaiman]

On Tue, May 28, 2013 at 1:15 PM, ibrahim sulaiman <isukity at gmail.com> wrote:
> Hello Romain,
>
> On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>>
>> Hello Ibrahim,
>>
>> On May 27, 2013, at 20:29 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> >> I have updated the example on the online documentation (as a side
note, there was a also a typo in the document: all the rules were using the
BID 20 whereas the ones with the HoA were supposed to use the BID 10), in
the section "Routing Policies":
>> >> http://umip.org/contrib/umip-mcoa-dsmipv6.html
>> >>
>> >
>> > Now the tunnels are not deleted but still nothing changes when
>> > applying the routing policies on the MR, all the traffic coming out of
>> > the MR (ping replies) still goes via one tunnel (the same interface
>> > before applying the policies)!!!!
>> > At the HA side, when applying the policies, I get the traffic (ping
>> > requests) split between the tunnels according to the policies and no
>> > problem with that!!!
>>
>> Can you explain a bit more the scenario: how many interfaces do you
have? are they both correctly registered to the HA? what is their BIDs?
what address you are pinging? Is the source/destination the HoA or the MNP?
what policies have you applied exactly?
>>
>>
>
> Here is the testbed setup I am having (see the figure and the details
> below please). I started with connecting the MR using wlan0 (the first
> Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
> HA. And then I connected it to the AN provided by the AR
> (2001:db8:1::/64) and after that I connect the second Egress interface
> (wlan2: BID20) to the same AN. Up to this point I have everything
> working fine, the BU/BA messaged were exchanged and the two tunnels
> were established.
> After that and before applying the policies, I started pinging at the
> CN both the HoA of the MR (2001:db8:444::2) and the address of its
> ingress interface (2001:db8:444:1::1). The HA sent both ping requests
> over the second tunnel (wlan2-HA) and the MR returned both ping
> replies over the first tunnel (wlan0-HA). After applying the following
> routing policies on the HA only
>
> #!/bin/sh
>
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:4444::2
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark
20
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
--set-mark 20
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark
10
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
--set-mark 10
>
> nothing changed, still I have the requests over wlan2 and the replies
> over wlan0. But swapping the BIDs like this
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark
10
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
--set-mark 10
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark
20
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
--set-mark 20
>
> then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
> requests for (2001:db8:444::2) are sent to wlan2. The replies are
> still sent by the MR over wlan0 even after applying the routing
> policies and swapping the BIDs.
>
>
>

Sorry for the mess with the previous figure, here is the correct one:

__ ____ ____ ____
| |________| |_______| | | |
|__| |___ | |___ | | ___|
HA sw|itch AR MR
|
|
__|__
| |
|____|
CN



> ___ _______
> ___ ___
> | |__________ | |__________ |
> | | |
> |___| |______ |
> |___| |___|
> HA Sw|itch
> AR MR
> |
> _|__
> | |
> |___|
> CN
> HA:
> HA address: 2001:db8:444::1
> Home prefix: 2001:db8:444::/64
>
> AR:
> Access prefix: 2001:db8:1::/64
>
> MR:
> HoA: 2001:db8:444::2
> CoA: 2001:db8:1::2
> MNP: 2001:db8:444:1::/64
> Ingress Interface (wlan1): 2001:db8:444:1::1
> It has 2 Egress interfaces: wlnn0 and wlan2
>
> The HA's configuration file
>
> # Sample UMIP configuration file for a MIPv6 Home Agent
> NodeConfig HA;
>
> # Set DebugLevel to 0 if you do not want debug messages
> DebugLevel 10;
>
> # Replace eth0 with the interface connected to the home link
> Interface "br0";
>
> # Accept registrations from Mobile Routers
> HaAcceptMobRtr enabled;
>
> # Accept MCoA and DSMIPv6 registrations
> HaAcceptMCoA enabled;
> HaAcceptDsmip6 enabled;
>
> # Accept IPv4 traffic from the MR
> HaAcceptIPv4Traffic enabled;
>
> # Binding information
> BindingAclPolicy 2001:db8:444:0::2 (2001:db8:444:1::/64)
> 10.10.10.100 (10.10.100.0/24) MCoA allow;
> DefaultBindingAclPolicy allow;
>
> # Enable IPsec static keying
> UseMnHaIPsec disabled;
> KeyMngMobCapability disabled;
>
> The routing policies script enabled on the HA:
>
> #!/bin/sh
>
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:4444::2
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark
20
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
--set-mark 20
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark
10
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
--set-mark 10
>
> The MR's configuration file
>
> # Sample UMIP configuration file for a Mobile Router
> NodeConfig MN;
>
> # Set DebugLevel to 0 if you do not want debug messages
> DebugLevel 10;
>
> # Enable the optimistic handovers
> OptimisticHandoff enabled;
>
> # Disable RO with other MNs (it is not compatible
> # with IPsec Tunnel Payload)
> DoRouteOptimizationCN disabled;
> DoRouteOptimizationMN disabled;
> UseCnBuAck disabled;
> MnDiscardHaParamProb enabled;
>
>
> # The Binding Lifetime (in sec.)
> MnMaxHaBindingLife 60;
>
> # Enable DSMIPv6
> MnUseDsmip6 enabled;
>
> # Enable the use of IPv4 traffic
> # inside the mobile network.
> MnUseIPv4Traffic enabled;
>
> # Use NEMO Explicit Mode
> MobRtrUseExplicitMode enabled;
>
> # List here the interfaces that you will use
> # on your mobile node. The available one with
> # the smallest preference number will be used.
>
> Interface "wlan0" {
> MnIfPreference 1;
> Bid 10;
> }
>
> Interface "wlan2" {
> MnIfPreference 2;
> Bid 20;
> }
>
> # Replace eth0 with one of your interface used on
> # your mobile node
> MnHomeLink "wlan0" {
> IsMobRtr enabled;
> HomeAgentAddress 2001:db8:444:0::1;
> HomeAddress 2001:db8:444:0::2/64 (2001:db8:444:1::/64);
>
> # Enable MCoA and register the interfaces used for MCoA
> # Replace eth0 and wlan0 with your egress interface names.
> MCoAReg enabled;
> MCoAIface "wlan0", "wlan2";
>
> # DSMIPv6 - The IPv4 parameters must be statically set. Put
> # here the IPv4 HoA and IPv4 MNP if any.
> HomeV4Address 10.10.10.100/24 (10.10.100.0/24);
> }
>
> # Enable IPsec static keying
> UseMnHaIPsec disabled;
> KeyMngMobCapability disabled;
>
>
> The routing policies script enabled on the MR:
>
> #!/bin/sh
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:444::2
>
>
> # Send all traffic from the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK
--set-mark 20
> ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
> --set-mark 20
>
> # Send all traffic from the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark
10
> ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
> --set-mark 10
>
>
> Thank you
>
> Ibrahim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130528/74a76db5/attachment-0001.html>

[Romain KUNTZ]

Hello Ibrahim,

On May 28, 2013, at 14:15 , ibrahim sulaiman <isukity at gmail.com> wrote:
> On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>>
>> Can you explain a bit more the scenario: how many interfaces do you have? are they both correctly registered to the HA? what is their BIDs? what address you are pinging? Is the source/destination the HoA or the MNP? what policies have you applied exactly?
>>
>
> Here is the testbed setup I am having (see the figure and the details
> below please). I started with connecting the MR using wlan0 (the first
> Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
> HA.

Just a side note: the MCoA/DSMIP implementation does not support returning home, so you should not try to connect any of the MR interface to the home link.

> And then I connected it to the AN provided by the AR
> (2001:db8:1::/64) and after that I connect the second Egress interface
> (wlan2: BID20) to the same AN. Up to this point I have everything
> working fine, the BU/BA messaged were exchanged and the two tunnels
> were established.
> After that and before applying the policies, I started pinging at the
> CN both the HoA of the MR (2001:db8:444::2) and the address of its
> ingress interface (2001:db8:444:1::1).

Ok. I must admit that I have never tested the routing policies with the MR's ingress interface as a source/destination address. For the MR, the ingress interface address is considered as a local address. However, the policy rule with the "OUTPUT" chain should take this case into account (the OUTPUT chain is used for altering locally-generated packets before routing).

Do you have an extra laptop that you can connect behind the MR in order to have a real Mobile Network Node with an MNP address (and use this one as the destination instead of the MR ingress interface address)?

> The HA sent both ping requests
> over the second tunnel (wlan2-HA) and the MR returned both ping
> replies over the first tunnel (wlan0-HA).

When no policies are applied, the packets are sent through the tunnel with the highest BID. So here, the packets should go through the wlan2-HA tunnel. This seems ok the the HA, but it is not on the MR.

Could you give me the results of the "ip -6 rule" command on the MR in this case?


> After applying the following
> routing policies on the HA only
>
> #!/bin/sh
>
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:4444::2
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
>
> nothing changed, still I have the requests over wlan2 and the replies
> over wlan0. But swapping the BIDs like this
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>
> then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
> requests for (2001:db8:444::2) are sent to wlan2.

Ok, so it seems that the routing policies do not work when the HoA is used as the destination, but works fine for the MNP.

I am not sure why. This would require more investigations but I don't have an MCoA testbed here. The support I can provide is very limited. I guess a workaround would be to use a different criteria than the HoA: for example, try to use the source address of the CN instead.

> The replies are
> still sent by the MR over wlan0 even after applying the routing
> policies and swapping the BIDs.

Here, I guess you meant that you applied the MR routing policy on the MR side, right?

> The routing policies script enabled on the MR:
>
> #!/bin/sh
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:444::2
>
>
> # Send all traffic from the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 20
> ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
> --set-mark 20
>
> # Send all traffic from the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 10
> ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
> --set-mark 10

Could you try with different ip6tables chains? (FORWARD or POSTROUTING)

Thank you,
Romain

[ibrahim sulaiman]

Hello Romain,

I have tried to redo everything all over again following the same
instructions and the scenario I described to you in the previous email
message and got it working as required. I do not know exactly what was
wrong with it but at least I get it working now.

Thank you so much Romain for your help.

Best regards

Ibrahim


On Wed, May 29, 2013 at 8:33 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:

> Hello Ibrahim,
>
> On May 28, 2013, at 14:15 , ibrahim sulaiman <isukity at gmail.com> wrote:
> > On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> >>
> >> Can you explain a bit more the scenario: how many interfaces do you
> have? are they both correctly registered to the HA? what is their BIDs?
> what address you are pinging? Is the source/destination the HoA or the MNP?
> what policies have you applied exactly?
> >>
> >
> > Here is the testbed setup I am having (see the figure and the details
> > below please). I started with connecting the MR using wlan0 (the first
> > Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
> > HA.
>
> Just a side note: the MCoA/DSMIP implementation does not support returning
> home, so you should not try to connect any of the MR interface to the home
> link.
>
> > And then I connected it to the AN provided by the AR
> > (2001:db8:1::/64) and after that I connect the second Egress interface
> > (wlan2: BID20) to the same AN. Up to this point I have everything
> > working fine, the BU/BA messaged were exchanged and the two tunnels
> > were established.
> > After that and before applying the policies, I started pinging at the
> > CN both the HoA of the MR (2001:db8:444::2) and the address of its
> > ingress interface (2001:db8:444:1::1).
>
> Ok. I must admit that I have never tested the routing policies with the
> MR's ingress interface as a source/destination address. For the MR, the
> ingress interface address is considered as a local address. However, the
> policy rule with the "OUTPUT" chain should take this case into account (the
> OUTPUT chain is used for altering locally-generated packets before routing).
>
> Do you have an extra laptop that you can connect behind the MR in order to
> have a real Mobile Network Node with an MNP address (and use this one as
> the destination instead of the MR ingress interface address)?
>
> > The HA sent both ping requests
> > over the second tunnel (wlan2-HA) and the MR returned both ping
> > replies over the first tunnel (wlan0-HA).
>
> When no policies are applied, the packets are sent through the tunnel with
> the highest BID. So here, the packets should go through the wlan2-HA
> tunnel. This seems ok the the HA, but it is not on the MR.
>
> Could you give me the results of the "ip -6 rule" command on the MR in
> this case?
>
>
> > After applying the following
> > routing policies on the HA only
> >
> > #!/bin/sh
> >
> > # Flush the mangle table
> > ip6tables -F -t mangle
> >
> > # MNP and HOA information
> > MNP=2001:db8:444:1::/64
> > HOA=2001:db8:4444::2
> >
> > # Send all traffic to the MNP via the interface which BID is 20:
> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark
> 20
> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
> --set-mark 20
> >
> > # Send all traffic to the HoA via the interface which BID is 10:
> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark
> 10
> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
> --set-mark 10
> >
> > nothing changed, still I have the requests over wlan2 and the replies
> > over wlan0. But swapping the BIDs like this
> >
> > # Send all traffic to the MNP via the interface which BID is 20:
> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark
> 10
> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
> --set-mark 10
> >
> > # Send all traffic to the HoA via the interface which BID is 10:
> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark
> 20
> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
> --set-mark 20
> >
> > then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
> > requests for (2001:db8:444::2) are sent to wlan2.
>
> Ok, so it seems that the routing policies do not work when the HoA is used
> as the destination, but works fine for the MNP.
>
> I am not sure why. This would require more investigations but I don't have
> an MCoA testbed here. The support I can provide is very limited. I guess a
> workaround would be to use a different criteria than the HoA: for example,
> try to use the source address of the CN instead.
>
> > The replies are
> > still sent by the MR over wlan0 even after applying the routing
> > policies and swapping the BIDs.
>
> Here, I guess you meant that you applied the MR routing policy on the MR
> side, right?
>
> > The routing policies script enabled on the MR:
> >
> > #!/bin/sh
> > # Flush the mangle table
> > ip6tables -F -t mangle
> >
> > # MNP and HOA information
> > MNP=2001:db8:444:1::/64
> > HOA=2001:db8:444::2
> >
> >
> > # Send all traffic from the MNP via the interface which BID is 20:
> > ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK
> --set-mark 20
> > ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
> > --set-mark 20
> >
> > # Send all traffic from the HoA via the interface which BID is 10:
> > ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark
> 10
> > ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
> > --set-mark 10
>
> Could you try with different ip6tables chains? (FORWARD or POSTROUTING)
>
> Thank you,
> Romain
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130602/66ef64eb/attachment.html>

[Romain KUNTZ]

This is good to hear Ibrahim!

Just for my information, did you manage to get the routing policy working too with the Prerouting ad Output chains?

Thanks,
Romain

On Jun 2, 2013, at 20:56, ibrahim sulaiman <isukity at gmail.com> wrote:

> Hello Romain,
>
> I have tried to redo everything all over again following the same instructions and the scenario I described to you in the previous email message and got it working as required. I do not know exactly what was wrong with it but at least I get it working now.
>
> Thank you so much Romain for your help.
>
> Best regards
>
> Ibrahim
>
>
> On Wed, May 29, 2013 at 8:33 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>> Hello Ibrahim,
>>
>> On May 28, 2013, at 14:15 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> > On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>> >>
>> >> Can you explain a bit more the scenario: how many interfaces do you have? are they both correctly registered to the HA? what is their BIDs? what address you are pinging? Is the source/destination the HoA or the MNP? what policies have you applied exactly?
>> >>
>> >
>> > Here is the testbed setup I am having (see the figure and the details
>> > below please). I started with connecting the MR using wlan0 (the first
>> > Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
>> > HA.
>>
>> Just a side note: the MCoA/DSMIP implementation does not support returning home, so you should not try to connect any of the MR interface to the home link.
>>
>> > And then I connected it to the AN provided by the AR
>> > (2001:db8:1::/64) and after that I connect the second Egress interface
>> > (wlan2: BID20) to the same AN. Up to this point I have everything
>> > working fine, the BU/BA messaged were exchanged and the two tunnels
>> > were established.
>> > After that and before applying the policies, I started pinging at the
>> > CN both the HoA of the MR (2001:db8:444::2) and the address of its
>> > ingress interface (2001:db8:444:1::1).
>>
>> Ok. I must admit that I have never tested the routing policies with the MR's ingress interface as a source/destination address. For the MR, the ingress interface address is considered as a local address. However, the policy rule with the "OUTPUT" chain should take this case into account (the OUTPUT chain is used for altering locally-generated packets before routing).
>>
>> Do you have an extra laptop that you can connect behind the MR in order to have a real Mobile Network Node with an MNP address (and use this one as the destination instead of the MR ingress interface address)?
>>
>> > The HA sent both ping requests
>> > over the second tunnel (wlan2-HA) and the MR returned both ping
>> > replies over the first tunnel (wlan0-HA).
>>
>> When no policies are applied, the packets are sent through the tunnel with the highest BID. So here, the packets should go through the wlan2-HA tunnel. This seems ok the the HA, but it is not on the MR.
>>
>> Could you give me the results of the "ip -6 rule" command on the MR in this case?
>>
>>
>> > After applying the following
>> > routing policies on the HA only
>> >
>> > #!/bin/sh
>> >
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:4444::2
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
>> >
>> > nothing changed, still I have the requests over wlan2 and the replies
>> > over wlan0. But swapping the BIDs like this
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>> >
>> > then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
>> > requests for (2001:db8:444::2) are sent to wlan2.
>>
>> Ok, so it seems that the routing policies do not work when the HoA is used as the destination, but works fine for the MNP.
>>
>> I am not sure why. This would require more investigations but I don't have an MCoA testbed here. The support I can provide is very limited. I guess a workaround would be to use a different criteria than the HoA: for example, try to use the source address of the CN instead.
>>
>> > The replies are
>> > still sent by the MR over wlan0 even after applying the routing
>> > policies and swapping the BIDs.
>>
>> Here, I guess you meant that you applied the MR routing policy on the MR side, right?
>>
>> > The routing policies script enabled on the MR:
>> >
>> > #!/bin/sh
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:444::2
>> >
>> >
>> > # Send all traffic from the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
>> > --set-mark 20
>> >
>> > # Send all traffic from the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
>> > --set-mark 10
>>
>> Could you try with different ip6tables chains? (FORWARD or POSTROUTING)
>>
>> Thank you,
>> Romain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130603/17bbb1b6/attachment.html>

[ibrahim sulaiman]

Hello Romain,

Yes, I got the routing policies working with the Prerouting ad Output
chains. Here is the routing policies at the MR side:

#!/bin/sh

# Flush the mangle table
ip6tables -F -t mangle

# MNP and HOA information
MNP=2001:db8:444:1::/64
HOA=2001:db8:444::2


# Send all traffic from the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 10

# Send all traffic from the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 20

And the routing policies applied on the HA:

#!/bin/sh

# Flush the mangle table
ip6tables -F -t mangle

# MNP and HOA information
MNP=2001:db8:444:1::/64
HOA=2001:db8:4444::2


# Send all traffic to the MNP via the interface which BID is 20:
ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10

# Send all traffic to the HoA via the interface which BID is 10:
ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20

However, when I set the marking for the MNP to 20 and for the HoA to 10 at
the HA side, it did not work for me as the request messages were only
forwarded via one tunnel (BID 20). On the other hand, both configurations
worked fine at the MR side.

Kind regards

Ibrahim



On Mon, Jun 3, 2013 at 6:06 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:

> This is good to hear Ibrahim!
>
> Just for my information, did you manage to get the routing policy working
> too with the Prerouting ad Output chains?
>
> Thanks,
> Romain
>
> On Jun 2, 2013, at 20:56, ibrahim sulaiman <isukity at gmail.com> wrote:
>
> Hello Romain,
>
> I have tried to redo everything all over again following the same
> instructions and the scenario I described to you in the previous email
> message and got it working as required. I do not know exactly what was
> wrong with it but at least I get it working now.
>
> Thank you so much Romain for your help.
>
> Best regards
>
> Ibrahim
>
>
> On Wed, May 29, 2013 at 8:33 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>
>> Hello Ibrahim,
>>
>> On May 28, 2013, at 14:15 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> > On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com>
>> wrote:
>> >>
>> >> Can you explain a bit more the scenario: how many interfaces do you
>> have? are they both correctly registered to the HA? what is their BIDs?
>> what address you are pinging? Is the source/destination the HoA or the MNP?
>> what policies have you applied exactly?
>> >>
>> >
>> > Here is the testbed setup I am having (see the figure and the details
>> > below please). I started with connecting the MR using wlan0 (the first
>> > Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
>> > HA.
>>
>> Just a side note: the MCoA/DSMIP implementation does not support
>> returning home, so you should not try to connect any of the MR interface to
>> the home link.
>>
>> > And then I connected it to the AN provided by the AR
>> > (2001:db8:1::/64) and after that I connect the second Egress interface
>> > (wlan2: BID20) to the same AN. Up to this point I have everything
>> > working fine, the BU/BA messaged were exchanged and the two tunnels
>> > were established.
>> > After that and before applying the policies, I started pinging at the
>> > CN both the HoA of the MR (2001:db8:444::2) and the address of its
>> > ingress interface (2001:db8:444:1::1).
>>
>> Ok. I must admit that I have never tested the routing policies with the
>> MR's ingress interface as a source/destination address. For the MR, the
>> ingress interface address is considered as a local address. However, the
>> policy rule with the "OUTPUT" chain should take this case into account (the
>> OUTPUT chain is used for altering locally-generated packets before routing).
>>
>> Do you have an extra laptop that you can connect behind the MR in order
>> to have a real Mobile Network Node with an MNP address (and use this one as
>> the destination instead of the MR ingress interface address)?
>>
>> > The HA sent both ping requests
>> > over the second tunnel (wlan2-HA) and the MR returned both ping
>> > replies over the first tunnel (wlan0-HA).
>>
>> When no policies are applied, the packets are sent through the tunnel
>> with the highest BID. So here, the packets should go through the wlan2-HA
>> tunnel. This seems ok the the HA, but it is not on the MR.
>>
>> Could you give me the results of the "ip -6 rule" command on the MR in
>> this case?
>>
>>
>> > After applying the following
>> > routing policies on the HA only
>> >
>> > #!/bin/sh
>> >
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:4444::2
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK
>> --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
>> --set-mark 20
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK
>> --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
>> --set-mark 10
>> >
>> > nothing changed, still I have the requests over wlan2 and the replies
>> > over wlan0. But swapping the BIDs like this
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK
>> --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK
>> --set-mark 10
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK
>> --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK
>> --set-mark 20
>> >
>> > then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
>> > requests for (2001:db8:444::2) are sent to wlan2.
>>
>> Ok, so it seems that the routing policies do not work when the HoA is
>> used as the destination, but works fine for the MNP.
>>
>> I am not sure why. This would require more investigations but I don't
>> have an MCoA testbed here. The support I can provide is very limited. I
>> guess a workaround would be to use a different criteria than the HoA: for
>> example, try to use the source address of the CN instead.
>>
>> > The replies are
>> > still sent by the MR over wlan0 even after applying the routing
>> > policies and swapping the BIDs.
>>
>> Here, I guess you meant that you applied the MR routing policy on the MR
>> side, right?
>>
>> > The routing policies script enabled on the MR:
>> >
>> > #!/bin/sh
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:444::2
>> >
>> >
>> > # Send all traffic from the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK
>> --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
>> > --set-mark 20
>> >
>> > # Send all traffic from the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK
>> --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
>> > --set-mark 10
>>
>> Could you try with different ip6tables chains? (FORWARD or POSTROUTING)
>>
>> Thank you,
>> Romain
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.nautilus6.org/pipermail/support/attachments/20130605/4fbb4202/attachment.html>

[Romain KUNTZ]

Hello Ibrahim,

Thank you for the feedback. I will let you know if I have a chance to dig into the policy routing issue on the HA side that you mention.

Best,
Romain


On Jun 5, 2013, at 17:33 , ibrahim sulaiman <isukity at gmail.com> wrote:

> Hello Romain,
>
> Yes, I got the routing policies working with the Prerouting ad Output chains. Here is the routing policies at the MR side:
>
> #!/bin/sh
>
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:444::2
>
>
> # Send all traffic from the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 10
> ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 10
>
> # Send all traffic from the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 20
> ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 20
>
> And the routing policies applied on the HA:
>
> #!/bin/sh
>
> # Flush the mangle table
> ip6tables -F -t mangle
>
> # MNP and HOA information
> MNP=2001:db8:444:1::/64
> HOA=2001:db8:4444::2
>
>
> # Send all traffic to the MNP via the interface which BID is 20:
> ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
> ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>
> # Send all traffic to the HoA via the interface which BID is 10:
> ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
> ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>
> However, when I set the marking for the MNP to 20 and for the HoA to 10 at the HA side, it did not work for me as the request messages were only forwarded via one tunnel (BID 20). On the other hand, both configurations worked fine at the MR side.
>
> Kind regards
>
> Ibrahim
>
>
>
> On Mon, Jun 3, 2013 at 6:06 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
> This is good to hear Ibrahim!
>
> Just for my information, did you manage to get the routing policy working too with the Prerouting ad Output chains?
>
> Thanks,
> Romain
>
> On Jun 2, 2013, at 20:56, ibrahim sulaiman <isukity at gmail.com> wrote:
>
>> Hello Romain,
>>
>> I have tried to redo everything all over again following the same instructions and the scenario I described to you in the previous email message and got it working as required. I do not know exactly what was wrong with it but at least I get it working now.
>>
>> Thank you so much Romain for your help.
>>
>> Best regards
>>
>> Ibrahim
>>
>>
>> On Wed, May 29, 2013 at 8:33 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>> Hello Ibrahim,
>>
>> On May 28, 2013, at 14:15 , ibrahim sulaiman <isukity at gmail.com> wrote:
>> > On Tue, May 28, 2013 at 7:48 AM, Romain KUNTZ <r.kuntz at gmail.com> wrote:
>> >>
>> >> Can you explain a bit more the scenario: how many interfaces do you have? are they both correctly registered to the HA? what is their BIDs? what address you are pinging? Is the source/destination the HoA or the MNP? what policies have you applied exactly?
>> >>
>> >
>> > Here is the testbed setup I am having (see the figure and the details
>> > below please). I started with connecting the MR using wlan0 (the first
>> > Egress interface: BID10) to the HN (2001:db8:444::/64) provided by the
>> > HA.
>>
>> Just a side note: the MCoA/DSMIP implementation does not support returning home, so you should not try to connect any of the MR interface to the home link.
>>
>> > And then I connected it to the AN provided by the AR
>> > (2001:db8:1::/64) and after that I connect the second Egress interface
>> > (wlan2: BID20) to the same AN. Up to this point I have everything
>> > working fine, the BU/BA messaged were exchanged and the two tunnels
>> > were established.
>> > After that and before applying the policies, I started pinging at the
>> > CN both the HoA of the MR (2001:db8:444::2) and the address of its
>> > ingress interface (2001:db8:444:1::1).
>>
>> Ok. I must admit that I have never tested the routing policies with the MR's ingress interface as a source/destination address. For the MR, the ingress interface address is considered as a local address. However, the policy rule with the "OUTPUT" chain should take this case into account (the OUTPUT chain is used for altering locally-generated packets before routing).
>>
>> Do you have an extra laptop that you can connect behind the MR in order to have a real Mobile Network Node with an MNP address (and use this one as the destination instead of the MR ingress interface address)?
>>
>> > The HA sent both ping requests
>> > over the second tunnel (wlan2-HA) and the MR returned both ping
>> > replies over the first tunnel (wlan0-HA).
>>
>> When no policies are applied, the packets are sent through the tunnel with the highest BID. So here, the packets should go through the wlan2-HA tunnel. This seems ok the the HA, but it is not on the MR.
>>
>> Could you give me the results of the "ip -6 rule" command on the MR in this case?
>>
>>
>> > After applying the following
>> > routing policies on the HA only
>> >
>> > #!/bin/sh
>> >
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:4444::2
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 20
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 10
>> >
>> > nothing changed, still I have the requests over wlan2 and the replies
>> > over wlan0. But swapping the BIDs like this
>> >
>> > # Send all traffic to the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -d ${MNP} -p icmpv6 -j MARK --set-mark 10
>> >
>> > # Send all traffic to the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -d ${HOA} -p icmpv6 -j MARK --set-mark 20
>> >
>> > then, the requests for (2001:db8:444:1::1) are sent to wlan0 and the
>> > requests for (2001:db8:444::2) are sent to wlan2.
>>
>> Ok, so it seems that the routing policies do not work when the HoA is used as the destination, but works fine for the MNP.
>>
>> I am not sure why. This would require more investigations but I don't have an MCoA testbed here. The support I can provide is very limited. I guess a workaround would be to use a different criteria than the HoA: for example, try to use the source address of the CN instead.
>>
>> > The replies are
>> > still sent by the MR over wlan0 even after applying the routing
>> > policies and swapping the BIDs.
>>
>> Here, I guess you meant that you applied the MR routing policy on the MR side, right?
>>
>> > The routing policies script enabled on the MR:
>> >
>> > #!/bin/sh
>> > # Flush the mangle table
>> > ip6tables -F -t mangle
>> >
>> > # MNP and HOA information
>> > MNP=2001:db8:444:1::/64
>> > HOA=2001:db8:444::2
>> >
>> >
>> > # Send all traffic from the MNP via the interface which BID is 20:
>> > ip6tables -A OUTPUT -t mangle -s ${MNP} -p icmpv6 -j MARK --set-mark 20
>> > ip6tables -A PREROUTING -t mangle -s ${MNP} -p icmpv6 -j MARK
>> > --set-mark 20
>> >
>> > # Send all traffic from the HoA via the interface which BID is 10:
>> > ip6tables -A OUTPUT -t mangle -s ${HOA} -p icmpv6 -j MARK --set-mark 10
>> > ip6tables -A PREROUTING -t mangle -s ${HOA} -p icmpv6 -j MARK
>> > --set-mark 10
>>
>> Could you try with different ip6tables chains? (FORWARD or POSTROUTING)
>>
>> Thank you,
>> Romain
>>
>>
>>
>>
>>
>>
>>
>>
>