Socket Error While Reading PDU

1,514 views
Skip to first unread message

Daniel Howard

unread,
Jan 30, 2014, 8:50:27 AM1/30/14
to fo-d...@googlegroups.com
I am using the SCP Example to test receiving files from a FUJI PACS (Synapse 4.1).  Every time a study is sent to the FO-Dicom SCP, it logs the error in the console: "Socket error while reading PDU: ConnectionReset [#####]"

 If you send directly from a Modality it stores without issue. Any tips on why this might be happening? Thanks as always!
Message has been deleted

Daniel Howard

unread,
Feb 1, 2014, 7:05:01 PM2/1/14
to fo-d...@googlegroups.com
I performed a WireShark capture on the connection while the Fuji PACS sent a study to the FO-Dicom SCP Example. It appears there is something about "Early termination of tag data"  (see attached screenshot) when the FO-SCP (192.168.102.5) sent back a P-Data back to the PACS (172.21.3.31). Based off this additional feedback anyone have an idea what might be wrong? Thanks as always!
Fuji- Fo-DicomSCP WireShark Captue.PNG

Daniel Howard

unread,
Feb 1, 2014, 9:46:14 PM2/1/14
to fo-d...@googlegroups.com
I have more to share with this issue. I setup storescp from DCMTK and sent a couple of studies from the Fuji PACS. The studies stored without issue. I then used the DCMTK storescu and pushed the stored studies to the Fo-Dicom SCP example and received the following error/warning from the DCMTK storescu:

W: DIMSE Warning: (STORESCU,OBSIDIAN): sendMessage: unable to convert dataset from 'JPEG Lossless, Non-hierarchical, 1st Order Prediction' transfer syntax to 'Little Endian Explicit'
E: Store Failed, file: D:\DCMTK_StoreAssoc1_1.2.840.113845.11.1000000002090985487.20130726142618.9381422\US.1.2.840.113663.1500.1.323676173.3.9.20130726.161257.500:
E: 0006:020e DIMSE Failed to send message

I checked in the FO-Dicom library and this transfer syntax is supported. Is this a possible bug in the library? Thanks!

Chris Horn

unread,
Feb 3, 2014, 2:13:33 AM2/3/14
to fo-d...@googlegroups.com
have you checked the conformance statement for theFuji PACS?

I've found that certain vendors are harder to work with than others and sometimes require specific tweaks to make work, or assistance from the vendor directly ( for a fee )

but just to cover the basics,
connection time out value is set to a reasonable value?
DIMSE time out set to a reasonable value?
Socket time out set to a reasonable value?
can you verify the connection?
do you have issues if you try and do DICOM Echo?

Colby Dillion

unread,
Feb 4, 2014, 2:31:20 PM2/4/14
to fo-d...@googlegroups.com
Can you upload or email me a sample image?

Colby Dillion

unread,
Feb 4, 2014, 2:32:51 PM2/4/14
to fo-d...@googlegroups.com
A copy of the fo-dicom log of the transfer would also be helpful.
Message has been deleted

Daniel Howard

unread,
Feb 4, 2014, 10:45:11 PM2/4/14
to fo-d...@googlegroups.com
Chris,

Thanks for the suggestions!! I have briefly looked over the conformance statement, but I don't see anything glaring that would be causing the issue.

I don't doubt that Fuji will try to charge for the least bit of help or information :-)

As for checking the connection and timeout settings, I unfortunately haven't had access these past few days as the PACS Admin has been out. I will check these settings when the admin is back in the office and let you know my findings. Thanks again for all your help!

Daniel Howard

unread,
Feb 4, 2014, 11:30:15 PM2/4/14
to fo-d...@googlegroups.com

Colby,

Thanks for the response! As requested, I have attached the FO-Dicom log entry of the transaction and a sample image (anonymized). Please let me know if you need further information and I will gladly supply it.

By the way, I have one other observation that I want to mention that is probably related to this issue. I have an application (using the library) that loops through sub folders in the main directory and reads the tags of the first DICOM file in each sub-folder. It then pauses for 3 seconds after the last sub-directory is read and then loops through the main directory again. It will normally run forever without incident when reading DICOM images, but if I put these Fuji Dicom files in the directory, it eventually crashes with the following error (see attached screen shot): "Cannot Access A Closed File".

If you need me to post the code of what I am doing, I will be happy to do so,  but it has not failed me until adding these Fuji DICOM images. Thanks again for you help!

dicom.dcm
Fuji To FO-Dicom Log.txt
Fuji Induced Closed File Read Error.PNG

gnRk108

unread,
Feb 6, 2014, 9:05:26 PM2/6/14
to fo-d...@googlegroups.com
I think it has to do with Transfer Syntax.
Meanwhile you can default to "ImplicitVRLittleEndian" instead of "ExplicitVRLittleEndian".

Daniel Howard

unread,
Feb 10, 2014, 2:07:26 PM2/10/14
to fo-d...@googlegroups.com
gnRk,

Thanks for your post! Forgive my ignorance, but how would I go about making ImplicitVRLittleEndian default? I commented out the other two transfer syntax and I am still have the same issue, is that what you were suggesting. Thanks again for your help!

Daniel Howard

unread,
Feb 16, 2014, 9:59:59 AM2/16/14
to fo-d...@googlegroups.com
Colby,

I just wanted to check in and see if you had a chance to take a look at this issue. Thanks as always for your hard work!

Colby Dillion

unread,
Feb 27, 2014, 11:58:09 AM2/27/14
to fo-d...@googlegroups.com
Hi Daniel,

There does not seem to be any issue with the image itself. I was able to test transferring studies from a Synapse PACS and was able to reproduce this error several times. It looks as though the PACS is sending the association release request but not keeping the connection open to receive the association release response. It is safe to ignore the error, though I'm sure we could add some logic to suppress it.

Colby

Mikahl M.

unread,
Apr 29, 2014, 10:19:23 AM4/29/14
to fo-d...@googlegroups.com
I am having DIMSE timeout errors (180seconds) at random on all of my Sonosite M-Turbos and multiple Facilities.  Also having PDU-read errors.  How could I modify the DIMSE timeout or Socket Timeout?
On the M-Turbos themselves the logs are full of: T-Socket Timeout errors when auto-querying the worklist every 30minutes.
These errors occur daily.

Victor Fredes

unread,
May 18, 2016, 6:16:31 PM5/18/16
to Fellow Oak DICOM
Hi Daniel, did it solve the problem?
Reply all
Reply to author
Forward
0 new messages