> -----Original Message----- > From: Erik Hugne [mailto:erik.hu...@gmail.com] > Sent: Wednesday, 08 June, 2016 15:39 > To: Ying Xue > Cc: Jon Maloy; Richard Alpe; Parthasarathy Bhuvaragan; tipc- > discuss...@lists.sourceforge.net > Subject: Re: [RFC PATCH] tipc: fix timer handling when socket is owned > > On Wed, Jun 08, 2016 at 01:58:18AM +0000, Xue, Ying wrote: > > Erik, please submit your patch to netdev with my acked-by and tested-by. > > It sounds like that Jon also acknowledged your patch :) > > If you dont mind, it's better if you include it in your next batch of patches.
I can do that, but I want feedback from GUNA first. > > Also, i noticed this error when i ran a custom test program today: > > [ 2271.393807] Retransmission failure on link <1.1.1:eth0-1.1.2:eth0> > [ 2271.393807] Resetting link Link <1.1.1:eth0-1.1.2:eth0> state e > [ 2271.395806] XMTQ: 50 [24827-24876], BKLGQ: 41, SNDNX: 24877, RCVNX: 26459 > [ 2271.396806] Failed msg: usr 0, typ 2, len 40, err 2 This is a rejected NAMED message, probably a SYN, with error code ERR_NO_PORT. Are you running your failed setup attempts from node 2 towards node 1? > [ 2271.397806] sqno 24827, prev: 1001001, src: 1005254 The source address doesn't look good, and probably causes the packet to be tossed away at the receiving side. Looking at tipc_msg_reverse() I really cannot see how the setting of this can go wrong, but I think this is the place to start looking. ///jon > > Two nodes, one bearer (eth) with default parameters. > Here's the test program i used: > https://gist.github.com/Hugne/37434559678384ea399aa8cd56f3c562 > > Notice the commented out 'listen' call, the bug only seems to occur > for me when i send large amounts of connections to a socket not marked > for listening > > I don't think this is related to the patch i made though.. > > //E ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
