Comments (13)
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.
from mdsplus.
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.
from mdsplus.
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.
from mdsplus.
Next steps in fixing this bug . . .
- reproduce the issue, and
- investigate the conjecture in the preceding post.
from mdsplus.
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.)
from mdsplus.
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 anif
statement to check for theSsINTERNAL
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.
from mdsplus.
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.
from mdsplus.
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.
from mdsplus.
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.)
from mdsplus.
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.
from mdsplus.
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.
from mdsplus.
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.
from mdsplus.
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.
from mdsplus.
Related Issues (20)
- Is it possible to limit the amount of concurrent connections of a specific user HOT 3
- Have TCL's `show version` command also display the build date HOT 1
- In `tdi/RfxDevices/DIO2` initialization, remove the flag that triggers a TDI `abort()` on a failed connection HOT 1
- Error reporting when using function mdsvalue in Matlab which version——stable_release-7-142-80 HOT 14
- Source repo contains obsolete public key for RPM packages HOT 2
- Wrong number of child nodes in python TreeNode.getChildren()
- add timestamps, client ip & name, pid to mdsip error logs, equivalent to "access" logs HOT 1
- assign priorities to incoming mdsip connections HOT 1
- intermittent failure to connect to MDSplus server HOT 2
- enable linking MDSplus to custom python conda environments, and NOT system-wide python HOT 2
- errors importing MDSplus with numpy 2.x HOT 1
- Stable 7.142.80, Windows: server does not accept incoming conenctions (Attempting to duplicate socket from pid 8660 socket 380) HOT 7
- Source code has outdated MIT License, so eventually should replace with current MIT License HOT 1
- RHEL manual builds done locally (not on build server) fail because incorrectly expects an RPM signing key HOT 1
- Existing MATLAB scripts are broken by changes in class/type caused by APD changes.
- Make `mdsip` logging compatible with the automatic log management features provided by the operating system HOT 1
- Python documentation on mdsplus.org broken. HOT 5
- Uninstalling MDSplus on RHEL systems fails to remove the MDSplus signing key from RPM's key manager HOT 2
- Error installing `mdsplus-python` package on RHEL7
- another trouble with numpy 2.x
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mdsplus.