Issue with storescp and "promiscuous" mode

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
bmoloney
Posts: 10
Joined: Wed, 2011-09-07, 00:38

Issue with storescp and "promiscuous" mode

#1 Post by bmoloney »

Hello,

I am not entirely sure if this is a bug in DCMTK, but it does seem like it.

For one of our network nodes (a PACS) I always get an error after storing the first image when I send to a storescp process started with promiscuous mode. The error does not occur when not in promiscuous mode (or when I use a config file that lists the non standard SOP classes explicitly)


Code: Select all

$ storescp -d -pm 12345
D: $dcmtk: storescp v3.6.0 2011-01-06 $
D: 
D: setting network receive timeout to 60 seconds
D: PDU Type: Associate Request, PDU Length: 347 + 6 bytes PDU header
D:   01  00  00  00  01  5b  00  01  00  00  4d  4f  4c  4f  4e  45
D:   59  50  43  43  43  20  20  20  20  20  41  49  52  43  50  41
D:   43  53  20  20  20  20  20  20  20  20  00  00  00  00  00  00
D:   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
D:   00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
D:   32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
D:   31  2e  31  20  00  00  38  01  00  ff  00  30  00  00  19  31
D:   2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  35  2e  31
D:   2e  34  2e  31  2e  31  2e  34  40  00  00  13  31  2e  32  2e
D:   38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31  20
D:   00  00  4d  03  00  ff  00  30  00  00  19  31  2e  32  2e  38
D:   34  30  2e  31  30  30  30  38  2e  35  2e  31  2e  34  2e  31
D:   2e  31  2e  34  40  00  00  11  31  2e  32  2e  38  34  30  2e
D:   31  30  30  30  38  2e  31  2e  32  40  00  00  13  31  2e  32
D:   2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31
D:   20  00  00  36  05  00  ff  00  30  00  00  19  31  2e  33  2e
D:   36  2e  31  2e  34  2e  31  2e  32  38  32  30  2e  32  32  38
D:   34  36  36  2e  31  40  00  00  11  31  2e  32  2e  38  34  30
D:   2e  31  30  30  30  38  2e  31  2e  32  50  00  00  33  51  00
D:   00  04  00  00  40  00  52  00  00  18  31  2e  33  2e  36  2e
D:   31  2e  34  2e  31  2e  32  38  32  30  2e  30  2e  33  2e  30
D:   2e  30  55  00  00  0b  49  47  50  41  43  53  5f  76  31  2e
D:   37
D: Parsing an A-ASSOCIATE PDU
I: Association Received
D: Parameters:
D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.0
D: Our Implementation Version Name:   OFFIS_DCMTK_360
D: Their Implementation Class UID:    1.3.6.1.4.1.2820.0.3.0.0
D: Their Implementation Version Name: IGPACS_v1.7
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    AIRCPACS
D: Called Application Name:     MOLONEYPCCC
D: Responding Application Name: 
D: Our Max PDU Receive Size:    16384
D: Their Max PDU Receive Size:  16384
D: Presentation Contexts:
D:   Context ID:        1 (Proposed)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianExplicit
D:   Context ID:        3 (Proposed)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianImplicit
D:       =LittleEndianExplicit
D:   Context ID:        5 (Proposed)
D:     Abstract Syntax: 1.3.6.1.4.1.2820.228466.1
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation:  none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response:  none
D: ======================= END A-ASSOCIATE-RQ ======================
D: Constructing Associate AC PDU
I: Association Acknowledged (Max Send PDV: 16372)
D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.0
D: Our Implementation Version Name:   OFFIS_DCMTK_360
D: Their Implementation Class UID:    1.3.6.1.4.1.2820.0.3.0.0
D: Their Implementation Version Name: IGPACS_v1.7
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    AIRCPACS
D: Called Application Name:     MOLONEYPCCC
D: Responding Application Name: STORESCP
D: Our Max PDU Receive Size:    16384
D: Their Max PDU Receive Size:  16384
D: Presentation Contexts:
D:   Context ID:        1 (Accepted)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianExplicit
D:   Context ID:        3 (Accepted)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianExplicit
D:   Context ID:        5 (Accepted)
D:     Abstract Syntax: 1.3.6.1.4.1.2820.228466.1
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation:  none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response:  none
D: ======================= END A-ASSOCIATE-AC ======================
I: Received Store Request: MsgID 1, (MR)
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type                  : C-STORE RQ
D: Presentation Context ID       : 1
D: Message ID                    : 1
D: Affected SOP Class UID        : MRImageStorage
D: Affected SOP Instance UID     : 1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485
D: Data Set                      : present
D: Priority                      : medium
D: ======================= END DIMSE MESSAGE =======================
I: storing DICOM file: ./MR.1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485
D: DcmFileFormat::checkMetaHeaderValue() Version of MetaHeader is ok: 0x0100
D: DcmFileFormat::checkMetaHeaderValue() use SOPClassUID [1.2.840.10008.5.1.4.1.1.4]
D: DcmFileFormat::checkMetaHeaderValue() use SOPInstanceUID [1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485] from Dataset
D: DcmFileFormat::checkMetaHeaderValue() use new TransferSyntaxUID [Little Endian Explicit] on writing following Dataset
D: DcmFileFormat: Found 8 Elements in DcmMetaInfo 'metinf'
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0008 len=448
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0010 len=90
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0018 len=432
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0020 len=310
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0028 len=188
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0029 len=52730
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0032 len=22
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0040 len=84
E: cannot handle command: 0x130
E: DIMSE failure (aborting association): 0006:0201 DIMSE Bad command type

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#2 Post by J. Riesmeier »

That's strange. I just checked that with storescp 3.6.0 and it worked as expected. Are you sure that you also used LittleEndianImplicit transfer syntax for the private SOP class when enabling the profile from a config file?

... seems that the error happens when transferring the (standard) MR image, right?

bmoloney
Posts: 10
Joined: Wed, 2011-09-07, 00:38

#3 Post by bmoloney »

I only see the error with transfers from one specific PACS, other network nodes do not have an issue.

This made me think it was an issue on that specific PACS, but it seems strange that disabling promiscuous mode makes the error go away. None of the images have to be non-standard SOP classes for the error to occur (in the example above I am just sending standard MR Images). I just like to use promiscuous mode in case there are some non-standard SOP classes included.

Not sure about the config file question. I use the one included with DCMTK with a few different SOP classes at the end.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#4 Post by J. Riesmeier »

The command type 0x0130 means N-ACTION-REQUEST, so my first guess would be that the sender assumes that the receiver supports DICOM Storage Commitment (although this was not negotiated - could you please check that). If this is really the case, it is a violation of the DICOM standard (but maybe, you can disable this service in the configuration of the sending system).
Last edited by J. Riesmeier on Fri, 2011-09-09, 14:35, edited 1 time in total.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#5 Post by J. Riesmeier »

Follow-up: I've just committed a minor change that will report more details on the "bad command type" to the ERROR and DEBUG logger (in order to make it easier to understand this kind of error).

bmoloney
Posts: 10
Joined: Wed, 2011-09-07, 00:38

#6 Post by bmoloney »

Thank you for being so responsive. The PACS does not have any special configuration to use Storage Commitment. Does the storescp application handle storage commitment differently when promiscuous mode is enabled?

I cloned the master branch of DCMTK, compiled, and retested (with the same data set, so no non-standard SOP Clasees):

Code: Select all

D: $dcmtk: storescp v3.6.1 CVS $
D: 
D: DcmDataDictionary: Loading file: /usr/global/lib/dicom.dic
D: setting network receive timeout to 60 seconds
D: PDU Type: Associate Request, PDU Length: 347 + 6 bytes PDU header
D:   01  00  00  00  01  5b  00  01  00  00  4d  4f  4c  4f  4e  45
D:   59  50  43  43  43  20  20  20  20  20  41  49  52  43  50  41
D:   43  53  20  20  20  20  20  20  20  20  00  00  00  00  00  00
D:   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
D:   00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
D:   32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
D:   31  2e  31  20  00  00  38  01  00  ff  00  30  00  00  19  31
D:   2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  35  2e  31
D:   2e  34  2e  31  2e  31  2e  34  40  00  00  13  31  2e  32  2e
D:   38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31  20
D:   00  00  4d  03  00  ff  00  30  00  00  19  31  2e  32  2e  38
D:   34  30  2e  31  30  30  30  38  2e  35  2e  31  2e  34  2e  31
D:   2e  31  2e  34  40  00  00  11  31  2e  32  2e  38  34  30  2e
D:   31  30  30  30  38  2e  31  2e  32  40  00  00  13  31  2e  32
D:   2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  32  2e  31
D:   20  00  00  36  05  00  ff  00  30  00  00  19  31  2e  33  2e
D:   36  2e  31  2e  34  2e  31  2e  32  38  32  30  2e  32  32  38
D:   34  36  36  2e  31  40  00  00  11  31  2e  32  2e  38  34  30
D:   2e  31  30  30  30  38  2e  31  2e  32  50  00  00  33  51  00
D:   00  04  00  00  40  00  52  00  00  18  31  2e  33  2e  36  2e
D:   31  2e  34  2e  31  2e  32  38  32  30  2e  30  2e  33  2e  30
D:   2e  30  55  00  00  0b  49  47  50  41  43  53  5f  76  31  2e
D:   37
D: Parsing an A-ASSOCIATE PDU
I: Association Received
D: Parameters:
D: ====================== BEGIN A-ASSOCIATE-RQ =====================
D: Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
D: Our Implementation Version Name:   OFFIS_DCMTK_361
D: Their Implementation Class UID:    1.3.6.1.4.1.2820.0.3.0.0
D: Their Implementation Version Name: IGPACS_v1.7
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    AIRCPACS
D: Called Application Name:     MOLONEYPCCC
D: Responding Application Name: 
D: Our Max PDU Receive Size:    16384
D: Their Max PDU Receive Size:  16384
D: Presentation Contexts:
D:   Context ID:        1 (Proposed)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianExplicit
D:   Context ID:        3 (Proposed)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianImplicit
D:       =LittleEndianExplicit
D:   Context ID:        5 (Proposed)
D:     Abstract Syntax: 1.3.6.1.4.1.2820.228466.1
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntax(es):
D:       =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation:  none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response:  none
D: ======================= END A-ASSOCIATE-RQ ======================
D: Constructing Associate AC PDU
I: Association Acknowledged (Max Send PDV: 16372)
D: ====================== BEGIN A-ASSOCIATE-AC =====================
D: Our Implementation Class UID:      1.2.276.0.7230010.3.0.3.6.1
D: Our Implementation Version Name:   OFFIS_DCMTK_361
D: Their Implementation Class UID:    1.3.6.1.4.1.2820.0.3.0.0
D: Their Implementation Version Name: IGPACS_v1.7
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    AIRCPACS
D: Called Application Name:     MOLONEYPCCC
D: Responding Application Name: STORESCP
D: Our Max PDU Receive Size:    16384
D: Their Max PDU Receive Size:  16384
D: Presentation Contexts:
D:   Context ID:        1 (Accepted)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianExplicit
D:   Context ID:        3 (Accepted)
D:     Abstract Syntax: =MRImageStorage
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianExplicit
D:   Context ID:        5 (Accepted)
D:     Abstract Syntax: 1.3.6.1.4.1.2820.228466.1
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default
D:     Accepted Transfer Syntax: =LittleEndianImplicit
D: Requested Extended Negotiation: none
D: Accepted Extended Negotiation:  none
D: Requested User Identity Negotiation: none
D: User Identity Negotiation Response:  none
D: ======================= END A-ASSOCIATE-AC ======================
I: Received Store Request: MsgID 1, (MR)
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type                  : C-STORE RQ
D: Presentation Context ID       : 1
D: Message ID                    : 1
D: Affected SOP Class UID        : MRImageStorage
D: Affected SOP Instance UID     : 1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485
D: Data Set                      : present
D: Priority                      : medium
D: ======================= END DIMSE MESSAGE =======================
I: storing DICOM file: ./MR.1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485
D: DcmFileFormat::checkMetaHeaderValue() Version of MetaHeader is ok: 0x0100
D: DcmFileFormat::checkMetaHeaderValue() use SOPClassUID [1.2.840.10008.5.1.4.1.1.4] from Dataset
D: DcmFileFormat::checkMetaHeaderValue() use SOPInstanceUID [1.3.12.2.1107.5.2.13.20559.30000008091514542656200003485] from Dataset
D: DcmFileFormat::checkMetaHeaderValue() use new TransferSyntaxUID [Little Endian Explicit] on writing following Dataset
D: DcmFileFormat: Found 8 Elements in DcmMetaInfo 'metinf'
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0008 len=448
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0010 len=90
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0018 len=432
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0020 len=310
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0028 len=188
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0029 len=52730
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0032 len=22
D: DcmItem::computeGroupLengthAndPadding() Length of Group 0x0040 len=84
E: Expected C-ECHO or C-STORE request but received DIMSE command 0x0130
D: ===================== INCOMING DIMSE MESSAGE ====================
D: Message Type                  : N-ACTION RQ
D: Presentation Context ID       : 5
D: Message ID                    : 2
D: Requested SOP Class UID       : 1.3.6.1.4.1.2820.228466.1
D: Requested SOP Instance UID    : 1.3.6.1.4.1.2820.228466
D: Action Type ID                : 0
D: Data Set                      : present
D: ======================= END DIMSE MESSAGE =======================
E: DIMSE failure (aborting association): 0006:0201 DIMSE Bad command type
What I find really strange is that when I disable promiscuous mode I don't see any N-ACTION RQ messages coming in, just C-STORE RQ messages.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#7 Post by J. Riesmeier »

I cloned the master branch of DCMTK, compiled, and retested (with the same data set, so no non-standard SOP Clasees)
That was really a good idea because now we know what the details of the N-ACTION-REQUEST message are:

Code: Select all

D: ===================== INCOMING DIMSE MESSAGE ==================== 
D: Message Type                  : N-ACTION RQ 
D: Presentation Context ID       : 5 
D: Message ID                    : 2 
D: Requested SOP Class UID       : 1.3.6.1.4.1.2820.228466.1 
D: Requested SOP Instance UID    : 1.3.6.1.4.1.2820.228466 
D: Action Type ID                : 0 
D: Data Set                      : present 
D: ======================= END DIMSE MESSAGE ======================= 
So, the N-ACTION has nothing to do with Storage Commitment (this was just a guess) but refers to the private SOP class "1.3.6.1.4.1.2820.228466.1", which is only accepted in promiscuous mode. In other words, in this mode you are not only accepting private storage SOP classes, but all SOP classes that are not known to storescp :-)

Btw, the UID root "1.3.6.1.4.1.2820" is explained here. The company Procom Technology should be able to provide a DICOM conformance statement where this private SOP class is described.

bmoloney
Posts: 10
Joined: Wed, 2011-09-07, 00:38

#8 Post by bmoloney »

Thanks again for the quick response.

I think I understand the issue now. It seems like it would be preferable for promiscuous mode to only accept unknown storage SOP classes (or at least make this configurable).

For me it is not a big deal, since there is a small number of non-standard storage SOP classes we deal with. I can just list them in a config file.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#9 Post by J. Riesmeier »

It seems like it would be preferable for promiscuous mode to only accept unknown storage SOP classes (or at least make this configurable).
Yes, unfortunately, this information (storage SOP class or not) cannot be derived from a private SOP class UID.
For me it is not a big deal, since there is a small number of non-standard storage SOP classes we deal with. I can just list them in a config file.
That's probably the best idea.

bmoloney
Posts: 10
Joined: Wed, 2011-09-07, 00:38

#10 Post by bmoloney »

Yes, unfortunately, this information (storage SOP class or not) cannot be derived from a private SOP class UID.
Doesn't the message type gives you this information (C-STORE RQ vs N-ACTION RQ)?

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#11 Post by J. Riesmeier »

DICOM defines conformance on the SOP class level, i.e. as soon as an SCP accepts a SOP class (during the association negotiation) it has to (fully) support it. So, checking the message type only is a step too late. This is also the reason why storescp aborts when receiving anything else than C-ECHO RQ or C-STORE RQ. Bottom line: Do not accept a SOP class if you don't support it :-)

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 1 guest