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
<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:[EMAIL PROTECTED]
Sent: dinsdag 1 mei 2007 23:57
To: [EMAIL PROTECTED]; Joris Dobbelsteen
Cc: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] Server not listening
Hi 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 anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain 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-prohibited
Thanks.
George
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
> >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.
<http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;
_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM
->
