gvan

У меня не подтвердилось. Была активна entware на разделе sda3. Через веб-интерфейс на главной странице отсоединил логический раздел. Entware естественно при этом отвалилась сама. Перегрузил роутер. При старте sda3 подключился без ошибок и entware с него также подцепилась нормально.

Т.е., даже если перед извлечением диска в веб-морде предварительно отмонтировать диск, но при этом не отключить entware через раздел opkg, то затем на диске будут возникать ошибки?

А сам раздел sda1 надеюсь "полечили" предварительно, как и предлагается в журнале? В ходе проверки они какие-то ошибки нашел? Такое сообщение может появиться, если когда-то произошло некорректное отключение роутера или же диск отсоединили без отмонтирования. Оно будет появляться постоянно, пока не провести проверку (либо загрузившись с другого раздела с entware, либо, подключив диск для проверки на ПК с linux). Выполните проверку, исправьте ошибки и понаблюдайте. Попробуйте перегрузить роутер штатно через веб и непосредственно через entware для того, чтобы убедиться, что ошибки после перезагрузке (без предварительного ручного отмонтирования) не появляются вновь. Как правило, при наличии некритичных ошибок на разделе с ext3/ext4 ничего теряться не должно (если конечно нет каких-то хардварных проблем).

Ну вот. Нужно поменять на -rwrr--r-- chmod 644 messages

Нет, этого не нужно делать. Роутер сам корректно отмонтирует накопители, если выполняется штатная перезагрузка.

А в чем некорректность отключения носителя при выполнении роутером команды reboot? В принципе можно заменить команду перезагрузки роутера на более нативную - ndmq -p 'system reboot' -P message

Сделал небольшой скрипт, который может рипить сразу несколько станций. В примере записываются 3 URL (их намеренно испортил, т.е. замените на свои по ссылке в первом сообщении). На Giga II при рипе одновременно трех станций нагрузка на роутер небольшая. Вполне можно и больше рипить. Этот скрипт можно запустить с параметром "stop" для завершения всех рипов. Создаем файл stream-di.sh. Размещаем в нем указанный код и делаем файл исполняемым командой 'chmod +x stream-di.sh'. Код скрипта: Также рекомендую предварительно настроить screen, разместив в конфигурационном файле код, представленный ниже. В этом случае экраны с запущенными сеансами будут подписаны и между ними можно будет легко переключаться по клавишам F11 и F12, чтобы посмотреть информацию по рипу станций. В принципе этим конфигом screen пользуюсь для всех случаев, но это отдельная тема для обсуждения... Конфиг screen в /opt/etc/screenrc: Нужно понимать, что объем флэшки и диска небезграничный. Посчитайте через минут 20 объем зарипленных мелодий и определите насколько вам хватит размера диска. Далее можно разместить в cron вызов скрипта с параметром stop, чтоб автоматически прекратить запись станций в нужный момент. Можно, конечно этого и не делать, тогда процесс streamripper завершится сам, когда место на диске кончится.

Нашел. Не успешные выборы (если по мнению роутера "есть трафик") получается никак в логах не отражаются. Значит, то что произошло у меня вчера, скорее всего, никак с выборами не связано, т.к. произошло это около 23 часов.

А в логах что-то должно появиться при успешных/не успешных попытках "конклава"? Как выглядит это строка? У меня стоит "оптимальный", через 6 часов. Но в логах ничего не обнаружил. Хотя такое ощущение, что вчера попал на выборы, причем в это время по wi-fi работало он-лайн видео. Естественно, это привело к полной остановке трафика.

Тогда нужно еще: $ ls -l /opt/etc/logrotate.d/ -rw-r--r-- 1 root root 158 Oct 10 09:19 messages Я думаю, что на файле /opt/etc/logrotate.d/messages у вас стоят права rwrwrw. Попробовал у себя поменять на такие - тоже появилась подобная ошибка.

Файловая система на диске с entware какая? Что показывает команда: $ ls -l /opt/etc/logrotate.conf -rw------- 1 root root 893 Dec 24 17:46 /opt/etc/logrotate.conf Должно быть так, как в пример выше - только чтение/запись для root. Но если файловая система ntfs, то корректно права на нужные изменить не удастся.

Не знаю, насколько это то, что нужно: D-link ftp://ftp.dlink.ru/pub/Wireless/DWL-2100AP/Firmware/2.50/Dview-DWL2100-v250eu-rc358.mib , раздел AdClientEntry (но там входящие/исходящие байты не прописаны). Есть еще у Cisco, но MIB-ы закрыты для скачивания. Возможно, кто-то еще подкинет ссылки.

Во втором сообщении темы об этом написано. Причина, скорее всего, в том, что батарейки в часах в роутере нет. При перезагрузке текущее время записывается в конфиг и при старте роутера берется от туда. У вас: Настало 12-12 Cron в entware, увидел, что нужно выполнить задачу ребута Запись времени 12-12 в конфиг Ребут Старт роутера Запись в часы роутера времени из конфига - 12-12 Старт entware и cron Cron видит, что пора выполнить задачу ребута, т.к. время 12-12 Далее повторить с п.2 нужное число раз Решение есть, но оно не совсем очевидное. Нужно задачу из cron выполнять только, если uptime роутера больше, например, 10 минут. Тогда есть надежда, что и часы засинхронизируются, и задача не выполнится повторно. Т.е. можно модернизировать запуск в cron так: [ `cut -d '.' -f 1 < /proc/uptime` -ge 600 ] && reboot

Нет ли в планах и насколько сложно реализовать в SNMP информацию о Wi-Fi клиентах? Вкладку с wi-fi клиентами нам вернули, в вебе информация с трафиком отображается. NDMS об этих клиентах знает. Информацию можно получить через http://my.keenetic.net/rci/show/associations или CLI "show associations": { "station": [ { "mac": "xx:xx:xx:xx:xx:xx", "ap": "WifiMaster0/AccessPoint0", "authenticated": "1", "txrate": "65", "uptime": "6273", "txbytes": "554139", "rxbytes": "4347197", "ht": "20", "mode": "11n", "gi": "800", "rssi": "-63", "mcs": "7" } ] } Если бы это можно было получить через SNMP и отразить на графиках, то вообще бы было замечательно. Понятно, что можно парсить эту информацию через скрипты. Но это предполагает наличие лишнего "костыля".

Мне не понравилась предыдущая версия логики сохранения версий конфига (когда по подобию стал делать сохранение версий прошивки), если скрипт обнаружил, что она изменилась. Это кусок кода в условии "if [ "$OLDCONF" != "$CURCONF" ]" Т.е., если код использовался избирательно, то можно заменить только этот участок программы.

Скрипт в первом сообщении темы изменен. Исправлен баг с сохранением конфигурации (не все копии конфигурации могли правильно сохраняться). А также в связи с тем, что разработчики фактически каждую неделю балуют нас отладочными версиями прошивок, то в функционал скрипта включена возможность сохранения копий прошивок. Как показала практика, не все отладочные версии прошивок могут полюбиться пользователю с первого раза. Особенно, если предварительно не ознакомиться в соответствующей теме об исправлениях и дополнениях в прошивке, а также о ее возможных багах. Теперь, если перед обновлением прошивки забыл ее сохранить через веб, то есть возможность откатиться на предыдущую версию, взяв ее из резервной копии.

Да, проверку файл прошел. Прошивка на роутер загрузилась. Будем считать изменения в 6 байтах неважными, но подозрительными...

Так я и не пробовал файл, полученный через CLI файл, засовывать через веб. Пока такой необходимости не было. А различие в содержимом меня как раз и насторожило, т.к. опасаюсь испортить роутер.

Возможно, глупый вопрос. Но сейчас озадачился периодическим сохранением прошивки из роутера по cron. Соответственно, для этого использую команду cli наподобие: copy flash:/firmware USBFLASH:/firmware-cli Также для сравнения сохраняю прошивку через веб (Система-Файлы). Прошивки по размеру получаются одинаковыми, но почти в самом конце 6 байт отличаются. Пробовал несколько раз. Байты одни и те же различаются, их содержимое также не изменяется (что для CLI, что для веба): Сравнение файлов firmware-web и firmware-cli 00BB0030: 10 7C 00BB0031: CE 91 00BB0032: 99 91 00BB0034: E0 68 00BB0035: 3E F5 00BB0036: C1 95 Это нормально? По какой причине это происходит? Безопасно ли восстанавливаться с прошивки, сохраненной через CLI (не дают мне покоя различия в этих 6 байтах)?

Если есть желание "рисовать картинки" прямо на роутере, то можно попробовать решение. Тем более пакет collectd включили в официальный список пакетов entware (т.е. можно ставить напрямую через opkg). Там же есть упоминание о готовом пакете netdata, который требует минимум настроек для получения результата, но статистика хранится не долговременно. Либо использовать внешний ресурс (сервер), который будет собирать статистику по SNMP с роутера и отображать ее (ссылки на такое ПО были в этой теме). Если используются 32-битные счетчики, то переполнение возникнет довольно быстро. Чтобы проверить из-за этого ли это происходит можно сделать следующее. Посчитать сколько времени прошло с предыдущего скачка (в секундах) и умножить на среднюю скорость по статистике нужного нам трафика. Если получим в сумме объем, равный примерно 4Гб (перевести биты в xБайты), то это оно - переполнение Но это очень примерно.

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

На Entware-3g тоже этого файла нет. Но необходимый интерфейс можно указать в скрипте старта/стопа /opt/etc/init.d/S54darkstat в строке ARGS="-i ppp0 --chroot /opt/var/empty --syslog" Причем у меня он запускается (через данный скрипт) без ошибок (но у меня подключение с провайдером - PPPoE).

Сам не пробовал на внешний сервер отдавать, но, судя по всему, примерно так: destination remote {udp("192.168.1.111" port(514));}; log { source(src); destination(remote); };

Ну, собственно говоря сто копий не хранится. Остаются архивы за последние несколько дней в зависимости от значения переменной DAYSTOR. Да и объем этих архивов конфигов небольшой. Также при выполнении команды "show running-config" всегда изменяется MD5 конфига и строка "clock date". Так что задача не совсем тривиальная. Первое сообщение дополнил кодом по сохранению только измененного конфига. Для этого при каждом запуске бэкапа сохраняется локальная так называемая текущая версия конфига. При последующих запусках содержимого полученного с роутера и сохраненного конфига сравнивается. При этом указанные выше строки не учитываются (переменная EXCLCONFCMD="Md5 checksum:\|clock date"). Т.к. логика скрипта усложнилась, то возможны какие-то неучтенные баги Проверяйте.

Первое сообщение дополнено информацией по восстановлению entware из резервной копии.