summaryrefslogtreecommitdiffstats
path: root/net/atm/lec_arpc.h
diff options
context:
space:
mode:
authorJon Paul Maloy <jon.maloy@ericsson.com>2016-07-11 22:08:35 +0200
committerDavid S. Miller <davem@davemloft.net>2016-07-12 07:42:12 +0200
commit2d18ac4ba7454a4260473e68be7e485ae71e7948 (patch)
tree0e31dd046751711ac548b9db6027e36495306e08 /net/atm/lec_arpc.h
parentr8152: Add support for setting pass through MAC address on RTL8153-AD (diff)
downloadlinux-2d18ac4ba7454a4260473e68be7e485ae71e7948.tar.xz
linux-2d18ac4ba7454a4260473e68be7e485ae71e7948.zip
tipc: extend broadcast link initialization criteria
At first contact between two nodes, an endpoint might sometimes have time to send out a LINK_PROTOCOL/STATE packet before it has received the broadcast initialization packet from the peer, i.e., before it has received a valid broadcast packet number to add to the 'bc_ack' field of the protocol message. This means that the peer endpoint will receive a protocol packet with an invalid broadcast acknowledge value of 0. Under unlucky circumstances this may lead to the original, already received acknowledge value being overwritten, so that the whole broadcast link goes stale after a while. We fix this by delaying the setting of the link field 'bc_peer_is_up' until we know that the peer really has received our own broadcast initialization message. The latter is always sent out as the first unicast message on a link, and always with seqeunce number 1. Because of this, we only need to look for a non-zero unicast acknowledge value in the arriving STATE messages, and once that is confirmed we know we are safe and can set the mentioned field. Before this moment, we must ignore all broadcast acknowledges from the peer. Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/atm/lec_arpc.h')
0 files changed, 0 insertions, 0 deletions