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

["Kohn, Rodolfo" <rodolfo.kohn@xxxxxxxxx>]

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:nakam@xxxxxxxxxxxxxx]
>Sent: Thursday, July 19, 2007 2:20 PM
>To: usagi-users@xxxxxxxxxxxxxx
>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" <rodolfo.kohn@xxxxxxxxx> 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 <nakam@xxxxxxxxxxxxxx>
>----------------------- Original Message -----------------------
>From:    Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>
>To:      陳一輝 <ihchen@xxxxxxxxxx>
>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
>mipl@xxxxxxxxxxxxxxx
>http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
>--------------------- Original Message Ends --------------------
>
>--
>Masahide NAKAMURA