Unknown PDU 47 upon retrieving DICOM data with Weasis via RESTful API

Hallo,
some time ago I wrote a Python plugin for handling GDT in-/output in Orthanc and built a Docker image for that.
To view studies, I’m using Weasis which is also tied to the primary software we use in our practice for record keeping. To instruct Weasis to open a specific study, we use the Weasis $dicom:rs-command on startup which causes Weasis to request a specified study via DICOMweb RESTful-API from the specified PACS.
While everything in my practice works as intended since more than a year, a colleague using exactly the same Docker image as I (but running under Windows / Docker Desktop) and the same Weasis version (3.6.2, but more recent versions don’t work, too) can’t make Weasis to open the specified study.
Orthanc log shows this error and Weasis opens blank without any images:

E1119 07:38:35.119756 CommandDispatcher.cpp:284] Receiving Association failed: Unrecognized PDU type: 47

Doing a manual DICOM Q/R in Weasis for the study works and he can view the requested study.

What does this error mean and what can we do to fix it?

Thanks for your help and Best regards!
Julian Hartig

Hi,

The error seems to indicate an invalid DICOM connection.

I’m a bit puzzled because, in your message, you talk about dicom-web and this error is a DICOM protocol error. Are you sure that your first command is not trying to issue a Dicom-web command on the DICOM port instead of the HTTP port ?

That might be useful to collect logs in verbose/trace mode to better identify the issue.

HTH,

Alain

Hallo Alain,
I’m puzzled as well. The command string for Weasis is

$dicom:close -a $dicom:rs --url “http://192.168.0.115:8090/dicom-web” -r “studyUID=2.25.33715171646343948261559108481944301396”

which should close all open studies and then use DICOMweb to retrieve the specified study. Port 8090 points to the web interface (which is reachable without problems by web browser), DICOM would be port 105 in this setup. Also, I’m using another REST request to Orthanc beforehand to retrieve the studyUID I’m using for the invocation of Weasis. The request goes to same IP and port and is answered as expected.
I will instruct my colleague to run Orthanc with trace output and hope this will give us some insight on the cause of the problem.

Thanks!
Julian Hartig

Hallo,
I’m now able to provide some further log output my colleague acquired. Alas, I’m afraid that it doesn’t seem to help much, at least not for me. This first excerpt is from Orthanc in debug mode:

T1119 13:11:12.316479 HttpServer.cpp:728] HTTP header: [host]: [192.168.0.115:8090]
T1119 13:11:12.320096 HttpServer.cpp:728] HTTP header: [content-length]: [111]
T1119 13:11:12.320181 HttpServer.cpp:728] HTTP header: [content-type]: [application/x-www-form-urlencoded]
I1119 13:11:12.325333 HttpServer.cpp:813] POST /tools/find
I1119 13:11:12.383637 ServerContext.cpp:958] Number of candidate resources after fast DB filtering on main DICOM tags: 1
I1119 13:11:12.385961 ServerContext.cpp:1095] Number of matching resources: 1
T1119 13:11:15.469768 ServerContext.cpp:225] Serializing the content of the jobs engine
T1119 13:11:15.943078 Connection.cpp:388] SQLite::Connection::FlushToDisk
E1119 13:11:16.793845 CommandDispatcher.cpp:284] Receiving Association failed: Unrecognized PDU type: 47
E1119 13:11:16.822159 CommandDispatcher.cpp:284] Receiving Association failed: Unrecognized PDU type: 47
T1119 13:11:20.978823 Connection.cpp:388] SQLite::Connection::FlushToDisk
T1119 13:11:25.538636 ServerContext.cpp:225] Serializing the content of the jobs engine

What we’re seeing here is at 13:11:12 a request by my PHP script to the tools/find REST-API to acquire a valid StudyUID for a given combination of patient, date and time. This request is answered as expected and a StudyUID is returned by Orthanc. At 13:11:16 we’re seeing the result of the attempt of Weasis to request image data of said study via DICOMweb.
The next bit is from the debug log of Weasis:

22.11.2021 18:54:16.287 DEBUG [Dicom Model-pool-3-thread-1] org.weasis.dicom.explorer.rs.RsQueryResult: QIDO-RS request: http://192.168.0.115:8090/dicom-web/studies?0020000D=2.25.168637000477662725344906985996927558964&includefield=00080020,00080030,00080050,00080061,00080090,00081030,00100010,00100020,00100021,00100030,00100040,0020000D,00200010
22.11.2021 18:54:16.365 ERROR [Dicom Model-pool-3-thread-1] org.weasis.dicom.explorer.rs.RsQueryResult: QIDO-RS with studyUID 2.25.168637000477662725344906985996927558964 org.weasis.core.util.StreamIOException: java.net.SocketException: Unexpected end of file from server
at org.weasis.core.api.util.NetworkUtil.prepareConnection(NetworkUtil.java:104)
at org.weasis.core.api.util.NetworkUtil.getUrlConnection(NetworkUtil.java:72)
at org.weasis.dicom.explorer.rs.RsQueryResult.parseJSON(RsQueryResult.java:130)

Invoking exactly the same URL as Weasis uses for its request in a standard web browser yields in JSON encoded information on the images etc. of the given study, as would be expected. I don’t know why Orthanc behaves differently upon the request of Weasis compared to the “manual” request with the same URL via web browser. I think the next thing we’ll try is a packet capture to see what’s going wrong here.

Best regards,
Julian Hartig

Hi Julian,

I just tried to open http://localhost:4242 in a browser (where 4242 is my DicomPort) and here’s what I have in the logs (sounds familiar :slight_smile: ):
E1124 08:31:26.142508 CommandDispatcher.cpp:283] Receiving Association failed: Unrecognized PDU type: 47

So, it seems that, somehow, weasis is mixing ports or you have ‘something’ that redirects a port to another but I’m pretty sure that this is not Orthanc related.

I’m afraid I can’t help any further …

Best regards,

Alain.

Hallo Alain,
thanks for your help so far.

Just to finish this up - a packet capture revealed that indeed Weasis was trying to issue a HTTP GET-Request to Orthanc’s DICOM-Port (105 in this particular setup). My colleague did configure a DICOM node manually in Weasis, but even deleting this didn’t solve the problem. Removing all settings / the complete .weasis-folder however did it - now everything works as intended.
Funny though, as even in the GET request’s URL Weasis specified http://: correctly but used the wrong port for connecting Orthanc nevertheless…

Best regards,
Julain Hartig