This content has been marked as final. Show 34 replies
If what you meant was for me to put this in the command line of the remote computer, this did not work.
Am I forgetting some kind of driver or something?
No, On Local server.
Pls Not "not work", Like ORA-***** occured...
asahideO wrote:Ok sorry, everything works on local server, through sql plus or sql developer.
"sqlplus sys/*****@dbconnect as sysdba" OK?
Edited by: crench92 on Jan 21, 2013 7:57 PM
Sorry, I cannot help you anymore...
But If you can, try to connect by other user.
sysdba via network may not allowed on your setting.
You still didn't provide the actuall error message you receive on your remote client?
If it's a network related error message, than either you have a firewall blocking your port (incoming on your server or outgoing on your client; PING does not say TCP connections are allowed), or your database listener is not configured properly.
If it's a username/password related message, check your keyboard settings...
This is what I have figured out so far:
in sqlplus I get a TNS timed out message, ORA-12170
I used Wireshark to capture what was going on and I was getting host administratively prohibited messages, (When trying to connect from client to server)
On my Windows 7 computer that is trying to connect, I looked in the ARP cache to see if there was anything for my server (192.168.1.135) and there was no resolution there
So it seems to be a network related issue, as expected. TNS timeouts can happen when your clients TNS configuration has a failure (or uses parameters that don't fit your environment, e.g. unroutable addresses or unresolvable hostnames) or the database listener of your XE isn't working (configured) as expected. According to your output from lsnrctl service your database listener has bound to brandon-Linux and seems to be up and running. Does the hostname it has bound to actually resolve to the IP address you are using (on both client and server)?
What is the result (with actual error code) when you connect using SQL Developer without TNS, but just entering hostname, port and service name/sid for your XE instance?
Udo wrote:I don't know. Is this something I should check on the server? On the client, I'm not using brandon-Linux but 192.168.1.135 in the HOSTS section of the tnsnames.ora on client.
Does the hostname it has bound to actually resolve to the IP address you are using (on both client and server)?
What is the result (with actual error code) when you connect using SQL Developer without TNS, but just entering hostname, port and service name/sid for your XE instance?I get the same thing as I get with TNS "Status: Failure-Test failed: IO Error: The Network Adapter could not establish the connection" even if I put 192.168.1.135 in the hostname section of SQL Developer or brandon-Linux
I was finally able to connect remotely by flushing my iptables file on the server. Should I leave this file alone now?
Now I can only ping the server for a couple of minutes, then goes back to unreachable.
So you finally agree that you have a firewall... ;)1 person found this helpful
As far as I know Fedora, it has a firewall daemon. Probably this "service" is updating the iptables rules of your system to the values it has been configured for, so if you overwrite this, it's just valid until the next update interval of your daemon.
You should use the means of your Fedora to configure your firewall instead. This could be something like firewall-config or whatever your Fedora install uses. Make it open port 1521 tcp (for your database listener) and (if you need that for other purposes) enable icmp ping and you are done.
So I went back in to the iptables file and it is still clear of any rules. I also noticed that once I ping from the server to the client, I can ping from the client to the server. Basically I can't ping from A to B until I ping from B to A first.
Does anyone know the problem I'm having?
1 person found this helpful
So I went back in to the iptables file and it is still clear of any rules.This means nothing and doesn't mean connections are allowed.
If you suspect a firewall issue, simply disable it. I don't know exactly which Fedora release you are using, but perhaps the following will do (or look it up in google):
# service iptables stop
Then disable the firewall on your Windows side too to be sure.
If you still have no connectivity, then you have a service configuration or network routing problem.
P.S. is there any kind of machine virtualization involved? If yes, you may simply use the wrong adapter for your virtual machine that does not allow incoming connections, e.g. NAT.