275 replies to this topic

[Vehemens]

While I am grateful that the workaround was successful, it is very hard to believe that this patch did not cause the problem when this is the first time this error has occurred, and it occurs the day the patch goes live.

[Anais Opal]

Jon Cunningham, on 15 July 2014 - 11:57 AM, said:

For those of you *still* having problems post DNS update, hit your start button, type into the run box the letters

CMD

then in the console box that comes up, type ipconfig /flushdns

and hit enter. Let us know if that works.

command prompt on win7 and above needs to be started with admin privileges, start--run will only let you read ip information.

The correct way is start--all programs--accessories--rght click command prompt--run as administrator. THEN you can issue ipconfig commands.

Just an FYI....

[Grimferth]

I will wait for the hotfix. I will not implement the change to use Google DNS. If no other solution is coming, then I guess I wasted my money on this game....

[Anais Opal]

Kyle Polulak, on 15 July 2014 - 11:24 AM, said:

Remember if a Google DNS change results in a 'fix' to your problem then your ISP is to blame not us.

ISP's want to squeeze as much money out of plebeians; one way they do this is by ignoring DNS caching rules and holding onto data to serve to your computer as long as possible to save pennies here and there. They break your experience, not us.

So when we ask you to switch your DNS to fix a problem it doesn't reside on either of our ends; look to your ISP as the culprit.

This statement is false.

Caching is for the serving of HTTP requests, i.e. webpages. The flushing of webcaches can be controlled.

Speaking as someone who has for the last 20 odd years, built, deployed, managed and troubleshot DNS and Mail servers, I can tell you that NS and MX records are updated dynamically across the Internet from a half dozen core 'backbone' name servers.

Here's how the process works.

Company A sets up a DNS server internally to serve its local network, the engineer sets the DNS server IP forwarders to query its ISP nameservers for any requests that cannot be resolved locally. The ISP takes any requests and checks it against its own local DNS, any information it can't resolve it forwards the request to backbone DNS servers. The backbone then returns the data to the ISP which then pushes it down to the local network.

EDIT 1: If the backbone cannot resolve the requests it sends an error back to the ISP which then sends the error to the Company DNS which sends a 'Not Found' error to the requesting client PC.

Now here's how DNS registration works.

Company A decides to host a webserver on its local network, the engineer sets up a domain name for the webserver host.company.com. Logs into the ISP's control panel for their account, and sets up an NS record for host.company.com. The ISP's DNS server then pushes that information onto the backbone and WITHIN 24 HOURS that new NS record has populated around the Internet on thousands of DNS servers.

How problems occur,

Company makes a change to the IP address and forgets to update the NS record.
ISP makes a change to the IP address but fails to notify the Company so the NS record doesn't get updated.
Nameserver at the ISP fails (rare and most if not all ISPs have 3)
Dynamic updates across the backbone take longer than usual but never more than 72 hours.

For an ISP to 'hold onto' DNS data would require teams of literally hundreds of people sitting with DNS consoles MANUALLY EDITING NS records practically 24 hours a day.

Once again PGI provides false information. This problem is being caused by one of a couple of the problems I listed above. Worse case scenario, someone at PGI has been messing with the NS records, made a mistake, or created a second NS record with slightly different information and that has been pushed WORLDWIDE.

I have this patching problem on TalkTalk in Scotland. So its not a single ISP problem, its multiple, ergo, f*cked up NS record which can only be caused by HUMAN ERROR.

EDIT 2: This is highlighted by the fact that the patcher is returning a 'down for maintenance' error back to the client which means that the IP information being returned is incorrect.

Edited by GlycerineOxide, 16 July 2014 - 05:15 AM.

[CygnusX7]

If there were changes on PGI's end that required DNS changes that have not propagated through out the many many internet providers all across the internet I can understand why we are having to do this. It will be temporary and is why it affects some and not others.

Perhaps I missed it but an explanation stating so would be great. This is a common occurrence when changes like this are made.

Edited by CygnusX7, 16 July 2014 - 05:13 AM.

[Ninthshadow]

Checking in here:

Flushed DNS again (as administrator) with no luck.

Still cannot access the patcher.

[C E Dwyer]

In hands of support,

how many still having problems that haven't switched to Google DNS

[Fyrerock]

I play another game called everyquest one by sony and it turned out that sony has not payed their domain name for the last 2 months, so yesterday the name was changed by domain name servers. Sony has corrected the problem but they say that DNS propagation takes as long as it takes about 48 hours. Could this have anything to do with the problem? The funny thing I did not have any problems logging into eq but I am still not able to log into MW.

[Anais Opal]

CygnusX7, on 16 July 2014 - 05:11 AM, said:

If there were changes on PGI's end that required DNS changes that have not propagated through out the many many internet providers all across the internet I can understand why we are having to do this. It will be temporary and is why it affects some and not others.

Perhaps I missed it but an explanation stating so would be great. This is a common occurrence when changes like this are made.

Please see my explanation of DNS at the bottom of page 13 of this thread

[Bulvar Jorgensson]

Are we actually going to get an intelligent response from PGI about this issue other than the work round we are being told to use.

If the have changed their address as such, why do they not have the same thing that snail mail has "Redirection", ohh your address has changed we can switch it over for the next 2 weeks.

I used the fix round to patch, but had to switch back to my normal virgin settings as playing or using games on my steam account were coming back with error's (which means until this is fixed I can do one or the other but it seems not have both).

48 hours of my Premium time back would be a start PGI, after all since January you have had over £300 of my hard earned cash for a FtP game???

I enjoy playing Mwo, it is the closest thing to the old Battletech, with enhanced graphics (which do impress my console playing mates). Even some of the mech/weapon issues we can all live with, this DnS issue however we cannot.

Edited by Bulvar Jorgensson, 16 July 2014 - 05:35 AM.

[CygnusX7]

GlycerineOxide, on 16 July 2014 - 05:29 AM, said:

Please see my explanation of DNS at the bottom of page 13 of this thread

I get how it works. I may have missed it but the situation PGI is having should come from PGI.

[dr bongstorm]

The work around works, but it has significantly slowed down my regular browsing.

WTF is with you guys, PGI? Why does your game break more then any other game I play?

Get it together. You are killing this IP, and I hope whoever has licensed it to you sees how big you are ******* the IP up and are holding you accountable.

Edited by dr bongstorm, 16 July 2014 - 05:43 AM.

[mad kat]

Conspiracy theorists will be along soon..........

Google knows all anyhow.

Edited by mad kat, 16 July 2014 - 05:47 AM.

[sgt scout]

tried fix 1, did not work.

i really dont want to try fix 2, my internet is sexy cool and has given me no problems ever. I can still play all other games whilst i was waiting for the servers to come back online.

lookup info:

non-authoritative answer:
name: a1982.d.akami.net
address: 62.252.169.10
62.252.169.24
aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net


side not: havent played this game in 2014 yet. Played for the first time this year 2 days before the patch.

not trying to attack the devs here as its nice to see so much replies to this thread which is something that never used to happen with you guys. But to immediately experience some form of the game failing is not good

[Triordinant]

20 hours later and still no go...

[Anais Opal]

sgt scout, on 16 July 2014 - 05:50 AM, said:

tried fix 1, did not work.

i really dont want to try fix 2, my internet is sexy cool and has given me no problems ever. I can still play all other games whilst i was waiting for the servers to come back online.

lookup info:

non-authoritative answer:
name: a1982.d.akami.net
address: 62.252.169.10
62.252.169.24
aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net


side not: havent played this game in 2014 yet. Played for the first time this year 2 days before the patch.

not trying to attack the devs here as its nice to see so much replies to this thread which is something that never used to happen with you guys. But to immediately experience some form of the game failing is not good

AHHHHHH

here we have the issue your nslookup resolved
non-authoritative answer:
name: a1982.d.akami.net
address: 62.252.169.10
62.252.169.24
aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net

Mine
non-authoritative answer:
name: a1982.d.akami.net
address: 62.252.169.222
62.252.169.190
aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net

ergo, an NS record update has failed somewhere.

Hey PGI, we found your problem for you..

Now go fix it, if you can....

Edited by GlycerineOxide, 16 July 2014 - 05:58 AM.

[Bmetranger]

Folks calm down they will fix it with community warfare. To Make up for this huge blunder. They will be giving everyone all 3 timberwolves with mechbays, plus 6000MC and 30 Premium time. It would be the least the could do if they want to keep what little player base they have left and remain viable as a company. Also the will be sending all their customer service reps to disney training so they don't come off sounding like condescending A holes.

[Anais Opal]

Sent: Wed 16/07/2014
To: 'support@mwomercs.com'
Subject: Patcher Issues
Please refer to the two forum posts below...

Why Kyle Polulak is talking complete rubbish...
http://mwomercs.com/...63#entry3562963
The actual issue.
http://mwomercs.com/...11#entry3563111

Whoever manages your domains needs to go back in and undo/fix whatever they did during maintenance yesterday.

Thanks!

[Felix Dante]

Krist Smith, on 15 July 2014 - 12:26 PM, said:

When we publish a new patch, there are a subset of files that aren't new - they're changed and require a refresh across all the CDN nodes in order for the changes to show up in all locations around the world. Sometimes (very rarely) this refresh doesn't hit all the locations for some reason. One explanation is that it's on the ISP not recognizing a change and not accepting the new version of the file into their cache, and another one is that the CDN node itself didn't get the refresh instruction. We have re-issued the refresh command and, at this point, it's highly unlikely that the same node would have skipped the instruction twice.

We aren't interested in placing blame on any one culprit, we are only interested in explaining what went wrong, fixing it, and creating a plan that avoids having to deal with it again. We aren't saying your ISP sucks or is going out of their way to prevent you from doing anything, but if a caching policy is too conservative and isn't tuned to recognize a changed file, then we are pretty much stuck for a solution (short of re-issuing the refresh command multiple times with our fingers crossed, hoping that at least one of those times the changes will be detected).

I have one particular request to anyone still having this issue - could you please specify if it's happening in the patcher or the game client? At this point, we're assuming it's in the patcher, but if that's incorrect we need to broaden our search.

Patcher for me. It's been like this since last night! I would like to get at least 24-48 hours of my premium time back too!

Edited by Felix Dante, 16 July 2014 - 06:29 AM.

[Anais Opal]

Krist Smith, on 15 July 2014 - 12:26 PM, said:

When we publish a new patch, there are a subset of files that aren't new - they're changed and require a refresh across all the CDN nodes in order for the changes to show up in all locations around the world. Sometimes (very rarely) this refresh doesn't hit all the locations for some reason. One explanation is that it's on the ISP not recognizing a change and not accepting the new version of the file into their cache, and another one is that the CDN node itself didn't get the refresh instruction. We have re-issued the refresh command and, at this point, it's highly unlikely that the same node would have skipped the instruction twice.

We aren't interested in placing blame on any one culprit, we are only interested in explaining what went wrong, fixing it, and creating a plan that avoids having to deal with it again. We aren't saying your ISP sucks or is going out of their way to prevent you from doing anything, but if a caching policy is too conservative and isn't tuned to recognize a changed file, then we are pretty much stuck for a solution (short of re-issuing the refresh command multiple times with our fingers crossed, hoping that at least one of those times the changes will be detected).

I have one particular request to anyone still having this issue - could you please specify if it's happening in the patcher or the game client? At this point, we're assuming it's in the patcher, but if that's incorrect we need to broaden our search.

Patcher, my system.cfg was blank so I am making the assumption that the patcher address is hardcoded. That being said, if you hard code a url (patcher.mwomercs.com) then the problem is not the patcher itself but NS records as i have outlined.
If you have hard coded the IP address then that was pretty daft.....