COM порт на терминале в другой подсети
COM порт на терминале в другой подсети
Доброго дня.
Ситуация относится к wtware косвенно. Может у кого-то уже была похожая ситуация.
Итак, есть wtware 5.6.12 установленный на жесткий диск. К нему по com порту подключен фискальный регистратор штрих-фр-к
Конфиг wtware
server=--new--
user = admin
clienthostname=wtw*MAC
display = 1280x1024
connection
sound = on
microphone = on
vnc = on
vnc_password = ХХХХХХХХХХ
serial = com17(com1)
Тестовый сервер терминалов (Windows Server 2016 std) находится в той же подсети, что и wtware.
Проброс происходит и все отлично работает.
Боевой сервер терминалов (Windows Server 2016 std) находится в другой подсети. Сети объединены каналами OpenVPN. Пинг до боевого сервера около 48 мс.
При подключении к боевому com-порт пробрасывается и виден по команде change port.
Но при этом тестирование драйвером FR выдает ошибку -1 нет связи. Скорости перепробовал все. Таймаут увеличил до 10000 (для сравнения в локальной сети отлично работает при таймауте 1000).
При этом, если подключаться обычным mstsc.exe даже на WinXP все работает как нужно.
Сервера настроены одинаково. Политики безопасности совпадают до последней запятой, как и пакеты обновлений. Сервера в обоих случаях виртуальные.
Ситуация относится к wtware косвенно. Может у кого-то уже была похожая ситуация.
Итак, есть wtware 5.6.12 установленный на жесткий диск. К нему по com порту подключен фискальный регистратор штрих-фр-к
Конфиг wtware
server=--new--
user = admin
clienthostname=wtw*MAC
display = 1280x1024
connection
sound = on
microphone = on
vnc = on
vnc_password = ХХХХХХХХХХ
serial = com17(com1)
Тестовый сервер терминалов (Windows Server 2016 std) находится в той же подсети, что и wtware.
Проброс происходит и все отлично работает.
Боевой сервер терминалов (Windows Server 2016 std) находится в другой подсети. Сети объединены каналами OpenVPN. Пинг до боевого сервера около 48 мс.
При подключении к боевому com-порт пробрасывается и виден по команде change port.
Но при этом тестирование драйвером FR выдает ошибку -1 нет связи. Скорости перепробовал все. Таймаут увеличил до 10000 (для сравнения в локальной сети отлично работает при таймауте 1000).
При этом, если подключаться обычным mstsc.exe даже на WinXP все работает как нужно.
Сервера настроены одинаково. Политики безопасности совпадают до последней запятой, как и пакеты обновлений. Сервера в обоих случаях виртуальные.
-
- Разработчик
- Сообщения: 11852
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: COM порт на терминале в другой подсети
Напиши:
serial = com17(com1),debug
Запусти тест на одном сервере, как можно меншьше действий до первой ошибки. Сохрани лог.
Запусти тест на втором сервере. В точности те же действия.
И покажи оба лога.
И втварь возми последнюю. Работать от этого не начнет, но мне будет легче читать лог.
serial = com17(com1),debug
Запусти тест на одном сервере, как можно меншьше действий до первой ошибки. Сохрани лог.
Запусти тест на втором сервере. В точности те же действия.
И покажи оба лога.
И втварь возми последнюю. Работать от этого не начнет, но мне будет легче читать лог.
Re: COM порт на терминале в другой подсети
Готово.
com17 - неудачная на удаленном сервере.
com17success - удачная на локальном.
В обоих случаях запускал проверку связи в драйвере FR.
Как только получал ответ, положительный (наименованием модели и номер фискального регистратора) или отрицательный (ошибка -1)
com17 - неудачная на удаленном сервере.
com17success - удачная на локальном.
В обоих случаях запускал проверку связи в драйвере FR.
Как только получал ответ, положительный (наименованием модели и номер фискального регистратора) или отрицательный (ошибка -1)
- Вложения
-
- com17success.txt
- (142.36 КБ) 1169 скачиваний
-
- com17.txt
- (138.63 КБ) 1222 скачивания
-
- Разработчик
- Сообщения: 11852
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: COM порт на терминале в другой подсети
Смотрю время от первой команды сервера "запиши в порт" до четвертого чтения из порта. Сначала три байта читаются по байту, видимо по ним определяется длина блока, и затем делается четвертое чтение на 24 байта.
Разница на полтора порядка. Тот, который success - быстрее. В логе success 24 байта читаются из порта в три приёма, потому что к моменту прихода запроса они ещё не были приняты. Во втором логе читается одной пачкой, значит лежат в очереди. Не знаю, как это может влиять, пока только различия осознаю.
Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?
Затем вторая запись:
На вторую запись железка отвечает по-разному. Причем пишется в обоих случаях один и тот же байт со значением 0x06. В успешном логе на этот байт железка отвечает во второй раз иначе. В неуспешном логе на этот байт железка и в первый, и во второй раз отвечает одинаково. Вот бы разработчиков железки пнуть...
Различие именно в реакции железки. Т.е. таймаут на виндовсе ничего не значит. Надо искать таймаут, или интервал ожидания, который пропишется в железку.
А давай ещё один эксперимент. Вот эту штуку:
https://docs.microsoft.com/en-us/sysint ... ds/portmon
Запусти на WinXP с железкой. И сними такие же логи обменов с обоими серверами. Интересно интервалы сравнить.
PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.
PPS: и сделай ещё один лог с дальним сервером вот от этой сборки:
http://pxe.ru/files/testing/201711091508.zip
0.27 секунды.com17.txt писал(а):[rdpdr-serial 0] [ 64.503396] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 0 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
[rdpdr-serial 0] [ 64.503439] [DEBUG] IRP_MJ_WRITE
...
[rdpdr-serial 0] [ 64.773062] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 0 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
[rdpdr-serial 0] [ 64.773102] [DEBUG] IRP_MJ_READ
0.008 секунды.com17success.txt писал(а):[rdpdr-serial 0] [ 76.783604] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
[rdpdr-serial 0] [ 76.783643] [DEBUG] IRP_MJ_WRITE
...
[rdpdr-serial 0] [ 76.791437] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
[rdpdr-serial 0] [ 76.791469] [DEBUG] IRP_MJ_READ
Разница на полтора порядка. Тот, который success - быстрее. В логе success 24 байта читаются из порта в три приёма, потому что к моменту прихода запроса они ещё не были приняты. Во втором логе читается одной пачкой, значит лежат в очереди. Не знаю, как это может влиять, пока только различия осознаю.
Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?
Затем вторая запись:
Через 0.32 секунды после первой записи.com17.txt писал(а):[rdpdr-serial 0] [ 64.826953] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 0 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
[rdpdr-serial 0] [ 64.826993] [DEBUG] IRP_MJ_WRITE
[rdpdr-serial 0] [ 64.827016] 00000000:06 .
Через 0.018 секунды после первой записи.com17success.txt писал(а):[rdpdr-serial 0] [ 76.801469] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
[rdpdr-serial 0] [ 76.801504] [DEBUG] IRP_MJ_WRITE
[rdpdr-serial 0] [ 76.801527] 00000000:06 .
На вторую запись железка отвечает по-разному. Причем пишется в обоих случаях один и тот же байт со значением 0x06. В успешном логе на этот байт железка отвечает во второй раз иначе. В неуспешном логе на этот байт железка и в первый, и во второй раз отвечает одинаково. Вот бы разработчиков железки пнуть...
Различие именно в реакции железки. Т.е. таймаут на виндовсе ничего не значит. Надо искать таймаут, или интервал ожидания, который пропишется в железку.
А давай ещё один эксперимент. Вот эту штуку:
https://docs.microsoft.com/en-us/sysint ... ds/portmon
Запусти на WinXP с железкой. И сними такие же логи обменов с обоими серверами. Интересно интервалы сравнить.
PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.
PPS: и сделай ещё один лог с дальним сервером вот от этой сборки:
http://pxe.ru/files/testing/201711091508.zip
Re: COM порт на терминале в другой подсети
Поставил новый релиз.
Сделал первые тесты и сохранил логи. Прошу прощения за мусор в них, не успел сделать чистый. Машина не вернулась из третьего после установки обновления ребута.
Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?
Чисто теоретически можно. Но это то еще шаманство
А давай ещё один эксперимент. Вот эту штуку:
Смогу сделать только оказавшись рядом на физике. Только на следующей неделе.
PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.
Моя ошибка. Уже исправлено. На момент написания первого сообщения совпадали. Дальше решил играть с политиками и не вернул на место.
Сделал первые тесты и сохранил логи. Прошу прощения за мусор в них, не успел сделать чистый. Машина не вернулась из третьего после установки обновления ребута.
Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?
Чисто теоретически можно. Но это то еще шаманство
А давай ещё один эксперимент. Вот эту штуку:
Смогу сделать только оказавшись рядом на физике. Только на следующей неделе.
PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.
Моя ошибка. Уже исправлено. На момент написания первого сообщения совпадали. Дальше решил играть с политиками и не вернул на место.
- Вложения
-
- com17_5619_20171109_2237.txt
- (143.8 КБ) 1221 скачивание
-
- com17_5619_20171109_2235_success.txt
- (139.19 КБ) 1184 скачивания
-
- Разработчик
- Сообщения: 11852
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: COM порт на терминале в другой подсети
Чёт я запутался
Первый IRP_MJ_WRITE пишет байт со значением 0x05. Затем у железки читают по одному байту три раза: 0x06, 0x02, 0x17. Затем из железки читают сразу 24 байта (FC000000010B0700D8D2D0C8D52DCCC8CDC82DD4D02DCAC3), и железка во всех четырех логах отдаёт одну и ту же последовательность.
В первой паре логов в success последовательность читалась в три приема, потмоу как слишком быстро её запросили, а в неудачном логе запросили через ~0.3 секунды, и она прошла за одно чтение.
Во второй паре логов - наоборот. В success все 24 байта считались за раз, а в неудачном читались в четыре приёма. Делаем вывод: читать за раз или по частям - значения не имеет.
Дальше, лог com17_5619_20171109_2235_success.txt: в порт пишется байт 0x06, затем сразу же ещё раз пишется 0x05, читается те же три байта по байту, читается те же 24 байта. Опять пишется 0x06, затем 0x05, затем читается три байта, затем читается те же 24 байта, и так ещё несколько циклов. Затем порт закрывается. Именно это происходило в прошлой паре логов в НЕуспешном логе! Ты это, названия файлов не перепутал?
Первый IRP_MJ_WRITE пишет байт со значением 0x05. Затем у железки читают по одному байту три раза: 0x06, 0x02, 0x17. Затем из железки читают сразу 24 байта (FC000000010B0700D8D2D0C8D52DCCC8CDC82DD4D02DCAC3), и железка во всех четырех логах отдаёт одну и ту же последовательность.
В первой паре логов в success последовательность читалась в три приема, потмоу как слишком быстро её запросили, а в неудачном логе запросили через ~0.3 секунды, и она прошла за одно чтение.
Во второй паре логов - наоборот. В success все 24 байта считались за раз, а в неудачном читались в четыре приёма. Делаем вывод: читать за раз или по частям - значения не имеет.
Дальше, лог com17_5619_20171109_2235_success.txt: в порт пишется байт 0x06, затем сразу же ещё раз пишется 0x05, читается те же три байта по байту, читается те же 24 байта. Опять пишется 0x06, затем 0x05, затем читается три байта, затем читается те же 24 байта, и так ещё несколько циклов. Затем порт закрывается. Именно это происходило в прошлой паре логов в НЕуспешном логе! Ты это, названия файлов не перепутал?
-
- Разработчик
- Сообщения: 11852
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: COM порт на терминале в другой подсети
Up: перепутал, ага. В первой паре логов success был на HYPER. Во второй паре логов на HYPER тот что НЕ success.
-
- Разработчик
- Сообщения: 11852
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: COM порт на терминале в другой подсети
В обоих успешных логах от первого WRITE до четвертого READ проходит ~0.008 секунды. И ответ из железки читается в точности одинаковыми кусками. Удивительная синхронность.
В первом неуспешном логе то е время я выше писал: ~0.27 секунды. Во втором неуспешном логе ~0.24 секунды.
В пинг 0.048 секуны охотно верю. Терминал получает команду:
[rdpdr-serial 0] [ 413.542309] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
Шлет ответ:
[rdpdr-serial 0] [ 413.542462] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 0 bytes of data.
Получает следующую команду:
[rdpdr-serial 0] [ 413.590908] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
Как раз через 0.048 секунды! Шлет ответ:
[rdpdr-serial 0] [ 413.591084] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 1 bytes of data.
И получает следующую команду:
[rdpdr-serial 0] [ 413.639638] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
Опять ровно 0.048 секунды. Шлет ответ:
[rdpdr-serial 0] [ 413.639812] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 1 bytes of data.
И следующая команда от сервера:
[rdpdr-serial 0] [ 413.688495] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
0.049 секунды. Как раз пакет доходит до сервера и сервер сразу отдает следующую команду. То же время, что нужно пакету с пингом и обратному пакету с ответом на пинг.
Но почему работает mstsc.exe - непонятно Жду логи portmon, может там какое-нибудьо озарение придет.
В первом неуспешном логе то е время я выше писал: ~0.27 секунды. Во втором неуспешном логе ~0.24 секунды.
В пинг 0.048 секуны охотно верю. Терминал получает команду:
[rdpdr-serial 0] [ 413.542309] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x4 MinorFunction 0x0, 33 bytes in stream.
Шлет ответ:
[rdpdr-serial 0] [ 413.542462] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 0 bytes of data.
Получает следующую команду:
[rdpdr-serial 0] [ 413.590908] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
Как раз через 0.048 секунды! Шлет ответ:
[rdpdr-serial 0] [ 413.591084] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 1 bytes of data.
И получает следующую команду:
[rdpdr-serial 0] [ 413.639638] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
Опять ровно 0.048 секунды. Шлет ответ:
[rdpdr-serial 0] [ 413.639812] [DEBUG] IRP Completion: Device 1, CompletionId 1, IoStatus 0x00000000, result 1, 1 bytes of data.
И следующая команда от сервера:
[rdpdr-serial 0] [ 413.688495] [DEBUG] Recv from RDP: DeviceId 1 FileId 1 CompletionId 1 MajorFunction 0x3 MinorFunction 0x0, 32 bytes in stream.
0.049 секунды. Как раз пакет доходит до сервера и сервер сразу отдает следующую команду. То же время, что нужно пакету с пингом и обратному пакету с ответом на пинг.
Но почему работает mstsc.exe - непонятно Жду логи portmon, может там какое-нибудьо озарение придет.
Re: COM порт на терминале в другой подсети
Доброго дня.
Благодарю за оперативную помощь. С логами разобрался сам.
Пришлось понизить скорость на порту кассы до 4800 и, о чудо, все завелось.
Выяснилась еще моя досадная ошибка. Касса, которая работает через mstsc имеет скорость 115200 и вовсе другой модели. На следующей неделе попробую ее подключить и, если интересно, опишу процедуру.
Еще раз выражаю огромную благодарность за оперативную помощь.
Благодарю за оперативную помощь. С логами разобрался сам.
Пришлось понизить скорость на порту кассы до 4800 и, о чудо, все завелось.
Выяснилась еще моя досадная ошибка. Касса, которая работает через mstsc имеет скорость 115200 и вовсе другой модели. На следующей неделе попробую ее подключить и, если интересно, опишу процедуру.
Еще раз выражаю огромную благодарность за оперативную помощь.