(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