Le ecureuil

Тогда рассказывайте какие протоколы использует Reolink. Скорее всего с multicast у вас ничего не получится.

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

На 64 и 128 устройствах нужно включать zram. Сделаем автовключение перед бетой.

Потому что очень желательно иметь камеры в сети сервера, так проще настроить доступ. По мощности все равно будет ограничение в самом слабом звене - у вас в обоих случаях 1211 им является.

Да, лучше на 1211.

Поставить как минимум 2.15 stable.

Нет, это костыль для макбуков чтобы нормально каналы верхние в 5 ГГц виделись и ac включался.

А если попробовать ac выключить?

А что за устройство?

Да, sys был лишний в начале. > system set net.netfilter.nf_conntrack_udp_timeout 1800 > system set net.netfilter.nf_conntrack_udp_timeout_stream 1800

Так ничего в кирпич не превратилось. Проблему видно, и понятно как решить (особенно если вы уж полезли в скрытые галки).

Даже вот и интересно: а как должно все работать, если совсем нет DNS?

Только целиком выключить.

Начните с включения ppe hardware и system set. Если не поможет, то да, self-test в момент обрыва.

Еще можете попробовать воткнуть что-то типа > system set net.sys.netfilter.nf_conntrack_udp_timeout 1800 > system set net.sys.netfilter.nf_conntrack_udp_timeout_stream 1800 Если это поможет при включенном ppe hardware, то сохраните настройки и используйте в таком виде.

Но скажу сразу что шанс починки пока я оцениваю как низкий, потому что если это аппаратная особенность, то только выключение поможет.

Видимо это из-за использования порта 4500 для IPsec (используется для vowifi). Можете скинуть self-test когда все ок, и оба говорят, и еще один self-test, когда кто-то перестал нормально работать?

В delta собрано 3.6.8, попробуйте обновиться и проверить.

Спасибо за наблюдения. Мы сами только вот на прошлой неделе увидели это, потому разбираемся.

Я не сказал что mac высечен в железе, я написал что его нельзя менять командой. Он зависит от того, что стоит на AccessPoint0, и высчитывается по определенному алгоритму. Этого ожидает железо, если задать свои ничего просто не будет работать. То есть произвольно задать mac на WifiStation нельзя, можно только сменить на AccessPoint0, и все остальные mac-и сами пересчитаются и установятся как нужно.

Да, именно об этом было исправление. Там еще особенность, что эти устройства - BE, а mac присваивался из LE без конверсии, оттого он не соответствовал напечатанному на коробке.

Uncategorized - это не распознано вообще, pace2 не выдал никакого нерезультата (или еще не выдал, не успел). А "Другие приложения" - это такая категория, в которую pace2 поместил трафик, явно сказав что не может распознать или же то, что не уместилось в Top 5.

На WifiStation нельзя менять mac - это ограничение железа.

Если это киоск или там офис из 3 человек, то какие проблемы в удаленном администрировании кроме самодурства руководства? Или все серьезно и никому вообще нельзя к сетям прикасаться кроме админов (даже свет выключать без их разрешения), или все можно отовсюду - а остальное фарс.

Все равно не вижу тут disaster recovery план. Когда я работал админом у нас любое действие (обновление ОС, сервера, перенос свитчей или перенастройка, что угодно в продакшене) всегда начиналось с разработки disaster recovery и его отработки в деталях и по времени. Хотя у нас production был часто довольно условный - поликлиника, работающая с 8 до 16 например - за ночь можно починить - но все равно когда что-то внезапно шло не по плану обязательно расследовалось, чтобы не повторялось. А тут какая-то важная система, и на ее судьбу влияет левая тетенька, которая совершенно ничего не сможет сделать если что-то пойдет не так. При этом удаленное администрирование запрещено. Не могу понять, что это за пример такой. Можно живое предприятие (без конкретного названия)? А то похоже на самодурство и перегибание начальства или ИБ, которые с другой стороны не понимают последствий.