Orthanc Not Sending Studies to Q/R Nodes Using Their Defined Port

[simon_kidd1]

Hello Orthanc group

My questions is, are there any tools in Orthanc I could use to better troubleshoot what Orthanc is doing when it connects back to nodes requesting studies (see below for the why)?

I’ve ran the service with verbose logging, but it gave me nothing new to work with:

sudo -u orthanc /usr/sbin/Orthanc --verbose /etc/orthanc/ 2>&1 > Orthanc.log

I0130 08:19:02.732690 CommandDispatcher.cpp:332] (dicom) Association Received from AET MVM-EB-V18—1 on IP —.—.—.—
I0130 08:19:02.732772 main.cpp:314] Incoming connection from AET MVM-EB-V18— on IP —.—.—.—, calling AET ----STORE
I0130 08:19:02.732997 CommandDispatcher.cpp:657] (dicom) Association Acknowledged (Max Send PDV: 116782)
I0130 08:19:02.733873 main.cpp:336] Incoming Move request from AET MVM-EB-V18— on IP —.—.—.—, calling AET ----STORE
W0130 08:19:02.733910 CommandDispatcher.cpp:811] Rejected Move request from remote DICOM modality with AET “MVM-EB-V18—” and hostname “—.—.—.—”
I0130 08:19:02.733923 CommandDispatcher.cpp:928] (dicom) DIMSE failure (aborting association): DIMSE Caller passed in an illegal association

Here’s my core issue in more detail

• The Orthanc Server: 'Orthanc’ or MVM-EB
• My workstation with a DICOM viewer: MVM-EB-18

My Orhtanc instance has suddenly started to send studies, requested by all viewer nodes, back to them using the wrong send port. Essentially using the random high port used in the initial request for a study to send it back to the requesting node.

The funny part is, I can still send studies TO Orhanc just fine to the server with no issues AND I can query Orthanc and get a list of available studies to retrieve, I just can’t download them.

I have a config file that clearly defines port 104 from Orthanc back to my requesting VM which has worked perfectly fine for over a year until 14 of December last year, the day before the Orthanc VM was moved into a new infrastructure instance by out hosting team; they are claiming no fowl on their part.

Although I clipped it off in the above screen grab, that section is terminated correctly with },

I have a local FW rule that allows ALL port and ALL protocols from the Orthanc server and I can telnet from the server to the node on the port, but if the returning port is not correct, then the requesting DICOM viewer will never receive the study.

I know this is a strange issue and very likely nothing to do with Orthanc itself, I can’t see anything in the config file that could even do this to the outgoing traffic other than the defined port under DicomModalities section of the orthanc.json file.

Kind regards,
Simon

[simon_kidd1]

I’ll also add that I have a dedicated all ports all protocols route setup by our networking team between the server and the client.
The server is running Orthanc 1.9.0

[alainmazy]

Hi Simon,

It’s very difficult to analyse your problem even with the detailed information you have provided.

Right now, I can only advise you to launch orthanc with --trace-dicom option (introduced in v 1.8.1) that should show you detailed information from DCMTK (same output as the DCMTK CLI tools)

Hope this helps,

Alain.

[BNOEAFK]

It may also help to run wireshark (or similar) and filter between Orthanc and the nodes to confirm what ports are being used between the two. Also check any (potentially new?) networking hardware between the two, including virtualized appliances?

[simon_kidd1]

Thank you both for your input, very helpful in what it a very strange situation. I unfortunately don’t have any access to the routers or VMware layer but I’ve certainly passed a lot of detailed packet captures to that team.
If I find a resolution, I’ll post it here in the rare chance someone else might experience something similar.

best regards,
Simon

[BNOEAFK]

Simon,

>DIMSE Caller passed in an illegal association

I'm sure you realize this, but I would believe it's this illegal association is the key to your issues. It would be interesting to see if a specific modality is making a request of Orthanc (AET / port / IP address / transfer syntax) that Orthanc isn't able to process...

[simon_kidd1]

Yes, that error was recorded because Orthanc was sending the studies back to the requesting viewer PCs using their requested high-port number and NOT the DICOM port the devices were configured to listen on. Working with my duplicate test server I have managed to figure out what it might’ve been doing and a workaround!

On the live service I am using Postgres and the Postgred plugin to manage transactions, I was also using [DicomModalitiesInDatabase =“TRUE”]. After the VM move it’s possible the database may have started recording the dynamic high ports from the devices query/retrieve requests against the device records in the database (a working theory, but not sure if that’s what that setting means).

As soon as I disabled [DicomModalitiesInDatabase] and used the [DicomModalities] list in orthanc.json I’m now able to Q/R. Using orthanc.json to manage access isn’t a problem at all, TBH, I didn’t really know how the database setting worked regarding device records, perhaps another setting has conflicted with it somehow.

Definitely a head-scratching experience and not over yet. If I find more detail on this I’ll post it here for future posterity.

Thanks again.
Simon