Jump to content

booroondook

Forum Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by booroondook

  1. 3 часа назад, Sartoris сказал:

    складывается такое ощущение, что это проблема самой малинки.

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

    При этом не имеет значения, какой именно сетевой интерфейс является в данный момент рабочим - Ethernet, WiFi, или даже оба сразу.

    Как мне показалось (но я до конца не уверен) для наличия обсуждаемой проблемы нужно, чтобы в Кинетике были зарегистрированы оба MAC-адреса устройства - и Ethernet'овский, и WiFi'ный. При этом DHCP-лизинг для них не является обязательным.

  2. Версия 3.9.4 на всех Кинетиках.

    Лог в момент бага - это как вообще?

    Вот сижу я за рабочей станцией с Windows 10. Вызываю командную строку. Посылаю команду "ping 192.168.0.xxx". В ответ получаю "Destination host not reachable".

    Вы этот лог имели в виду, или какой? Роутер такие события не логирует вообще.

     

    P.S. Проблема решилась. Симптомы были очень похожи на включенную изоляцию WiFi-клиентов. Оставалось только найти тот модуль, который её включил. И это , судя по всему, оказался OPKG-шный модуль Netfilter. После его удаления проблема перестала проявляться.

    • Upvote 1
  3. Основной роутер: Omni (KN-1410)

    Ретрансляторы: 3 шт. Start (KN-1111) и 2 шт. Lite (KN-1311) - некоторые связаны с основным роутером по кабелю, некоторые по WiFi

    Организована WiFi-система.

    Клиентов сети: порядка 100 (серверы, рабочие станции, камеры видеонаблюдения, устройства умного дома, медиаприставки. телевизоры, смартфоны). Часть клиентов подключена к сети по кабелю, часть - по WiFi через разные ретрансляторы.

    Проблема состоит в том, что WiFi-устройства (не кабельные, а только WFi), подключенные к ретрансляторам (но не к основному роутеру), недоступны по сети со стороны других клиентов (например, рабочих станций под Windows, серверов под Linux и др.) - а именно: не проходит ping, нет доступа по telnet на известные открытые порты, не открываются веб-интерфейсы (у кого они есть). Точно так же не проходит ping на эти устройства из Web-интерфейсов ретрансляторов (при условии, что устройство подключено не к данному ретранслятору, а к другому). При этом из Web-интерфейса основного роутера ping на эти устройства проходит всегда.

    Тип недоступного устройства роли не играет - это может быть и IoT-устройство (розетка, выключатель, умная лампа), и камера видеонаблюдения, и смартфон. Стоит также заметить, что IoT-устройства из числа "недоступных" продолжают передавать требуемые от них данные на сервер умного дома и управляться с его стороны.

    Замечено также, что если перезагрузить (например, по питанию) такое "недоступное" устройство, то оно начинает отвечать на ping, и это продолжается некоторое время, а затем снова становится недоступным. Тот же эффект можно наблюдать, если перезагрузить ретранслятор, обслуживающий такое "недоступное" устройство.

     

    Хотелось бы узнать суть описанного явления, а также способы устранения этой проблемы.

     

    • Need more info 1
  4. 1 час назад, Rhon сказал:

    Это может быть проблема самой камеры, когда она отвечает ARP кадров со своих обоих интерфейсов - проводного и wifi. 
    Причем один из интерфейсов может не быть активным, но ядро ОС камеры, все равно отвечает.

    Проблема касается не только камер. Например, имеется RaspberryPi, подключенный к сети и по кабелю, и по WiFi. С ним точно такая же ситуация - в списке устройств показываются два устройства с одинаковыми MAC-адресами (причем, и там, и там показан MAC-адрес именно WiFi-карты, а не Ethermet), но с разными IP. А в журнале ошибок указан конфликт между теперь уже разными MFC'ами (Ethernet'овским и WiFi'ным), которые якобы работают на одном и том же IP-адресе (и указан IP-адрес, закрепленный в настройках для WiFi-адаптера).

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

    P.S. Проверил инструкцию по вашей ссылке на Raspberry Pi - не помогло.

     

  5. 8 минут назад, loginella сказал:

    Белый список в помощь.

    Да - так и сделал в итоге. Спасибо!

    9 минут назад, loginella сказал:

    И, да, эта функция на смартфонах отключаема, потому они так не устроены

    Здесь надо учитывать "skill level" конкретного пользователя. Абсолютное большинство пользователей Андроида и слыхом не слыхивало об этой функции, поэтому они пользуются теми настройками, которые были "из коробки". А "из коробки" как раз настроено на случайный MAC.

    • Upvote 1
  6. Можно ли заблокировать устройство, по неполному MAC-адресу?

    Немного поясню вопрос. Необходимо заблокировать смартфон на Андроиде (ну, когда-то сдуру сообщили соседке пароль от WiFi, а теперь она "тычется" в мою сеть, а менять пароль WiFi не хочется по ряду причин).

    Современные версии Андроида устроены так, что при каждом подключении генерируют новый случайный MAC-адрес, поэтому блокировать устройство по полному MAC-адресу - бессмысленная затея.

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

    В связи с этим возникает вопрос - а можно ли как-то блокировать устройства не по конкретным полным MAC-адресам, а по маске MAC-адреса?

  7. В данный момент (после нескольких перезагрузок Кинетика) ситуация слегка изменилась, а именно:

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

    (на картинке IP-адреса замазаны, но "расшифрую" - для MACа Ethernet-адаптера (00:12:41:...) IP-адрес 192.168.0.80, а для MACа WiFi-адаптера (30:ff:f6:...) IP-адрес 192.168.0.40)  

    2. Но в логе по-прежнему появляются записи:

     
    Авг 16 11:58:23 ndm
    Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts 00:12:41:XX:XX:XX and 30:ff:f6:XX:XX:XX have the same IPv4 address 192.168.0.40.
    То есть, говорится о том, что оба эти MAC-адреса используют один и тот же IP-адрес 192.168.0.40, закрепленный за WiFi-адаптером камеры.
    Но на самом деле это не так, потому что второй адрес (192.168.0.80, закрепленный за Ethernet-адаптером камеры) пингуется, и через него можно попасть в Web-интерфейс администрирования камеры, и именно по этому адресу камера "прицеплена" к видеорегистратору.
    Так что получается, что "дуркует" только сам Кинетик.
     
    P.S. По факту, конечно же, на работоспособность это не влияет, однако сообщения в логе о якобы существующих ошибках несколько напрягают.
     
  8. В 13.08.2021 в 21:19, Васька Поперечный сказал:

    Здесь очевидно, что MAC вдюхи wifi и ethernet совпадают

    В том-то и дело, что MAC-адреса разные - внимательнее прочитайте первое сообщение. 

    2021-08-16 10_48_39-Window.png

    P.S. Для WiFi-адаптера тоже указано "По проводу", потому что он подцепляется к сети не через точку доступа Кинетика, а через другую точку доступа, которая, в свою очередь, соединена с Кинетиком по проводу.

  9. Keenetic Omni, режим роутера, сеть разветвленная (коммутаторы, точки доступа WiFi, порядка полусотни проводных и беспроводных клиентов).

    В логе повторяется много раз следующая запись:

    Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts aa:bb:cc:dd:ee:ff and ff:ee:dd:cc:bb:aa have the same IPv4 address 192.168.0.100

    (здесь MAC- и IP-адреса изменены для приватности)

    Смотрю, что же это за устройства и обнаруживаю, что оба MAC-адреса принадлежат одной и той же камере видеонаблюдения, которая подключена к сети и через Ethernet, и по WiFi (причём, по WiFi не к точке доступа роутера, а к другой точке доступа, тоже входящей в мою сеть - поэтому Кинетик показывает подключение "по проводу") . То есть, один MAC-адрес принадлежит Ethernet-адаптеру камеры, а второй - её же WiFi-адаптеру.

    И при этом оба этих MACа зарегистрированы как разные устройства, и обоим присваиваются разные выделенные IP-адреса (DHCP static lease). А Кинетик в своем логе упоминает только тот IP-адрес, который принадлежит именно WiFi-адаптеру камеры.

    Смотрю список устройств и вижу вот такое чудо: зарегистрированное устройство с MAC-адресом WiFi-адаптера повторяется в списке два раза - при этом обе записи полностью совпадают - и присвоенное имя, и MAC-адрес, и IP-адрес, и вид подключения.

    Ну ладно, думаю. Удалю-ка я их обоих (ну, то есть, две этих одинаковых позиции) из зарегистрированных устройств - пусть "живут своей жизнью." Но при этом Ethernet-подключение камеры не трогаю, оставляю в списке. Удалил. Смотрю - теперь в списке незарегистрированных устройств два устройства "Без имени" с одинаковыми MAC- и IP-адресами. Перезагрузил Кинетик. Ничего не изменилось: всё так же в незарегистрированных устройствах два "близнеца", а в логе снова бегут эти строчки.

    Что делать-то?

    P.S. Советы типа "отключи на видеокамере одно из подключений" не принимаются, ибо нужно там иметь и Ethernet, и WiFi.

    P.P.S. Сохранил конфигурацию в файл - в файле никаких дублей нет. Странно.

    • Upvote 1
  10. KeenDNS - это решение для серых адресов. Мне оно не нужно, т.к. есть белый адрес.

    Цитата
    ip http ssl acme get mydomain.ru

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

    P.S. А хотя нет - сработало, хоть и пришлось ждать долго.

    Спасибо за помощь!

  11. Ну, вот мои настройки. Вроде бы всё, как у вас. Однако, если я обращаюсь...

    https://myname.keenetic.pro -  получаю главную страницу веб-сервера (т.к. он согласно правилам переадресации в статусе DMZ, и на него переадресуется порт 443)

    https://myname.keenetic.pro:8443 -  получаю веб-админку роутера. Меня это удовлетворяет лишь отчасти (т.к. порт не пересекается с https-портом веб-сервера)

    https://my_domain:8443 -  получаю бесконечное ожидание открытия страницы в браузере

    https://my_ip_address:8443  -  получаю бесконечное ожидание открытия страницы в браузере.

    А мне-то как раз и нужно обращаться извне именно по моему доменному имени (благо есть и белый IP, и зарегистрированный домен), а не через "костыль", предоставляемый KeenDNS

    1453559913_2021-07-2918_53_57-KeeneticOmni.png.3b3d19ad30c89d678b18e8e66a9e34b1.png

    2069136019_2021-07-2918_49_56-Window.thumb.png.05196692382af42cea8ba2ab2455b35c.png

    1249414061_2021-07-2918_44_19-Window.png.0c1d91016675d0a43ebfea39e7e5f94c.png

  12. Устройство: Keenctic Omni

    Версия ПО: Keenetic OS 3.6.10

    Нужен доступ из внешний сети к веб-интерфейсу администрирования по протоколу HTTPS на нестандартный порт.

    Конфигурация такая: "белый" IP-адрес, за роутером работает веб-сервер. Т.к. этот сервер использует (вполне естественно)  https и 443-й порт, то на него проброшены порты 80-й и 443-й.

    В связи с этим обращение извне на https://<domain_name>.keenetic.pro (не говоря уже про https://<IP-адрес>) приводит к попаданию на главную страницу этого самого веб-сервера (и это понятно, потому что 443-й порт переброшен на веб-сервер).

    Выходом из ситуации было бы назначение для "админки" какого-нибудь нестандартного порта - например, 8443 или 9943 или еще какого-нибудь.

    Но в GUI-настройках я ничего подобного не нашел. Еще я пробовал назначить переадресацию порта 8443  на 443-й порт самого роутера. И это тоже не помогает.

    Может быть, можно назначить нестандартный порт не через GUI, а через CLI? Но я не знаю, как.

×
×
  • Create New...