I have followed the guides at https://www.azerothcore.org/acore-docker/, and everything installs and works fine. Auth, WorldServer, DB, etc all work. However, when trying to play locally (LAN, main computer with client, the server on a different Windows machine on same LAN), it consistently loops back to realm selection.
So, I searched here and found these two questions/answers:
Azerothcore: Looping on Realm Selection List
How to resolve sticking in "Realm Selection"?
I have followed the guide in the bottom one, and have changed the Address field in the database to my external IP address (assigned by ISP). The LocalAddress is 127.0.0.1 The rest of the information appears to be correct.
When trying to connect via the external IP, it won't connect at all. But when I try setting my realmlist to 127.0.0.1 it will connect and log me in, but continually loops back to the realm selection screen.
To make sure it was updating, I changed the name of the realm and it shows up correctly when I try and log in. So the data appears to be saved to the database, but I cannot get it to connect from the LAN.
Followed the official guides, and changed the IP address in the DB to external IP. Same result, except now it takes a few seconds to connect and try to log into the realm. Then fails, back to realm selection.
Help would be appreciated. Thanks.
It's 99.9% related to your networking. That's what it turns out to be for pretty much everyone asking this question.
Most likely either a port isn't forwarded correctly, or your firewall prevents the connection. Try and use an external service to verify if the port is open. (Do a search for "Port open check"). Also, check your firewall to have the worldserver listed as an exception in the right folder.
Another common mistake is to change the "default" values when using HeidiSQL in the realmlist db instead of changing the actual values in the 'data' tab.
Related
I have a database instance running on Amazon AWS. I use the RPostgreSQL package to connect my R session to my AWS database.
My issue is that every time I attempt to connect to my database instance after not having done so for a while, I get a "Connection timed out" error.
I can then use a browser to go to my AWS Console, edit the Inbound and Outbound rules for my security group to allow my IP Inbound & Outbound access. Then I can connect again just fine.
But then if I don't work on my database for a day or two, when I try to connect to my DB, it doesn't work, and the permissions for Inbound/Outbound access no longer match my IP address (which I'm sure is the cause of the problem).
So... is my IP address changing? Or are the edits I'm making to my security group's inbound/outbound permissions not being saved correctly?
To be clear, here's the order of events of how things have been going:
Haven't worked on DB for a few days, attempt to connect from my R sessions. I get an error.
Use browser to go to AWS Console and edit my security group's Inbound/Outbound rules by selecting "My IP"
Try again to connect to my DB from my R session. Hooray! It works.
A few days later - pick up the project again, attempt to reconnect to my AWS DB from R, and it no longer works...
Repeat this cycle of madness
Make post on SO hoping for an angel to help me
This isn't a debilitating problem, it's just extremely annoying to have to re-do my security settings every time I want to connect to my AWS DB.
Thanks in advance for any help you can provide!
It depends, but most possibly it seems to be that your IP is changing. Most of the ISP have Dynamic IP allocation, which means the IP can change if the router is restarted.
It is hence recommended to use DNS name instead of IP address in the security group setting.
It is easier to note down your IP address and check back after two days.
Can you see your IP address which you added two days ago in the Security Group page? If yes, you can just goto google "what is my IP" and see if both the values are same. Security Group (SG) setting does not get refreshed or changed on it's own(unless you are allocating a new Security Group).
One more thing you can try. Allow all connection (0.0.0.0) just to test. After two days or so, try again. If it works, it means there is issue with the IP address changing.
Currently we have a system in place where multiple server backup to a server in house. There are a total of 11 different servers backing up to this one storage server. Without any change(any that we are aware of) one of the servers stopped being able to connect to the storage server. It's weird too because the one that can't connect is actually our DNS server. It can ping the storage server and nslookup returns the appropriate value. However when I tried to browse to the server in windows explore via network I get the following message:
"Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose." - Error Code: 0x800004005 Unspecified error.
If at all possible I would like the solution to not have to restart the server(obviously that's a big request) but we run 24/7 and can't have the DNS server down for the next few weeks.
Thanks in advance!
I am completely guessing here however lets start with this, does it work if you try and connect to the share using IP?
A few things to consider in the mean time? What O.S is it?
-> Is network discovery off?
-> Have any firewalls been accidentally turned on
-> We had a similar sort of problem when the server lost it's trust relationship with AD (required a reboot I am afraid).
Unfortunately this error can relate to a range of problems including network devices, anti-virus, firewalls, shares, user accounts etc etc.
This may be a general topic, but I came across the issue while working on some code using the Rook package.
The recent R versions include an http server. You may have seen this while checking for help topics using RGui. It opens a new browser with the IP/Port, etc.
For eg., if I enter ?paste, this brings up,
http://127.0.0.1:31234/library/.../paste.html
But if I use my IP, say 192.168.1.2 in place of 127.0.0.1, the page fails to load, I get an error
While trying to retrieve the URL:http://192....
The following error was encountered:
We can not connect to the server you have requested
I have other apps that have httpd interfaces, and I can go to those app's http interfaces using both 127.0.0.1 and 192.168.1.2 ... etc. So, as far as system/network permissions are concerned - I do not think that is the issue here.
Rather, there is something specific to the R httpd process that disallows it to be accessed using the domain name, etc ?
The above was tested in a corporate network. When I tried the same process from my home network it worked fine. However, since I already access http interfaces of many other locally installed apps from the corporate PC, I think there might be something specific to R's http process that needs to be checked ?
Workstation is running - Windows XP
Please let me know if you have any thoughts on the above,
Regards,
Raj.
Fixed it. The trick is to specify,
s <- Rhttpd$new()
s$start(listen="0.0.0.0",port="20000")
when starting the Rook process. Specifying 0.0.0.0 makes it listen to all the interfaces and now I can access it using my external IP. Thanks a lot for your help nonetheless !
When opening a TCP port, the local IP address may be chosen. For incoming connections, typically INADDR_ANY (-1) is supplied to bind(), which means to open the port on every available interface.
However, it is quite possible to open a port on just one interface on your machine (in this case, 127.0.0.1), simply by supplying the IP address of the interface. Seems that R does just this.
My guess is that you may have a proxy in place on your corporate network. Your browser is probably configured to use that proxy to access the Internet. Most browsers will exclude an address which they know to be local (127.0.0.1 or localhost) from using the proxy, but might not exclude any other IP.
Try disabling the proxy in your browser (even "Auto-Detect", completely turn the proxy off) and see if you're able to connect.
I had the same problem.
If you are using RStudio, this might be a bug in the RStudio. Check out this link:
https://support.rstudio.com/hc/communities/public/questions/202656007-Cryptic-error-on-starting-RStudio-daily-with-R-devel
Updating to the latest version of RStudio with the latest version of R fixes the problem.
I have an ASP.NET application that I use to read the contents of a web page by a HttpWebRequest frequently. There's no problem with the remote address and my application is always working fine.
While I don't change anything, sometimes (about once a day) I get this error:
the remote name could not be resolved.
Why a previously resolved DNS name sometimes fails to be resolved?
The intermittent nature of this is going to be extremely difficult to resolve and it's going to take a configuration change instead of a code solution. (hint: read everything ;)
I would guess that the remote servers DNS is set to expire pretty often. Probably daily or maybe even every 12 hours or so. This is the TTL (time to live) setting. Admins sometimes set this to an artificially low level if they need the ability to quickly move the site to a new server.
You can determine how often it expires by going to a command prompt and running:
nslookup
set debug
www.theserverdomain.com
At the top of this will be a section that says "AUTHORITY RECORDS:" with an item under it that says "ttl".
Now, (and I'm making an educated guess here), what's probably happening when you query your DNS server to resolve that host name your server will have this value cached.
However, once it expires the your server will have to contact another server upstream to get the ip address resolution, called DNS forwarding. If there are a lot of hops between yours and the remote server OR if one of the DNS servers between the sites is overloaded then it could timeout and send back the message you are receiving.
If this is true then the ONLY thing you can do is hardcode the DNS and IP address combination in your web servers hosts file. This is usually at C:\Windows\System32\drivers\etc and is a file named "hosts". There is an example on how to properly edit this within the file itself.
Once you create the host mapping in that file, your web server will no longer have to contact the DNS server to perform name resolution and it won't matter what the TTL is set to.
The only danger here is if they move the web site to a new IP address. At which point you could simply update your hosts file again...
The first thing I would check is if DNS is no longer correctly configured or malfunctioning.
Try (from a Windows command line)
nslookup MyDnsNameHere
and see if you get the IP you would expect.
I have an application that is using ActiveDirectoryMembershipProvider to grant access to users. The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
We've opened the LDAP port to the DC on the inside network - yet no matter what we try, we end up with an error that says "The specified domain or server could not be contacted."
Does anyone have any suggestions on how I can resolve this? We've tried everything we can think of and just aren't getting anywhere.
My connection string is:
<add name="ADConnectionString"
connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/>
And my provider is:
<add name="ActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider"
connectionStringName="ADConnectionString"
attributeMapUsername="SAMAccountName"
connectionProtection="None"
connectionUsername="LdapUser"
connectionPassword="LdapPassword" />
The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
Since you could query directly using an LDAP tool, that suggests that the firewall is open correctly. However, keep in mind that the ActiveDirectoryMembershipProvider is not using plain old LDAP, it's using Microsoft technologies. For example, if you set connectionProtection="Secure", ADMP will try using SSL and port 636, if that fails, it will use Microsoft's built-in IPSec signing (see this article for more details).
Anyway, this makes me wonder about a couple things:
Does the AD domain have an IPSec "required" policy which refuses connections from non-domain/non-configured computers? (Probably not, since you connected with plain LDAP, but it's worth investigating.)
Have you added the domain controller's NetBIOS name to your lmhosts file, and its DNS name to your hosts file? (Many protocols check that their target's reported name matches the name you tried to connect to.)
A lot of people have noted problems using ADMP between different domains, and the solution required that a one-way trust be created. Since it sounds like your client computer is not in a domain, you can't have that trust--unless either (a) it is a member of a different domain with a one-way trust or (b) it is a member of the same domain and thus client-server trust is implicit.
It seems like the solution is to open port 445.
Read this thread
We're not allowed to open so I guess I'm stuck.
You can use this two articles, may be solve your problem
www.ddj.com/windows/184406424
forums.asp.net/t/1408268.aspx
and check your firewalls
I had this error, and managed to fix it. There are multiple reasons that can lead to this, here is a to-do list to identify exect problem:
Create a micro application, with single method Membership.GetAllUsers(), execute on machine outside Active Directory (AD), with incorrect password in connection string, check if you get incorrect password exception. If you don't get it you can't connect to your AD server, check firewall, if you do get invalid password exception, goto next step.
If you can, try to execute same app, localy on AD server, first with incorrect password, than with correct, executing app locally provides more detailed exception what is wrong (for me this exception lead me to fixing problem). In my case it told me that Server service is not started, than that Workstation service is not started.
Some thoughts on the fact that it required Server and Workstation services to be working on server: afaik Server service is used for windows file sharing (netbios over TCP), and is using 445 port, so it mey be that this port must be opened in addition to LDAP port. My second observation was that event if 445 port opened (netstat -an) it still can be not working, winows will drop all packets to this port if Windows Client and File and Printer sharing checkboxes are not checked on network interface adapter which rcived this packets. Check "telnet External_IP 445". Thats all info i gathered while strugling with this problem.
Have you tested with an LDAP browsing tool, from the remote box to see if it can connect with the criteria being used here? I.e. Is it a connectivity problem or something else?
In case anyone stumbles on this and wants to smash their head on a wall... Recently tried doing all this for an AD server that my company had in a different domain than the current context. Was using the IP provided and getting failures as stated here. Even used a tool like Softerra LDAP Admin and it worked fine, however AccountManagement failed.
We had a publicly exposed URL hooked to that IP address (still only allowing certain IP's to make calls). Once I replaced the IP with the URL provided, it worked like a charm.
Hope this saves someone the hours of head smashing I just put myself through.