Skip to content
  • Jon Paul Maloy's avatar
    tipc: extend broadcast link initialization criteria · 2d18ac4b
    Jon Paul Maloy authored
    
    
    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: default avatarYing Xue <ying.xue@windriver.com>
    Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    2d18ac4b