netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [net 1/1] tipc: avoid inheriting msg_non_seq flag when message is returned
@ 2017-08-14 16:28 Jon Maloy
  2017-08-14 18:20 ` David Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Jon Maloy @ 2017-08-14 16:28 UTC (permalink / raw)
  To: davem, netdev; +Cc: parthasarathy.bhuvaragan, ying.xue, tipc-discussion

In the function msg_reverse(), we reverse the header while trying to
reuse the original buffer whenever possible. Those rejected/returned
messages are always transmitted as unicast, but the msg_non_seq field
is not explicitly set to zero as it should be.

We have seen cases where multicast senders set the message type to
"NOT dest_droppable", meaning that a multicast message shorter than
one MTU will be returned, e.g., during receive buffer overflow, by
reusing the original buffer. This has the effect that even the
'msg_non_seq' field is inadvertently inherited by the rejected message,
although it is now sent as a unicast message. This again leads the
receiving unicast link endpoint to steer the packet toward the broadcast
link receive function, where it is dropped. The affected unicast link is
thereafter (after 100 failed retransmissions) declared 'stale' and
reset.

We fix this by unconditionally setting the 'msg_non_seq' flag to zero
for all rejected/returned messages.

Reported-by: Canh Duc Luu <canh.d.luu@dektech.com.au>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
 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.1.4

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [net 1/1] tipc: avoid inheriting msg_non_seq flag when message is returned
  2017-08-14 16:28 [net 1/1] tipc: avoid inheriting msg_non_seq flag when message is returned Jon Maloy
@ 2017-08-14 18:20 ` David Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2017-08-14 18:20 UTC (permalink / raw)
  To: jon.maloy; +Cc: netdev, parthasarathy.bhuvaragan, ying.xue, tipc-discussion

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 14 Aug 2017 18:28:49 +0200

> In the function msg_reverse(), we reverse the header while trying to
> reuse the original buffer whenever possible. Those rejected/returned
> messages are always transmitted as unicast, but the msg_non_seq field
> is not explicitly set to zero as it should be.
> 
> We have seen cases where multicast senders set the message type to
> "NOT dest_droppable", meaning that a multicast message shorter than
> one MTU will be returned, e.g., during receive buffer overflow, by
> reusing the original buffer. This has the effect that even the
> 'msg_non_seq' field is inadvertently inherited by the rejected message,
> although it is now sent as a unicast message. This again leads the
> receiving unicast link endpoint to steer the packet toward the broadcast
> link receive function, where it is dropped. The affected unicast link is
> thereafter (after 100 failed retransmissions) declared 'stale' and
> reset.
> 
> We fix this by unconditionally setting the 'msg_non_seq' flag to zero
> for all rejected/returned messages.
> 
> Reported-by: Canh Duc Luu <canh.d.luu@dektech.com.au>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Also applied, thanks again.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-08-14 18:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-14 16:28 [net 1/1] tipc: avoid inheriting msg_non_seq flag when message is returned Jon Maloy
2017-08-14 18:20 ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).