bonkersbobcat
07-03-2002, 11:58 AM
Originally posted by Mr Guy
IPCHAINS is just old and can't hack it.
Warning: this is long, but does lead to a question.
BACKGROUND:
I ran IPCHAINS for a long time with SEQ without problems.
I have a DSL connection, a multi-NIC linux box acting as a firewall / router / NAT device, and several machines on an inside network.
Back when Luclin came out, I installed Luclin, upgraded my IPchains configuration to IPtables, and built a new EQ box running XP. (Silly me for changing multiple things in my network environment at once. I am in the business and I KNOW BETTER, but oh well, I had a free weekend.)
I found that if I spent more then 5 minutes in a zone, EQ would crash upon my next zone.
After much swearing and investigation, I determined the problem was really not new hardware, XP, or Luclin, it was my change from IPchains to IPtables.
It appears that EQ uses several network connections during operation. One is used to transfer the zone data; One is used to maintain a security connection; and One is used for all the during-game communication (what SEQ spends most of its time watching.)
The second connection I refer to is UDP-based and seems only to be active when zoning.
This is problematic with NATing or Masquerading network devices because the UDP protocol is connectionless. (Connections are defined by the application, not the UDP protocol itself.) Since UDP is connectionless, networking devices doing NATing or masquerading have to "guess" when the connection is over. This "guess" is usually done via timeout. If no traffic has occurred between a set of mapped ports of a period of time, then the mapping between the ports is discarded.
Since traffic on this connection only occurs when you zone, and you could spend more time in a zone then your network allows for an idle UDP connection, your connection can be dropped while you are in the zone. If this happens, the next time you zone, your connection will no longer be there and then result is a crash to desktop during your next zone.
To prevent this you need to make sure your NATing or masquerading network device keeps UDP connections alive longer then the amount of time you will spend in a zone.
Under IPchains there is a command that sets this timeout value.
Under IPtables, you can not set the timeout value for UDP connections. This timeout value is hard coded in the linux kernel (the NATing code anyway) and can only be changed by editing one of the header files and building a new kernel that has a much higher timeout value. The hard coded values is 5 minutes (or a similar small value, it's been a while since I have looked at it.)
I solved my problem by editing said header file and building a new kernel with a 10 hour timeout value. Now as long as I zone every 10 hours, I have no crash to desktop problem.
QUESTIONS (finally):
It has been a while since I have gone through all of this and I have noticed that there has been no discussion on the topic of NATed UDP connection timeouts on this board. So I have to wonder if (why) am I the only one who has gone through all this.
I am planning up rebuilding my firewall box, and am wondering if I still need to go through the trouble of building a kernel with custom UDP timeout values.
Are people successfully playing EQ through a linux based router on a current kernel and using NAT without having to build a custom kernel with an altered UDP timeout value?
Has anyone else had to adjust their networking configuration to increase the timeout values for UDP connections?
Was there a change in the way EQ uses its "security" connection during the Luclin timeframe? If there was a change, has it reverted to a more reasonable condition? (It is an unusual network design pattern to maintain an application level UDP "connection" over long periods of time with no traffic.)
Are there any there any holes or things I missed in my above analysis? (The end result was correct for me. When I altered the UDP timeout values, EQ worked; when I revered to the original timeout values, EQ crashed on zoning.)
TIA for input
IPCHAINS is just old and can't hack it.
Warning: this is long, but does lead to a question.
BACKGROUND:
I ran IPCHAINS for a long time with SEQ without problems.
I have a DSL connection, a multi-NIC linux box acting as a firewall / router / NAT device, and several machines on an inside network.
Back when Luclin came out, I installed Luclin, upgraded my IPchains configuration to IPtables, and built a new EQ box running XP. (Silly me for changing multiple things in my network environment at once. I am in the business and I KNOW BETTER, but oh well, I had a free weekend.)
I found that if I spent more then 5 minutes in a zone, EQ would crash upon my next zone.
After much swearing and investigation, I determined the problem was really not new hardware, XP, or Luclin, it was my change from IPchains to IPtables.
It appears that EQ uses several network connections during operation. One is used to transfer the zone data; One is used to maintain a security connection; and One is used for all the during-game communication (what SEQ spends most of its time watching.)
The second connection I refer to is UDP-based and seems only to be active when zoning.
This is problematic with NATing or Masquerading network devices because the UDP protocol is connectionless. (Connections are defined by the application, not the UDP protocol itself.) Since UDP is connectionless, networking devices doing NATing or masquerading have to "guess" when the connection is over. This "guess" is usually done via timeout. If no traffic has occurred between a set of mapped ports of a period of time, then the mapping between the ports is discarded.
Since traffic on this connection only occurs when you zone, and you could spend more time in a zone then your network allows for an idle UDP connection, your connection can be dropped while you are in the zone. If this happens, the next time you zone, your connection will no longer be there and then result is a crash to desktop during your next zone.
To prevent this you need to make sure your NATing or masquerading network device keeps UDP connections alive longer then the amount of time you will spend in a zone.
Under IPchains there is a command that sets this timeout value.
Under IPtables, you can not set the timeout value for UDP connections. This timeout value is hard coded in the linux kernel (the NATing code anyway) and can only be changed by editing one of the header files and building a new kernel that has a much higher timeout value. The hard coded values is 5 minutes (or a similar small value, it's been a while since I have looked at it.)
I solved my problem by editing said header file and building a new kernel with a 10 hour timeout value. Now as long as I zone every 10 hours, I have no crash to desktop problem.
QUESTIONS (finally):
It has been a while since I have gone through all of this and I have noticed that there has been no discussion on the topic of NATed UDP connection timeouts on this board. So I have to wonder if (why) am I the only one who has gone through all this.
I am planning up rebuilding my firewall box, and am wondering if I still need to go through the trouble of building a kernel with custom UDP timeout values.
Are people successfully playing EQ through a linux based router on a current kernel and using NAT without having to build a custom kernel with an altered UDP timeout value?
Has anyone else had to adjust their networking configuration to increase the timeout values for UDP connections?
Was there a change in the way EQ uses its "security" connection during the Luclin timeframe? If there was a change, has it reverted to a more reasonable condition? (It is an unusual network design pattern to maintain an application level UDP "connection" over long periods of time with no traffic.)
Are there any there any holes or things I missed in my above analysis? (The end result was correct for me. When I altered the UDP timeout values, EQ worked; when I revered to the original timeout values, EQ crashed on zoning.)
TIA for input