The traditional storage provider (listener) in the Slicer release is implemented using dcmtk’s storescp and yes, it responds to echo for me:
$ echoscu -v localhost 11112
I: Requesting Association
I: Association Accepted (Max Send PDV: 16372)
I: Sending Echo Request (MsgID 1)
I: Received Echo Response (Success)
I: Releasing Association
If you use ps on linux I can see the listener running with these arguments. You can just run the same or similar commands outside of Slicer for debugging.
.../Slicer-5.5.0-2023-11-15-linux-amd64/bin/../bin/storescp 11112 --accept-all --output-directory /mnt/timc-batch2/data/db2/incoming --exec-sync --exec-on-reception /mnt/timc-batch2/Slicer-5.5.0-2023-11-15-linux-amd64/bin/../bin/dcmdump --load-short --print-short --print-filename --search PatientName "/mnt/timc-batch2/data/db2/incoming/#f"
You could try echoscu like this from localhost or from a different machine to see if the ports are working.
If pynetdicom had existed when Slicer’s dicom networking was implemented we might have used that, but it’s also kind of nice that these kind of connection issues can be debugged independently with just the command line tools, and also using the separate process makes it event driven (networking doesn’t block the UI). I see that pynetdicom also provides a way to run it’s storescp as a command line tool so that might help for testing. It should also be possible to install pynetdicom directly in Slicer’s python.
Things may be different too with the new dicom browser that’s available in the Preview version of Slicer.
Good luck - debugging these dimse connections can be a pain so ask follow-ups as needed and report back what you find so it will help others in the future.