Доброго времени суток, уважаемые форумчане. У меня стоит задача настроить правильную передачу ворклистов c DCM4CHEE (если важно, сервер используется dcm4che arc light 5) в непосредственно рентгеновский аппарат.
Логи самого аппараты выглядят следующим образом: 2019-03-12 14:42:55.83 File: WorklistSCU.cpp, Line: 236, ErrorCode: 0(0x0000) Open connection 2019-03-12 14:42:55.83 File: WorklistSCU.cpp, Line: 632, ErrorCode: 0(0x0000) Connection is set 2019-03-12 14:42:55.85 File: WorklistSCU.cpp, Line: 531, ErrorCode: 0(0x0000) Association accepted 2019-03-12 14:42:55.85 File: WorklistReciever.cpp, Line: 80, ErrorCode: 0(0x0000) Send C-FIND Request 2019-03-12 14:42:55.85 File: WorklistSCU.cpp, Line: 341, ErrorCode: 0(0x0000) C-FIND request is sent 2019-03-12 14:42:55.86 File: WorklistReciever.cpp, Line: 130, ErrorCode: 0(0x0000) 0 new items gotten 2019-03-12 14:42:55.86 File: WorklistSCU.cpp, Line: 632, ErrorCode: 0(0x0000) All items were processed, no new data 2019-03-12 14:42:55.86 File: WorklistSCU.cpp, Line: 376, ErrorCode: 0(0x0000) Send release request 2019-03-12 14:42:55.86 File: WorklistSCU.cpp, Line: 632, ErrorCode: 0(0x0000) A release response has been gotten 2019-03-12 14:42:55.86 File: WorklistSCU.cpp, Line: 403, ErrorCode: 0(0x0000) Close the connection 2019-03-12 14:43:02.80 File: WorklistSCU.cpp, Line: 236, ErrorCode: 0(0x0000) Open connection 2019-03-12 14:43:02.82 File: WorklistSCU.cpp, Line: 632, ErrorCode: 0(0x0000) Connection is set 2019-03-12 14:43:02.82 File: WorklistSCU.cpp, Line: 531, ErrorCode: 0(0x0000) Association accepted 2019-03-12 14:43:02.82 File: WorklistReciever.cpp, Line: 80, ErrorCode: 0(0x0000) Send C-FIND Request 2019-03-12 14:43:02.82 File: WorklistSCU.cpp, Line: 341, ErrorCode: 0(0x0000) C-FIND request is sent 2019-03-12 14:43:02.84 File: WorklistReciever.cpp, Line: 163, ErrorCode: 6(0x0006) Item processing failed 2019-03-12 14:43:02.84 File: WorklistReciever.cpp, Line: 130, ErrorCode: 0(0x0000) 0 new items gotten 2019-03-12 14:43:02.84 File: WorklistSCU.cpp, Line: 611, ErrorCode: 6(0x0006) Database Error 2019-03-12 14:43:02.84 File: WorklistSCU.cpp, Line: 376, ErrorCode: 0(0x0000) Send release request 2019-03-12 14:43:02.84 File: WorklistSCU.cpp, Line: 632, ErrorCode: 0(0x0000) A release response has been gotten 2019-03-12 14:43:02.84 File: WorklistSCU.cpp, Line: 403, ErrorCode: 0(0x0000) Close the connection
Тестировал сервер программой IQ_DICOMTest, и она отображала все ворклисты,но без запланированной процедуры (что странно, т.к. у некоторых записей разные AET конечных устройств), уже и не знаю как еще попробовать заставить эту связь работать, предполагаю, что ошибка в шаблоне ворклиста, хранимого на сервере, раз он обращается к нему и не получает никакие записи, но как правильно не знаю и нигде не нашел. Буду очень признателен за любую помощь, заранее спасибо.
Модальность аппарата совпадает с модальностью исследований из листа? проверяет ли клиент соответствие (0008,0090) Referring Physician‘s Name вообще неизвестно. И что-то мне не нравится строчка Database Error. Раньше электрон костылил для dicom какие-то отдельные базы в mdb, и если к ним не было доступа, то обмен переставал работать, но это было в древних версиях.
В чем странность, что модальность у аппарата в настройках станции стоит DX, у сервисов ее нельзя изменить с CR (при изменении и сохранениии меняет обратно). Я пробовал ворклисты и с той и другой модальностью, результат один и тот же. Мне вот лично казалось, что дело именно в теге "00401001", т.к. я за все время изучения документации, так и не понял откуда брать ID процедуры. И ведь, поправьте если ошибаюсь, разве в логах рентгена не написано, что он устанавливает соединение с сервером и делает вид, что там как-будто нет worklist-ов.
Сообщение отредактировал AndreySm1996 - Среда, 13.Мар.2019, 10:45
2019-03-12 14:42:58,438 INFO [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-2) Accept connection Socket[addr=/192.168.101.1,port=49738,localport=11112] 2019-03-12 14:42:58,439 INFO [org.dcm4che3.net.Association] (EE-ManagedExecutorService-default-Thread-65) DCM4CHEE<-QWERTY(46) >> A-ASSOCIATE-RQ 2019-03-12 14:42:58,440 INFO [org.dcm4che3.net.Association] (EE-ManagedExecutorService-default-Thread-65) DCM4CHEE<-QWERTY(46) << A-ASSOCIATE-AC 2019-03-12 14:42:58,444 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-65) DCM4CHEE<-QWERTY(46) >> 101:C-FIND-RQ[pcid=1, prior=1 cuid=1.2.840.10008.5.1.4.31 - Modality Worklist Information Model - FIND tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian 2019-03-12 14:42:58,448 INFO [org.dcm4chee.arc.procedure.scp.MWLCFindSCP] (EE-ManagedExecutorService-default-Thread-65) DCM4CHEE<-QWERTY(46): Process MWL C-FIND RQ: (FFFA,FFFA) SQ [1 Items] DigitalSignaturesSequence >Item #1 >(0400,0005) US [] MACIDNumber >(0400,0100) UI [] DigitalSignatureUID >(0400,0105) DT [] DigitalSignatureDateTime >(0400,0110) CS [] CertificateType >(0400,0115) OB [] CertificateOfSigner >(0400,0120) OB [] Signature >(0400,0305) CS [] CertifiedTimestampType >(0400,0310) OB [] CertifiedTimestamp (0008,0005) CS [] SpecificCharacterSet (0008,0012) DA [] InstanceCreationDate (0008,0013) TM [] InstanceCreationTime (0008,0014) UI [] InstanceCreatorUID (0008,0016) UI [1.2.840.10008.5.1.4.31] SOPClassUID (0008,0018) UI [] SOPInstanceUID (0008,0050) SH [] AccessionNumber (0008,0080) LO [] InstitutionName (0008,0081) ST [] InstitutionAddress (0008,0082) SQ [1 Items] InstitutionCodeSequence >Item #1 >(0008,0100) SH [] CodeValue >(0008,0102) SH [] CodingSchemeDesignator >(0008,0103) SH [] CodingSchemeVersion >(0008,0104) LO [] CodeMeaning >(0008,0105) CS [] MappingResource >(0008,0106) DT [] ContextGroupVersion >(0008,0107) DT [] ContextGroupLocalVersion >(0008,010B) CS [] ContextGroupExtensionFlag >(0008,010D) UI [] ContextGroupExtensionCreatorUID >(0008,010F) CS [] ContextIdentifier (0008,0090) PN [] ReferringPhysicianName (0008,0092) ST [] ReferringPhysicianAddress (0008,0094) SH [] ReferringPhysicianTelephoneNumbers (0008,0096) SQ [1 Items] ReferringPhysicianIdentificationSequence >Item #1 >(0008,0080) LO [] InstitutionName >(0008,0081) ST [] InstitutionAddress >(0008,0082) SQ [1 Items] InstitutionCodeSequence >>Item #1 >>(0008,0100) SH [] CodeValue >>(0008,0102) SH [] CodingSchemeDesignator >>(0008,0103) SH [] CodingSchemeVersion >>(0008,0104) LO [] CodeMeaning >>(0008,0105) CS [] MappingResource >>(0008,0106) DT [] ContextGroupVersion >>(0008,0107) DT [] ContextGroupLocalVersion >>(0008,010B) CS [] ContextGroupExtensionFlag >>(0008,010D) UI [] ContextGroupExtensionCreatorUID >>(0008,010F) CS [] ContextIdentifier
Правильно ли я понимаю, что это и есть условия фильтра? Не понятно лишь, как все же должен выглядеть worklist, который хочет увидеть на сервере рентген.
Конкретно проверял работу 4.х версии с Ворклиста (источник - пакс от АГФЫ)...ТАкже 3-ей версией ЭОС проверял. ИТОГ- вобщем все работает за исключением того, что НЕЛЬЗЯ прокручивать списки нормально с пациентами! Почему-то если более примерно 10 записей получает Электрон, то при попытке пролистывания курсор "улетает" вверх или вниз соот-но, не дает программа ткнуть "посредине". Единственный вариант - уменьшать список получаемыйх записей до минимума - типа фильтрами отбора. Однако, это изврат... Вот как-то так. Изгалялся как мог - в итоге плюнул.
Попробовал отловить пакеты, с рентгена Wireshark-ом, но ничего не вышло. Он как будто их не ловит, хотя когда я IQ_DICOMTest посылаю на сервер запросы, WS прекрасно это видит, ну также как и на вашем скриншоте отображается последовательность пакетов. И теперь я вот думаю, верификацию то сервисы проходят, что Storage, что Worklist, но WS упорно не обнаруживает пакеты, которые должен слать рентген. Но на сервер исследования то приходят...
Дата: Четверг, 14.Мар.2019, 18:19 | Сообщение # 10
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация
Москва
ах-да, маленькие нюансы. в вашем логе это чей адрес? Accept connection Socket[addr=/192.168.101.1,port=49738,localport=11112] раньше, клиентский софт электрона слал RPC-запросы на свой сервер, и уже там запускались COM-объекты, которые работали по DICOM. используйте tcpdump на dicom-сервере с записью в pcap-файл, если у вас linux-сервер. https://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html только укажите еще фильтр по порту, типа tcpdump -i <interface> -w <some-file> port 11112
Сообщение отредактировал naves - Четверг, 14.Мар.2019, 18:21
Дата: Пятница, 15.Мар.2019, 13:23 | Сообщение # 11
Стажер
У вас сообщений: 9
Программист
OFFлайн
Российская Федерация
Санкт-Петербург
День добрый, tcpdump еще не успел посмотреть, жаль он не показывает содержимое пакета, как WireShark, но ничего.
Цитатаnaves ()
в вашем логе это чей адрес? Accept connection Socket[addr=/192.168.101.1,port=49738,localport=11112]
С уверенностью могу сказать, что этот IP ни сервера (192.168.6.30), ни станции (192.168.101.100) станция кстати с двумя сетевыми картами (АРМ лаборанта в серверной конфигурации). Т.к. заканчивается на 1, смею предположить, что это IP роутера, но почему он отображается в логах не могу знать.
Дата: Понедельник, 18.Мар.2019, 10:40 | Сообщение # 13
Стажер
У вас сообщений: 9
Программист
OFFлайн
Российская Федерация
Санкт-Петербург
Добрый день, я просто по IP сервера пытался ловить пакеты, разве это не верный вариант? Что же касается сетевух, то одна сетевая АРМа лаборанта для внешней сети как я понимаю (192.168.101.100) и второй IP - внутренняя сеть с сервером, который шел с завода (192.168.4.3). но он даже и не пингуется.
Дата: Понедельник, 18.Мар.2019, 12:33 | Сообщение # 14
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация
Москва
Wireshark умеет одновременно захватывать пакеты только с одного интерфейса, и если выбрать неправильный интерфейс то ничего не будет. Запустите Wireshark и посмотрите какая вообще сетевая активность начинается при нажатии кнопки получить список. Давным давно меня тоже поставило в тупик, что с компа лаборанта вместо DICOM-пакетов пошли RPC-запросы в сторону сервера электрона. Потом уже только понял, что там накручено.
Извиняюсь, за то, что пропал на другом проекте. К сути, мне кажется, что я определенно что-то делаю не так при настройке сервера, а именно при добавлении удаленного AET рентгена в список AETов на сервере. Кстати, что странно, если станцию лаборанта просматривать nmap то наблюдается следующая картина (см. скриншот) - 5 открытых непонятных портов. Так вот, если я добавляю на сервере в Application Entities list с IP станции лаборанта и портом 104 echo запрос с DCM4CHEE не проходит (см. скриншот), хотя наверное должен. Подскажите пожалуйста, в чем еще я мог накосячить при настрйоке и развертывании, пока думаю, что мб 104 порт на станции рентгена закрыт и соответственно все не работает. P.S. Сервер на Wildfly 11 и в docker контейнере
Так вот, если я добавляю на сервере в Application Entities list с IP станции лаборанта и портом 104 echo запрос с DCM4CHEE не проходит (см. скриншот), хотя наверное должен
не должен.
Здесь я могу начать пространно растекаться мыслью по тексту, что диком-клиент не обязан постоянно держать открытым порт, тем более для запроса любого списка. И отправлять снимки он тоже может с любого порта. И вообще кроме c-move, еще есть c-get, где отправка снимков идет в рамках уже созданного соединения, и не нужно запускать отдельный порт для приема.
Логи из первого поста вы откуда взяли? В любой непонятной ситуации используйте tcpdump (с) Плясать надо от печки (с) Запустите на dicom-сервере tcpdump, и убедитесь что запросы приходят именно с лаборантского компа. Мне кажется, у вас там рояль в кустах есть.
Сообщение отредактировал naves - Среда, 27.Мар.2019, 13:32
Дата: Четверг, 28.Мар.2019, 16:27 | Сообщение # 17
Стажер
У вас сообщений: 9
Программист
OFFлайн
Российская Федерация
Санкт-Петербург
1) Логи были взяты из файла DicomWorklist.txt (что-то типо того), расположенного то ли на сервере рентгена то ли на АРМ лаборанта (не могу точнее сказать, не посмотрел куда монтировались диски)
На удивление tcpdump и wireshark не могут отловить пакеты при передаче снимков на ПАКС и запросе ворклистов, хотя логи сервера Wildfly во время запроса ворклистов выглядят так:
2019-03-28 15:33:42,796 INFO [org.dcm4che3.net.Connection] (EE-ManagedExecutorService-default-Thread-2) Accept connection Socket[addr=/192.168.101.1,port=50174,localport=11112] 2019-03-28 15:33:42,797 INFO [org.dcm4che3.net.Association] (EE-ManagedExecutorService-default-Thread-33) DCM4CHEE<-QWERTY(49) >> A-ASSOCIATE-RQ 2019-03-28 15:33:42,797 INFO [org.dcm4che3.net.Association] (EE-ManagedExecutorService-default-Thread-33) DCM4CHEE<-QWERTY(49) << A-ASSOCIATE-AC 2019-03-28 15:33:42,802 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-33) DCM4CHEE<-QWERTY(49) >> 146:C-FIND-RQ[pcid=1, prior=1 cuid=1.2.840.10008.5.1.4.31 - Modality Worklist Information Model - FIND tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian 2019-03-28 15:33:42,803 INFO [org.dcm4chee.arc.procedure.scp.MWLCFindSCP] (EE-ManagedExecutorService-default-Thread-33) DCM4CHEE<-QWERTY(49): Process MWL C-FIND RQ: (FFFA,FFFA) SQ [1 Items] DigitalSignaturesSequence >Item #1 >(0400,0005) US [] MACIDNumber >(0400,0100) UI [] DigitalSignatureUID >(0400,0105) DT [] DigitalSignatureDateTime >(0400,0110) CS [] CertificateType >(0400,0115) OB [] CertificateOfSigner >(0400,0120) OB [] Signature >(0400,0305) CS [] CertifiedTimestampType >(0400,0310) OB [] CertifiedTimestamp (0008,0005) CS [] SpecificCharacterSet (0008,0012) DA [] InstanceCreationDate (0008,0013) TM [] InstanceCreationTime (0008,0014) UI [] InstanceCreatorUID (0008,0016) UI [1.2.840.10008.5.1.4.31] SOPClassUID (0008,0018) UI [] SOPInstanceUID (0008,0050) SH [] AccessionNumber (0008,0080) LO [] InstitutionName (0008,0081) ST [] InstitutionAddress (0008,0082) SQ [1 Items] InstitutionCodeSequence >Item #1 >(0008,0100) SH [] CodeValue >(0008,0102) SH [] CodingSchemeDesignator >(0008,0103) SH [] CodingSchemeVersion >(0008,0104) LO [] CodeMeaning >(0008,0105) CS [] MappingResource >(0008,0106) DT [] ContextGroupVersion >(0008,0107) DT [] ContextGroupLocalVersion >(0008,010B) CS [] ContextGroupExtensionFlag >(0008,010D) UI [] ContextGroupExtensionCreatorUID >(0008,010F) CS [] ContextIdentifier (0008,0090) PN [] ReferringPhysicianName (0008,0092) ST [] ReferringPhysicianAddress (0008,0094) SH [] ReferringPhysicianTelephoneNumbers (0008,0096) SQ [1 Items] ReferringPhysicianIdentificationSequence >Item #1 >(0008,0080) LO [] InstitutionName >(0008,0081) ST [] InstitutionAddress >(0008,0082) SQ [1 Items] InstitutionCodeSequence >>Item #1 >>(0008,0100) SH [] CodeValue >>(0008,0102) SH [] CodingSchemeDesignator >>(0008,0103) SH [] CodingSchemeVersion >>(0008,0104) LO [] CodeMeaning >>(0008,0105) CS [] MappingResource >>(0008,0106) DT [] ContextGroupVersion >>(0008,0107) DT [] ContextGroupLocalVersion >>(0008,010B) CS [] ContextGroupExtensionFlag >>(0008,010D) UI [] ContextGroupExtensionCreatorUID >>(0008,010F) CS [] ContextIdentifier ...
2019-03-28 15:33:42,816 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-34) DCM4CHEE<-QWERTY(49) << 146:C-FIND-RSP[pcid=1, status=ff00H cuid=1.2.840.10008.5.1.4.31 - Modality Worklist Information Model - FIND tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian 2019-03-28 15:33:42,817 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-34) DCM4CHEE<-QWERTY(49) << 146:C-FIND-RSP[pcid=1, status=0H cuid=1.2.840.10008.5.1.4.31 - Modality Worklist Information Model – FIND
Логи рентгена выглядят следующим образом, он пишет как будто не нашел никаких новых заказов на исследование (см. скриншот)
Также добавлю, что пинги в tcpdump отображаются и запросы на верификацию с сервисов рентгена также там видны:
dgb@pacs1:~/dcm4chee-arc-light/docker$ sudo tcpdump -v -i ens160 ip src 192.168.101.100 tcpdump: listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes 14:57:23.879771 IP (tos 0x0, ttl 127, id 18175, offset 0, flags [none], proto ICMP (1), length 60) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 29, length 40 14:57:24.888428 IP (tos 0x0, ttl 127, id 18180, offset 0, flags [none], proto ICMP (1), length 60) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 30, length 40 14:57:25.902393 IP (tos 0x0, ttl 127, id 18185, offset 0, flags [none], proto ICMP (1), length 60) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 31, length 40 14:57:26.916122 IP (tos 0x0, ttl 127, id 18190, offset 0, flags [none], proto ICMP (1), length 60) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 32, length 40 14:57:45.961372 IP (tos 0x0, ttl 128, id 18790, offset 0, flags [none], proto UDP (17), length 78) 192.168.101.100.netbios-ns > 192.168.101.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 14:57:53.488446 IP (tos 0x0, ttl 254, id 18881, offset 0, flags [none], proto ICMP (1), length 28) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 33, length 8 14:57:53.491806 IP (tos 0x0, ttl 127, id 18882, offset 0, flags [DF], proto TCP (6), length 48) 192.168.101.100.49752 > pacs1.dicom: Flags [S], cksum 0xd22a (correct), seq 91380974, win 29696, options [mss 1460,nop,nop,sackOK], length 0 14:57:53.492238 IP (tos 0x0, ttl 127, id 18883, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49752 > pacs1.dicom: Flags [.], cksum 0xe998 (correct), ack 4003276456, win 29696, length 0 14:57:53.492688 IP (tos 0x0, ttl 127, id 18884, offset 0, flags [DF], proto TCP (6), length 246) 192.168.101.100.49752 > pacs1.dicom: Flags [P.], cksum 0x17c5 (correct), seq 0:206, ack 1, win 29696, length 206 14:57:53.524200 IP (tos 0x0, ttl 127, id 18885, offset 0, flags [DF], proto TCP (6), length 120) 192.168.101.100.49752 > pacs1.dicom: Flags [P.], cksum 0x2058 (correct), seq 206:286, ack 178, win 29519, length 80 14:57:53.752518 IP (tos 0x0, ttl 127, id 18888, offset 0, flags [DF], proto TCP (6), length 52) 192.168.101.100.49752 > pacs1.dicom: Flags [.], cksum 0x861b (correct), ack 268, win 29429, options [nop,nop,sack 1 {178:268}], length 0 14:57:55.419804 IP (tos 0x0, ttl 127, id 18895, offset 0, flags [DF], proto TCP (6), length 50) 192.168.101.100.49752 > pacs1.dicom: Flags [P.], cksum 0xe364 (correct), seq 286:296, ack 268, win 29429, length 10 14:57:55.420832 IP (tos 0x0, ttl 127, id 18896, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49752 > pacs1.dicom: Flags [F.], cksum 0xe86f (correct), seq 296, ack 278, win 29419, length 0 14:57:55.473592 IP (tos 0x0, ttl 127, id 18898, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49752 > pacs1.dicom: Flags [.], cksum 0xe86e (correct), ack 279, win 29419, length 0 14:58:01.923261 IP (tos 0x0, ttl 254, id 19243, offset 0, flags [none], proto ICMP (1), length 28) 192.168.101.100 > pacs1: ICMP echo request, id 1, seq 34, length 8 14:58:01.926198 IP (tos 0x0, ttl 127, id 19244, offset 0, flags [DF], proto TCP (6), length 48) 192.168.101.100.49753 > pacs1.dicom: Flags [S], cksum 0x2df4 (correct), seq 1266268956, win 29696, options [mss 1460,nop,nop,sackOK], length 0 14:58:01.926566 IP (tos 0x0, ttl 127, id 19245, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49753 > pacs1.dicom: Flags [.], cksum 0xdb20 (correct), ack 1382690077, win 29696, length 0 14:58:01.927730 IP (tos 0x0, ttl 127, id 19246, offset 0, flags [DF], proto TCP (6), length 246) 192.168.101.100.49753 > pacs1.dicom: Flags [P.], cksum 0x094d (correct), seq 0:206, ack 1, win 29696, length 206 14:58:01.929816 IP (tos 0x0, ttl 127, id 19247, offset 0, flags [DF], proto TCP (6), length 120) 192.168.101.100.49753 > pacs1.dicom: Flags [P.], cksum 0x11e0 (correct), seq 206:286, ack 178, win 29519, length 80 14:58:02.130785 IP (tos 0x0, ttl 127, id 19249, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49753 > pacs1.dicom: Flags [.], cksum 0xda02 (correct), ack 268, win 29429, length 0 14:58:03.502127 IP (tos 0x0, ttl 127, id 19283, offset 0, flags [DF], proto TCP (6), length 50) 192.168.101.100.49753 > pacs1.dicom: Flags [P.], cksum 0xd4ec (correct), seq 286:296, ack 268, win 29429, length 10 14:58:03.503668 IP (tos 0x0, ttl 127, id 19284, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49753 > pacs1.dicom: Flags [F.], cksum 0xd9f7 (correct), seq 296, ack 278, win 29419, length 0 14:58:03.557300 IP (tos 0x0, ttl 127, id 19285, offset 0, flags [DF], proto TCP (6), length 40) 192.168.101.100.49753 > pacs1.dicom: Flags [.], cksum 0xd9f6 (correct), ack 279, win 29419, length 0 15:01:13.693500 IP (tos 0x0, ttl 128, id 14879, offset 0, flags [none], proto UDP (17), length 229) 192.168.101.100.netbios-dgm > 192.168.101.255.netbios-dgm: NBT UDP PACKET(138)
Итого. Из всей сложившейся ситуации могу предположить, что ошибки в неверно заданном ворклисте. Особенно для меня не понятно откуда берутся данные этих полей (которые, как я знаю являются обязательными для заполнения): "00400009":{ //Идентификатор исследования "vr": "SH", "Value": [ "88005553534242" ] }, "00401001": { //Идентификатор процедуры "vr": "SH", "Value": [ "16286" ] },
Жаль, я не знаю как должен все же выглядеть ворклист, у которого все поля заполнены так, как нужно для корректной работы с рентгеном.
Дата: Четверг, 28.Мар.2019, 17:14 | Сообщение # 18
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация
Москва
ЦитатаAndreySm1996 ()
На удивление tcpdump и wireshark не могут отловить пакеты при передаче снимков на ПАКС и запросе ворклистов, хотя логи сервера Wildfly во время запроса ворклистов выглядят так:
у вас в первой же строчке лога написано, что коннект идет с адреса 192.168.101.1 зы прячьте портянки под спойлеры
Сообщение отредактировал naves - Четверг, 28.Мар.2019, 17:14