gvan
-
Posts
210 -
Joined
-
Days Won
2
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by gvan
-
-
1 минуту назад, Захар сказал:
А если opkg отключён, то с кнопкой Fn проблем нет
А если без кнопки отключать (отмонтировать раздел через главную страницу)?
-
2 минуты назад, Захар сказал:
Сами проверьте. Я ничего не передёргивал.
У меня не подтвердилось.
Была активна entware на разделе sda3. Через веб-интерфейс на главной странице отсоединил логический раздел. Entware естественно при этом отвалилась сама.
Перегрузил роутер. При старте sda3 подключился без ошибок и entware с него также подцепилась нормально.
-
1 минуту назад, Захар сказал:
что перед каждым извлечением USB-носителя надо отключать галочку "Включить"
Т.е., даже если перед извлечением диска в веб-морде предварительно отмонтировать диск, но при этом не отключить entware через раздел opkg, то затем на диске будут возникать ошибки?
-
4 часа назад, Захар сказал:
У меня постоянно после отсоеденение и повторного присоеденения выходит сообщение об ошибке: "[W] Feb 21 15:38:55 ndm: kernel: EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended"
А сам раздел sda1 надеюсь "полечили" предварительно, как и предлагается в журнале? В ходе проверки они какие-то ошибки нашел?
Такое сообщение может появиться, если когда-то произошло некорректное отключение роутера или же диск отсоединили без отмонтирования. Оно будет появляться постоянно, пока не провести проверку (либо загрузившись с другого раздела с entware, либо, подключив диск для проверки на ПК с linux). Выполните проверку, исправьте ошибки и понаблюдайте. Попробуйте перегрузить роутер штатно через веб и непосредственно через entware для того, чтобы убедиться, что ошибки после перезагрузке (без предварительного ручного отмонтирования) не появляются вновь.
Как правило, при наличии некритичных ошибок на разделе с ext3/ext4 ничего теряться не должно (если конечно нет каких-то хардварных проблем).
-
1 минуту назад, Oleg Shabanov сказал:
-rwxrw-rw- 1 root root 176 Jan 27 17:21 messages
Ну вот. Нужно поменять на -rwrr--r--
chmod 644 messages -
2 часа назад, emlen сказал:
а я обычно перед перезагрузкой через веб-морду еще предварительно тыкал по отмонтировать носители.
Нет, этого не нужно делать. Роутер сам корректно отмонтирует накопители, если выполняется штатная перезагрузка.
-
1
-
-
11 час назад, emlen сказал:
а как-то можно внешний носитель при этом корректно отрубать?
А в чем некорректность отключения носителя при выполнении роутером команды reboot?
В принципе можно заменить команду перезагрузки роутера на более нативную -
ndmq -p 'system reboot' -P message
-
Сделал небольшой скрипт, который может рипить сразу несколько станций.
В примере записываются 3 URL (их намеренно испортил, т.е. замените на свои по ссылке в первом сообщении).
На Giga II при рипе одновременно трех станций нагрузка на роутер небольшая. Вполне можно и больше рипить.
Этот скрипт можно запустить с параметром "stop" для завершения всех рипов.
Создаем файл stream-di.sh. Размещаем в нем указанный код и делаем файл исполняемым командой 'chmod +x stream-di.sh'.
Код скрипта:
Скрытый текст#!/opt/bin/sh prefix="/opt" PATH=${prefix}/bin:${prefix}/sbin:/sbin:/bin:/usr/sbin:/usr/bin # Каталог, куда будут писаться рипы SDIR='/tmp/mnt/KINGSTON1/DI' # Список URL для рипа в формате 'описание|URL'. На каждой строчке по одной станции SLIST='Ambient|http://___.__.fm/ambient_hi?xxxx AtmosphericBreaks|http://___.__.fm/atmosphericbreaks_hi?xxxx ClassicVocalTrance|http://___.__.fm/classicvocaltrance_hi?xxxx' # Если запустить с ключем stop, то завершаются все копии рипов. Иначе запускаем в screen рип каждого из URL if [ "$1" != "stop" ] then for STATION in $SLIST do # Вычленяем имя станции и URL SNAME=`echo $STATION | cut -d '|' -f 1` SURL=`echo $STATION | cut -d '|' -f 2` echo "Starting ripping $SNAME $SURL" # Запускаем процесс рипа с именем окна, состоящим из имени станции screen -t $SNAME streamripper $SURL -q -d $SDIR done else # Если запущен с ключем stop, завершаем все процессы рипа killall streamripper fiТакже рекомендую предварительно настроить screen, разместив в конфигурационном файле код, представленный ниже. В этом случае экраны с запущенными сеансами будут подписаны и между ними можно будет легко переключаться по клавишам F11 и F12, чтобы посмотреть информацию по рипу станций. В принципе этим конфигом screen пользуюсь для всех случаев, но это отдельная тема для обсуждения...
Конфиг screen в /opt/etc/screenrc:
Скрытый текст# Bind F11 and F12 (NOT F1 and F2) to previous and next screen window bindkey -k F1 prev bindkey -k F2 next startup_message off # Window list at the bottom. hardstatus alwayslastline hardstatus string "%-w%{= BW}%50>%n %t%{-}%+w%<" # From Stephen Shirley # Don't block command output if the terminal stops responding # (like if the ssh connection times out for example). nonblock on # Allow editors etc. to restore display on exit # rather than leaving existing text in place altscreen on # Enable 256-color mode when screen is started with TERM=xterm-256color # Taken from: http://frexx.de/xterm-256-notes/ # # Note that TERM != "xterm-256color" within a screen window. Rather it is # "screen" or "screen-bce" # # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b ".I" # tell screen how to set colors. AB = background, AF=foreground #termcapinfo xterm-256color 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'Нужно понимать, что объем флэшки и диска небезграничный. Посчитайте через минут 20 объем зарипленных мелодий и определите насколько вам хватит размера диска.
Далее можно разместить в cron вызов скрипта с параметром stop, чтоб автоматически прекратить запись станций в нужный момент. Можно, конечно этого и не делать, тогда процесс streamripper завершится сам, когда место на диске кончится.
-
1
-
-
2 минуты назад, demos.vlz сказал:
Feb 06 03:00:00ndmkernel: AP 2.4GHz: run channel auto-switch
"оптимальный", через 6 часов - выборы будут в 3, 9, 15, 21
Нашел. Не успешные выборы (если по мнению роутера "есть трафик") получается никак в логах не отражаются.
Значит, то что произошло у меня вчера, скорее всего, никак с выборами не связано, т.к. произошло это около 23 часов.
-
5 минут назад, demos.vlz сказал:
Бывает, что автоскан не срабатывает с одним подключенным устройством, а бывает, что срабатывает с 4.
А в логах что-то должно появиться при успешных/не успешных попытках "конклава"? Как выглядит это строка?
У меня стоит "оптимальный", через 6 часов. Но в логах ничего не обнаружил.
Хотя такое ощущение, что вчера попал на выборы, причем в это время по wi-fi работало он-лайн видео. Естественно, это привело к полной остановке трафика.
-
22 часа назад, Oleg Shabanov сказал:
~ # ls -l /opt/etc/logrotate.conf
Тогда нужно еще:
$ ls -l /opt/etc/logrotate.d/ -rw-r--r-- 1 root root 158 Oct 10 09:19 messagesЯ думаю, что на файле /opt/etc/logrotate.d/messages у вас стоят права rwrwrw. Попробовал у себя поменять на такие - тоже появилась подобная ошибка.
-
2 часа назад, Le ecureuil сказал:
но чаще всего он запрашивает последний выданный, возможно даже в другой сети, с WiFi это элементарно
Скорее всего. В настройках на ее телефоне нашел какую-то еще сохраненную открытую гостевую точку. Причем эта точка находится в зоне слабой видимости. Также была включена опция оповещения об открытых сетях.
Наверно, на нее и цеплялось, а потом уже переключалось на основную, предлагая предыдущий IP.
-
31 минуту назад, Mamay сказал:
Клиент - телефон дочери на андроид. Вероятность того, что кто-то умышленно забил статичный IP на её телефоне - равняется нулю...
Угу. Тоже телефон дочери, и тоже на андроид
Только это и на предыдущих прошивках роутера наблюдалось ("без улучшенного DHCP").
С другими андроидами подобного в логах не видел.
Jan 29 19:29:11 192.168.1.1 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.83 from 00:xx:xx:xx:xx:xx. Jan 29 19:29:11 192.168.1.1 ndhcps: static client with wrong IP. Jan 29 19:29:11 192.168.1.1 ndhcps: sending NAK to 00:xx:xx:xx:xx:xx. Jan 29 19:29:12 192.168.1.1 ndhcps: DHCPDISCOVER received from 00:xx:xx:xx:xx:xx. Jan 29 19:29:12 192.168.1.1 ndhcps: making OFFER of 192.168.1.vw to 00:xx:xx:xx:xx:xx. Jan 29 19:29:12 192.168.1.1 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.1.vw from 00:xx:xx:xx:xx:xx. Jan 29 19:29:12 192.168.1.1 ndhcps: sending ACK of 192.168.1.vw to 00:xx:xx:xx:xx:xx.У нее Philips w6500.
Посмотрел предыдущие логи (имеются с 1.01.2017) такой ошибки не нашел. Прошивки обновляю регулярно. Но точно помню, что видел такую ошибку и ранее, возможно, пару месяцев назад. Версию прошивки, конечно, не вспомню. Настройки wi-fi в ее телефоне гляну сегодня вечером. Но сомневаюсь, что кто-то статично там забил адрес, поскольку виноват тогда буду я
-
19 часов назад, Oleg Shabanov сказал:
error: Ignoring messages because of bad file mode - must be 0644 or 0444.
Файловая система на диске с entware какая? Что показывает команда:
$ ls -l /opt/etc/logrotate.conf -rw------- 1 root root 893 Dec 24 17:46 /opt/etc/logrotate.confДолжно быть так, как в пример выше - только чтение/запись для root. Но если файловая система ntfs, то корректно права на нужные изменить не удастся.
-
16 часов назад, Le ecureuil сказал:
Скиньте ссылку на более-менее популярный MIB с подобной информацией, подумаем.
Не знаю, насколько это то, что нужно:
D-link ftp://ftp.dlink.ru/pub/Wireless/DWL-2100AP/Firmware/2.50/Dview-DWL2100-v250eu-rc358.mib , раздел AdClientEntry (но там входящие/исходящие байты не прописаны).
Есть еще у Cisco, но MIB-ы закрыты для скачивания.
Возможно, кто-то еще подкинет ссылки.
-
15 часов назад, Buha сказал:
Роутер так же начинает циклически перезагружаться.
Во втором сообщении темы об этом написано.
Причина, скорее всего, в том, что батарейки в часах в роутере нет. При перезагрузке текущее время записывается в конфиг и при старте роутера берется от туда.
У вас:
- Настало 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-
2
-
Нет ли в планах и насколько сложно реализовать в 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 и отразить на графиках, то вообще бы было замечательно.
Понятно, что можно парсить эту информацию через скрипты. Но это предполагает наличие лишнего "костыля".
-
1 час назад, emlen сказал:
не могли бы уточнить что за баг и в каком месте был
Мне не понравилась предыдущая версия логики сохранения версий конфига (когда по подобию стал делать сохранение версий прошивки), если скрипт обнаружил, что она изменилась. Это кусок кода в условии "if [ "$OLDCONF" != "$CURCONF" ]"
Скрытый текстБыло:
if [ "$OLDCONF" != "$CURCONF" ] then logger -t $TAG "Config is changed. Do new copy." cp -f ${BACSTORDIR}config-${DATE} ${BACSTORDIR}config-cur gzip -f ${BACSTORDIR}config-${DATE} else logger -t $TAG "Config is not changed. Renew current config copy." cp -f ${BACSTORDIR}config-${DATE} ${BACSTORDIR}config-cur rm ${BACSTORDIR}config-${DATE} fiУ меня тоже вроде проблем не возникало. Но по факту получается следующее. Есть вчерашняя версия конфига config-cur, получили свежую копию config-$DATE. Сравнили и, если есть различия, фактически затерли существующую версию конфига в архиве командой "cp -f ${BACSTORDIR}config-${DATE} ${BACSTORDIR}config-cur"
Поменял код на более логичный, когда предыдущая версия конфига точно "уйдет" в архив, а существующая версия станет config-cur
if [ "$OLDCONF" != "$CURCONF" ] then logger -t $TAG "Config is changed. Do new copy." cp -f ${BACSTORDIR}config-${DATE} ${BACSTORDIR}config-cur-new mv -f ${BACSTORDIR}config-cur ${BACSTORDIR}config-${DATE} gzip -f ${BACSTORDIR}config-${DATE} mv ${BACSTORDIR}config-cur-new ${BACSTORDIR}config-cur else logger -t $TAG "Config is not changed. Renew current config copy." mv -f ${BACSTORDIR}config-${DATE} ${BACSTORDIR}config-cur fiТ.е., если код использовался избирательно, то можно заменить только этот участок программы.
-
1
-
-
Скрипт в первом сообщении темы изменен.
Исправлен баг с сохранением конфигурации (не все копии конфигурации могли правильно сохраняться). А также в связи с тем, что разработчики фактически каждую неделю балуют нас отладочными версиями прошивок, то в функционал скрипта включена возможность сохранения копий прошивок.
Как показала практика, не все отладочные версии прошивок могут полюбиться пользователю с первого раза. Особенно, если предварительно не ознакомиться в соответствующей теме об исправлениях и дополнениях в прошивке, а также о ее возможных багах.
Теперь, если перед обновлением прошивки забыл ее сохранить через веб, то есть возможность откатиться на предыдущую версию, взяв ее из резервной копии.
-
3
-
-
8 минут назад, Le ecureuil сказал:
Web валидирует прошивку и подпись, поэтому он не даст вам засунуть испорченную, а также просто неправильный файл. Можете попробовать.
Да, проверку файл прошел. Прошивка на роутер загрузилась.
Будем считать изменения в 6 байтах неважными, но подозрительными...
-
1
-
-
28 минут назад, kis-markiz сказал:
У меня в своё время была проблема с долгой раскруткой диска сигейт при выходе из сна. Hdparm не помог, пришлось запрещать сон утилиткой от производителя.
Для своего fujitsu такой утилитки не видел. С другой стороны, пока никаких других багов (кроме как ошибок при раскрутке в логе) не видел:
Jan 19 04:02:06 192.168.1.1 ndm: kernel: sd 1:0:0:0: [sdb] Unhandled error code Jan 19 04:02:06 192.168.1.1 ndm: kernel: sd 1:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x00 Jan 19 04:02:06 192.168.1.1 ndm: kernel: sd 1:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 13 e8 08 18 00 00 08 00 Jan 19 04:02:06 192.168.1.1 ndm: kernel: end_request: I/O error, dev sdb, sector 333973528Совсем запрещать сон тоже не хочется. И даже не в целях экономии электроэнергии, а в целях тишины. Да и бывают ситуации, что подключенный к кинетику винт не требуется пару недель. И зачем тогда его заставлять работать в холостую.
-
5 минут назад, Le ecureuil сказал:
Если затем попробовать прошить через Web, он принимает оба файла без ошибок?
Так я и не пробовал файл, полученный через CLI файл, засовывать через веб. Пока такой необходимости не было. А различие в содержимом меня как раз и насторожило, т.к. опасаюсь испортить роутер.
-
1 час назад, zyxmon сказал:
`hdparm -B 254` или `hdparm -B 255` должно помочь.
Я пробовал и так, и так. hdparm частично ругается на ошибку (поэтому прошлый раз я на эксперименты забил). smartctl отрабатывает без ошибок, но влияния на остановку двигателя не оказывает, т.к. винт продолжает засыпать.
Еще раз попробовал.
root$ hdparm -B 255 /dev/sdb /dev/sdb: setting Advanced Power Management level to disabled HDIO_DRIVE_CMD failed: Invalid argument APM_level = off root$ smartctl -s standby=off /dev/sdb smartctl 6.5 2016-05-07 r4318 [mips-linux-3.4.113] (localbuild) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF ENABLE/DISABLE COMMANDS SECTION === Standby timer set to 0 (disabled)И, если не ошибаюсь, то для hdparm требуется флаг -S (из хелпа: "-S Set standby (spindown) timeout"). Но его установка у меня тоже проходит с ошибкой:
root$ hdparm -S 0 /dev/sdb /dev/sdb: setting standby to 0 (off) HDIO_DRIVE_CMD(setidle) failed: Invalid argumentСделал еще так:
root$ smartctl -s apm=off /dev/sdb smartctl 6.5 2016-05-07 r4318 [mips-linux-3.4.113] (localbuild) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF ENABLE/DISABLE COMMANDS SECTION === APM disabled1 час назад, zyxmon сказал:Это баг ядра. Проявляется на разных устройствах. Есть такое решение (пост №37)
Попробовал
echo 'temporary write through' > /sys/block/sdb/device/scsi_disk/1:0:0:0/cache_typeНо содержимое этого файла так и остается просто "write through".
-
Возможно, глупый вопрос. Но сейчас озадачился периодическим сохранением прошивки из роутера по 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 байтах
)?
-
1
-
Только это и на предыдущих прошивках роутера наблюдалось ("без улучшенного DHCP").
)?
Отмонтирование накопителя при работающем opkg
in Вопросы по сборке и настройке Opkg
Posted
Если это бывает, то, скорее всего, это баг. В этом случае его нужно устранять.
Для этого нужна полная информация по названию роутера, версии прошивки, как воспроизвести.
У меня кнопочка Fn далеко, поэтому проверил воспроизводство бага логически на своей версии прошивки. Вам также советую это попробовать (а не игнорировать).