Данная проблема с подключением к зашифрованной базе при наличии антивирусника проявляется на windows 7, преимущественно home basic/premium. Пользователи, которые ставили на ту жу машину windows 10 или обновляли 7 до 10 не получали подобной проблемы при той же версии антивирусника, что был и на 7-ке. Докопаться до истины проблемы мешает короткий сеанс связи с пользователем, ибо нужно сидеть с их ПК целый день. Пробовал у себя на виртуалке VM ставить win 7 home premium и антивирусники, с которыми есть проблемы, - все работает, никакой ошибки нет.

Симонов Денис, проблема проявляться на многих антивирусах. Там ни исключения не помогают, ни настройки встроенного браундмауэра антивирусника. Была предпринята попытка продемонстрировать ошибку и передать все необходимые сведения тех. поддержке Касперского - после передачи нашего запроса разработчикам Касперского всё затихло.

Нас интересует, есть ли возможность у разработчиков Firebird оказать тех. поддержку по этой проблеме или что-то конкретно для нас "допили", чтобы не ждать обновления. Естественно за отдельную плату, которую можно обсудить. Еще раз напоминаю, что проблема проявляется при подключении к ЗАШИФРОВАННОЙ БАЗЕ. Происходит какой-то сценарий, который вынуждает разные антивирусники реагировать.

hvlad, Приветствую. Используется шифрование базы данных с помощью плагина, написанного Tonal . Подключение к базе данных идет сначала в делфях, затем в c#. Под рукой у нас сейчас есть система на windows 7 , в которой эта проблема воспроизводится с установленным kaspersky total security (могло закончиться действие триала, но восстановим). Также она возникает(ала) на других антивирусниках: nod32, norton, avast, была один раз на avg. Причем не на каждой системе такое происходит. Очень часто возникает на win7, на win10 было замечено всего один раз. Там даже выгрузка антивирусника не помогает, только полный снос. Собственно, в программе возвращается callback return 0 . То есть плагин не получил нужный буфер с ключом от firebird как я понимаю. У пользователей в логах чаще было через раз: то ошибка вернулась при установке соединения в делфях, то в c#. В делфях реализованы попытки подключения по localhost, inet4, inet6, если были неудачные попытки. В c# - только одна строка подключения. Я у одного пользователя ради теста запускал тестовое делфи приложение, которое просто выполняет попытки подключения под разными строками подключения. На всех одинаково с частотой возникает. Иногда у новых пользователей коннект успешный никогда не происходит, то есть ошибка всегда появляется при антивируснике. Чаще бывает, что после 10 попыток одна удачная может произойти. Firebird 3.0.4 32-bit superclassic

Собственно, Tonal предлагал в этой теме реализовывать XNET в .net-провайдере с мыслью что это может решить проблему. Но мы решили проверить подключение к ЗАШИФРОВАННОЙ БАЗЕ через XNET в DELPHI и обнаружили баг - возвращается всегда callback return 0 . Я добавил эту проблему в трэкер - по ней тишина, она ни кому не назначена для решения. В трекере .net-провайдера я добавил New Feature на реализацию xnet - Jiri Cincura уже ей заниматься. То есть пока не удалось проверить есть ли ошибка подключения при антивируснике к зашифрованной базе через XNET .

kdv, я не стал их еще раз писать, потому что в этой теме уже они были, hvlad отправил сам нас в трекер. Но раз Вы не видели, то вот:
http://tracker.firebirdsql.org/browse/DNET-881
http://tracker.firebirdsql.org/browse/CORE-6055

kdv, имел бы опыт подобных сообщений - написал бы более содержательнее. А так как смог, так и написал. Это проблеме уже скоро год будет, после того как написал в трекере переключился на другие вещи, поэтому начал некоторые вещи подзабывать, связанные с данной проблемой.

Нет, не пробовали. Попробуем. Исходники нашего плагина я Вам отправлю. С виртуалкой проблемной машины - не все так просто, есть ошибки при конвертации, будем стараться вытащить её.

hvlad, как с Вами связаться для отправки исходников плагина?

Забыл здесь написать, что проблема была решена. Огромная благодарность hvlad , с которым мы взаимодействовали дальше по почте. Его предположение подтвердилось. Необходимо было уменьшить размер переменных, содержащих путь к приложению и путь к модулю, структуры буфера в нашем плагине шифрования базы данных.



Данное изменение было внесено в структуру плагина и в эту же структуру в самой программе. После этого ошибка callback return 0 перестала возникать при наличии антивирусника.
Вот подробный ответ hvlad по поводу данного момента:
hvladПроблема в том, что колбек криптоплагина вызывается сервером асинхронно. Из-за этого
ответ от клиента (с ключём шифрования) приходит в сервер "вне очереди" - а для таких
пакетов у нас есть требование (наверное не документированное, увы) - они должны целиком
помещаться в один физический сетевой пакет. Это связано с тем, как организован наш
сетевой сервер. И по этой же причине, кстати, нет поддержки сетевых колбеков для других
протоколов (xnet, wnet). В будущем это будет улучшено, но сейчас при получении не полного
асинхронного пакета он тихо отбрасывается (тоже не лучший вариант). Откуда появляются
не полные пакеты: TCP имеет право фрагментировать сегменты, превышающие размером MTU.
Он это обычно делает, но очень странно видеть такую фрагментацию на localhost'е. Скорее
всего, антивирус является косвенной причиной для появления такой фрагментации - наверняка
он как-то вмешивается в сетевой стек и добавляет свою обработку, приводящую в итоге к
фрагментации пакетов даже на localhost. Типичное значение MTU - 1500 байт. У вас изначально
размер пакета был 4148, теперь стал 1072