From: Geoffrey D. B. <g...@ne...> - 2007-01-30 13:16:45
|
On Tue, Jan 30, 2007 at 09:21:02PM +1030, Daryl Tester wrote: > Geoffrey D. Bennett wrote: > > > Maybe I'm > > misreading the source, but I would expect to see some "Control message > > resend try x" (x counting up from 1 to 5) log messages before the > > tunnel gets dropped? > > You need debug level 3 to see those messages, and your logs looked > a little scanty for that (although that may have been creative editing > on your part - the "Control message unacked" look to be at 3 according > to 2.1.20 sources). I do have debug level 3 on. I excluded the messages about other tunnels and the "Sending v5 heartbeat" messages on the assumption that they were irrelevant. > > Does anyone > > have any ideas as to why after 1 second the tunnel was dropped instead > > of the message being retransmitted? > > Gotta admit that the logic in that section makes me go a little > cross-eyed. If the tunnel window size dropped to zero I could see > it skipping the retransmit without it updating the retry timers, > but that's just wild speculation on my part. You could patch the > Control message log message to print the Window size, if it occurs > often enough. AFAICT, the tunnel window size (you are talking about tunnel[t].window, yes?) is set when the tunnel is created and never changed. The last control message before things went bad in my log was "Control message (173 bytes): (unacked 1) l-ns 1401 l-nr 1777 r-ns 1777 r-nr 1401" -- the "unacked 1" is tunnel[t].controlc, which should be 0 by the time that function (processudp()) finishes. When you say about skipping the retx without it updating the retry timers, are you talking about this bit of code: // resend pending messages as timeout on reply if (tunnel[t].retry <= TIME) { controlt *c = tunnel[t].controls; uint8_t w = tunnel[t].window; tunnel[t].try++; // another try if (tunnel[t].try > 5) tunnelkill(t, "Timeout on control message"); // game over else while (c && w--) { tunnelsend(c->buf, c->length, t); c = c->next; } t_actions++; } ? In my case, tunnel[t].controls is going to point to the one and only message that hasn't been acknowledged. tunnel[t].window can't be 0. So I'm confused. Oh well, out with the debugger... Thanks, -- Geoffrey D. Bennett, RHCE, RHCX mailto:g...@ne... Senior Systems Engineer sip:g...@ne... NetCraft Australia Pty Ltd http://www.netcraft.com.au/geoffrey/ |