mdsip.hosts file does not working in mdsip

[ahaglory]

Affiliation
What University / Laboratory / Company are you from, if any?
KFE - KSTAR
Version(s) Affected
The MDSplus Version(s) affected, if any.
All (Test ver : 7_131_6 & 7_132_0)
Platform
The Operating System you're running on.
Rocky Linux 8.5
Describe the bug
A clear and concise description of what the bug is.

It is possible to plot data on the client even if all contents delete of the '/etc/mdsip.hosts' file.
Even if the mdsip error log file says 'Access denied', I can plot the data on the client.
So, I confirmed that there was an error in line 559 'status= SendMdsMsgC' of the 'mdstcpip/mdsipshr/Connections.c' file on github.
After removing 'status' from the "Connections.c" file and testing mdsip, data access was blocked normally.

Could you please check this?
To Reproduce
Steps to reproduce the behavior:

1. Yum install el8 version on Linux Rocky 8.5
2. run : rpm - post_install_script & setup.sh
3. edit /etc/xinetd.d/mdsip (disable yes -> no) and setup tree path
4. delete and comment out in /etc/mdsip.hosts
5. Other PC - jScope -> connect and plot data

Expected behavior
Even if the mdsip error log file says 'Access denied', I can plot the data on the client.
After removing 'status' from the "Connections.c" file and testing mdsip, data access was blocked normally.

Screenshots
n/a

Additional context
When source compiling the mdsplus stable version, the version information is displayed as '0.0.0' using mdstcl, and the contents of the ChangeLog file are empty.

[mwinkel-dev]

Hi @ahaglory -- Thanks for submitting this issue. We are busy with other projects during the week of November 13 - 17, but should be able to investigate this issue within a few days.

[mwinkel-dev]

Hi @ahaglory -- Apologies for the delay. (We've been very busy lately.) I am now working on this issue and will see if I can reproduce it today.

[mwinkel-dev]

Here is a conjecture about the likely root cause of this issue . . .

Based on an inspection of the source code, the likely issue is that the SendMdsMsgC() call is returning status of SsINTERNAL. (The mdstcpip/mdsipshr/SendMdsMsg.c file defines SendMdsMsgC() which in turn calls send_bytes() -- also defined in the same file -- which can return SsINTERNAL.).

Note that SsINTERNAL = -1 and does not conform to the usual definition of a MDSplus status code. Although the -1 is used to denote a severe internal error, its low order bit is set. And thus the STATUS_OK macro treats SsINTERNAL as a variant of "success".

Proper handling of SsINTERNAL requires logic similar to that seen in the SendMdsMsg() routine (see the SendMdsMsg.c source file).

If the above conjecture is correct, then the Connections.c file should retain the status = SendMdsMsgC(c, msg, 0) line. However, that line should be followed by an if statement to process a status of SsINTERNAL similar to that found in the SendMdsMsg() routine.

[mwinkel-dev]

Next steps in fixing this bug . . .

1. reproduce the issue, and
2. investigate the conjecture in the preceding post.

[mwinkel-dev]

Hi @ahaglory,

What version of MDSplus are you running on your PC? Are both computers -- the PC and the mdsip Server -- running the same version of MDSplus?

If they are different versions, then I will have to change my computers accordingly to investigate this issue.

Tonight, I used two computers running the same version of MDSplus alpha, and was unable to reproduce the problem you reported. (Although the conjecture I made two posts above is not the root cause, there is indeed an issue with SsINTERNAL that also needs to be fixed.)

[mwinkel-dev]

Hi @ahaglory -- The root cause of the bug you reported is likely caused by having mismatched versions of MDSplus -- that the PCs are running an older version than the version your are running on your mdsip server.

Note that the message header data structure has evolved over time. For example in the stable_6_1_9 version, the MsgHdr structure contained an int fill; field. However in the current alpha, that field is absent from MsgHdr.

Thus the best conjecture is that the line that you flagged as the issue (i.e., the status = SendMdsMsgC(c, msg, 0); at line 559 of Connections.c) is failing -- it repeatedly tries sending a message to the older MDSplus software on the PC, gives up after ten tries, and returns a SsINTERNAL status. Which as described above is not being processed properly -- it is being treated as a variant of success, and then the code goes ahead and erroneously creates the connection.

If this conjecture is correct, then the solution involves changing two things.

• The SendMdsMsgC() statement will be retained, but will be followed by an if statement to check for the SsINTERNAL status and process it properly.
• And when installing new versions of MDSplus at your facility, the same version of MDSplus should be installed on server and client computers. For example, when testing MDSplus 7_131_6 on the data archive server, the client PCs should also be running version 7_131_6.

Later this week, I will submit a PR to add the proper processing of the SsINTERNAL status code.

[mwinkel-dev]

Injecting faults into the source code still didn't reproduce the bug. Although forcing the condition that returns the SsINTERNAL does indeed cause the code to erroneously create a connection, the failure signature (log files, behavior, etc.) is different than described in the initial bug report. So, perhaps the above conjecture isn't the complete explanation.

Please provide additional information: version of software on PC, and whether any additional error messages appeared on the screen or in the mdsip log files (typically located in /var/log/mdsplus/mdsipd).

Note that my experiments have used the current alpha. I will repeat them with the current stable.

[ahaglory]

Hi, Sorry for the late reply.
In 'SendMdsMsgC', the return value is always OK as the transmission is successful.
Regardless of the result of the verification of 'authorize client' (1 - line 538) above, the status value is overwritten at line 559.

Please check the source code again.

Thank you for your hard work, it is greatly appreciated.

[mwinkel-dev]

Hi @ahaglory,

Thanks for the clarification! You are correct about the source code (lines 538 versus line 559 of the mdstcpip/mdsipshr/Connections.c file).

The puzzle now is figuring out why this failure did not arise in my experiments. Today, I will repeat my experiments, but with additional test cases.

Please let me know if you are using different versions of MDSplus on your server than on your client workstations. (My testing has only been with the same version of MDSplus on both server and client.)

[mwinkel-dev]

Hi @ahaglory,

On the server side, if a user is not authorized (by the mdsip.hosts file), the server sends a "failure" status to the client.

On the client side, if a message is received that contains the "failure" status, the client kills the connection. Which presumably affects the server side too.

In all client-server software, it is important to have compatible versions of software on both client and server. I will do more experiments to determine if the source code lines you have identified are truly failing when both client and server are running the same version of software. (It is possible that there is indeed a bug.)

I will also experiment with creating the equivalent of mismatched protocols on client and server, to see if that will enable me to reproduce this issue.

[mwinkel-dev]

Hi @ahaglory,

The bug you reported has now been reproduced with the current alpha.

The problem with my previous experiments was that the bug was being masked. The client software was disconnecting because the user was unauthorized. So, I incorrectly assumed that the server was not saving the connection.

The addition of some debug print statements in the server code proves that even though the user is unauthorized, the connection is erroneously being saved. Output of the debug print statements follows.

Access denied: markw
XMW *********************
XMW SERVER - status before SendMdsMsgC: 0      # the zero indicates authorization failure
XMW SERVER - message header status field: 0    # client is being notified of the authorization failure        
XMW SERVER - status after SendMdsMsgC: 65545   # client displays error, but server receives MDSplusSUCCESS
XMW SERVER - before add connection             # thus server saves the connection even though it shouldn't

Now that the issue has been reproduced, the fix will be trivial. It will be ready as soon as the maintenance work is finished on the Jenkins build server. (The fix will also include the correct code to handle the SsINTERNAL error code.)

ADDENDUM: Although the server side is erroneously adding the connection, still unable to access information using that connection. (Have two identical Rocky 9.3 VMs running the current version of alpha.) No luck getting jScope to plot data as described in the initial bug report. Also unable to access data using a custom C program. Similarly,mdstcl also is unable to access data. Thus, there is still a possibility that different versions of software on the server and the PC might be a factor in this bug. Regardless, a fix will be made to eliminate the erroneous saving of the unauthorized connection.

[mwinkel-dev]

Was able to force jScope to behave as described in the initial bug report. However, that required crippling the client-side software. Had to disable the code in the client that handles the authorization error returned by the server.

Perhaps similar issues can arise if the PC running jScope has an older version of MDSplus than is running on the mdsip server.

Regardless, there is indeed a bug on the server side that needs to be fixed.

[mwinkel-dev]

Hi @ahaglory,

The fix for this issue is now available in alpha_release-7-139-67. You can obtain that release from the GitHub site.
https://github.com/MDSplus/mdsplus/releases

And after we complete some maintenance work on our build server, you will also be able to obtain it from the package repository on the mdsplus.org web site as per usual.