Can't connect to IDS9.21 from a Linux client

can you connect to your database-server at all, lets say with telnet or ftp? if not, did you secure your database server in an excessive way using encrypted passwords or whatever?

we are using several linux systems which interact with eachother after placing /etc/hosts entries on the server site without any problems.

You did not say, if you checked your $INFORMIXHOME/etc/sqlhosts file and /etc/services respectively.

what exactly changes in the errorlog, when you make an /etc/hosts entry on the server?
is there a user account for the clientuser on the database server?

Thanks for your reply.
If I stop the server, then start it in a console, error messages are displayed directly in the console when I try to connect from the Linux client-
listener thread error = -956; oserr = 0; errstr = (root@dyn076.mydomain.com); client host or user (root@dyn076.mydomain.com) is not trusted by the server

The server /etc/hosts file includes-
194.131.70.234 dyn076.mydomain.com

and when I tried changing the above to root@dyn076.mydomain.com , the error log message changed, reporting root@root@dyn076.mydomain.com as the errstr and user name(!) dyn076.mydomain.com is definitely the client machine's name as this is displayed when I ping the Informix server from the client.

I have also found that I cannot ftp or telnet the server- I get 'connection refused'. I also tried ftp-ing as a non-root user with the same effect.
I did the default install for the server, so there is no additional password encryption to my knowledge.

I based the $INFORMIXDIR/etc/sqlhosts and /etc/services entries on the equivalent Windows client entries (which does connect to the server)

I have tried connecting to the server as informix and my own username, both of which work from the Windows client.
It just seems like the server refuses to recognise the linux client machine.

Thanks again for your help.
Gary

This may not be the complete solution but we can connect from Linux now. We can now connect by logging on to the client machine as a non-root user.
I read somewhere that DHCP may have been preventing the client machine from connecting to the host. Although our network is still running DHCP and the connection succeeds.