Cant get on game :(

[annewandering]

does SE have a lockout if you try more than a certain number of times even if you have the right pws?

[Daniel_Hatcher]

does SE have a lockout if you try more than a certain number of times even if you have the right pws?

Yes, if you logon too many times incorrectly they block it for a certain period of time 15 minutes~1 hour I believe.

Try disabling the firewall and any virus scan.

If it works try disabling one at a time and see if which one is causing the problem, may also be worth temporarily disabling the firewall on your modem/router and checking.

Obviously don't leave them off, just to check if it's a problem with them.

PS. I had this problem before, ended up being a problem with the ISP.

[RAIST]

been a while since I used the MyCoolTools apps (Vizualware). I think that one is just measuring the latency...and running from US to JP is going to have high lag in general, typically hovering around the 200ms mark for me (compared to <90 just about anywhere in NA and sometimes even EU).

What you are usually looking for with FFXI is whether you are are hitting a "blackhole" situation (stalled routing) or packet loss. Tracert is a quick, easy DOS command that reports the round-trip time to each hop in the path to your destination, so is usually a quick way to check for stalls in routing (which is usually the case when this is going on). You may even have a ping tool in your router config pages where you can put the IP in yourself to test it outside of your internal network (tracert starts from your PC and may be affected by security software and such, doing it from the router or modem takes your system out of the equation).

You can run a handy tool called TCPView (Microsfot link) to see all your TCP connections in real time to capture the IP's you are actually using (or run netstat -s in a DOS box while connecting to do the same thing). You will see some IP's go into a waiting state while connecting/zoning, often times will have a port ID appended like 4002, 5001, etc that are in the recommended port forwarding guidelines. They tend to release fast in TCPView, where as netstat will report them for a longer period of time, so I usually use that myself. More often than not, these are the connections that are getting dropped--the active connections are just that, actively transmitting and can be considered good. It's the ones that go into standby, waiting for server response or waiting to transmit to the server that typically cause the problem---they don't transmit/receive when expected and you get bounced.

One thing often overlooked (and why it gets so heavily stressed to check local security software logs/settings), is that FFXI uses a lot of UDP transmission. This protocol has no mechanism to make sure the packets reach the destination--if it gets lost, so be it. Have to just wait for the next cycle to update. But...if after x amount of time you or the server don't get these packets, disconnection happens. That's why it's important to check your security logs and rules. A lot of times only TCP gets allowed/enabled--and not the UDP. So, you connect initially via TCP but eventually you loose the UDP "heartbeat", and get thrown off a few minutes later. If ou are setting your own port forwarding in your router, you may notice you have options for setting just TCP, just UPD, or both TCP/UDP in the rule. You want to make sure you are allowing BOTH protocols, whether that needs to be two seperate rules for each protocol, or one that enables both protocols. Likewise, if someone else is setting the forwarding for you (like your ISP), make sure they know you need BOTH TCP and UDP forwarded.

[EDIT]: Oh yeah, though it is rare, I have even seen some people have DNS from SE get blocked. If DNS calls are logged as being rejected, need to reverse-lookup the IP (sometimes you get lucky just googling the IP, but somehere like dnsstuff.com has tools for it) to see if it's SE. If it is confirmed to be an SE IP, need to allow it through either with a DNS enable/allow rule or just enable/allow that IP.

More in depth tools are out there to test other things, but usually all that is needed is the trace to find a problematic segment. If everything checks out for generic connectivity through tracing and the quality of your service is under suspiscion, something like DSLreports.com's Line Quality Test can help you determine if there are packet loss or high jitter issues on your line due to interference, poor tuning, etc. closer to home (these typically test thinkgs more like your ISP's local segments, your closest node and such). Another thing you could try there is the Tweaktest (this is a quicker tool than line quality, but less info). If TwekTest detects retransmitted packets, it's usually a sign that something isn't tuned right somewhere either at the system and/or ISP level that is causing packets to get discarded and retried. Other sites have similar tools, this is just one I have bookmarked and I hit it a lot out of habit.

These things are sometimes tricky to track down....but someone has to get the ball rolling, or it could take weeks to resolve (as seen about a month ago in the UK...was like a month before that mess got sorted out with O2/BT).

{edit}
As Daniel mentioned above, sometimes it is our own Router that can be causing the problem. Some have built-in firewalls, elvated security for NAT and such. The config pages vary from brand to brand, and even model to model within the same brand, so it's hard to give examples. But there should be details on the settings either in online help within the config pages, or in a manual or PDF on the install disc. If you see things like NAT Security, SIP ALG, SPI Firewall options and such you are heading you in the right direction.

[annewandering]

interesting new line on TCPview. visicom-47.national.net.

visicom-47.nationalnet.com

visicom-47.nationalnet.com IP address location & more:
Host of the IP: visicom-47.nationalnet.com[Whois] [Reverse IP]
Host IP [?]: 66.115.174.8 [Whois] [Reverse IP]
IP country code: US
IP address country: United States
IP address state: Georgia
IP address city: Marietta
IP postcode: 30067
IP address latitude: 33.9306
IP address longitude: -84.4613
ISP of this IP [?]: NationalNet
Organization: NationalNet
Local time in United States: 2012-07-06 16:24

It does a wait then goes red then closes. pol.exe does the same.

[RAIST]

hmm...that sounds a bit odd. The contact info on that site's registration at TUCOWS is dns2@websol.net (WebSolutions of Georgia). They host all kinds of websites there....who knows what is trying to connect to a site in the background. Have you run malware scans and such? You might have picked up a DNS redirector or something, who knows. Or possibly your ISP has been hit by the malware that the FBI has been up in arms about (can test it from the links at www.dcwg.org). If you don't have one, malwarebytes.org has a pretty good free malware scanner for personal use (click the Download button for redirect to a mirroring site for the free version) It's one of the tools that tons of companies turn to for troubleshooting malware problems--even other malware/security/antivirus companies will point to it when their support team is having trouble cleaning something.

[Zamms]

I had issues like this when i had Verizon DSL, signal would be weak random ro, not being able to connect or stay connected. I switched to Comcast and i have not had any issues since. It maybe something to look into.