[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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: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



-- Romain KUNTZ kuntz@xxxxxxxxxxxxxxxxxx Louis Pasteur University - Networks and Protocols Team