It has been written: >> Except that if you read the man page for nmap you find.... >> >> Filtered means that a firewall, filter, or other network obstacle is >> covering the port and preventing nmap from determining whether the port is open. >> >> And >> >> [egreshko@misty ~]$ telnet 86.43.71.228 993 >> Trying 86.43.71.228... >> >> Times out.... >> >> > >> > Nmap finished: 1 IP address (1 host up) scanned in 20.467 seconds >> > ===================================== >> > >> > But "netstat -anp --tcp" does not show anything listening on 993 I forgot to mention....that you should see.... [root@f7 ~]# netstat -nap | grep 993 tcp 0 0 :::993 :::* LISTEN 3318/dovecot Or something to that effect. But, since you said that telnet to port 993 on localhost works it is confusing. You don't happen to have an DSL router with an embedded firewall giving you grief do you? For a test, you can always disable your firewall and check again. The port should show as "open" and not "filtered". >> > ===================================== >> > [tim@martha ~]$ sudo netstat -anp --tcp >> > Active Internet connections (servers and established) >> > Proto Recv-Q Send-Q Local Address Foreign Address >> > State PID/Program name >> > tcp 0 0 127.0.0.1:8000 0.0.0.0:* >> > LISTEN 1745/nasd >> > tcp 0 0 127.0.0.1:2208 0.0.0.0:* >> > LISTEN 1637/hpiod >> > tcp 0 0 0.0.0.0:139 0.0.0.0:* >> > LISTEN 1878/smbd >> > tcp 0 0 0.0.0.0:631 0.0.0.0:* >> > LISTEN 1654/cupsd >> > tcp 0 0 127.0.0.1:25 0.0.0.0:* >> > LISTEN 1714/sendmail: acce >> > tcp 0 0 0.0.0.0:445 0.0.0.0:* >> > LISTEN 1878/smbd >> > tcp 0 0 127.0.0.1:2207 0.0.0.0:* >> > LISTEN 1642/python >> > tcp 0 0 0.0.0.0:33215 0.0.0.0:* >> > LISTEN 1443/rpc.statd >> > tcp 0 0 192.168.1.149:34676 86.43.71.228:2001 >> > ESTABLISHED 3298/ssh >> > tcp 0 0 :::901 :::* >> > LISTEN 1680/xinetd >> > tcp 0 0 :::111 :::* >> > LISTEN 1422/rpcbind >> > tcp 0 0 :::22 :::* >> > LISTEN 1668/sshd >> > tcp 0 0 :::631 :::* >> > LISTEN 1654/cupsd >> > ===================================== >> > >> > I can telnet 993 on my server without problem: >> > ===================================== >> > [tim@alfred ~]$ telnet localhost 993 >> > Trying 127.0.0.1... >> > Connected to localhost.localdomain (127.0.0.1). >> > Escape character is '^]'. >> > ^] >> > telnet> quit >> > Connection closed. >> > ===================================== >> > >> > And "iptables -L" seems to allow this connection: >> > ===================================== >> > ... >> > Chain net2fw (1 references) >> > target prot opt source destination >> > ACCEPT 0 -- anywhere anywhere state >> > RELATED,ESTABLISHED >> > ACCEPT icmp -- anywhere anywhere icmp >> > echo-request >> > ACCEPT tcp -- anywhere anywhere tcp dpt:http >> > ACCEPT tcp -- anywhere anywhere tcp dpt:ssh >> > ACCEPT tcp -- anywhere anywhere tcp dpt:https >> > ACCEPT tcp -- anywhere anywhere tcp >> > dpt:appserv-http >> > ACCEPT udp -- anywhere anywhere udp >> > dpt:appserv-http >> > ACCEPT tcp -- anywhere anywhere tcp dpt:smtp >> > ACCEPT tcp -- anywhere anywhere tcp dpt:imaps >> > Drop 0 -- anywhere anywhere >> > LOG 0 -- anywhere anywhere LOG level info >> > prefix `Shorewall:net2fw:DROP:' >> > DROP 0 -- anywhere anywhere >> > ... >> > ===================================== >> > >> > So my best guess is that there is something wrong >> > with my dovecot configuration. >> > I "yum remove"d and "yum install"ed dovecot >> > (and re-edited dovecot.conf), >> > but that didn't seem to make any difference. >> > >> >> Why not tcpdump it over your ssh session to the server while you try to >> >> connect and see what you can see. >> >> >> >> Another more exotic workaround would be, on your local machine >> >> >> >> ssh root@myserver -N -L993:localhost:993 >> >> >> >> while this runs, 993 (the first number) on your local client box will >> >> magically be an encrypted wormhole to port 993 on myserver. Try running >> >> that in one terminal session, and temporarily alter kmail to go look at >> >> localhost for IMAP instead of myserver. >> > >> > I'll try these tomorrow. >> > Thanks very much for your help anyway. >> > >> >> >> -- >> First Law of Bicycling: >> No matter which way you ride, it's uphill and against the wind. >> > I had a problem with my app/web server listening on "::::80" awhile > back. I'd try to connect (telnet, browser, etc.) and it'd just sit > there. I switched to listen on "0.0.0.0:80" and it all worked like a > charm. I'm terribly ignorant on IPv6 so I can't speak to what the root > problem was, but the work-around did the trick. > > -- *Mark C. Allman, PMP* > -- Allman Professional Consulting, Inc. > -- www.allmanpc.com <http://www.allmanpc.com>, 617-947-4263 > > > > *BusinessMsg* -- the secure, managed, J2EE/AJAX Enterprise IM/IC solution. > -- A child of five could understand this! Fetch me a child of five.
