Григорий Бондаренко

16 dBi это очень хорошее усиление, как у маленькой тарелки. У вас могут быть проблемы со связью вот какие (сначала с меньшей вероятностью):
1. Станция ну очень далеко, и даже за краем горизонта и ландшафт попадает в зону Френеля увеличивая затухание.
2. Станция не так далеко, но в зоне Френеля деревья, скалы, печные трубы, Годжира.
3. Вы неправильно установили антенну и у вас поляризация антенны не совпадает с базовой станцией (MIMO две антенны под 90 градусов, каждая по 45 к горизонту)
4. Фидер длиннее нужного или тонкий -- всё усиление остается в нем, менять фидер, переносить трансивер к антенне. И пигтейлы должны быть прям качествоенно соединены и быть коретенькими.
5. И конечно же, что там за камера? Что у нее за антенны штатные, две ли их? (должно быть, а то че за LTE?). Не проверить ли с этой антенной другое LTE устройство, особенно на коротких кабелях?

Вот ещё что нашёл
https://isazonov.wordpress.com/2020/04/24/usoclien...

UsoClient StartInstall

Если для feature update сработает, будет замечательно

Ещё можно поискать в коде 1.6.1.1 эти две строки
и добавить к ним третью, похоже, это главное что отличает старую и новую версии.

$objInstaller = $objSession.CreateUpdateInstaller()
$objInstaller.Updates = $objCollectionTmp

$objInstaller.IsForced = $true

Безопасность программного рейда не сильно отличается от аппаратного, но программный рейд позволяет создавать очень гибкие конфигурации, например рейд поверх iscsi дисков, размещенных на разных физических машинах (а это уже повышение надежности, так как выход из строя машины к примеру из-за пожара может чисто территориально не повлиять на другие диски).

У программного рейда наверное есть только одна проблема касаемо надежности - отсутствие энергонезависимого кеша на запись (но никто его и не включает на win), но и не все аппаратные такой имеют. Еще аппаратный может комплектоваться со своим кешем на чтение и своими алгоритмами оптимизации доступа, что повышает скорость результата - т.е. в итоге это вопрос производительности а не надежности.

Зато такие вещи как вендорлок у аппаратных рейдов - создают невероятно большую. головную боль и генерируют лишние траты денег (зачастую очень большие)

Вообще такое поведение было больше характерно для старых рейд контроллеров.
Лично сталкивался с тем, что первый диск в рейде 1-м считается главным. И соответственно все действительно рушилось, если первый диск рушился. Решалось выставлением второго диска в место первого при сбое и заменой диска, но да бага была.
А вообще сейчас это больше зависит от реализации рейда, точнее его логики. Софтовый рейд может действительно не загрузиться, так как рейд в системе включается только когда загружен драйвер, соответственно до его включения система как-то должна стартовать. Раньше решалось прописыванием загрузчика на второй диск и загрузкой с него.
И еще софтовый рейд не может быть загрузочным, если он не зеркало, т.е. вские raid 0,5,6 и далее - не могут стартовать систему.

Но у софтового рейда есть другая проблема. а именно резервирование производительности.
т.е. его нельзя ставить на системы с высокой нагрузкой...
Поясню: драйвер это по сути программа, с большим приоритетом но программа, т.е. предположим, что вы загрузили свой сервер задачами, которые сильно эксплуатируют диск, память и проц. и в итоге у вас драйвер окажется вытеснен из списка активных задач или памяти - в этот момент у вам все встанет.
Еще одной проблемой может встать восстановление... Помнится мой софтовый рейд 5 из 4-х дисков при восстановлении диска упал в производительности в 16 раз...

Система зависает, т.к. не может произвести операцию чтения/записи. После перезагрузки сервера автоматически запускается ресинхронизация дисков,

1.Странно, что система зависает, если не может произвести любую операцию с диском.
2.Странно, что софт не проверяет целостность дисков перед ресинхронизацией.

Крайне сомнительные строки у автора статьи...

я стал искать информацию, подтверждающую/опровергающую данное утверждение. И не смог найти.

не удивительно...

https://openvpn.net/faq/tls-error-tls-key-negotiat...

В вашем случае очень похоже на последний пункт:

Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.

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

Однако сходу приходит в голову сценарий в котором в доверенном браузере, имеющем подпись, запускается вредоносный Javascript. Или, например используется java environment, который может выполнить jar с вредоносным кодом. Или любой другой похожий сценарий, в котором некое доверенное ПО выполняет некий код третьей стороны. В условиях ограниченных учёток это, скорее всего, не приведёт к неработоспособности системы, но вот данные в папках, доступных пользователю, можно потерять. Насколько для вас это критично -- нужно смотреть по вашей модели угроз и оценивать риск. Может быть и так, что, условно, при ежедневном резервном копировании данных пользователя риск потери данных, накопленных за день, ниже, чем затраты на антивирус.

Ну и риски уязвимостей в механизмах безопасности ОС, разумеется, тоже никто не отменял.

Главный вопрос - почему информация о звонке приходит на UDP? Как реализован контроль доставки? Где гарантии, что пакет не потерялся? То есть, сюда просится TCP со всеми наворотами, вроде heartbeat, keep-alive и контроллеров.

И да ответ "у нас ethernet, пакеты не теряются" никуда не годится. Даже на loopback пакеты с удовольствием могут теряться.

А так, это задачка по Qt джуну на один-два вечера.