Configuration:
- Linux Kernel 2.6.20
- TIPC 1.7.5

I am using TIPC in a chassis based environment. Each card in the chassis
runs TIPC and the Node address for a card is based on the slot it is
plugged. For example, a card in slot 3 would have a node address of <1.1.3>.

The problem I observer occurs when I start to move around cards that are
plugged into the chassis. The TIPC port associated with the card that is
moved never gets created. Here is a simple example:
Card A in slot 1 has node address <1.1.1> and MAC address MAC_A
Card B in slot 2 has node address <1.1.2> and MAC address MAC_B

If I move Card B to slot 3 (node address is now <1.1.3> and MAC address is
still MAC_B) the link shows "up" when I run tipc-config -l on Card A and
Card B, but the TIPC port never gets created (tipc-config -p) and
applications using TIPC cannot send messages.

I believe the problem is caused by the fact that the original link between <
1.1.1> and <1.1.2> never gets deleted. When I perform a tipc-config -l on
Card A I see a link between <1.1.1> and <1.1.2> "down", and a link between <
1.1.1> and <1.1.3> "up". Instrumenting the code it appears that the original
link still has MAC_B as the media address and this causes problems when Card
B comes up with the same MAC but on a different link and Node address.

Question 1: There seems to be a tipc_link_delete function but it does not
seem to be used when communication is lost with a peer. Why are links not
deleted?

I was able to workaround this issue by clearing the media address before
resetting the link when a peer is not responding, see below. I saw something
similar done in tipc_discover.c and this comment.
     * TODO: It might be better to delete these "stale" link endpoints,
     * but this could be tricky [see tipc_link_delete()].

Question 2: Is there a plan to cleanup stale links in a future release? If
not, is the change shown below an appropriate fix?

Change:
===================================================================
--- linux-2.6.20.7/net/tipc/tipc_link.c (original copy)
+++ linux-2.6.20.7/net/tipc/tipc_link.c (working copy)
@@ -836,6 +836,12 @@
                                         l_ptr->fsm_msg_cnt);
                                warn("Resetting link <%s>, peer not
responding\n",
                                     l_ptr->name);
+                memset(&l_ptr->media_addr, 0, sizeof(struct
tipc_media_addr));
                                tipc_link_reset(l_ptr);
                                l_ptr->state = RESET_UNKNOWN;
                                l_ptr->fsm_msg_cnt = 0;


Richard Lopez
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to