(usagi-users 03911) Re: Problem in mh_send sending Binding ACK from HA

Nakamura and Romain,

Thank you for your help.
I finally could have my MN registered to the HA. 

Thanks,
Rodolfo.


>-----Original Message-----
>From: Masahide NAKAMURA [mailto:[email protected]]
>Sent: Friday, July 20, 2007 6:55 PM
>To: [email protected]
>Subject: (usagi-users 03906) Re: Problem in mh_send sending Binding ACK
>from HA
>
>> Did you properly configure RADVD on your home agent to advertise the
>> home prefix on your home link? This is mandatory, and can be a reason
>> why BAck status 132 is sent to your MN.
>
>Right.
>See http://www.linux-ipv6.org/memo/mipv6/ to configure HA for example.
>
>Cheers,
>
>
>
>On Thu, 19 Jul 2007 22:16:33 +0200
>Romain KUNTZ <[email protected]> wrote:
>
>> Hi Rodolfo,
>>
>> Did you properly configure RADVD on your home agent to advertise the
>> home prefix on your home link? This is mandatory, and can be a reason
>> why BAck status 132 is sent to your MN.
>>
>> Cheers,
>> romain
>>
>> On 2007/07/19, at 20:29, Kohn, Rodolfo wrote:
>>
>> > Hi Nakamura,
>> >
>> > Thank you for your help. Another question below.
>> >
>> >>> This is the log. You'll note that there is a problem with the BU
>> >>> or my
>> >>> configuration that makes the HA send an error 132 with the ACK.
>> >>
>> >> Easy reason for BA status=132 is either the HA does not have any
>> >> valid
>> >> home prefix, or MN tries another home prefix than HA configured.
>> >>
>> >
>> > Where should I set a valid home prefix for the HA?
>> >
>> >
>> > This is my HA configuration file
>> >
>> >
>> > NodeConfig HA;
>> >
>> > DebugLevel 10;
>> >
>> > Interface "eth0";
>> >
>> > ##
>> > ## IPsec configuration
>> > ##
>> >
>> > UseMnHaIPsec disabled;
>> >
>> > ## Key Management Mobility Capability
>> > #KeyMngMobCapability disabled;
>> >
>> > IPsecPolicySet {
>> > 	HomeAgentAddress 3ffe:2620:6:1::1;
>> >
>> > 	HomeAddress 3ffe:2620:6:1::1234/64;
>> > #	HomeAddress 3ffe:2620:6:1::1235/64;
>> >
>> > 	#IPsecPolicy Mh UseESP;
>> > 	#IPsecPolicy TunnelMh UseESP;
>> >
>> > #	IPsecPolicy Mh UseESP 1 2;
>> > #	IPsecPolicy ICMP UseESP 5;
>> > #	IPsecPolicy TunnelMh UseESP 3 4;
>> > }
>> >
>> >
>> > I've set the IPv6 address in the HA with
>> >
>> > ifconfig eth0 add 3ffe:2620:6:1::1
>> >
>> > before running mip6d.
>> >
>> >
>> > Thanks,
>> > Rodolfo.
>> >
>> >
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Masahide NAKAMURA [mailto:[email protected]]
>> >> Sent: Thursday, July 19, 2007 2:20 PM
>> >> To: [email protected]
>> >> Subject: (usagi-users 03899) Re: Problem in mh_send sending
>> >> Binding ACK
>> >> from HA
>> >>
>> >> Hi,
>> >>
>> >> On Thu, 19 Jul 2007 08:08:14 -0700
>> >> "Kohn, Rodolfo" <[email protected]> wrote:
>> >>> This is the log. You'll note that there is a problem with the BU
>> >>> or my
>> >>> configuration that makes the HA send an error 132 with the ACK.
>> >>
>> >> Easy reason for BA status=132 is either the HA does not have any
>> >> valid
>> >> home prefix, or MN tries another home prefix than HA configured.
>> >>
>> >>
>> >>> However, there is another problem and that is the one that
>> >>> worries me:
>> >>> the Binding Update Acknowledgement does not leave the HA node.
>> >>>
>> >>>
>> >>>
>> >>> Looking at the code I realized that function mh_send, in mh.c, is
>> >>> calling function inet6_rth_space with the arguments
>> >>> (IPV6_RTHDR_TYPE_2,
>> >>> 1): and this function is returning 0. Probably function
>> >>> inet6_rth_space
>> >>> does not recognize the value IPV6_RTHDR_TYPE_2.
>> >>>
>> >>>
>> >>>
>> >>> I noted that function inet6_rth_space I'm using is defined in
>> >>> libc.so.6
>> >>> .
>> >>>
>> >>> On the other side, I noted this function is also defined in
>> >>> libmissing
>> >>> directory but I'm not using this one.
>> >>>
>> >>>
>> >>>
>> >>> Could anybody help me with this problem? Maybe I should use a
>> >>> specific
>> >>> configure or make parameter or I need to use a different libc
>> >>> version?
>> >>
>> >> The fix is already on mipv6-daemon git tree, the branch name is umip-
>> >> 20070428
>> >> (or later).
>> >>
>> >> # FYI, this issue was discussed on mipl ML. I should have to do
>> >> cross-post
>> >> to
>> >> # this ML. See blow.
>> >>
>> >>
>> >> Regards,
>> >>
>> >>
>> >> Forwarded by Masahide NAKAMURA <[email protected]>
>> >> ----------------------- Original Message -----------------------
>> >> From:    Masahide NAKAMURA <[email protected]>
>> >> To:       <[email protected]>
>> >> Date:    Tue, 29 May 2007 19:46:48 +0900
>> >> Subject: Re: [mipl] Can't get Binding Acknowledgement with code 0
>> >> from HA
>> >> ----
>> >>
>> >> Hi,
>> >>
>> >>  wrote:
>> >>> Dear Sir,
>> >>>
>> >>>     I install USAGI MIPv6 umip-0.3 on linux 2.16.21-rc5 and try
>> >>> to do
>> >> conformance test with Tahi's Tool.
>> >>>     Depending  on configuration, the umip-0.3 mip6d can be a MN,
>> >>> HA, or
>> >> CN.  After configuring umip-0.3 mip6d to be a MN, I obtain
>> >> excellent test
>> >> results and experience.  But when I configure umip-0.3 mip6d to be
>> >> a HA, I
>> >> get a problem and can't solve it.
>> >>> Could anybody do me a favour and give me suggestions ?
>> >>>     My problem is :
>> >>>     The Tester (MN) sends BU to HA (umip-0.3 mip6d) , and then
>> >>> the HA
>> >> will return a Binding Acknowledgement with code 0 in normal case.
>> >> It is
>> >> only a basic home registration procedure, but I just can't get
>> >> the  Binding
>> >> Acknowledgement with code 0. I use ethereal to monitor  traffic
>> >> and does
>> >> not find BA.
>> >>>     But if I check Binding Cache of HA, I can find correct BC record
>> >> druing home registration procedure. By the way,  from the daemon
>> >> log, it
>> >> seems the HA receives BU and return BA (as shown in red word).
>> >> Also by
>> >> other test cases, I find the ethereal can capture Binding
>> >> Acknowledgement
>> >> returning from HA with all status field values except  0.
>> >>>     If I configure the daemon to be a CN, the result are same. With
>> >> ethereal, I still can't find Binding Acknowledgement with status
>> >> field 0.
>> >>>     I think the daemon work well whatever it is a HA or CN, but
>> >>> I just
>> >> can't get BA with code 0.
>> >>
>> >>
>> >> Can you say glibc version of the environment?
>> >>
>> >> I found an issue with newer glibc which supports IPv6 Advanced
>> >> Socket API
>> >> for routing header type 0 but not type2.
>> >> On such case CN/HA will go wrong and not send RH2 packet without any
>> >> debug message for both MIPL-2.0.2 and it with umip-0.3.
>> >> It seems that your report is similar to it.
>> >>
>> >> Try below experimental patches:
>> >>
>> >> http://www.linux-ipv6.org/gitweb/gitweb.fcgi?p=gitroot/mipv6-
>> >> daemon.git;a=commit;h=99f0ba06312fb8a4104753671070b80a95c9951e
>> >> http://www.linux-ipv6.org/gitweb/gitweb.fcgi?p=gitroot/mipv6-
>> >> daemon.git;a=commit;h=68b38634de47f424a7f5df24fb6deb21c6b48fcf
>> >>
>> >> And please note you should restart autoreconf after applying them.
>> >>
>> >> Cheers,
>> >>
>> >> --
>> >> Masahide NAKAMURA
>> >>
>> >> _______________________________________________
>> >> mipl mailing list
>> >> [email protected]
>> >> http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
>> >> --------------------- Original Message Ends --------------------
>> >>
>> >> --
>> >> Masahide NAKAMURA
>> >
>> >
>>
>> --
>> Romain KUNTZ
>> [email protected]
>> Louis Pasteur University - Networks and Protocols Team
>>
>>
>>
>
>--
>Masahide NAKAMURA