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]

Good suggestion. I'll look at adding support for this.

[jay]

Well, I dusted off my efforts on implementing this again. Last time I tried was over a year ago (mention of it in the old Savitar conference.) I hit a brick wall when I last tried, and had forgotten about it. Tried getting back into it again last night and hit the same brick wall. This snippit of a chat I had sums it up best:

/jay

----

Jay is trying to add a sort of "keepalive" ping to his moo client -- so connections through NAT devices (for example) don't time out on idle.

Charkes [to you]: so far that has only been implemented by MOO features

You say, "I looked at TCP_KEEPALIVE but it's not really part of the tcp spec, and there's lots of mention that the minimum keepalive time is 2 hours on my implementation (Open Transport)"

Charkes [to you]: what you should do is send a string and block the known reply

You [to Charkes]: Been doing that for years.

You [to Charkes]: My moo client isn't really a moo client -- its a M* client, so I'm trying to come up with a solution that doesn't use the server. I'm now trying to generalize it.

Charkes [to you]: good luck

You [to Charkes]: It's that bad, huh?

Charkes is on 4 different MOOs which means 4 different features programmed by 4 different people... 4 strings to gag on the client side

You say, "man. so much for TCP_KEEPALIVE"

[Guest_eltee_*]

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.

essentially it would be like setting a ##task 600 <null> where <null> was quite literally nothing

[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"

[Guest_eltee_*]

I don't know if it will help but the code I made for the win32 implementation of the nat timeout killer is literally just a timer event.. and every time the event triggers (once every 10 minutes by default) it does the following:


void timer(void)
{
socket.send NULL;
}

works on every NAT timeouting router i've had/tried (a belkin, three linksys' and a dlink-604

and as far as I know its never inter-acted with a mu* at all.. in fact if you are idle 10 minutes and send an empty tcp packet to the mu* server. The NAT router resets the connection as 0s idle (not actually inspecting the packet itself but merely passing it on), while the mu* opens the packet, then tosses it as worthless and you are still 10 minutes idle online.

[jay]

okey-dokey, I added support for keepalive in the just released Savitar 1.3.4. Let me know how it works for you.

/Jay

[Guest_eltee_*]

works great ^.^

thanks so much thats the last thing that really bothered me, its jus bout perfect in my eyes now ^.^

(signs off to go pay a visit ta kagi)

[Guest_eltee_*]

quick hiccup. Since i've enabled the nat timeout i've had no problem with the timeouts, but there is an unfortunate little hiccup. Theres no problem if it auto-reconnects.. but if it doesn't and sits at the disconnect notify... the next NAT killer interval it pops an alert type two and crashes back to the finder.

(aka i think its tryin to send the packet even with the connection closed and havin a problem)