Wind River Support Network

Description

It seems that the broadcast Name Discovery packets are internally queued but not processed until another TIPC packet is processed.

For example:
1. unicast Request
2. broadcast Name Distribution (3 ms later)
3. random incoming TIPC message (110 ms later, unrelated)
4. Notification of the Name (<1ms later)


18:33:11.356266 TIPC v2.0 1.1.1:1392467991 > 1.1.2:747067710, headerlength 40 bytes, MessageSize 181 bytes, Low Importance Data payload, messageType NAMED_MSG
18:33:11.359584 TIPC v2.0 1.1.1:0 > 0.0.0:4711, headerlength 40 bytes, MessageSize 68 bytes, Name Table Update Protocol internal, messageType CONN_MSG
18:33:11.470428 TIPC v2.0 1.1.1:2066309238 > 1.1.2:3460299225, headerlength 32 bytes, MessageSize 80 bytes, Low Importance Data payload, messageType DIRECT_MSG
18:33:11.470621 write(1, "Server 553693189,32 got 1 within"..., 39Server 553693189,32 got 1 within 0 [s]

To reproduce:

Need 2 nodes, 1 running WRL8 (RCPL26), the other WRL3 (TIPC version 1.7.7)
The node is connected through an L2 switch which induces a delay of 3 ms on the broadcast packet (the device was not investigated)

The WRL 3 node open a sever type/instance, sends a request to the WRL 8 node and wait for a reply (which never comes back)
The WRL 8 mode upon reception of the request, check the topology server for the presence of the requester server type/instance and wait for 20ms for it to show up. But the topology server doesn’t tell us about the presence and our code refuse to reply to the request.

Steps to Reproduce

Attached you’ll find a small test code which can show the issue.
 
On WRL 8 node intelx86_64 window 1: tipc-test monitor
On WRL 8 node intelx86_64 window 2: tipc-test server
On WRL 3 node intelx86_64 window 3: tipc-test client
 
The server test is using the same 20ms expiry that we use for in our code for when waiting/looking for a TIPC server type/instance.
 
The test code has been put together quickly, so it lacks quality and clarity; but it does show the behavior:
 
Sample output rough order (the bad “unexpected” behavior is the EXPIRED)
Window 1: tipc-test monitor
Window 2: tipc-test server
Window 2: Waiting for hello.
Window 1: Server 1145254400,128,128 got PUBLISHED(1)
Window 3: tipc-test client
Window 3: Sending hello.
Window 3: Sent hello.
Window 1: Server 1145254400,129,129 got PUBLISHED(1)
Window 2: Assuming received hello.
Window 2: Server 1145254400,129, 1145254400 got EXPIRED(3)
Window 2: Peer is missing not sending.
Window 3: Server 1145254400,129,129 got PUBLISHED(1)
Window 3: Server 1145254400,129,129 got WITHDRAWN(2)
Window 3: Server 1145254400,128,128 got WITHDRAWN(2)
 
When using a larger subscription expiry, the server can see the publication but how large is large enough depends on the background TIPC traffic; so increasing the expiry timer is not a solution.
 
The only configuration where the issue is seen is as described:
“server” on WRL 8, “client” on WRL 3, broadcast packet between node delayed (while unicast aren’t)