Jump to content

OmegaTron

Forum Members
  • Content count

    101
  • Joined

  • Last visited

Community Reputation

4 Neutral

About OmegaTron

  • Rank
    Advanced Member

Equipment

  • Keenetic
    Omni II [v2.11.C.0.0-2]
  1. В очередной раз сев за комп обнаружил валящийся в syslog лог. Полез в веб-морду - ожидаемо зависла. Разбираться не стал, ребутнул через ssh. Сегодня только дошли руки посмотреть, что же там роутер накидал в лог May 1 09:54:47 ndm: kernel: CPU 0 Unable to handle kernel paging request at virtual address 163cffac, epc == 80183de4, ra == 80183d70 May 1 09:54:47 ndm: kernel: Oops[#1]: May 1 09:54:47 ndm: kernel: Cpu 0 May 1 09:54:47 ndm: kernel: $ 0 : 00000000 00000065 163cffac 830c3e48 May 1 09:54:47 ndm: kernel: $ 4 : 163cffac 00000010 163d0000 ffffffeb May 1 09:54:47 ndm: kernel: $ 8 : 00000010 00000000 00000000 00000000 May 1 09:54:47 ndm: kernel: $12 : 77065d4c 00000807 00000000 00000000 May 1 09:54:47 ndm: kernel: $16 : 830c3e48 803000d8 000089ff 803000d8 May 1 09:54:47 ndm: kernel: $20 : 77065cfc 00000000 00000000 7787d2c0 May 1 09:54:47 ndm: kernel: $24 : 00000000 77964d00 May 1 09:54:47 ndm: kernel: $28 : 830c2000 830c3e00 770665f0 80183d70 May 1 09:54:47 ndm: kernel: Hi : 000000c9 May 1 09:54:47 ndm: kernel: Lo : 000b930c May 1 09:54:47 ndm: kernel: epc : 80183de4 dev_get_by_name_rcu+0xa4/0xfc May 1 09:54:47 ndm: kernel: Tainted: P O May 1 09:54:47 ndm: kernel: ra : 80183d70 dev_get_by_name_rcu+0x30/0xfc May 1 09:54:47 ndm: kernel: Status: 1100ec03 KERNEL EXL IE May 1 09:54:47 ndm: kernel: Cause : 00800008 May 1 09:54:47 ndm: kernel: BadVA : 163cffac May 1 09:54:47 ndm: kernel: PrId : 00019650 (MIPS 24KEc) May 1 09:54:47 ndm: kernel: Modules linked in: fastvpn(PO) hw_nat(O) mt76x2_ap(O) rtsoc_eth(PO) ip_set_hash_ip ip_set_hash_ipportip ip_set_hash_net ip_set_hash_ipport ip_set_hash_ipportnet ip_set_bitmap_port xt_set ip_set_bitmap_ipmac ip_set_hash_netiface ip_set_bitmap_ip ip_set_hash_netport ip_set_list_set usbextras(PO) nls_utf8 ip_set xt_IPMARK(O) nfsd xt_ACCOUNT(O) nls_cp1251 nfs usb_storage nfnetlink_log xt_DNETMAP(O) xt_length2(O) arptable_filter sd_mod ohci_hcd sr_mod nls_cp437 xt_DELUDE(O) xt_CHAOS(O) lockd auth_rpcgss sg ext4 xt_LOGMARK(O) nfnetlink_queue ebtable_broute xt_STEAL(O) nls_cp866 xt_ipp2p(O) xt_DHCPMAC(O) ebtable_filter jffs2 xt_psd(O) ebtable_nat ehci_hcd xt_TPROXY cifs xt_RAWNAT(O) xt_SYSRQ(O) xt_TARPIT(O) nf_conntrack_netlink usbcore ebt_redirect xt_geoip(O) xt_iprange xt_NOTRACK ipt_ULOG ip6t_rt xt_connbytes xt_addrtype xt_recent lzo_decompress ip6t_mh xt_string cdrom resetnds(PO) hmac ebt_dnat des_generic xt_iface(O) ebt_802_3 mtdoops_proc(O) nacct(PO) xt_comment nf_tproxy_c [...] May 1 09:54:47 ndm: kernel: Process ndm (pid: 135, threadinfo=830c2000, task=83d46d20, tls=7706e960) May 1 09:54:47 ndm: kernel: Stack : 7787d2c0 8018ada8 00000001 ffffffff 77065cdc 830c3e48 830c3e48 80186d44 May 1 09:54:47 ndm: kernel: 77065cfc 00000000 00000000 7787d2c0 77065cdc 8018b268 007ba000 83098ae0 May 1 09:54:47 ndm: kernel: 0000043c 80f66f40 32687465 00000000 00000000 00000000 77065d4c 00000000 May 1 09:54:47 ndm: kernel: 00000000 00000000 00000000 00000000 8383a8e0 77065cdc 000089ff 77065cdc May 1 09:54:47 ndm: kernel: 000089ff 77065cdc 00000000 7787d2c0 770665f0 800ad914 80f66f40 83890658 May 1 09:54:47 ndm: kernel: ... May 1 09:54:47 ndm: kernel: Call Trace: May 1 09:54:47 ndm: kernel: [<80183de4>] dev_get_by_name_rcu+0xa4/0xfc May 1 09:54:47 ndm: kernel: [<80186d44>] dev_load+0x14/0x9c May 1 09:54:47 ndm: kernel: [<8018b268>] dev_ioctl+0x34c/0x664 May 1 09:54:47 ndm: kernel: [<800ad914>] do_vfs_ioctl+0x48c/0x5c8 May 1 09:54:47 ndm: kernel: [<800ada98>] sys_ioctl+0x48/0x90 May 1 09:54:47 ndm: kernel: [<80011250>] stack_done+0x20/0x44 May 1 09:54:47 ndm: kernel: May 1 09:54:47 ndm: kernel: May 1 09:54:47 ndm: kernel: Code: 8fbf001c 00402021 01002821 May 1 09:54:47 ndm: kernel: 10a00006 90610000 24a5ffff 14270004 24840001 May 1 09:54:47 ndm: kernel: ---[ end trace fee9c31a07fa0035 ]--- May 1 09:54:48 ndm: Thread: failed to get thread 135 statistics: invalid argument. May 1 09:55:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 30 seconds. May 1 09:55:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 60 seconds acquired May 1 09:54:47. May 1 09:56:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 60 seconds. May 1 09:56:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 90 seconds. May 1 09:56:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 120 seconds acquired May 1 09:54:47. May 1 09:57:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 120 seconds. May 1 09:57:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 150 seconds. May 1 09:57:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 180 seconds acquired May 1 09:54:47. May 1 09:58:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 180 seconds. May 1 09:58:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 210 seconds. May 1 09:58:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 240 seconds acquired May 1 09:54:47. May 1 09:59:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 240 seconds. May 1 09:59:38 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 270 seconds. May 1 09:59:47 ndm: Core::Watchdog: Timer holds REPOSITORY (25) lock 300 seconds acquired May 1 09:54:47. May 1 10:00:08 ndm: Event::Acceptor: sending "Event::Type::Neighbour" to "Network::Interface::AccessPoint" 300 seconds. И так вплоть до ребута. Вот что было при обращении к веб-морде May 1 23:32:20 keenetic_omni nginx: 2018/05/01 23:32:20 [error] 407#0: *5257 upstream timed out (145: Unknown error) while reading response header from upstream, client: 192.168.0.10, server: my.keenetic.net, request: "POST /ci HTTP/1.1", upstream: "scgi://unix:/var/run/ndm.scgi.socket", host: "192.168.0.1:10080", referrer: "http://192.168.0.1:10080/" Ну и на закуску, сообщение о неясном баге, датированное сегодняшним днём (ночью) May 3 00:18:42 ndm: kernel: BUG: Bad page map in process ndm pte:126a5a1e pmd:830b8000 May 3 00:18:42 ndm: kernel: addr:00afb470 vm_flags:00100077 anon_vma:830a7c58 mapping: (null) index:afb May 3 00:18:42 ndm: kernel: Call Trace: May 3 00:18:42 ndm: kernel: [<8028247c>] dump_stack+0x8/0x34 May 3 00:18:42 ndm: kernel: [<80080fa8>] print_bad_pte+0x18c/0x208 May 3 00:18:42 ndm: kernel: [<80084620>] handle_pte_fault+0x2c8/0x834 May 3 00:18:42 ndm: kernel: [<80084c1c>] handle_mm_fault+0x90/0xe8 May 3 00:18:42 ndm: kernel: [<80012f28>] do_page_fault+0xb8/0x390 May 3 00:18:42 ndm: kernel: [<800099a0>] ret_from_exception+0x0/0x10 May 3 00:18:42 ndm: kernel: Apr 25 02:05:24 pppd[395]: Remote message: Authentication success,Welcome! Apr 25 02:05:24 pppd[395]: PAP authentication succeeded Прошивка 2.11.C.0.0-2
  2. Не так давно мой Омни II активно одолевали баги и дабы выяснить их причину надо было писать логи. Предложенный в данной теме syslog-ng меня не устроил перегруженностью и гемморойной настройкой и я решил прикрутить на Омни для сбора логов то же самое, что ранее использовал на смартфонах для ловли логов. А именно socat или netcat. Достаточно указать сам роутер в качестве приёмника логов и натравить socat/netcat (ставится отдельно) на прослушивание 514 порта и дело в шляпе. Есть правда небольшой нюанс - записанный лог не имеет форматирования и для приведения его в читабельный вид нужен редактор с поддержкой regexp'ов, через который в логе нужно заменить <[0-9]{1,3}>на "\n". Как вариант, можно прогнать через sed cat syslog.txt|sed -r "s/<[0-9]{1,3}>/\n/g" > syslog_fix.txt Вот мой велосипед #!/bin/sh PATH=/opt/bin:/opt/sbin:/sbin:/bin:/usr/sbin:/usr/bin start() { socat -u UDP-RECV:514 STDOUT >> /opt/var/log/syslog.txt & } stop() { killall socat } case "$1" in start) start ;; stop) stop ;; restart) stop sleep 3 start ;; *) echo "Usage: $0 {start|stop|restart}" ;; esac вместо socat можно использовать netcat (только полноценный) nc -l -u -p 514 >> /opt/var/log/syslog.txt & У такого решения есть ряд минусов и плюсов. Главный плюс - данный костыль прост как табуретка и требует минимальной настройки. Минусы - неформатированный лог, отсутствие загрузочной информации и пожалуй отсутствие ранжирования логов по датам. При желании это всё можно запилить, но я намеренно не стал усложнять скрипт ибо для моих нужд его с лихвой хватает. Надеюсь кому-нибудь такое решение пригодится. Если кто допилит - будет ещё лучше
  3. Про ndmq я в курсе, но мне удобней использовать для этих целей curl - он универсальней ))) Но я говорил не о взаимодействии с cli извне устройства, а извне шелла т.е. внутри устройства так сказать. Судя по справке ndmc это не умеет - там только открытие сессии, версия и собственно справка. Касательно включенных/выключенных устройств есть ещё проблема касающаяся варианта с 2-мя сетевыми картами (а у меня на десктопе их фактически 3, включая беспроводную, на буке - 2), что вкупе с несколькими устройствами делает ситуацию совсем печальной. Ежели бы можно было снять ограничение или хотя бы увеличить ограничение до 10 устройств - было бы замечательно.
  4. Кому как, а я например отслеживаю syslog-активность за тем тем устройством, за которым работаю в данный моммент. Если в syslog начинает сыпаться слишком много, я начинаю проверять Кидать в консоль весь конфиг ради 3-х строчек ? *** Хм, а бинарник cli (ndmc) поддерживает приём команд "извне" (всмысле из обычного шелла) ? Тогда бы можно было сообразить костыль *** В целом можно сделать запрос к вебморде для смены активного получателя лога. Вот только есть в этой затее одно но - если активным будет несколько устройств, то получать его будет только то устройство, которое подало команду на получение последним (за вычетом 2-х устройств добавленных через шелл, одно из которых уже зарезервировано за самим роутером).
  5. Я так понимаю, через cli список клиентов-получателей syslog'a посмотреть не выйдет ? Чем обусловлено ограничение лога тремя получателями ? У меня 2 машины и бук, включаемые попеременно + смартфон + роутер сам на себя пишет лог. Т.е. финальное количество клиентов превышает 3 и приходится через cli менять получателей, если я не забываю об этом.
  6. Обнаружил в выхлопе ifconfig отдельный петлевой интерфейс ezcfg0 с ip 78.47.125.180, я так понимаю, это костыль для редиректа с my.keenetic.net на роутер ? dns-сервер сервер отдаёт 78.47.125.180, а клиент переходя по нему попадает на роутер. Единственное, что не понял - к чему такие сложности, почему нельзя было обойтись записью в hosts ? Или расчёт на то, что конечный юзер может сменить в настройках подключения дефолтный dns, раздаваемый роутером + нет привязки к конкретной подсети ? Теперь понятно, почему мне ранее про 78.47.125.180 говорили как про loopback - адрес и предлагали его использовать как альтернативу локалхосту при добавление правил сопоставления dns и адресов в CLI через команду ip host (а мне рвало шаблон от "белого" адреса и я из-за этого ломился на стандартный 80-й порт, хотя дефакто 78.47.125.180 равносилен дефолтному ip адресу роутера и надо было ломиться на те порты, которые мной же и были прописаны в роутере).
  7. В последнюю неделю в лог стали сыпаться сообщения вида (мак один и тот же) я так понимаю, кто-то пытается сбрутить пароль, но получает отлуп ещё на начальном этапе от мак-фильтра ? Или же это чей то гаджет, будучи единожды "натравленным" на мою сеть, при потере своей упорно ломится ко мне ?
  8. Не подскажете, чем прошивка с офф.сайта отличается от прошивки с keenopt ? Разница лишь в наличии поддержки opkg или есть какие-нибудь ещё отличия в виде наличия фиксов (если да, то каких - есть ли ченджлог) ? Судя по дате, прошивка с keenopt не слишком древняя.
  9. Это был точно не я - я даже логи PuTTY проверил на предмет подобного. А кроме меня доступа к роутеру ни у кого не было. Единственное объяснение, которое пока крутится - я мог что-то не то поменять в веб-морде при первой настройке, на сырой заводской прошивке, что после последующего апдейта дало такой эффект т.к. прошивка была переработана радикально по сравнению со стоком (либо что-то отвалилось при автоапдейте). Все действия в консоли у меня контролируются и логгируются. Как ни странно, помогло. Спасибо. Селф-тест ещё нужен ? Проблема решена.
  10. Ещё как умеют - я не даром вспомнил автоапдейт, когда роутер переодически сам грузил прошивки. Единственное, я не помню, когда это возникло - или после первого обновления с заводской прошивки или в последующем процессе автоапдейтов. Шаловливые ручки в CLI не лазили - интерфейс с именем "Home" в CLI на месте (и без проблем регулируется, о чём я писал выше). Да и раз уж на то пошло, ежели бы его не было, смог бы я тогда подключиться к роутеру ? upd: Говорил же, что я что-то похожее на форуме видел, вот, нашёл - https://forum.keenetic.net/topic/2985-исчез-интерфейс upd: Вот выхлоп CLI (config)> show interface Home id: Bridge0 index: 0 type: Bridge description: LAN interface-name: Home link: up connected: yes state: up mtu: 1500 tx-queue: 1000 address: 192.168.1.101 mask: 255.255.255.0 uptime: 4974 global: yes defaultgw: no priority: 700 security-level: private mac: 00:00:00:00:00:00 auth-type: none bridge: interface, link = yes, inherited = yes: FastEthernet0/Vlan1 interface, link = yes: WifiMaster0/AccessPoint0 (config)> MAC я убрал.
  11. Да я потому с этой проблемой и тянул (ибо не слишком критично), что не хотел сбрасывть в дефолт т.к. влом всё настратвать заново т.к. при обратной подгрузке конфига всё вернётся назад (всмысле без сегмента). Потому и поинтересовался, встречался ли такой баг ранее (и как его лечили).
  12. Собственно сабж. Проблема давняя и вылезла после какого-то обновления (возможно тогда, когда ещё работал автоапдейт) без каких либо действий с моей стороны. Через CLI интерфейс виден и без проблем регулируется. Через веб-фейс - нет. Кто-нибудь с подобным сталкивался ? Вроде на форуме что-то подобное проскакивало, но не могу найти.
  13. Le ecureuil, когда появится мануал - если не затруднит, маякните в данной теме или в ЛС, либо скажите, где его искать потом.
  14. Со стороны Омни или на крайняк компа (могу и его подоткнуть в свитч) это переполнение возможно отследить ? И если да, то как ? Свитч шарит WAN - там всего 3 кабеля - от провайдера, до Омни и до второго роутера. Скорей всего это wan омни т.к. за проверенным годами keenetic'ом такого не наблюдалось.
  15. Уже долгое время где-то раз в месяц вылезает странный глюк, при котором мой Omni II перестаёт отвечать по LAN, хотя по WLAN остаётся доступен. При этом видно, что pppoe-сессия порвана и другие LAN устройства как с самого роутера, так и через WLAN недоступны. При этом, что интересно, на соседнем роутере pppoe-сессия тоже рвётся (у меня есть возможность поднимать 2 сессии за раз) и мультикаст от провайдера перестаёт идти. Обычно, для решения проблемы я просто вырубал по питанию сетевой фильтр, в который подключены свитч, который шарит WAN на второй роутер и Омни. По началу я грешил на свитч и не особо заморачивался, ибо проблема вылезала редко. Но в этот раз я решил выкл/вкл свитч и посмотреть, что будет. После того, как я это проделал, на соседнем роутере pppoe-сессия поднялась и через пару минут снова отвалилась, после чего не поднималась. После того, как выкл/вкл по питанию и Омни и свитч, всё заработало, как ни в чём не бывало - роутер стал виден по lan и сам стал видеть lan-устройства (в том числе восстановилась сессия на втором роутере). Теперь вопрос - что ЭТО ? Как Омни умудряется влиять на свитч ? В логах ничего криминального не было. Лишь упоминание, что упала pppoe-сессия и роутер её пытается поднять. Аптайм около суток. Наблюдаю проблему давно и на разных версиях прошивок.
×