Re: Server not listening - Mailing list pgadmin-support
From | Joris Dobbelsteen |
---|---|
Subject | Re: Server not listening |
Date | |
Msg-id | 73427AD314CC364C8DF0FFF9C4D693FF037AEE@nehemiah.joris2k.local Whole thread Raw |
In response to | Server not listening (GeorgeHeller <george.heller@yahoo.com>) |
List | pgadmin-support |
George,
In my opinion this table looks a little odd. The server seems to be accepting everything. If not, I'm missing something here. If the first rule(s) of RH-Firewall-1-INPUT don't hit, at least the line denoting postgres should. Otherwise its the default policy. This doesn't seem to be a problem in any way.
Up to the next step. On the client (XP) execute:
ipconfig /all
tracert <postgresql_hostname/ip>
On the server, also run ifconfig and provide the output. This provides some additional information in case later steps went wrong.
Secondly we are going to see what's going on at the network level. This is a little more involved and has a couple steps done together.
On the server, try running "tcpdump port 5432". Just let it running while you are trying to connect to the postgresql server.
On the client (XP) try to connect. Please use, from the command prompt, use "telnet <postgresql_hostname/ip> 5432".
If you get a "Could not open a connection to ..." indicate if it takes less than 5 seconds or, say, roughly 20 seconds. This gives some more information about the possible cause. (In the first case, the remote system denied it, while in the latter there is a timeout).
After this return to the server. You should see a lot of packets flying (having flown) over the screen. Every now and them you should see a line include something like ack. You should not see any lines listing rst, or nothing at all.
Alternatively, if you are not sure, capture this information to a file and mail it.
You should see something like this:
=================================
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:32:02.896456 IP 192.168.10.161.3885 > shushan.postgresql: S 2704075561:2704075561(0) win 65535 <mss 1460,nop,wscale 2,nop,nop,sackOK>
00:32:03.107584 IP shushan.postgresql > 192.168.10.161.3885: S 662668163:662668163(0) ack 2704075562 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 2>
00:32:03.107743 IP 192.168.10.161.3885 > shushan.postgresql: . ack 1 win 49275
00:32:03.107796 IP 192.168.10.161.3885 > shushan.postgresql: P 1:9(8) ack 1 win 49275
00:32:03.107848 IP shushan.postgresql > 192.168.10.161.3885: . ack 9 win 1460
00:32:03.107898 IP shushan.postgresql > 192.168.10.161.3885: P 1:2(1) ack 9 win 1460
00:32:02.897474 IP 192.168.10.161.3885 > shushan.postgresql: P 9:50(41) ack 2 win 49274
00:32:02.899190 IP shushan.postgresql > 192.168.10.161.3885: P 2:15(13) ack 50 win 1460
00:32:02.900353 IP 192.168.10.161.3885 > shushan.postgresql: P 50:91(41) ack 15 win 49271
00:32:02.912700 IP shushan.postgresql > 192.168.10.161.3885: P 15:296(281) ack 91 win 1460
00:32:02.914380 IP 192.168.10.161.3885 > shushan.postgresql: P 91:227(136) ack 296 win 49201
00:32:02.954465 IP shushan.postgresql > 192.168.10.161.3885: . ack 227 win 1728
00:32:03.201125 IP shushan.postgresql > 192.168.10.161.3885: P 296:468(172) ack 227 win 1728
00:32:03.202817 IP 192.168.10.161.3885 > shushan.postgresql: P 227:265(38) ack 468 win 49158
00:32:03.203245 IP shushan.postgresql > 192.168.10.161.3885: . ack 265 win 1728
00:32:03.205695 IP shushan.postgresql > 192.168.10.161.3885: P 468:512(44) ack 265 win 1728
00:32:03.207206 IP 192.168.10.161.3885 > shushan.postgresql: P 265:288(23) ack 512 win 49147
00:32:03.225787 IP shushan.postgresql > 192.168.10.161.3885: P 512:680(168) ack 288 win 1728
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:32:02.896456 IP 192.168.10.161.3885 > shushan.postgresql: S 2704075561:2704075561(0) win 65535 <mss 1460,nop,wscale 2,nop,nop,sackOK>
00:32:03.107584 IP shushan.postgresql > 192.168.10.161.3885: S 662668163:662668163(0) ack 2704075562 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 2>
00:32:03.107743 IP 192.168.10.161.3885 > shushan.postgresql: . ack 1 win 49275
00:32:03.107796 IP 192.168.10.161.3885 > shushan.postgresql: P 1:9(8) ack 1 win 49275
00:32:03.107848 IP shushan.postgresql > 192.168.10.161.3885: . ack 9 win 1460
00:32:03.107898 IP shushan.postgresql > 192.168.10.161.3885: P 1:2(1) ack 9 win 1460
00:32:02.897474 IP 192.168.10.161.3885 > shushan.postgresql: P 9:50(41) ack 2 win 49274
00:32:02.899190 IP shushan.postgresql > 192.168.10.161.3885: P 2:15(13) ack 50 win 1460
00:32:02.900353 IP 192.168.10.161.3885 > shushan.postgresql: P 50:91(41) ack 15 win 49271
00:32:02.912700 IP shushan.postgresql > 192.168.10.161.3885: P 15:296(281) ack 91 win 1460
00:32:02.914380 IP 192.168.10.161.3885 > shushan.postgresql: P 91:227(136) ack 296 win 49201
00:32:02.954465 IP shushan.postgresql > 192.168.10.161.3885: . ack 227 win 1728
00:32:03.201125 IP shushan.postgresql > 192.168.10.161.3885: P 296:468(172) ack 227 win 1728
00:32:03.202817 IP 192.168.10.161.3885 > shushan.postgresql: P 227:265(38) ack 468 win 49158
00:32:03.203245 IP shushan.postgresql > 192.168.10.161.3885: . ack 265 win 1728
00:32:03.205695 IP shushan.postgresql > 192.168.10.161.3885: P 468:512(44) ack 265 win 1728
00:32:03.207206 IP 192.168.10.161.3885 > shushan.postgresql: P 265:288(23) ack 512 win 49147
00:32:03.225787 IP shushan.postgresql > 192.168.10.161.3885: P 512:680(168) ack 288 win 1728
<continues on and on>
====================================
If you don't see something like this there is probably an intermediate system in your way.
- Joris
From: George Heller [mailto:george.heller@yahoo.com]
Sent: dinsdag 1 mei 2007 23:57
To: andy.shellam-lists@mailnetwork.co.uk; Joris Dobbelsteen
Cc: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] Server not listeningHi Andy/Joris,This is what my /sbin/iptables -L looks like:Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhereChain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhereChain OUTPUT (policy ACCEPT)
target prot opt source destinationChain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:postgres
REJECT all -- anywhere anywhere reject-with icmp-host-prohibitedThanks.George
andy.shellam-lists@mailnetwork.co.uk wrote:Hi George,
As Joris said, we need you to try what he has suggested.
The fact you can now connect via SSH proves PostgreSQL is set up and
configured correctly, which would point to a firewall or intermediate router
blocking your connections.
On the server (as root), do "iptables -L" or "/usr/local/sbin/iptables -L" if
the previous doesn't work, and post the full output so we can see if a
software firewall is blocking.
And please try and get some information about your network - who set the
server up, is there a hardware firewall or router firewall in between you and
the server, etc.
Thanks
Andy.
George Heller wrote:
> Hi,
>
> Ok, I have reached to the point where the SSH tunelling works, and I am
able
> to connect using it to PgAdmin. But I still want to know what exactly is
wrong
> with the other setup.
>
> I just came across this in the postgres documentation, about starting the
> postmaster with an -i option, if you want your server to accept TCP/IP
> connections.
> http://www.postgresql.org/docs/7.4/static/postmaster-start.html
>
> I just used the -D option as specified, to start the server. Is it
necessary
> to use the -i option so that my server can listen, or is the documentation
just
> too old? If yes, what is the syntax for the same?
>
> Thanks.
> George.
>
> Joris Dobbelsteen wrote:
> >-----Original Message-----
> >From: Andy Shellam [mailto:andy.shellam-lists@mailnetwork.co.uk]
> >Sent: woensdag 25 april 2007 21:25
> >To: Joris Dobbelsteen
> >Cc: George Heller; pgadmin-support@postgresql.org
> >Subject: Re: [pgadmin-support] Server not listening
> >
> >I concur, but just so you know I suggested SSH so George can
> >get up and running quickly while diagnosing the problems later
> >as it requires a lot of information he doesn't seem to have.
> >We've already established he has SSH access so it seemed an
> >obvious way to connect so he could actually begin to use PostgreSQL.
>
> Hopefully you took no offence while I took this a sharp turn.
>
> I agree that this would be probably a good idea to get it working.
> Alternatively it might seem easier to have a temporary set up on the
> local computer, if feasable.
>
> [snip]
>
> - Joris Dobbelsteen
>
>
>
>
> ---------------------------------
> Ahhh...imagining that irresistible "new car" smell?
> Check outnew cars at Yahoo! Autos.
>
> !DSPAM:37,4636eb7689291063614559!
>
_________________________________________________________
DISCLAIMER
This e-mail was sent through a Mail Network server.
The Mail Network accepts no liability for it's content.
Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
pgadmin-support by date: