Chat server problem - Firewall issue?

[BobAtWork]

Sorry for a general help question, I hope it's ok that I came here with my help request, since I haven't been able to get help anywhere else and I suspect the people reading this forum will be more knowledgable than most on the issue.

I'm having trouble doing any kind of /join in game to a chat channel. Some times I'll get connected and then suddenly stop seeing any response to my input or other incoming chat messages, but most of the time I can't even /join. I type /join channel (or whatever) and nothing happens. No response, no text, no error message, no usage, nothing. It's been very limiting. When I was interviewing for my current guild, they tried to get me into a chat channel to get to know me a little better and it was embarassing that I could not even join chat!

I suspect this may be a firewall issue. The chat servers are reputed to be on a separate system than the game servers, and I thought at first that it might be possible that the incoming packets come in through a different port than the game's UDP packets and that my firewall is blocking them. But this raises the question of why it *sometimes* works for a few seconds before quitting (rarely, but it has happened). It would seem that if it's a firewall issue, the packets wouldn't get in at all.

But I'm at a complete loss at what could be causing this problem. Anyone have any additional ideas? Meanwhile, to test the firewall theory, does anyone know the port ranges that need to be supported for chat channel support? On the official support boards I haven't seen any specific reference to firewall port ranges in connection with CHAT, just the game itself (which has never been an issue for me).

Thanks in advance for any ideas or thoughts here!

I am using a SonicWall SOHO2 firewall on a LAN that has all Win XP Pro machines. It has port-forwarding so I can set up whatever range I need to support chat. Thanks, and keep up the great work on this project!

Bob

[AlphaBeta]

Take the firewall offline and see if it works

[S_B_R]

There is a similar problem effecting Linksys routers. I'd suggest going to the official EQ tech support forums and search for "Linksys router" or anything like that...

[darkgrue]

I own several SonicWALL SOHOs (from the original SOHO to the 3), they all exhibit this behavior. I suspect that any stateful-inspection firewall has the potential to cause this problem.

The reason, I believe, is that the state table timeouts for UDP connections are consideribly shorter (and on the SonicWALL, not user settable). If the chat channel(s) you are joined to at any one particular time are effectively "silent" such that the UDP timers expire, the firewall thinks the connection is closed, and removes the state entry from the table. When the chat server tries to send subsequent chat traffic to your EQ client, it can't since the firewall has once again blocked the port. And since the client doesn't ever again submit the traffic that opened the ports in the first place, those ports remain closed.

This problem is most likely to happen if you are joined to low-volume or no chat channels at all, and can also happen during zoning, which seems to suspend chat traffic. You can fix it by zoning or logging out and back in. Another work around (which is what I use) is to join a high-volume channel like #bazaar, and put it in a minimized chat box. It hasn't been a 100% solution, but it has reduced the number of times that I've lost chat server connectivity.

Unfortunately, since the UDP timers aren't adjustible on the SonicWALLs (and probably many other makes of firewall), there's not much to be done or said except that the chat server protocol was ill-concieved, and is not firewall-friendly at all.

[BobAtWork]

Thanks, darkgrue. That appears to confirm that it's a firewall issue (that, and the fact that it works fine without the firewall).

I'll try your workaround of joining a busy chat channel (Bazaar sounds like a good logical choice) as a keepalive. I have multiple boxes running multiple accounts. I typically leave one in Trader mode when I'm soloing the other. If I place the 2nd account in Bazaar chat, it seems that would remedy the situation for my main account since the blockage is taking place at the firewall level (i.e., for all of my systems interfacing to the Internet).

I haven't been overly impressed with the SOHO for a variety of reasons, mostly deficiencies for handling the online gaming and IM experience, which I understand was probably not high on their list of priorities. But I'm considering alternatives. Any that you would recommend? Should I be looking for one that has configurable UDP timeout settings, or is that unlikely? I am of course concerned about security, but not to the point of disrupting my primary activities on this system.

Thanks again,

Bob

[bioh]

i am having same issues with firebox II....

and did not have them with the linux firewall i had before.

so i think ill probably drop the firebox, even though its pretty, and such...
but you're quite correct, once the nat expires, the incoming connections (even if you add on a service i think its udp 9876) will not get passed back.... how lame.

[fryfrog]

with the linksys routers, there is some new like temp port forward thing (find out about it by searching for linksys on the eq forums). basically, you set it to forward any port from 1024-65555 (what ever that top number is). its not REALLY a port forward, sort of a dynamic port forward. anytime YOUR computer opens a connection on port X, the router makes a port forward on port X in that port range. eq's chat can use 1 port from 1024-65565 (what ever the top port is).

this fixed all my issues.

[Cryonic]

2^16=65536

so the range is 0 - 65535 for all possible ports

[darkgrue]

If I place the 2nd account in Bazaar chat, it seems that would remedy the situation for my main account since the blockage is taking place at the firewall level (i.e., for all of my systems interfacing to the Internet).

No, because you have NAT/PAT going on at the same time - as far as the firewall is concerned the connection to each box is a separate entry in the table even though they are talking to the same server. Remember, the table is connection-based. The firewall still will time out the table entry for your primary account.

You need to have a high-volume chat channel running on the account you want to nurse your chat server connectivity going on.

I haven't been overly impressed with the SOHO for a variety of reasons, mostly deficiencies for handling the online gaming and IM experience, which I understand was probably not high on their list of priorities.

I've not experienced any problems with the SOHO in with gaming or IM, in fact, just the opposite. The problem here is common to all stateful-inspection firewalls, and not limited to just the SonicWALL product. As I said, the protocol itself is not firewall-friendly.

In fact, the instructions Sony provides on worthless tech support page for getting EQ to work with a firewall will actually disable or significantly diminish the effectiveness and security of the firewall products they've listed unofficial "support" for!

But I'm considering alternatives. Any that you would recommend? Should I be looking for one that has configurable UDP timeout settings, or is that unlikely?

I don't think it's likely you'll find a good alternative, and honestly, there's nothing wrong with your SOHO. (Well, barring buggy firmware code, they release new firmware as appropriate...) As I mentioned, this is a side-effect of the way stateful inspection firewalls work. If you want the security of a firewall, you're stuck with it. If you want to use a NAT/PAT router that's using port triggering (which is what the Linksys and a few others use), don't confuse that with a "firewall", regardless of the words they use on the box. The real reason it doesn't work well is Verant wrote a crappy application protocol.

Tweaking the UDP timers is a really unusual thing to even want to do (and there is a very good reason they're set so short). You may not be able to even set the UDP timers long enough to eliminate the problem without functionally crippling the firewall by filling up the UDP state table in a heartbeat.

[Cryonic]

SOHO == Small Office/Home Office. It is a general acronym for low-end hardware that might only be considered/purchased by low volume users. As opposed to things like Managed Switches which are, for the most part, relegated to use by large users (e.g. Universities, Corporations, etc...) that are willing to pay for the features/support.

[fee]

The EQ client connects to the World Chat Server on port 9876. Not sure what capabilities your firewall has but here are a couple possible suggestions.

Destination Network Address Translation (DNAT):
If you only have one EQ client behind your NAT firewall at any given time, you could specify a DNAT rule to send all traffic from Source port 9876 to your EQ client. Draw back is this will only work for 1 EQ client at a time. Someone mentioned dynamic port forwarding (DDNAT), if your hardware supports it, use it.

Use the Linux Netfilter (iptables):
Netfilter is able to NAT these types of connections without any trouble.

Example netfilter rule for simple NAT on a PPPoE connection.

 iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Tweak the interface to fit your given situation.

Fee

[darkgrue]

I think the initial client connect is on UDP port 9876, but the return connections are on a random UDP port >1024, so in fact you have to forward the entire range. IIRC, there's a couple of chat servers, too.

I could be wrong, it was a while since I last researched this problem, and ended up giving up in disgust. Sony doesn't document the chat server protocol anywhere, either. The forementioned useless firewall FAQ page they provide doesn't even mention the chat server connection at all, in fact.

[BobAtWork]

Hmm. The net/net seems to be that autologging onto a busy chat channel (e.g., bazaar) is going to be my only available work-around for this annoying problem. How big an impact is this additional chatter going to have on my throughput? Is this going to make getting around in the Bazaar even worse than it is today? Geez, what a pain.

Thanks to all for the analysis, I've been reading it carefully. I'm not encouraged, but I'm glad I brought the question here.

Bob

[darkgrue]

The amount of data sent by text messages from the game isn't very high data-rate at all. If I was to make a guess, the chat text probably represents the smallest percentage of the data transfered during gameplay, at all times. You would need some very concentrated effort from a large numbe of people specifically intended to flood clients in order to see any appreciable lag (all other things being equal). Also, since messages are first sent (or generated) by the server, then re-broad|multi-cast to the clients, there are already some rate limiting functions built into the servers (like the often-isn't-functional /severfilter). To demonstrate this, try and send a whole bunch of tells to another player, right after each other using a macro or some really quick shift-up-arrow action - you're likely to see the server squelch most of them.

You also need to keep in mind that the "bazaar" chat channel, and the actual Bazaar zone are two separate and different things, only related in that the players use them to buy and sell items.

The first is just the name of an arbitrary chat channel. Most (some? one?) server set up "bazaar" as the name of the chat channel used for advertising items for sale/trade, in leiu of the Bazaar zone (the chat channels were implemented well in advance of the Bazaar trader functions). Also because people can't (in the case of container items) or won't for whatever reason use the trader mode in the Bazaar zone. The channel may or may not exist on your server (or may be named something else) the idea here is only to pick a channel to join that tends to send new messages fairly often.

The latter is of course the zone off of Shadowhaven and the Nexus, where players can go to buy items, or sell them in trader mode. And, as you've alluded to, it's one of the most laggy zones in the game since the rendering engine pitches a fit rendering that many PCs in line-of-sight (and I suspect the crappy culling engine Sony's using truly has cut down on rendering non-visible surfaces).

I have several channels set up to join on login. The first is my guild's raid channel, then bazaar. I created a separate chat window, set it up so that bazaar goes to it, and when I log in, I just minimize the window and forget about it. Doesn't seem to impact my client at all, nor would I expect it to. So, no, joining chat channels shouldn't make your lag in the Bazaar zone any worse, unless you have a specific problem where the number or volume of the chat channels you have joined is already causing problems across the board for you. It's pretty crappy to have to use a work-around, but I've gotten used to it, and it's not nearly as inconvenient as always having to log/zone multiple times to get the stupid chat channels back.

Oh, should mention - easy way to see if you've lost connectivity to the chat servers is to do a /list. If you don't get any response (i.e. it doesn't list the channels you've joined), you're no longer talking to the chat servers. When you re-zone, you'll see it send you a "you have joined blah blah channel" messages as the client re-establishes the connection (zoning seems to cause the client to renegotiate the connection to the chat server).

[SlowNLazy]

When you re-zone, you'll see it send you a "you have joined blah blah channel" messages as the client re-establishes the connection (zoning seems to cause the client to renegotiate the connection to the chat server). [/B]

I've been lurking in hopes to solve my issue with the hand-me-down Sonic Wall FW... About to gank the damn thing in favor of a linux based firewall...

One observation however; Once I loose my chat channels, zoning doesnt bring them back and I'm back to square one... Which oddly enough, at this point I have a higher failure rate to rejoining a chat channel. Usually I'm forced to rezone again....