/**** Кратко говоря - нытьё об этом *****/Надеюсь, они всё практически обернули в какую-то форму структурированной обработки исключений, если это всё ещё актуально. Android (12 лет назад, основная ветка) и многие ветки Linux задолили исправление time_t для 64-бит давным-давно, почему в здравом уме и теле Ubiquiti всё ещё на interop-компонентах, использующих 32-битное значение, интересно? Большинство предварительных проверок компиляции это поймают (я исправил, наверное, сотни, если не тысячи таких, в конце 90-х, в коде ОС), потому что довольно легко сломать компонент, если коммуникационную конструкцию (пакет, контрольную сумму, что угодно) можно внедрить, чтобы она пришла раньше, чем была отправлена, вызывая всякие проблемы, вроде деления на ноль и многое-многое другое.Я понимаю проблему с абстрактным кодом, особенно с JIT, и, может быть, всё это обернуто в обработку исключений (снова, можно только надеяться), но это стоит ОЧЕНЬ много циклов CPU для каждого пойманного-обработанного исключения, это буквально может вызвать DoS в многих случаях. Не то чтобы не существует (code) scrubbers для этого типа вещей для JIT-кода, на протяжении ТАКИХ долгих лет.Стоило бы убрать все конструкции, которые зависят от 32-битных значений, независимо от природы, учитывая чрезвычайно высокий риск или стоимость их обработки в противном случае. Меня бы выставили за дверь, если бы что-то подобное сохранилось и в 2000-е, исходя из моего опыта./**** Кратко говоря - нытьё об этом *****/Иногда я действительно поражаюсь решениям UI-инженеров, например, супер-старый менеджер памяти в версиях 1.x новых UDM, который сохранялся более года и вызывал МНОГО-МНОГО сбоев из-за утечек, вызывающих сбои из-за нехватки физической памяти даже для управления указателями на подкачанный heap. Это попадает в ту же категорию, и, возможно, даже более рискованно, если кто-нибудь выяснит пути внедрения для этого, учитывая количество UI-based Controllers там, насколько я понимаю???Я быстро поискал и мне понадобилась всего минута, чтобы найти недавний (не исправленный до корня) CVE: Высокорискованная уязвимость, затрагивающая UniFi Network Server | Cybernews

Разработчики часто забывают про такие ограничения, особенно если работают с фреймворком, который скрывает детали, например, представление значения времени. До реальной проблемы нам ещё как минимум 10 лет, а решение вполне известно (использовать 64-битные значения времени). Уверен, до этого дойдут.

Вероятнее всего, причина в этом… https://en.m.wikipedia.org/wiki/Year_2038_problem. Это известная проблема в среде разработчиков. Зачем создавать правило с пользовательским расписанием, которое будет работать так далеко в будущем, если можно просто использовать опцию "Каждую неделю"?

@khtadmin Думаю, это, скажем так, "решено" (свободно использую этот термин) для @cb9501, если я правильно понимаю? Установи период на 2038 год и вернемся к этому через 14 лет... 🙄 😁 Надеюсь, кто-нибудь в UI обратит на это внимание (отмечен выше) и хотя бы попытается разобраться, а пока попробуем выяснить, это сдвиг побитово или какая-то проблема с лимитом, особенно учитывая, что это может повлиять на другие вещи, в зависимости от того, как здесь используется функциональность работы с датами?

Возвращаюсь к этому вопросу, так как сегодня вечером ещё немного покопался. Я удалил все свои правила и создал два новых. Один из протестированных работал, НО… приостановка и повторное включение того же правила как будто не работали, и моё устройство было заблокировано даже после удаления связанного с ним правила. Я удалил первое правило, которое применялось к другому устройству, и у моего устройства (не связанного с этим правилом) снова появился доступ в интернет. Я попробовал сделать наоборот, и столкнулся с похожими проблемами при попытке приостановить и повторно включить правило, а также при создании новых. В итоге моё устройство было навсегда заблокировано от интернета (локальная сеть работала отлично) до тех пор, пока я не удалил все правила. Может, кто-нибудь другой сможет попробовать создать два правила и несколько раз приостановить и повторно включить одно из них, чтобы попробовать воспроизвести эту проблему? Кажется, иногда правило начинает действовать только через 15-30 секунд, и нужно нажимать кнопку "Готово" после приостановки/повторного включения. Это всё, что мне удалось заметить. Спасибо!

@khtadmin Я только что провёл тест и посмотрел логи демона. API моста (предположительно, связующее звено между абстрактным уровнем и БД) не обрабатывает вызов API и возвращает неверный диапазон дат. У меня возникает желание запустить API-explorer и завалить его кучей запросов, просто чтобы посмотреть, что произойдёт. Надеюсь, у того, кто отвечает за тестирование этих компонентов, уже есть какие-то стресс-тесты или тесты на сбой, как минимум.

Редактирую: Я провёл это ещё несколько раз (написал простенькую автоматизацию для веб) и это приводит к сбою и перехватывает исключение в функции вроде set_inform_interval (могу показать полностью декорированные вызовы/стек, если кому-то интересно). Это, по-видимому, запускает обновление глобального интервала кэша — мгновенное обновление, вероятно, чтобы нормализовать неудачный диапазон дат, полагаю.

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

Мой вариант, не имея доступа к исходному коду/символам (или, честно говоря, хороших навыков отладки Linux), заключается в том, что значения в БД — 32s, а промежуточный API защищает их с помощью обработчика исключений там. Ставлю, что если вызвать, скажем, 10k таких запросов, то очень плохие вещи произойдут, особенно на контроллере с ограниченными ресурсами.