Help: 908 errors with NT client and linux IFS2000/9.20 server
Posted in 2000
Fuzzy set up an Informix IFS2000 9.20UC1 server on Linux; local dbaccess connections over IPC and TCP worked, but NT clients using Client SDK (2.30/2.40/2.50) with setnet32 and onsoctcp always got -908 "connection refused", even for the informix user. Art Kagel suggested trusted-host entries in /etc/hosts.equiv or .rhosts (already done) and hardwiring IP address and port instead of host/service names, which didn't help — a bogus port gave the same error. Martyn Ayshford suggested telnetting from the client to the listener port; that also failed, showing the server wasn't accepting connections on that port. The thread ends with Fuzzy still asking what was blocking the port, so no resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Server Administration, Security, Permissions & Auditing, Networking & sqlhosts Configuration, Platform-Specific Issues
Argh!
I can't figure out what's going on here.
Set up a IFS2000 9.20uc1 server on linux ... all went well. I've got
ipc and tcp configured (ipc on cpu, tcp on net poll threads).
Connecting on this machine using dbaccess works fine through both ipc
and tcp (sqlhosts is fine, I have an alias for the tcp, and this is
working, thus I know the tcp connection is working). I've set up the
tcp service in /etc/services, and added the client machines to
$INFORMIXDIR/etc/hosts.allow
I've run pwunconv to revert to normal from shadowed passwords
On an NT client (with 2.30, 2.40 or 2.50 client SDK), I configure
setnet32 with the host details, server, service and protocol details
(service and host as per values in hosts and services file on NT
machine that I just put in place for informix ... port numbers and
service names match on linux and NT.) protocol is onsoctcp, as it is
on the linux box.
When I try dbaccess on any client, I'm getting -908 "connection
refused" errors, for all userids, including informix. Any one have
any idea of anything I've overlooked. I think I've covered everything
I can think of. Is there anything wrong with 9.20uc1 that is fixed in
a later release (uc4 ?).
ciao
Fuzzy
:-)
The clients have to be trusted on the server and each user must have a valid
login account on the server. You either have to list each client in
/etc/hosts.equiv or in the .rhosts file in each user's home directory.
Art S. Kagel
Fuzzy wrote:
>
> Argh!
>
> I can't figure out what's going on here.
>
> Set up a IFS2000 9.20uc1 server on linux ... all went well. I've got
> ipc and tcp configured (ipc on cpu, tcp on net poll threads).
> Connecting on this machine using dbaccess works fine through both ipc
> and tcp (sqlhosts is fine, I have an alias for the tcp, and this is
> working, thus I know the tcp connection is working). I've set up the
> tcp service in /etc/services, and added the client machines to
> $INFORMIXDIR/etc/hosts.allow
>
> I've run pwunconv to revert to normal from shadowed passwords
>
> On an NT client (with 2.30, 2.40 or 2.50 client SDK), I configure
> setnet32 with the host details, server, service and protocol details
> (service and host as per values in hosts and services file on NT
> machine that I just put in place for informix ... port numbers and
> service names match on linux and NT.) protocol is onsoctcp, as it is
> on the linux box.
>
> When I try dbaccess on any client, I'm getting -908 "connection
> refused" errors, for all userids, including informix. Any one have
> any idea of anything I've overlooked. I think I've covered everything
> I can think of. Is there anything wrong with 9.20uc1 that is fixed in
> a later release (uc4 ?).
>
> ciao
> Fuzzy
> :-)
On Wed, 04 Oct 2000 15:30:27 -0400, "Art S. Kagel" <kagel@bloomberg.net> wrote: >The clients have to be trusted on the server and each user must have a valid >login account on the server. You either have to list each client in >/etc/hosts.equiv or in the .rhosts file in each user's home directory. > >Art S. Kagel D'oh! Stupid hosts.equiv - I have no idea what I was thinking when I did hosts.allow. At least my other machines now have FTP access :-) Thanks Art Ciao Fuzzy :-)
On Thu, 05 Oct 2000 06:42:20 GMT, granta@nospam.student.canberra.edu.au (Fuzzy) wrote: >On Wed, 04 Oct 2000 15:30:27 -0400, "Art S. Kagel" ><kagel@bloomberg.net> wrote: > >>The clients have to be trusted on the server and each user must have a valid >>login account on the server. You either have to list each client in >>/etc/hosts.equiv or in the .rhosts file in each user's home directory. >> >>Art S. Kagel > >D'oh! Stupid hosts.equiv - I have no idea what I was thinking when I >did hosts.allow. At least my other machines now have FTP access :-) D'oh again ... I had actually done this in hosts.equiv ... it was a typo writing hosts.allow. Still no joy, Art. Any ideas how to troubleshoot which bit could be going wrong? Thanks Fuzzy :-)
Have you tried hardwiring the port number and host's IP address int setnet32 instead of the hostname and service name? Art S. Kagel Fuzzy wrote: > > On Thu, 05 Oct 2000 06:42:20 GMT, > granta@nospam.student.canberra.edu.au (Fuzzy) wrote: > > >On Wed, 04 Oct 2000 15:30:27 -0400, "Art S. Kagel" > ><kagel@bloomberg.net> wrote: > > > >>The clients have to be trusted on the server and each user must have a valid > >>login account on the server. You either have to list each client in > >>/etc/hosts.equiv or in the .rhosts file in each user's home directory. > >> > >>Art S. Kagel > > > >D'oh! Stupid hosts.equiv - I have no idea what I was thinking when I > >did hosts.allow. At least my other machines now have FTP access :-) > > D'oh again ... I had actually done this in hosts.equiv ... it was a > typo writing hosts.allow. > > Still no joy, Art. Any ideas how to troubleshoot which bit could be > going wrong? > > Thanks > Fuzzy > :-)
On Wed, 11 Oct 2000 11:04:13 -0400, "Art S. Kagel" <kagel@bloomberg.net> wrote: >Have you tried hardwiring the port number and host's IP address int setnet32 >instead of the hostname and service name? > >Art S. Kagel tried using IP and port number in both setnet32, and in sqlhosts, and in both at the same time. Still 908 error. Interestingly, putting a completely bogus port in setnet32 also gives 908 error, so I don't know what the story is. I think I'm going mad! Thanks for the help, Art. If you can think of anything else, let me know. Ciao Fuzzy ;-)
On client Try telnet server portno where server is name of your server (or IP address) and portno is the number you setup as your tcp listener. If you see connection refused your server is not listening properly. If you see what looks like the beginnings of a telnet session ( ie a server is answering you) at least you'll know the physical side of the connection process is working. mja In article <39e536af.6541766@newshost.interact.net.au>, granta@nospam.student.canberra.edu.au (Fuzzy) wrote: > On Wed, 11 Oct 2000 11:04:13 -0400, "Art S. Kagel" > <kagel@bloomberg.net> wrote: > > >Have you tried hardwiring the port number and host's IP address int setnet32 > >instead of the hostname and service name? > > > >Art S. Kagel > > tried using IP and port number in both setnet32, and in sqlhosts, and > in both at the same time. Still 908 error. Interestingly, putting a > completely bogus port in setnet32 also gives 908 error, so I don't > know what the story is. I think I'm going mad! > > Thanks for the help, Art. If you can think of anything else, let me > know. > > Ciao > Fuzzy > ;-) > > Sent via Deja.com http://www.deja.com/ Before you buy.
On Wed, 18 Oct 2000 10:22:20 GMT, martyn.ayshford@orange.co.uk wrote: >On client > >Try telnet server portno > >where server is name of your server (or IP address) and portno is the >number you setup as your tcp listener. > >If you see connection refused your server is not listening properly. Martyn, you're a life-saver! Yes, trying to telnet to server portno fails with a connection refused error. Now the obvious question is, what's preventing connections on that port, and how can I change this? I'm assuming this is somewhere in one of my tcp/ip config files on the server (something like hosts.allow, hosts.deny, or some such beast), but I can't for the life of me think where to look. Any ideas? Thanks Fuzzy :-)