killing NAT timeouts, for fun and profit Options

[Guest_eltee_*]

Given a number of users are stuck behind annoying timeout prone routers these days (and unfortunately that the number of us are growing not shrinking) it would be nice to have a 'world' option to kill NAT timeouts.

This is pretty easily done by jus sending an empty packet to the connected world every x minutes. The packet, being empty, is discarded, but after it fools the NAT device into realizing the connection is still live.

A bonus (over using ##task) is that there is no indication its happened at all within the actual mu*. If you are idle 10 minutes and an empty packet is bounced, you are still idle 10 minutes. This helps by not leaving connections open indefinately (the mu* timeout will still apply) and lets people know when you are infact, idle.

Once something like this is in place, those of us with these routers will *NEVER* suffer another NAT timeout again. Not bad, ending months or nigh on years of frustration for lots of people with a single little quick change. ^.^

[jay]

More online discussion about this topic, pasted here to continue the thread and the idea.. I would love to implement a solution to NAT timeouts!

/jay

Brandon says, "Send a ' ' periodically"
Brandon says, "when idle"
Brandon says, "every server I know of will get that and discard it"
Brandon says, "er, send " \n""
Brandon says, "or simply "\n""
Jay (to Brandon) asks, "Really? You've done this?"
Brandon says, "or even just send " " and remember what you've sent, so when the user types something it first sends a \n or something"
Brandon says, "no, i'm just saying from my experience"
Brandon says, "the only thing the \n will do is mess with the prompt, but the user probably doesn't care if they are idle anyway"
Receiving input. Enter "." to finish or "@abort" to abort.
------------------------------- Jay (@paste's) --------------------------------
hmm I did it for something at work pc side by simply using a tcp 'send' where the actual data being sent was just "" (an empty string). Essentially it sends out a packet with no data in it whatsoever, just a header that passes thorugh the local router box out to the mu* and is promptly discarded at the os level as being a worthless packet, jus one of those every 10 minutes.

The local NAT router is fooled into thinking the connection is still live, and the mu* itself never actually sees the packet to interfere with idle times or send back any reply. In fact using it I do actually get disconnected *by* the mu* for inactivity after an hour if I do actually idle.

---------------------------------- + Finis + ----------------------------------
4 lines of text pasted
Jay says, "Excerpt from my moo client's conference, just posted."
Jay says, "..by a user."
Jay (to Brandon) asks, "What do you make of it?"
Brandon says, "sounds like it might work"
rozzin mmmm.
Brandon says, "Some security software on the lan may not like it"
Jay says, "Would be trivial to implement, give a user selectable timeout value. Test it against the user base for a spell, etc."
Brandon says, "Frankly, if I were you, I'd just ask the user for an idle command to run, customizable per server"
Brandon says, "let the user plugin their own 'null' command"
Jay says, "I have a "task" command designed for that purpose -- firing periodic commands. That's what I've been using here for years on this Cold, thus why my idle time is never > 5 minutes."
Jay would like to provide a more "unabtrusive" option for those who want to preserve idle time.
rozzin says, "And, from my perspective, it's annoying as hell."
Jay says, "I mean, they could use one, or the other, or both."
rozzin nods.
Jay agrees with rozzin.
Jay says, "It "breaks reality" having a non-idle time."
Brandon says, "Well, you could just code a noop command, that doesn't change your activity timer"
Jay doesn't want to code to specific server features. So far, one of the big "features" of my moo client is that it makes no assumptions about servers. It is "agnostic"