как ломануть 1C 8.3 for Linux

[deniskhodus]

Добрый день.
Спасибо за ответы.
1. Про KEEPALIVE и UDP - нужно было написать "KEEPALIVE" в кавычках, т.к. я не имел в виду особенность протокола TCP (и, будучи серверным админом и сетевиком циско, как работает UDP я знаю). Под "KEEPALIVE" я имел в виду запрос-ответ от клиента к HASPLM вида "ей, я жив, ключ тоже?", который (запрос) на HASPLM, среди прочего, сбрасыват таймер таймаута "живости" клиента. Дак вот под виндой оно каждые 2,5-3 минуты проходит, а к никсовому серверу HASPLM - нет. Кроме того, обмен пакетами UDP проходит довольно весело и уверенно при запуске клиента, при этом совершенно ничего не посылается в сторону HASPLM после запуска вплоть, включая, подыхание клиента 1С (т.е. клиент 1С перед возникновением ошибки KEYWASLOST в сторону HASPLM ничего не посылает).
Для вопроизвдения:
а) Берем линуксовый HASPLM с сетевым ключем;
б) Берем чистую машинку на Windows (7,8,10, мы пробовали на 7 и на 2012) - важно виндовую, потому что линуксовый клиент 1С работает без нареканий.
в) На этой машинке, при остановленных службах вида обновлений (они жрут ресурсы), с 0,5% использования ЦП, запускаем клиент 1С и файловую базу (или серверную, но запретив пользовать лицензию с сервера предприятий)
г) Просто ждем. Делать в базе что-либо вообще не обязательно. Неважно - вы будете в базе работать или просто смотреть на стартовый экран после запуска, не нажав в клиенте ни единой кнопочки, эти 2 минуты не трогая мышку и клаву - по истечении 2х минут клиент 1С вываливается с ошибкой KEYWASLOST. Потребление ресурсов при этом на уровне плинтуса - т.е. никакого. Проверено как на живых машинах, так и на виртуалке (правда на виртуалке с 2012R2).
Если бы дело было в загрузке ЦП и невозможности время от времени клиентом отправить UDP запрос - то тогда запрос от клиента хотя бы иногда приходил бы на сервер HASPLM. Мы третий день бьемся с проблемой и в 100% случаев клиент, после запуска, не общается больше с сервером Linux HASPLM вообще, просто вываливаясь с ошибкой KEYWASLOST.

ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует. Как, например, вечная ошибка клиента 1С в том, что по IP-шнику это чудо работать не умеет (топаем в hosts и прописываем IP=hostname ибо если клиенту сказать "Сервер предприятия на 10.5.16.12", то клиент скажет "ээээ, я не могу найти сервер my1cserver12") - вот из этой же оперы - клиент втупую через жопу работает с HASP.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем. В 1С я НЕ верю.

ЗЫ. За подсказку про автономный сервер спасибо. Почитаю посмотрю. Правда это все равно пахнет нелицензионностью, если честно. А мы пытаемся не ломануть лицензии, а убрать из уравнения ненужные машины, в данном случае - на винде. И тема найдена по поиску вида "Ключ защиты более недоступен". Хотя, если честно, почитав назад - мне было довольно интересно.

Еще раз спасибо.

[leov-001]

Добрый день.
ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует. Как, например, вечная ошибка клиента 1С в том, что по IP-шнику это чудо работать не умеет (топаем в hosts и прописываем IP=hostname ибо если клиенту сказать "Сервер предприятия на 10.5.16.12", то клиент скажет "ээээ, я не могу найти сервер my1cserver12") - вот из этой же оперы - клиент втупую через жопу работает с HASP.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем. В 1С я НЕ верю.
Еще раз спасибо.

Сотанавливаем сервер 1С
Идем /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 в файле 1CV8Clst.lst hostname меняем на ip-шник

[HPDX2300]

Дак вот под виндой оно каждые 2,5-3 минуты проходит, а к никсовому серверу HASPLM - нет. Кроме того, обмен пакетами UDP проходит довольно весело и уверенно при запуске клиента, при этом совершенно ничего не посылается в сторону HASPLM после запуска вплоть, включая, подыхание клиента 1С (т.е. клиент 1С перед возникновением ошибки KEYWASLOST в сторону HASPLM ничего не посылает).
Для вопроизвдения:
а) Берем линуксовый HASPLM с сетевым ключем;
б) Берем чистую машинку на Windows (7,8,10, мы пробовали на 7 и на 2012) - важно виндовую, потому что линуксовый клиент 1С работает без нареканий.
в) На этой машинке, при остановленных службах вида обновлений (они жрут ресурсы), с 0,5% использования ЦП, запускаем клиент 1С и файловую базу (или серверную, но запретив пользовать лицензию с сервера предприятий)
г) Просто ждем. Делать в базе что-либо вообще не обязательно. Неважно - вы будете в базе работать или просто смотреть на стартовый экран после запуска, не нажав в клиенте ни единой кнопочки, эти 2 минуты не трогая мышку и клаву - по истечении 2х минут клиент 1С вываливается с ошибкой KEYWASLOST. Потребление ресурсов при этом на уровне плинтуса - т.е. никакого. Проверено как на живых машинах, так и на виртуалке (правда на виртуалке с 2012R2).
Если бы дело было в загрузке ЦП и невозможности время от времени клиентом отправить UDP запрос - то тогда запрос от клиента хотя бы иногда приходил бы на сервер HASPLM. Мы третий день бьемся с проблемой и в 100% случаев клиент, после запуска, не общается больше с сервером Linux HASPLM вообще, просто вываливаясь с ошибкой KEYWASLOST.

ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем.

вот тут есть
Инструкция по эксплуатации программных продуктов «1C» и ключей защиты HASP
там, в частности, написано более подробно чем в доке "одинсек" про параметры таймаутов nethasp.ini:
"...Если часть маршрута между запускаемой программой и ключами HASP проходит через Интернет или на ключе более 100 лицензий, могут возникнуть проблемы с тайм-аутами при доставке
пакетов. Время ожидания ответа можно регулировать с помощью параметров NH_SESSION и NH_SEND_RCV. По умолчанию они закомментированы, и их значение составляет 30 и 5 секунд
соответственно. Таким образом, делается 6 попыток найти ключ по 5 секунд каждая. При необходимости Вы можете увеличить эти параметры...."

т.е. величина NH_SESSION кратна величине NH_SEND_RCV (NH_SESSION = NH_SEND_RCV * K, где K целое число ). Если указать величны NH_SESSION < NH_SEND_RCV , то как-бы ничего не должно перепосылаться. Этот момент совершенного не освещен в доке "одинсек".

еще вот этот момент в Working_with_HASP_and_1C.pdf :
"1C 8.x работает только по UDP. Однако ее можно заставить использовать TCP неявно. Для этого, помимо того, что описано выше, необходимо разрешить в свойствах протокола TCP/IP (Properties - Advanced - WINS) поддержку NetBios over TCP/IP на рабочих станциях, где работает защищенное приложение и на машине, где установлен ключ."



а следующий параграф ''HASP4 и "зависшие" сессии'' о многом говорит:
"Система защиты HASP4 устарела и была снята с поддержки в 2006 году, с тех пор для неё ничего не дорабатывалось. В менеджере лицензий 8.32 периодически возможно "зависание части лицензий", происходящее из-за некорректного завершения сессии с ключом."

Между исх.кодом платформы и HASP-ключом есть очевидная "прослойка" - "HASP API" (его исходники называются примерно так - "HASP SDK") + "HASP LM".
Следы "HASP API" легко находятся в либах, работающих с HASP-ключом.
Например, используя тулзу strings увидим в backbas.dll строки с названиями функций из "HASP API" (бублично доступен только .h файл с прототипами функций):
HASPAPI_VERSION
LOCALHASP_HASPSTATUS
LOCALHASP_HASPCODE
LOCALHASP_ISHASP
LOCALHASP_DECODEDATA
LOCALHASP_ENCODEDATA
NETHASP_ENCODEDATA
NETHASP_DECODEDATA
NETHASP_LASTSTATUS
NETHASP_SETIDLETIME
NETHASP_HASPCODE
NETHASP_READBLOCK
NETHASP_HASPID
NETHASP_GETPROTOCOL
NETHASP_SET_SERVER_BY_NAME
NETHASP_SET_CONFIG_FILENAME
NETHASP_HASPQUERYLICENSE
NETHASP_DEFAULTCONFIG
NETHASP_SETPROTOCOL

на сайте вендора HASP4 написано, что он похерен и не поддерживается с 2006 года - парни из "один сек" не будут париться и самостоятельно ковыряться в коде "HASP API", да ещё наверняка там не все идет в сорцах, и некоторые либы могут поставляться в скомпилированном виде - бери и используй при сборке (линковке) приложения.
Вообщем, "удаление гланд автогеном через анальное отверстие"