> From: jnc@xxxxxxxxxxxxxxxxxxx (Noel Chiappa) > It's not at all clear to me that this was the wrong engineering choice on > their part. If they didn't GC dead connections after some sort of timeout (and > would it make any significant different whether it was 5 minutes, or 1 hour) > it would consume resources and perhaps lead to problems. > > Although I suppose they could impose an LRU algorithm on state blocks, > instead. I'd have to think about it for a while, to see if there were other > problems caused by not GC'ing inactive mappings. Problems in doing it right? hmmmmph. More recent boxes from some of the same vendors that have killed my ssh sessions do not kill my ssh sessions despite days of inactivity. That's not to say the newer boxes don't still have problems that can only be solved--er--attacked by power cycling when they stop responding every week or so. My current tactic involves solid state relays that driven by taking less than 5 ma from an RS-232 pin 20 and simple code that looks for signs of illness in the junk. (Yes, I know of far better, UL certified implementations. They cost more than the NAT junk.) Besides, if "GC" refers to "garbage collection," my prejudice is that you don't garbage collect active data. I've had the junk kill active ssh sessions. Whether they run a timer or just have bugs that appear after an hour or two, only someone with access to source could say. > Furthermore, it's relatively easy to avoid the SSH session problem - my > default login on Unix boxes has for many years now included starting this > shell script in the backgound: > > while 1 > echo " " > sleep 600 > end > > precisely to avoid having them shut down due to NAT timeouts (no matter how > long I go without typing on them). I try to avoid building failures into anything, especially if the failures are obscure and intermittent. That might keep an ssh session alive despite boorken NAT junk, but depending on imponderables including tty "driver" output buffering vs. application context switching on the ssh server side, it will also occassionally break curses programs including `top`, `sysstat`, `vi`, and `emacs`. Having a standards committee write more documents that say "DON'T BE STUPID!" sounds unlikely to solve many problems in NAT boxes, even if committee "solutions" weren't the hallmark of the design and implementation of garbage, probably including the junk NAT boxes at issue. Vernon Schryver vjs@xxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf