Unable to make remote client connection with error 1055

S

sgd123

New Member
We are using Progress 8.3c version for MFGPro version 9.0. Users connect from their windows desktop using MFGPro 9.0 US English GUI client remotely to the database on Red Hat Linux 7.3. We have started the database in -H -S -N mode with -Mn=6, -Ma=1 & -n=10 and users are able to make remote connections & do their day-to-day operations. But sometimes we get following weird error resulting into cur. users field of _Server VST going negative (-49 or -50) as seen thru promon. And we are left with no choice but restart the database.

Server's received count 1 does not equal client(1)'s send count 1414744096. (1055)
I know that we are using the older version of Progress but if sombody is aware of any solution or any workaround on this, kindly share with us. It is highly appreciated. Thanks in advance for your replies.
Thanks and Regards,
Santosh
 
This KB article suggests a 1055 error can be caused by a port scanner or other application that connects to the DB server on a server port.

Does this issue happen often? And if so it it always the same port? One diagnostic option is to run a packet trace on your DB server to capture network traffic on the server ports. Then review the trace to look for any IP addresses that do not belong to DB clients. Alternatively, if you have a firewall between the server and clients you could review its logs for the same information.
 
You should use -minport and -maxport when starting the database broker to explicitly define a port range for the remote servers.

In the past we had issues with port scanners resulting in similar error messages that you describe. You should check with your network guys ( I know they are sometimes hard to work with ) and define a port range on firewalls and port scanners that is save for you to use so that your application is not disrupted.

Heavy Regards, RealHeavyDude.
 
RealHeavyDude said:
You should use -minport and -maxport when starting the database broker to explicitly define a port range for the remote servers.

In the past we had issues with port scanners resulting in similar error messages that you describe. You should check with your network guys ( I know they are sometimes hard to work with ) and define a port range on firewalls and port scanners that is save for you to use so that your application is not disrupted.

Heavy Regards, RealHeavyDude.
Click to expand...

Thanks Dude for reply,
In fact we have already defied a port range of 10 ports per database using -minport & -maxport parameters and a given range of ports is dedicated to each database. They are not using any port scanners on the server. Could this be caused by MFGPRO GUI client software installed on each user's desktop? I do not know if only one particular user getting this issue or it's coming randomly for any user as such. We have six remote users making GUI (4GL REMC) client connections. I will have to check this. Will it help if we double the -n value from 10 to 20?
Thanks and Regards,
Santosh
 
sgd123 said:
Thanks Dude for reply,
In fact we have already defied a port range of 10 ports per database using -minport & -maxport parameters and a given range of ports is dedicated to each database. They are not using any port scanners on the server. Could this be caused by MFGPRO GUI client software installed on each user's desktop? I do not know if only one particular user getting this issue or it's coming randomly for any user as such. We have six remote users making GUI (4GL REMC) client connections. I will have to check this. Will it help if we double the -n value from 10 to 20?
Thanks and Regards,
Santosh
Click to expand...

While your -n is quite low, if it were the cause of clients being unable to connect you'd see a different error.

When this issue happens do you track which port the affected server was listening on? Is it more than one server at a time, or only one? Is it different ports, or always the same one? If it's a single port it would suggest some non-Progress client application connecting to the DB server and confusing it.
 
Thanks Rob for your reply,
We have already confirmed with system person that there is no port scanned software running on the server. I have asked for running the packer trace on the server anyways. I have a doubt if they get any IP address not belonging to DB clients. Moreover we are using dedicated ports per database and I hope there is no port conflict on the server. Awaiting reply. Thanks.
Regards,
Santosh
 
What happens if you extend the minport/maxport ranges to 100 port numbers for each server?
 
sgd123 said:
Moreover we are using dedicated ports per database and I hope there is no port conflict on the server.
Click to expand...

It doesn't sound like there is any port conflict. That could result in the broker being unable to spawn a server which is not the problem you describe. You describe a server that is running and, presumably, cannot accept a connection from a client. Is there any other information available in the DB log at the time of the issue that sheds light on a possible cause? Also, you indicate that there are multiple DBs on this machine. Do they all exhibit the described symptoms, or just one?

As I said, if I were you I'd run tcpdump and capture traffic to see what's happening on the network. You may also have to face the possibility that this is an unpatched bug in your version of Progress and you just have to live with the DB restarts.
 
Not only do we use -minport and -maxport but we also needed to change the port range in order to avoid conflicts with the port scanner. From the Progress application point of view you only need to change it at the database startup - although you might need to change it in firewall definitions and network related software too.

In our case the port scanner was scanning only particular ports in the network because on other machines ports out of the port range defined for the Progress database were used by a different technology which was suspected to be responsible for data leaks.

Heavy Regards, RealHeavyDude.
 
You must log in or register to reply here.
Back
Top