From: LUU Duc Canh <[email protected]>
When Sender sends mcast messages non-droppable, in the case Server
terminates suddenly there is exist message that sent out from Sender
but Receiver can not see any correct port with the mcast address. This
message will be reject by reversing and sending on unicast link to
Sender. This message is non-sequence and still mcast type. At Sender
function node.c:tipc_rcv() check msg_non_seq() and pass to
tipc_node_bc_rcv(). And this function gives message to corresponding
broadcast link of Receiver node to process tipc_bcast_rcv() ->
tipc_link_rcv(). Therefore, Sender never sent ACK of reject message to
Receiver. So the unicast link will be reset when Receiver try to send
until stale_count equal to 100.
This patch fixes the problem by set bit non_seq in reverse message to
0 so broadcast link will not handle these messages.
To reproduce:
Receiver:
tipc-pipe -s --rdm --mc 100 200
Sender:
tipc-pipe --rdm --mc 120 150 --dest_droppable 0
--data_num 5000 --data_size 200
When Sender is sending, kill tipc-pipe by SIGINT suddenly at
Receiver, and unicast link will be reset.
Signed-off-by: LUU Duc Canh <[email protected]>
---
net/tipc/msg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index ab30876..dcd90e6 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -513,6 +513,7 @@ bool tipc_msg_reverse(u32 own_node, struct sk_buff **skb,
int err)
/* Now reverse the concerned fields */
msg_set_errcode(hdr, err);
+ msg_set_non_seq(hdr, 0);
msg_set_origport(hdr, msg_destport(&ohdr));
msg_set_destport(hdr, msg_origport(&ohdr));
msg_set_destnode(hdr, msg_prevnode(&ohdr));
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
