Паспорт генерации изображения
Промт генерации изображения
Dark neon 'underside of progress' scene, cyberpunk workshop mood. A glowing teal-cyan pipe-connection stretched between a small camera and a server, alive and established, pulsing connected; but the data flow of warm amber capsules stalls at the very entrance and will not pour in: the pipe glows, inside a ringing emptiness; cold established channel versus amber flow that never came. Tangled fiber cables, blinking port LEDs, condensation on metal, quiet machine room, rain-on-glass. Deep shadow, volumetric haze, warm amber and cyan color palette, shallow depth of field, cinematic film still on 35mm, intricately detailed, ultra-detailed, fine textures, rich layered background, ornate mechanical detail, sharp focus, moody atmosphere.
Сессия жива, логи чисты, файлов нет - история о том, как «здоровый» сервер может оказаться абсолютно бесполезным.
Домашняя камера пишет кольцевой архив на microSD: карта маленькая, перезаписывается за пару суток, и любое интересное событие рискует стереться раньше, чем я до него доберусь. Логичный шаг - отдать запись на домашний сервер, тем более что у камеры есть штатная функция NAS. Дальше всё должно было быть скучно.
Статус в приложении Mi Home говорит: «Нормальное состояние передачи». Камера зашла на сетевую шару, создала свою папку xiaomi_camera_videos и затихла. Проходит двадцать минут, затем сорок - в папке пусто. Ни одного видеофайла, ни одного лога. При этом связь не обрывается: камера считает, что всё в порядке, сервер считает, что клиент подключён.
Тишина в папке при живом соединении - это самый раздражающий вид поломки. Ты не видишь ошибки, ты видишь отсутствие действия.
Поиск виноватых по привычке
Первой пришла мысль о «раскачке». Бывает, что и брендовый китайский ноунейим стартует медленно: буферизация, проверка прав, долгий первый пакет. Решил подождать. Заварил чай. Спустя сорок минут чай кончился, тишина стала абсолютной.
Окей, переключился на протоколы. В памяти всплыло, что старое железо или специфические прошивки до сих пор требуют SMB1. Это дырявый, небезопасный стандарт, который в нормальном мире давно похоронили. Но здесь я был готов на любые костыли, лишь бы ЗАРАБОТАЛО. Включил SMB1 на сервере, передёрнул соединение в камере - результат тот же. Ноль байт. SMB1 сразу отправился в корзину, куда ему и место. Что-ж, попытка засчитана.
Ловушка была в том, что попытки «починить» сервер, были, по сути, основаны на поведении клиента (тот самый брендовый китайский ноунейм). Я откатил настройки, пересобрал права доступа и покрутил версии протокола, но камера продолжала молчать. Все метрики рапортовали, что канал открыт, но данные по нему не текли.
Улики вместо догадок
Когда перебор вариантов зашёл в тупик, позвал ИИ. Не для того, чтобы он угадал причину, а чтобы структурировать диагностику по серверной части. Вместо того чтобы перебирать настройки доступа, напарник предложил посмотреть, что реально происходит на уровне сокетов и системных логов в момент «тишины».
Запустил проверку открытых соединений:
sudo lsof -nP -iTCP:445Результат подтвердил: сессия ESTABLISHED. Камера держит порт, связь есть.
Затем полез в логи процесса smbd через системный журнал:
sudo log show --last 25m --predicate 'process == "smbd"'И тут возникла заминка. Лог был забит строками с меткой Error, упоминающими connect_to_named_tree и bind_tree. Любой, кто привык к стандартным логам Linux, сразу бы решил, что всё сломалось здесь.
Но ИИ подсветил важный нюанс: в реализации smbd от Apple метка Error в этих конкретных операциях часто является историческим артефактом. Это не сбой, а штатный уровень логирования самого процесса подключения. То есть записи «Ошибка» в логе на самом деле означали: «Я успешно подключился к дереву каталогов».
Настоящий диагноз читался не по наличию ошибок, а по их отсутствию. В логах была авторизация, было создание папки (mkdir), а затем - звенящая пустота. Ни одной операции write. Ни одного отказа в доступе (denied). Сервер был полностью готов принимать данные, но клиент просто перестал их слать.
Смирение и откат
Стало понятно: сервер здоров. Протоколы совместимы. Права настроены верно. Но камера не пишет.
Вывод оказался неутешительным. Прошивка камеры заточена под конкретные, сертифицированные NAS от Synology или QNAP. Она не просто подключается по SMB - она, судя по всему, опрашивает сервер на предмет «похожести» на одобренное устройство. Если ответ её не устраивает, она молча прекращает передачу, при этом формально сохраняя статус «подключено».
Никакой правкой .conf или сменой версии протокола это не лечится. Это закрытая логика прошивки, которую не переписать извне.
Пришлось признать поражение и вернуть всё как было.
sharing -r nas-camОдной командой снёс шару, удалил служебного пользователя и вернул камеру на прежний архив.
Изнанка сертификации
Эта история оставила неприятный осадок, но важный технический вывод. Мы привыкли думать, что протокол - это универсальный язык. Если оба устройства говорят на SMB, они должны понимать друг друга.
Но в мире потребительского IoT протокол - это лишь обертка. Внутри сидит проверка на «свой-чужой». Сервер может быть технически идеален, но если он не представился нужным именем или не ответил на скрытый запрос так, как того ждёт прошивка, он будет игнорироваться.
Это не техническая ошибка, а архитектурный барьер. И самое ценное здесь - вовремя остановиться. Можно потратить неделю, пытаясь эмулировать ответы Synology на macOS, но в какой-то момент нужно просто понять: эта железка не хочет с тобой работать. И никакая настройка своего сервера этого не купит.
Этот провал стал отличным топливом для следующего шага. Раз стандартный smbd от Apple не проходит «проверку на вшивость» китайской камеры, возник вопрос: а что будет, если скомпилировать настоящую Samba из исходников? Но это уже совсем другая история.
Часть темы «Умный дом без облака» - там собраны остальные разборы этого стека.