Jump to content

Dorik1972

Forum Members
 View Profile  See their activity

  • Posts

    122

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by Dorik1972

    VPN/IPsec

    in 2.15

    Posted

    22 часа назад, Le ecureuil сказал:

    Дали ссылку выше.

    Я там тоже бываю ежедневно, потому если проблема реальная и воспроизводится, то до меня ее доведут и официально будет выделено время для исправления.

    А на этом форуме все больше по доброте душевной, ну или если устройство уже не поддерживается официально :)

     Не уверен что KN-1310 уже не поддерживается офф ))) В общем отписался "куда послали" ... Заодно проверил в качестве клиента Giga III , при всех однотипных "манипуляциях" все работает аж бигом и в "межсетевом экране" появляется "закладка" с добавленым "VPN/IPSec" ... ради "прикола" сбросил в заводские KN-1310 , повторил все с "нуля" ... картина "маслом" - ЗАКЛАДКИ НЕТ ... как-то так 

    VPN/IPsec

    in 2.15

    Posted

    34 минуты назад, Le ecureuil сказал:

    Давайте с этим лучше в официальную техподдержку, здесь может затеряться.

    При всем уважении )) Так привык тут тусить , что "в душе не ..." где ОФИЦИАЛЬНАЯ ? Ткните носом плизззз 

    VPN/IPsec

    in 2.15

    Posted · Edited by Dorik1972

    Прошивка 2.15  2.15.C.0.0-0 

    Если сделать вот так - https://help.keenetic.com/hc/ru/articles/360001390359 , то в Настройка Keenetic#2 - п2  в  "межсетовой экран" не появляется "закладка" с  интерфейсом l2tp-ipsec ... что не дает возможности добавить правила и "лазить" с Keennetic #1 в локальную сеть Keenetic #2 ... Хотя в Keenetic #2 на страничке "Другие подключения" все отображается и работает

    1372297221_IMAGE2019-03-05075510.thumb.jpg.783ebc3cabc4ef2c4428d8a719a7971c.jpg

    в качестве "пациента-клиента" Keenetic #2 для тестов использовались  Giga II и KN-1310 . "Картинка" одинакова ни там ни там на страничке "межсетовой экран" НЕТ "закладки" с добавленным и работающим "L2TP/IPSec"  .... 

    Проверил для "эксперимента"  если добавить в качестве типа подключения (протокол) OpenVPN, что на Giga II что KN-1310 - то все "нарядно" , на страничке "межсетевой экран" сходу появляется соответствующая закладка добавленного "интерфейса". 

     

    Не скачивается обновление 2.12.A.3.0-4

    in 2.12

    Posted · Edited by Dorik1972 

    Feb 16 09:46:52ndmComponents::Manager: update task started.
Feb 16 09:46:53ndmCore::Ndss: [2345] HTTP error: 500 (Internal Server Error).
Feb 16 09:46:53ndmComponents::Manager: request failed (500).
Feb 16 09:47:12ndmComponents::Manager: invalid size: 0.

    Обе Ultra II - никак ... Лог приведен выше. Остальные (Giga II, Giga III, Keenetic II. Viva) - обновились без проблем

    Firmware update

    in 2.12

    Posted

    1 час назад, Infy сказал:

    @Dorik1972 Приведите выводы команд "show version" и "show system".
    Также очень желательно выложить сюда файл с текущей прошивкой, загруженной через веб-интерфейс.

    С удовольствием ...но на следующей неделе. Оставшаяся не обновленной  Viva далековато ... и проводить "эксперименты" удаленно чревато внеплановым выездом на объект :smile: 

    Firmware update

    in 2.12

    Posted · Edited by Dorik1972

    3 минуты назад, Le ecureuil сказал:

    У вас "все компоненты"?

    нет конечно ... там и половина не выбраны . Впихнул таки всюду через старый интерфейс ..кроме Viva там никак 

    Feb 02 12:45:31ndmIo::File: unable to write data: no space left on device.
Feb 02 12:45:31ndmComponents::Manager: system failed [0xcffd02e1].

    Пробовал "руцями" пробежаться по "гапочкам" снял-поставил компоненту ....  

    Components::Manager: system failed [0xcffd02e1].
Feb 02 12:27:46ndmComponents::Manager: component "angular-ndw" is queued for removal.
Feb 02 12:27:47ndmComponents::Manager: component "angular-ndw" is queued for installation.
Feb 02 12:27:50ndmComponents::Manager: component "kabinet" is queued for removal.
Feb 02 12:27:55ndmComponents::Manager: component "nathelper-ftp" is queued for removal.
Feb 02 12:27:56ndmComponents::Manager: component "nathelper-pptp" is queued for removal.
Feb 02 12:27:57ndmComponents::Manager: component "nathelper-sip" is queued for removal.
Feb 02 12:28:10ndmComponents::Manager: component "transmission" is queued for removal.
Feb 02 12:28:16ndmComponents::Manager: component "cifs" is queued for removal.
Feb 02 12:28:17ndmComponents::Manager: component "hfsplus" is queued for removal.
Feb 02 12:28:22ndmComponents::Manager: component "hfsplus" is queued for installation.
Feb 02 12:28:29ndmComponents::Manager: component "acl" is queued for installation.
Feb 02 12:28:59ndmComponents::Manager: update task started.

    оставил "минимум" без которого никак ... результата нет ...  NO SPACE

    Firmware update

    in 2.12

    Posted · Edited by Dorik1972

    При попытке обновиться c предыдущей на крайнюю 2.12.A.3.0-0:

    Ultra II, Gga II, Viva, Giga III, Keenetic II 

    Feb 02 13:30:23ndmComponents::Manager: update task started.
Feb 02 13:30:23ndmComponents::Manager: firmware image is too large.

    Иногда , после 3-5 попыток "тыцнуть" по обновить - обновляет .... в Ultra II удалось "впихнуть", в одну из 2-х .... остальные - никак  "впихнулись" с 3-5 раза через webстарый интерфейс 

    Определение состояния доступа в Интренет

    in 2.11

    Posted

    4 часа назад, Le ecureuil сказал:

    Чтобы иметь возможность установить свои хосты установите компонент easyconfig (Netfriend), и задайте ваши хосты в cli:

    > easyconfig host <your.site.tld>

    При этом преднастроенные сайты не будут использоваться, будет использоваться только ваш.

     ПРИМНОГО БЛАГОДАРЕН !!! ... ( от "изнасилованныых" мной технарей моего прова :D - отдельное БОЛЬШОЕ СПАСИБО )

    Определение состояния доступа в Интренет

    in 2.11

    Posted · Edited by Dorik1972

    Аналогичная "БАЙДА" ... я уже прова "изнасиловал" :) прибежали с "оммометрами" физику "вышколили" от Wan-порта зверька до прова верхнего уровня :)  При том что мой порт на свитче у прова "флипает" раз в сутки от силы, а у меня в логах "труба-приплыли" каждые 20 сек "упал-встал", а тут тест доступности и-нета по ya.ru  )))  Может можно как-то из CLI самому задавать (или добавить такую возможность) хосты для проверки работоспособности и-нета ... вне зависимости от "хочухи" какого-нибудь президента .... А то мало ли ... у каждого свой през...идент ... и ХОЧУХИ - явно не совпадают ;)

    p.s. О! Предлагаю добавить 4-ый  и 5-ый хосты проверки доступности нета - rutracker.org и pornhub.com  ... ну а че ... весьма посещаемые и неубиенные ресурсы .... Зато сразу трабла "нарисуется"  и обильно посыпятся  self-testы :cool:

    ipv6

    in 2.11

    Posted · Edited by Dorik1972

    1 час назад, Goblin сказал:

    в прошивке  2.11.A.2.0-0 ipv6 поломали? в логе красным....

    dhcp6c[777] client6_send: transmit failed: Network is unreachable

    и тест не проходит.

    Ultra II все проходит ... через "туннель"

     

    Снимок экрана 2017-09-19 в 08.50.46.png

    2.10.A.7.0-5 Keenetic Ultra II

    in 2.10

    Posted

    Работало "не затыкаясь" неделю после обновления ... сегодня с утра => 

    Sep  8 06:32:51 192.168.2.1 ndm: Process: "ARP ping check" has been killed.
Sep  8 06:33:45 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=15000 jiffies)
Sep  8 06:33:45 192.168.2.1 ndm: kernel: Call Trace:                                                                   
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<802d62cc>] dump_stack+0x8/0x34                                              
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8007a830>] __rcu_pending+0x1e0/0x530                                        
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8007b76c>] rcu_check_callbacks+0x118/0x180                                  
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<80035810>] update_process_times+0x48/0x74                                   
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<800674cc>] tick_sched_timer+0x7c/0x34c                                      
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8004bde8>] __run_hrtimer.isra.4+0x68/0x138                                  
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8004c8b0>] hrtimer_interrupt+0x1b0/0x4e8                                    
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<80011990>] c0_compare_interrupt+0x64/0x90                                   
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<80073c08>] handle_irq_event_percpu+0x70/0x1fc                               
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<800777b8>] handle_percpu_irq+0x8c/0xbc                                      
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8007325c>] generic_handle_irq+0x3c/0x54                                     
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8000cbe0>] do_IRQ+0x18/0x28                                                 
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8000b010>] ret_from_irq+0x0/0x4                                             
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8014c344>] prio_tree_remove+0x84/0x13c                                      
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<800a17d8>] unlink_file_vma+0x44/0x80
  Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<8009b910>] free_pgtables+0x58/0x16c
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<800a4004>] exit_mmap+0x108/0x14c
Sep  8 06:33:45 192.168.2.1 ndm: kernel: [<80025960>] mmput+0x44/0x130
Sep  8 06:33:45 192.168.2.1 ndm: kernel:
Sep  8 06:36:45 Keenetic_Ultra kernel:
Sep  8 06:36:45 Keenetic_Ultra kernel[8040>]: xtma+x0/x4
Sep  8 06:36:45 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=60003 jiffies)
Sep  8 06:36:45 192.168.2.1 ndm: kernel: Call Trace:
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<802d62cc>] dump_stack+0x8/0x34
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007a830>] __rcu_pending+0x1e0/0x530
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007b76c>] rcu_check_callbacks+0x118/0x180
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80035810>] update_process_times+0x48/0x74
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800674cc>] tick_sched_timer+0x7c/0x34c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8004bde8>] __run_hrtimer.isra.4+0x68/0x138
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8004c8b0>] hrtimer_interrupt+0x1b0/0x4e8
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80011990>] c0_compare_interrupt+0x64/0x90
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80073c08>] handle_irq_event_percpu+0x70/0x1fc
  Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800777b8>] handle_percpu_irq+0x8c/0xbc
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007325c>] generic_handle_irq+0x3c/0x54
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8000cbe0>] do_IRQ+0x18/0x28
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8000b010>] ret_from_irq+0x0/0x4
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8014c060>] get_index.isra.0.part.1+0x20/0x2c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8014c354>] prio_tree_remove+0x94/0x13c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800a17d8>] unlink_file_vma+0x44/0x80
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8009b910>] freptbe+x801c<><0a04]ei_mp01801c<><0290]mpt04/x3
Sep  8 06:36:45 192.168.2.1 ndm: kernel: 4
Sep  8 06:39:45 Keenetic_Ultra kernel[8056>]: mu+x4010<>0004<><0400]gtidxir..at10002
Sep  8 06:39:45 Keenetic_Ultra kernel[81c5>]: rote_eoe09/x3
Sep  8 06:39:45 Keenetic_Ultra kernel[801d>]: nikfl_m+x408
Sep  8 06:39:45 Keenetic_Ultra kernel[80b1>]: reptbe+x801c<><0a04]ei_mp01801c<><0290]mpt04/x3
Sep  8 06:39:45 Keenetic_Ultra kernel:
Sep  8 06:36:45 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=60003 jiffies)
Sep  8 06:36:45 192.168.2.1 ndm: kernel: Call Trace:
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<802d62cc>] dump_stack+0x8/0x34
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007a830>] __rcu_pending+0x1e0/0x530
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007b76c>] rcu_check_callbacks+0x118/0x180
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80035810>] update_process_times+0x48/0x74
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800674cc>] tick_sched_timer+0x7c/0x34c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8004bde8>] __run_hrtimer.isra.4+0x68/0x138
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8004c8b0>] hrtimer_interrupt+0x1b0/0x4e8
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80011990>] c0_compare_interrupt+0x64/0x90
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<80073c08>] handle_irq_event_percpu+0x70/0x1fc
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800777b8>] handle_percpu_irq+0x8c/0xbc
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8007325c>] generic_handle_irq+0x3c/0x54
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8000cbe0>] do_IRQ+0x18/0x28
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8000b010>] ret_from_irq+0x0/0x4
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8014c060>] get_index.isra.0.part.1+0x20/0x2c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8014c354>] prio_tree_remove+0x94/0x13c
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<800a17d8>] unlink_file_vma+0x44/0x80
Sep  8 06:36:45 192.168.2.1 ndm: kernel: [<8009b910>] freptbe+x801c<><0a04]ei_mp01801c<><0290]mpt04/x3
Sep  8 06:36:45 192.168.2.1 ndm: kernel: 4

    Ну и дальше сплошные "краши"  ... перегрузка по питанию исправила ситуацию :) и пока как и раньше все работает хорошо . Вопрос что это было? И было ли у кого-то еще?

    Зависает Ultra II на 2.10.A.2.0-0

    in 2.10

    Posted

    9 часов назад, Клуб любителей мускусных уток сказал:

    Походу видимо пока не умирал, раз не сбросил, уже 27-ое...?

    Dorik, как дела то? 

    Вообще по уму даже после сброса на заводские и загрузку провести хард ребут по кнопке

    Можно и кнопкой )) А можно и по tftpd ему "впихнуть" прошивку для надеги  .... НО! Комарады опосля сброса в "заводские" и пернастройки с "нуля" kernel panic больше не ловил ... Зато в 100% случаев из 100 поймал другую неприятность связанную с использованием сервиса DDNS. Трабла наблюдается только на Ultra II и только на текущей "крайней" 2.10.А.3 . Итак :

    1) На страничке web-интефейса "Интернет"=>"DDNS" - заполняем свои учетные данные (я и спользую www.noip.com)

    2) На страничке "Система"=>"Параметры" - тыцяем "гапочку"  на "Доступ к веб-конфигуратору через Интернет:" - порт оставляем по умолчанию - 80-ый

    3) Перегружаем (чисто для "самоуспокоения").... пытаемся ломануться на ВАСЯ.ddns.net - И НИФИГА ))))

    До этого все работало "как часики" ... и продолжает работать что на Giga II что на Extra ....

     4) Идем на страничку "Безопасность"=>"Трансляция сетевых адресов (NAT)" ... Руцями рисуем правило проброса из-вне на 192.168.1.1:80 - И ВУАЛЯ ... все теперь работает ....

    Вроде как раньше при наличии "гапочки" на доступ ... сие правило добавлялось автоматом ? или ? 

    Дальше веселее .... имея БЕЛЫЙ IP  (при условии что гапочка разрешения доступа к веб-конфигуратору "ON")..... идем на страничку "Приложения"=>"KeenDNS" - заполняем ВАСЯ.mykeenetic.net  .. и говорим - ПРЯМОЙ ДОСТУП (IP-то белый) ... тут же получаем предупреждение что "Прямой доступ невозможен с серым IP-адресом. Используйте режим «Через облако» или приобретите у провайдера белый IP-адрес." что нифига "не белый" .... Если проигнорить предупреждение то без правила проброса 80-ого порта работать НЕ БУДЕТ ..... А через "облако" - "как часы" ... 

    В общем проверьте плиззз .... сдается мне что я не "уникальный" в описанной мной ситуации .....

    Зависает Ultra II на 2.10.A.2.0-0

    in 2.10

    Posted · Edited by Dorik1972

    Первое "падение" 

    Jun 24 20:42:29 Keenetic_Ultra kernel: AP 5GHz: run channel auto-switch
Jun 24 20:42:39 192.168.2.1 ndm: kernel: ACS result: primary channel 36, 80 MHz spectrum min dirty (with CCA) = 0
Jun 24 20:42:40 192.168.2.1 wmond: WifiMaster1/AccessPoint0: (MT76x2) BSS(rai0) channel switched to 36.
Jun 24 20:45:58 192.168.2.1 ndm: Process: "ARP ping check" has been killed.
Jun 24 20:46:37 192.168.2.1 ndm: kernel: AP 2.4GHz: run channel auto-switch
Jun 24 20:46:43 192.168.2.1 ndm: kernel: 6>C eut rmr hne ,4 H pcrmmndry(ihCA  4
Jun 24 20:46:43 192.168.2.1 wmond: WifiMaster0/AccessPoint0: (MT76x2) BSS(ra0) channel switched to 1.
Jun 24 20:46:48 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=15000 jiffies)
Jun 24 20:46:48 192.168.2.1 ndm: kernel: Call Trace:
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<802d9120>] dump_stack+0x8/0x34
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8007af9c>] __rcu_pending+0x1e0/0x544
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8007bee4>] rcu_check_callbacks+0x118/0x180
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80035b40>] update_process_times+0x48/0x74
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80067a6c>] tick_sched_timer+0x7c/0x34c
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8004c308>] __run_hrtimer.isra.5+0x68/0x138
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8004cdc4>] hrtimer_interrupt+0x1b4/0x4dc
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800119f0>] c0_compare_interrupt+0x64/0x90
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800742ac>] handle_irq_event_percpu+0x70/0x1fc
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80077eec>] handle_percpu_irq+0x8c/0xbc
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80073908>] generic_handle_irq+0x3c/0x54
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8000cb4c>] do_IRQ+0x18/0x2c
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8000af70>] ret_from_irq+0x0/0x4
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8014d8d4>] prio_tree_remove+0x18/0x13c
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800a2360>] unlink_file_vma+0x44/0x80
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8009c3f4>] free_pgtables+0xac/0x16c
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800a4bc8>] exit_mmap+0x108/0x14c
Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80025a90>] mmput+0x44/0x130
Jun 24 20:46:48 192.168.2.1 ndm: kernel:
Jun 24 20:49:48 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=60003 jiffies)
Jun 24 20:49:48 192.168.2.1 ndm: kernel: Call Trace:
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<802d9120>] dump_stack+0x8/0x34
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8007af9c>] __rcu_pending+0x1e0/0x544
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8007bee4>] rcu_check_callbacks+0x118/0x180
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80035b40>] update_process_times+0x48/0x74
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80067a6c>] tick_sched_timer+0x7c/0x34c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8004c308>] __run_hrtimer.isra.5+0x68/0x138
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8004cdc4>] hrtimer_interrupt+0x1b4/0x4dc
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800119f0>] c0_compare_interrupt+0x64/0x90
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800742ac>] handle_irq_event_percpu+0x70/0x1fc
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80077eec>] handle_percpu_irq+0x8c/0xbc 
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80073908>] generic_handle_irq+0x3c/0x54
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8000cb4c>] do_IRQ+0x18/0x2c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8000af70>] ret_from_irq+0x0/0x4
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8014d634>] get_index.isra.0.part.1+0x4/0x2c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8014d970>] prio_tree_remove+0xb4/0x13c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800a2360>] unlink_file_vma+0x44/0x80
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8009c3f4>] free_pgtables+0xac/0x16c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800a4bc8>] exit_mmap+0x108/0x14c
Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80025a90>] mmput+0x44/0x130
Jun 24 20:49:48 192.168.2.1 ndm: kernel:

    Второе "падение" - точно такое же ... Пока что сбросил в "заводские" и перенастроил все с "нуля" .... Мало ли "криво" прошивка лягла ... еще раз помрет - сброшу и селф-тест и собственно лог ... 

     

     

    Зависает Ultra II на 2.10.A.2.0-0

    in 2.10

    Posted · Edited by Dorik1972

    28 минут назад, Le ecureuil сказал:

    Приложите self-test просто нормально работающей системы, чтобы понять ее конфигурацию.

    Завтра до 13-00 по MSK сделаю . Не на "базе" :( .... после перегруза по питанию пару часов "живет нормальной" жизнью )) Так что self-test - не проблема. Заметил что пациент "перед смертью" переставал откликаться на 80-ом порту. Чрез DDNS напрочь не хотел давать доступ. При этом IP пингуется и в "рабочем кабинете" на no-ip рефрешится из web-интерфейса Ultra II. Тест "из вне" говорит что 80 порт открыт.  Перешел на XXXX.mykeenetic.net  - не дает "прямого доступа" , только через облако. Хотя IP - "белый". Через "облако" - работало ... но и в итоге "помер" . Провайдеру "мозг вынес" , клянется что изменений НОЛЬ .... за 2-ое суток просмотрели лог подключений - ошибок нет. Было одно "мусорное" подключение когда вместо родного IP была попытка подключения роутера с IP 78.47.125.180 . Подозреваю что это XXXX.mykeenetic.net в момент попытки "прямого доступа" - по времени в аккурат совпало с перенастройкой с DDNS на mykeenetic.net) . От прова - тоже пинговался, пока не "помер". IP- неизменен на протяжении 5-ти лет .

    p.s. Мобильное приложение My.Keenetic (android) - показывает что роутер в сети :) но при попытке войти - "Подключение отклонено Интернет-центром, не включен модуль удаленного доступа" . При этом "родной" IP - не пингуется ......

    Зависает Ultra II на 2.10.A.2.0-0

    in 2.10

    Posted

    Только что, Padavan сказал:

    Dorik1972

    Все-же неплохо бы получить кусок лога перед возникновением дедлока, так как "точно такая-же" может быть совсем из другой оперы.

    В первом случае виден дедлок, предположительно после срабатывания пинг-чекера. Однако данных в логе мало, хотелось бы видеть побольше строк до появления дедлока.

     

    Сделать смогу завтра так как не дома. Поймал с утра ... дважды.  В третий раз , судя по всему, "помер" уже на удаленке :( .  Физически не доступен на данный момент".  Ping-чекер не задействован. К сожалению писал "по памяти".

    Зависает Ultra II на 2.10.A.2.0-0

    in 2.10

    Posted

    В 18.06.2017 в 11:28, Dale сказал:

    После обновления прошивки уже два раза столкнулся с завианием роутера с одинаковыми симптомами. При полном отсутствии каких-либо предварительных сообщений роутер внезапно зависает, при этом syslog серверу он успевает отправить вот такое:

      Показать содержимое 
    

18.06.2017 10:50,Info,192.168.1.1,PingCheck::Profile: interface ISP connection check failed.
18.06.2017 10:50,Error,192.168.1.1,Opkg::Manager: /opt/etc/ndm/wan.d/port.sh: timed out.
18.06.2017 10:50,Error,192.168.1.1,kernel: INFO: rcu_sched self-detected stall on CPU { 0}  (t=15000 jiffies)
18.06.2017 10:50,Warning,192.168.1.1,kernel: Call Trace:
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<802d9060>] dump_stack+0x8/0x34
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8007af9c>] __rcu_pending+0x1e0/0x544
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8007be44>] rcu_check_callbacks+0x78/0x180
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<80035b40>] update_process_times+0x48/0x74
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<80067a6c>] tick_sched_timer+0x7c/0x34c
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8004c308>] __run_hrtimer.isra.5+0x68/0x138
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8004cdc4>] hrtimer_interrupt+0x1b4/0x4dc
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<800119f0>] c0_compare_interrupt+0x64/0x90
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<800742ac>] handle_irq_event_percpu+0x70/0x1fc
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<80077eec>] handle_percpu_irq+0x8c/0xbc
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<80073908>] generic_handle_irq+0x3c/0x54
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8000cb4c>] do_IRQ+0x18/0x2c
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<8000af70>] ret_from_irq+0x0/0x4
18.06.2017 10:50,Warning,192.168.1.1,kernel: [<802dd364>] _raw_read_unlock_bh+0xb4/0xd0
18.06.2017 10:50,Warning,192.168.1.1,kernel: 
18.06.2017 10:50,Notice,192.168.1.1,closing control connection due to missing echo reply
18.06.2017 10:50,Notice,192.168.1.1,Sent control packet type is 12 'Call-Clear-Request' 
18.06.2017 10:50,Notice,192.168.1.1,Closing PPTP connection
18.06.2017 10:50,Notice,192.168.1.1,Sent control packet type is 3 'Stop-Control-Connection-Request' 
18.06.2017 10:50,Notice,192.168.1.1,Closing connection (call state)
18.06.2017 10:51,Error,192.168.1.1,kernel: INFO: rcu_bh detected stalls on CPUs/tasks: { 0} (detected by 1, t=15004 jiffies)
18.06.2017 10:51,Error,192.168.1.1,kernel: INFO: Stall ended before state dump start

     

    После чего остается только делать reset. Call trace каждый раз один и тот же. Селфтест по понятным причинам привести не могу, конфиг в скрытом сообщении ниже.

    Поймал ТОЧНО такйю же "неприятность" после перехода на своей Ultra II на 2.10.A.3.0-0 .... Спасает только ребут по питанию ... Работает недолго 2-3 часа .. и снова ... бегом к роутеру "штепсель" выдергивать ..... Как побороть неприятность ?

    Отображение состояния IPSec в web-интерфейсе

    in 2.10

    Posted

     Прежде всего СПС ! Разрабам за великолепный продукт :)

    А теперь немного картинок.  Имеем связку Zyxel Ultra II и Giga II  (Дом-Дача ...Классика :) )после обновления IPSec прекрасно работает но!  На "Системный монитор"->"IPSec VPN" подключение не отображается ну никак .....

    Это лог полключения "клиента" Giga II ("клиент") + лог Ultra II ("сервер") + "Состояние подключения" (одинаково на обоих устройствах) 

     

    Снимок экрана 2017-06-10 в 09.05.51.png

    Снимок экрана 2017-06-10 в 09.06.05.png

    Снимок экрана 2017-06-10 в 09.06.31.png

    Ряд "непоняток" в 2.09.A.3.0-0

    in 2.09

    Posted

    13 минуты назад, iggo сказал:

    Не могу подтвердить. Когда гнездо свободно, выбор есть (USB2.0 - USB3.0). Когда есть подключенное устройство - протокол согласован, выбор недоступен.

    Мой косяк :( но... п2 и п3 - остаются... судя по всему не только у меня "глюк" такой наблюдается

    Ряд "непоняток" в 2.09.A.3.0-0

    in 2.09

    Posted · Edited by Dorik1972

    Девайс Ultra II :

    1) Недоступен выбор "Режим работы USB" на закладке "Система/Параметры" (вопрос закрыт)

    2) Перестал отрабатываться скрипт при запуске/перезапуске роутера в /opt/etc/ndm/netfilter.d (даже с одной строкой ... например п3)

    3) Если задать "в ручную" правило 

    iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

    то глядя в iptables -t nat -L имеем 

    Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
_NDM_DNAT  all  --  anywhere             anywhere            
_NDM_EZ_BYPASS  all  --  anywhere             anywhere            
_NDM_UPNP_REDIRECT  all  --  anywhere             anywhere            
_NDM_SL_PRIVATE  tcp  --  anywhere             my.keenetic.net      tcp dpt:http
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:http redir ports 3128

    НО! Любое оращение на 80 порт с любого внутреннего IP как "бегало" через 80 ... так и продолжает "бегать" через 80 ... добавленное правило игнорируется :) 

    В предыдущем драфте таких "нюансов" не наблюдалось..... 

×
×
  • Create New...