Windows-терминалы WTware

Программа-клиент службы терминалов Windows Terminal Services, для бездисковых терминалов и загрузки по сети. Основной сайт http://www.wtware.ru
Текущее время: Сб ноя 18, 2017 3:58 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 9 сообщений ] 
Автор Сообщение
СообщениеДобавлено: Ср ноя 08, 2017 4:41 pm 
Не в сети

Зарегистрирован: Вс ноя 05, 2017 11:56 am
Сообщения: 4
Доброго дня.
Ситуация относится к 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 все работает как нужно.

Сервера настроены одинаково. Политики безопасности совпадают до последней запятой, как и пакеты обновлений. Сервера в обоих случаях виртуальные.


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Ср ноя 08, 2017 8:37 pm 
Не в сети
Разработчик
Разработчик

Зарегистрирован: Ср окт 01, 2003 12:06 am
Сообщения: 8962
Откуда: Роcсия, Тольятти
Напиши:
serial = com17(com1),debug

Запусти тест на одном сервере, как можно меншьше действий до первой ошибки. Сохрани лог.

Запусти тест на втором сервере. В точности те же действия.

И покажи оба лога.

И втварь возми последнюю. Работать от этого не начнет, но мне будет легче читать лог.


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Ср ноя 08, 2017 10:35 pm 
Не в сети

Зарегистрирован: Вс ноя 05, 2017 11:56 am
Сообщения: 4
Готово.
com17 - неудачная на удаленном сервере.
com17success - удачная на локальном.
В обоих случаях запускал проверку связи в драйвере FR.
Как только получал ответ, положительный (наименованием модели и номер фискального регистратора) или отрицательный (ошибка -1)


Вложения:
com17success.txt [142.36 КБ]
6 скачиваний
com17.txt [138.63 КБ]
6 скачиваний
Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Чт ноя 09, 2017 1:25 pm 
Не в сети
Разработчик
Разработчик

Зарегистрирован: Ср окт 01, 2003 12:06 am
Сообщения: 8962
Откуда: Роcсия, Тольятти
Смотрю время от первой команды сервера "запиши в порт" до четвертого чтения из порта. Сначала три байта читаются по байту, видимо по ним определяется длина блока, и затем делается четвертое чтение на 24 байта.

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.27 секунды.


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


0.008 секунды.


Разница на полтора порядка. Тот, который success - быстрее. В логе success 24 байта читаются из порта в три приёма, потому что к моменту прихода запроса они ещё не были приняты. Во втором логе читается одной пачкой, значит лежат в очереди. Не знаю, как это может влиять, пока только различия осознаю.

Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?


Затем вторая запись:

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.32 секунды после первой записи.

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 .


Через 0.018 секунды после первой записи.

На вторую запись железка отвечает по-разному. Причем пишется в обоих случаях один и тот же байт со значением 0x06. В успешном логе на этот байт железка отвечает во второй раз иначе. В неуспешном логе на этот байт железка и в первый, и во второй раз отвечает одинаково. Вот бы разработчиков железки пнуть...

Различие именно в реакции железки. Т.е. таймаут на виндовсе ничего не значит. Надо искать таймаут, или интервал ожидания, который пропишется в железку.


А давай ещё один эксперимент. Вот эту штуку:

https://docs.microsoft.com/en-us/sysint ... ds/portmon

Запусти на WinXP с железкой. И сними такие же логи обменов с обоими серверами. Интересно интервалы сравнить.

PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.

PPS: и сделай ещё один лог с дальним сервером вот от этой сборки:

http://pxe.ru/files/testing/201711091508.zip


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Чт ноя 09, 2017 10:45 pm 
Не в сети

Зарегистрирован: Вс ноя 05, 2017 11:56 am
Сообщения: 4
Поставил новый релиз.
Сделал первые тесты и сохранил логи. Прошу прощения за мусор в них, не успел сделать чистый. Машина не вернулась из третьего после установки обновления ребута.


Железка работает с портом на скорости 19200. А нельзя сделать скорость ниже?
Чисто теоретически можно. Но это то еще шаманство


А давай ещё один эксперимент. Вот эту штуку:
Смогу сделать только оказавшись рядом на физике. Только на следующей неделе.


PS: и политики безопасности НЕ совпадают. На дальнем сервере включена NLA. Это никак не должно быть связано с работой ком-портов, просто деталь из лога.
Моя ошибка. Уже исправлено. На момент написания первого сообщения совпадали. Дальше решил играть с политиками и не вернул на место.


Вложения:
com17_5619_20171109_2237.txt [143.8 КБ]
6 скачиваний
com17_5619_20171109_2235_success.txt [139.19 КБ]
6 скачиваний
Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Пт ноя 10, 2017 10:18 pm 
Не в сети
Разработчик
Разработчик

Зарегистрирован: Ср окт 01, 2003 12:06 am
Сообщения: 8962
Откуда: Роcсия, Тольятти
Чёт я запутался :(

Первый 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 байта, и так ещё несколько циклов. Затем порт закрывается. Именно это происходило в прошлой паре логов в НЕуспешном логе! Ты это, названия файлов не перепутал?


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Пт ноя 10, 2017 10:20 pm 
Не в сети
Разработчик
Разработчик

Зарегистрирован: Ср окт 01, 2003 12:06 am
Сообщения: 8962
Откуда: Роcсия, Тольятти
Up: перепутал, ага. В первой паре логов success был на HYPER. Во второй паре логов на HYPER тот что НЕ success.


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Сб ноя 11, 2017 12:19 am 
Не в сети
Разработчик
Разработчик

Зарегистрирован: Ср окт 01, 2003 12:06 am
Сообщения: 8962
Откуда: Роcсия, Тольятти
В обоих успешных логах от первого 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, может там какое-нибудьо озарение придет.


Пожаловаться на это сообщение
Вернуться к началу
СообщениеДобавлено: Пт ноя 17, 2017 5:30 pm 
Не в сети

Зарегистрирован: Вс ноя 05, 2017 11:56 am
Сообщения: 4
Доброго дня.
Благодарю за оперативную помощь. С логами разобрался сам.
Пришлось понизить скорость на порту кассы до 4800 и, о чудо, все завелось.
Выяснилась еще моя досадная ошибка. Касса, которая работает через mstsc имеет скорость 115200 и вовсе другой модели. На следующей неделе попробую ее подключить и, если интересно, опишу процедуру.
Еще раз выражаю огромную благодарность за оперативную помощь.


Пожаловаться на это сообщение
Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 9 сообщений ] 

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 6 гостей


Вы можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB