Пока поставил первый попавшийся на глаза Teplocom ST-555. Прыгающее напряжение он выравнивает, ну и ладно. А по результатам мониторинга за прошедшие 3 холодных месяца полное отключение электропитания было 4 раза на 5-60 минут. За это время дом остыть не успевает. Сам котел вполне способен запуститься самостоятельно. Ну или пнуть его можно удаленно, на крайний-то случай…
В оперативку (у бананы ее 1Gb). Раз в 15 минут сеанс связи с сервером. Если сервер подтвердил получение и корректную обработку данных, то из устройства они удаляются. В случае ошибки данные сохраняются до следующего сеанса. Пока что максимальный период отсутствия связи (из-за каких-то работ на сети оператора) был 3 суток. После восстановления связи потерь данных не обнаружено.
Спасибо, учту. Хотя дешевле сделать корпус с защелками, который снимать перед приходом контролеров и ставить обратно после их ухода. А текущая реализация — просто макет для отладки софта/железяки (описание железяки готовится в виде следующей статьи).
Дамы и господа, всех с прошедшими праздниками!
Наконец-то дошли руки сделать фотки крепления сенсора на газовый счетчик. Может быть кому-то пригодятся.
О, спасибо за идею, тоже подумаю, из чего можно сделать автономный счетчик. Единственное, что смущает — SS441A в режиме покоя от 5V кушает 5mA. Многовато будет для батарейки…
Так вроде больше о hardware статья. Ну да, не обзорная, скорее howto получился. По идее подключения сенсора, по созданию device tree конфигурации по физическим исходным разъемам. Если статья все-таки не по теме, то перенесу ее на хабр.
Не выберет, т.к. DHCP Relay Agent в запросе к серверу вполне может отправлять и dhcp option 82. А сервер может ограничить кол-во выдаваемых адресов по клиенту. Просто в моем конкретном случае это излишне (подразумевается наличие клиента с кривыми руками, способного воткнуть не то и не туда, а не злонамеренного хакера).
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
Сейчас есть только 2 используемых IP: DHCP Server (он же default gateway для клиентов из всех VLAN) и DHCP Relay Agent. Если селить сервер на каждый VLAN, то имеем следующее:
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
Платформа не важна. Отладка вообще велась на десктопной машине, а целевая система собиралась при помощи buildroot. Но замечание о терминологии принимается, по-возможности внесу в статью исправления. И, возможно, стоит указать минимально необходимые опции сборки ядра для поддержки используемых фич. Хотя в современных generic ядрах все они присутствуют по умолчанию. Интересно, а есть здесь хаб для embedded programming?
Вообще-то в комментариях проскакивало, что это решение не для сервера, а для embedded-системы. Необслуживаемо — это верно, обслуживать просто нечего. Схема проста до невозможности и, практически, не использует ip-адресации.
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.
Если что-то имеет DHCP (в т.ч. и relay) не на management, а как сервис, то это уже L3 (по модели OSI).
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).
DHCP Relay в коммутаторе означает L3. Причину отказа от него см. выше. А вот о «программном решении, но без этого огорода» можно поподробнее? Идею на пальцах или ссылку на реализацию?
Вот я спрашиваю: дизайн с кучей сетей, соответствующими правилами в firewall, с периодическим добавлением/удалением сетей будет проще? Здесь единственный входной параметр: кол-во требуемых VLAN, все остальное может быть создано скриптом с единственным циклом, который создает интерфейсы и добавляет их в бридж.
Так я же и говорю: «или чисто аппаратное решение на коммутаторе L3, или аппаратно-программное решение на коммутаторе с (как минимум) поддержкой 802.1q». Второе выбрал в том числе и потому, что система встраиваемая, и вся эта логика зашивается более-менее жестко. В моем случае конфигурация вообще создается скриптами, а входным параметром является единственное число — кол-во необходимых VLAN. Соответственно требование к обвязке снижается до L2-коммутатора и админа-школьника, способного прописать на нем VLAN-ы.
На каждый VLAN вешать свою подсеть со своим default gateway. Разруливать маршрутизацию iptables. При добавлении vlan добавлять еще одну подсеть. Точно проще будет?
Наконец-то дошли руки сделать фотки крепления сенсора на газовый счетчик. Может быть кому-то пригодятся.
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).