MIPv6
Issues
Home
Test Plan
Tester
Issues
Results
TAHI Tests

Issues

Here is a list of some issues found in MIPL 2.0 since we started testing on MIPL 2.0:

  Description Found in version State
1RO is not triggered by incoming UDP packets.2.0rc2
2UDP packets may leave a node with no source address.2.0rc2Fixed in MIPL 2.0rc3
3IPSec setting does not work for MPS/MPA packets.2.0rc2Fixed in MIPL 2.0rc3
4Encrypted HoTI packets blocked by Home Agent.2.0rc2Fixed in MIPL 2.0rc3
5Multi-interface configuration for the Mobile Node does not work as expected.2.0rc2
6Mobile nodes don't acknowledge BUs sent by other mobile nodes.2.0rc3Configuration incompatibility
7Mobile node keeps refreshing its BU every few seconds.2.0 snapshot 20051214Fixed in MIPL 2.0 snapshot 20051215
8Mobile node option MnRouterProbeTimeout is not used.2.0 snapshot 20060126Not a bug
9Comparison between Binding Update Lifetime and Mobile Prefix Lifetime is bugged.2.0 snapshot 20060201Fixed in MIPL 2.0 final
10Virtual Terminal is broken.2.0Fixed in MIPL 2.0.1
11CN adds routing header type 2 to neighbor discovery packets.2.0.1Fixed in snapshot 20060425

1 RO is not triggered by incoming UDP packets

The Route Optimization is not triggered on the Mobile Node by incoming UDP packets. This is a problem with applications that produce unidirectional UDP streams, such applications include video and sound streaming. These streams will always be tunneled to the Mobile Node via its Home Agent. This is important to use RO on these streams because they often eat a lot of bandwith. We discovered this issue while streaming video with Videolan Client.

2 UDP packets may leave a node with no source address

Fixed in MIPL 2.0rc3

This is a bug in the kernel that can block/corrupt UDP traffic between MN and CN once the RO has been triggered (TCP is OK as well as UDP sockets that are binded).

This is not specific to the mobility, but was introduce by the new code brought by the mobility for source address selection. This problem can occur when you use an UDP socket to send data (not binded and not connected) and add a route to your correspondent with a prefix len of 128. In this case, there is a high probability your packet will leave the node without a source address (which can be problematic :) ). Then, when the correspondent receives the packet without source address, the packet may be dropped somewhere in the stack.

3 IPSec setting does not work for MPS/MPA packets

Fixed in MIPL 2.0rc3

Mobile prefix solicitation works well without IPsec but fails when IPsec is configured for these packets.

4 Encrypted HoTI packets blocked by Home Agent

Fixed in MIPL 2.0rc3

When IPSec is used to protect the Return Routability procedure, the HoTI packets are discarded when they arrived on the Home Agent. Without IPSec, RR procedure works well.

5 Multi-interface configuration for the Mobile Node does not work as expected

Configuring more than one interfaces in the mip6d.conf does not give the expected results when running the tests.

What we expect is:

  • We configure two interfaces in mip6d.conf and set a higher preference on one of them:
    • eth0, wired ethernet 100MB (our preferred link),
    • eth1, wifi 802.11b.
  • We start the test unplugged using the wifi interface.
  • Later, we plug eth0 to have a better quality of service.
  • The daemon should detect the new link, see it is its preferred interface and switch to it.

6 Mobile nodes don't acknowledge BUs sent by other mobile nodes

Fixed: IPsec configuration problem between the Linux Mobile Nodes and the non-Linux Home Agent node

This problem occured with two mobile nodes registered with the same home agent. Both mobile nodes are on foreign links. When the nodes begin to communicate RR procedure is triggered and succeeds (HoTI/HoT and CoTI/COT are OK). Then, one mobile node sends its BU with the A flag set. The other mobile receives it (traces in daemon) but never sends the BA. The node that sends the BU keeps sending more BUs from time to time. All the packets between the two nodes continue to go through the IP6-IP6 tunnels via the home agent.

See test result for test T8-CP1-MV1 in serie S3.

Resolution

This problem was caused by an incompatibility of IPsec configurations installed on the MIPL Mobile Nodes and on the non-Linux Home Agent. Changing IPsec option "TunnelMh" to "TunnelHomeTesting" in MIPL configuration solved the problem.

7 Mobile node keeps refreshing its BU every few seconds

Fixed in MIPL 2.0 snapshot 20051215

This problem is a regression introduced after 2.0rc3.
MN keeps refreshing its BU every 'conf.InitialBindackTimeoutReReg_ts' seconds.

It seems to me a call to set_bule_lifetime() got lost in mn_recv_ba() during the re-architecturing of the code.

Indeed, when I start my mobile node on a foreign network it successfully registers with its home agent (BU/BA & MPS/MPA) but restart a registration after a few seconds.

By comparing daemon traces between rc3 and latest snapshot, I found that in mn_recv_ba() (previously known as ba_rcv()), the delay contained in the bul was not change anymore after the BA from HA is received. As a consequence, after "conf.InitialBindackTimeoutReReg_ts" seconds a new registration was triggered: callback bu_refresh() is called).

In RC3, mn.c::ba_rcv() calls set_bule_lifetime() at line 1125 after it receives BA.

(Line numbers refers to snapshot 20051214)
In fact, the call to set_bule_lifetime() is still here at line 1097, but it was moved. Now, you only call set_bule_lifetime() if the binding refresh option was found in the MH. If this option is not present, you leave the bul delay unchanged, which seems a bit problematic as the original delay is quite short.
I think set_bule_lifetime() should be called with the value of ba_lifetime we got at line 1088 when IP6_MHOPT_BREFRESH is not set.

Proposed patch:

diff -Nur mipv6-20051214/src/mn.c mipv6-20051214-new/src/mn.c
--- mipv6-20051214/src/mn.c	2005-12-12 15:59:17.000000000 +0000
+++ mipv6-20051214-new/src/mn.c	2005-12-14 14:46:36.000000000 +0000
@@ -1089,13 +1089,15 @@
 	post_ba_bul_update(bule);
 	if (bule->flags & IP6_MH_BU_HOME) {
 		struct ip6_mh_opt_refresh_advice *bra;
+		struct timespec br_adv;
+		tsclear(br_adv);
 		bra = mh_opt(&ba->ip6mhba_hdr, &mh_opts, IP6_MHOPT_BREFRESH);
 		if (bra) {
-			struct timespec br_adv;
 			tssetsec(br_adv, ntohs(bra->ip6mora_interval) << 2);
 			br_adv = tsmin(br_adv, ba_lifetime);
-			set_bule_lifetime(bule, &ba_lifetime, &br_adv);
 		}
+		set_bule_lifetime(bule, &ba_lifetime, &br_adv);
+
 		if (!tsisset(ba_lifetime)) {
 			xfrm_unblock_policy(bule->home);
 			mn_dereg_home(bule->home);

8 Mobile node option MnRouterProbeTimeout is not used
Not a bug
Ville told the behaviour described below is the intended behaviour. ProbeRouterTimeout is used to allow sub-second handoff delays

There is a bug in src/movement.c:md_probe_router().
The mobile node configuration variable MnProbeRouterTimeout is only taken into account if it is smaller than rtr->iface->retransmit (1 sec by default). I think it should be the opposite, or better if MnProbeRouterTimeout is set use it without comparing it to rtr->iface->retransmit.
(I found it because TAHI is a bit slow to respond in some cases: Test MN-3-3-1-1-002)

Proposed patch:
--- mipv6-20060201/src/movement.c  2006-02-01 17:02:24.000000000 +0000
+++ mipv6-20060201-new/src/movement.c  2006-02-01 17:03:03.000000000 +0000
@@ -1104,7 +1104,7 @@

                clock_gettime(CLOCK_REALTIME, &rtr->timestamp);
                if (tsisset(conf.MnRouterProbeTimeout_ts) &&
-                   tsbefore(rtr->iface->retransmit,
+                   tsafter(rtr->iface->retransmit,
                            conf.MnRouterProbeTimeout_ts)) {
                        rtr->lifetime = conf.MnRouterProbeTimeout_ts;
                } else {
9 Comparison between Binding Update Lifetime and Mobile Prefix Lifetime is bugged

Fixed in MIPL 2.0 final

There is a bug is the comparison done between Binding Update Lifetime and Mobile Prefix Lifetime when receiving a BU.
This comparison is done to determine whether the BA status should be 0 (success) or 1 (success but prefix discovery necessary).
The bug is in ndisc_ha.c: mpd_prefix_check(). There, the prefix lifetime is limited to MAX_BINDING_LIFETIME:

ndisc_ha.c : mpd_prefix_check()
...
tssetsec(*lft, valid_time & MAX_BINDING_LIFETIME);
...
  • According to RFC2461, prefix lifetime is a 32-bit unsigned integer, and max value is 0xffffffff representing infinity.
  • MAX_BINDING_LIFETIME is only 0x3FFFC.
Limiting the prefix lifetime to MAX_BINDING_LIFETIME in mpd_prefix_check() makes the test "prefix is or will be deprecated during the requested lifetime" (in ha_recv_bu_worker() (line 761)) incorrect.
It does not check the real thing and wrongly send BA with a status of 1 instead of 0 in many cases.

IMHO, the truncation done in mpd_prefix_check() should not be here.
Or, may be, it can work if we replace it by: ssetsec(*lft, min(valid_time, MAX_BINDING_LIFETIME));
min() is definitely better than '&'.

This issue makes TAHI tests HA_2_1_9, HA_8_1_7 and HA_8_1_8 fail.

10 Virual Terminal is broken

Fixed in MIPL 2.0.1

The Virtual Terminal functionality in MIPL 2.0 final is broken. Parsing of commands is messed up.
Also the daemon segfaults when the command 'bul' is called. This a small 'printf' problem at line 670. printf interprets the argument represented by %ls as a string pointer and crashes the daemon.

The following patch fix these issues:

diff -Nurp mipv6-2.0/src/vt.c mipv6-2.0-fixed/src/vt.c
--- mipv6-2.0/src/vt.c	2006-02-14 14:01:54.000000000 +0100
+++ mipv6-2.0-fixed/src/vt.c	2006-02-14 15:02:18.000000000 +0100
@@ -657,17 +657,17 @@ static int bul_vt_dump(void *data, void 
 
 			tssub(ts_now, bule->lastsent, ts);
 			tssub(bule->lifetime, ts, ts);
-			vt_printf(vh, "%l", ts.tv_sec);
+			vt_printf(vh, "%ld", ts.tv_sec);
 		}
 	} else
 		vt_printf(vh, "(error)");
 
-	vt_printf(vh, " / %l", bule->lifetime.tv_sec);
+	vt_printf(vh, " / %ld", bule->lifetime.tv_sec);
 
 	vt_printf(vh, " seq %u", bule->seq);
 
 	vt_printf(vh, " resend %d", bule->consecutive_resends);
-	vt_printf(vh, " delay %l(after %ls)", bule->delay.tv_sec,
+	vt_printf(vh, " delay %ld(after %lds)", bule->delay.tv_sec,
 		  bule->lastsent.tv_sec +
 		  bule->delay.tv_sec - ts_now.tv_sec);
 	if (vh->vh_opt.verbose == VT_BOOL_TRUE) {
@@ -676,7 +676,7 @@ static int bul_vt_dump(void *data, void 
 			if (!ts_now_broken) {
 				struct timespec ts;
 				tssub(bule->expires, ts_now, ts);
-				vt_printf(vh, "%l", ts.tv_sec);
+				vt_printf(vh, "%ld", ts.tv_sec);
 			} else
 				vt_printf(vh, "(error)");
 		} else
@@ -695,9 +695,9 @@ static int bul_vt_dump(void *data, void 
 				struct timespec ts;
 				tssub(ts_now, lastsent, ts);
 				tssub(delay, ts, ts);
-				vt_printf(vh, "%l", ts.tv_sec);
+				vt_printf(vh, "%ld", ts.tv_sec);
 			}
-			vt_printf(vh, " / %l", delay.tv_sec);
+			vt_printf(vh, " / %ld", delay.tv_sec);
 		}
 	}
 	vt_printf(vh, "\n");
@@ -1157,13 +1157,13 @@ static int vt_connect_input(struct vt_ha
 	for (i = 0; i < len; i++) {
 		int show = 0;
 
-		if (line[i] == '\n' || line[i] == '\r') != 0) {
+		if (line[i] == '\n' || line[i] == '\r') {
 			line[i] = '\0';
 			continue;
 		}
 
 		for (j = i + 1; j < len; j++) {
-			if (line[i] == '\n' || line[i] == '\r') != 0) {
+			if (line[j] == '\n' || line[j] == '\r') {
 				line[j] = '\0';
 				show = 1;
 				break;

11 CN adds routing header type 2 to Neighbor Discovery packets

Ville Nuorvala confirmed this is a bug and has posted a patch for this bug on mipl-devel. It should be fixed in release 2.0.2.

In MIPL 2.0.1, I observed that the CN node adds Routing Header Type 2 to Neighbor Discovery packets it sends to registered Mobile Nodes.
The RFC 3775 explicitely states that a CN node MUST NOT do this in section 9.3.2. (p.77).

(The same rule applies to MN, section 11.3.1.(p.108))

This is problematic in the following case:

Initial states:

  • A mobility-aware Correspondant Node in the Home Network starts a connection to a Mobile Node in a foreign network.
  • Return Routability procedure takes place and the CN adds a Binding Cache Entry for the Mobile Node.
  • Traffic between the nodes is route optimized.
Then the MN comes back home:
  • MN sends a BU to its Home Agent to de-register its CoA.
  • MN wants to send a BU to its CN
  • MN sends a Neighbour Solicitation to discover its CN link-layer address.
    The source address used is the MN Home Address.
  • CN receives the NS and prepares its Neighbor Advertisement.
    As it has a BCE for the MN Home Address, it inserts a Routing Header Type 2 in the packet, swapping the Home Address with the old/deprecated CoA.
  • The NA message leaves the CN node with the old CoA as destination address.
    MN never receives it.
Traffic between both nodes is blocked until the MN receives the NA and manages to send its BU. This happens when either BCE expires in the CN node or the CN nodes receives ICMPv6 Destination Unreachable for the CoA.

It seems to me that, when a BCE is added, the CN node needs to set some more XFRM selectors/policies to let the Neighbor Discovery packets leave the node without a Routing Header Type 2 being added:
  • Src:CN address, Dst:Any, Proto: 58, Type: 133..137, Code:0, Action:"Do not add RT2"

My investigations lead me to the routines xfrm_add_bce()/__xfrm_add_bce() where I suppose the problem may be solved. These routines are called after a call to cn_recv_bu().

Ethereal capture

This problem can be observed in the following Ethereal capture: http://www.bullopensource.org/mipv6/filedownload.php?file_id=384.
  • NS packet from MN Home Address to CN: packet 978
  • NA packet from CN to MN old Care of Address: packet 979





Last update: Wed Jun 07 2006