Секретный адреса ретрансляторов

[Parus]

Ребята, что за баг или фича такая - устройство iot отказывалось подключаться на выделенном ей ip. Начал рыть -там открывается ретранслятор, жестко привязанный на 192.168.1.3 , подключенный по проводу к ведущему.., но занимающий один из адресов гостевой сети для iot 192.168.0.81?? Почему нигде не документировано, что ретранслятор имеет еще и адреса других подсетей и это приводит к конфликтам? Это что, каждый ретранслятор имеет еще фантомный адрес из гостевой?? Где можно узнать эти адреса, чтобы не назначать их устройствам в сети и не терять кучу времени в поисках неисправности?

[KeyYerS]

     Ваша дом сеть - 192.168.1.* ,  а гостевая - 192.168.0.* , так?   Что Вас удивило в том, что контроллер "оставляет" за собой адрес 192.168.0.1 для роутинга клиентов гостевой сети (но поскольку в вебе ничем и никак не настраивается этот доп/ip адрес ретранслятора, вещающего гостевую сеть клиентам) то закономерно, что контроллер ему "выдаёт" первый адрес из гостевого пула, настроенного Вами. Следующему ретранслятору "следующий" ip адрес и т.д.  А уж потом свободные адреса непосредственно клиентам. Иначе маршрутизация клиентам гостевой сети вообще не "взлетит".  Соглашусь, что это упущение, но скорее всего будет ответ, что типа "это через CLI преспокойно прописывается" или тому подобное.

Изменено 13 декабря пользователем KeyYerS

[mrGhotius]

51 минуту назад, KeyYerS сказал:

Ваша дом сеть - 192.168.1.* ,  а гостевая - 192.168.0.* , так?   Что Вас удивило в том, что контроллер "оставляет" за собой адрес 192.168.0.1 для роутинга клиентов гостевой сети

Да, это логично, у интерфейсов подсетей свой адрес, как правило первый в подсети.

 

51 минуту назад, KeyYerS сказал:

что контроллер ему "выдаёт" первый адрес из гостевого пула, настроенного Вами. Следующему ретранслятору "следующий" ip адрес и т.д.  А уж потом свободные адреса непосредственно клиентам. Иначе маршрутизация клиентам гостевой сети вообще не "взлетит".

Зачем ретранслятору адреса из других подсетей? Ведь маршрутизацией занимается контроллер, а ретранслятор выступает здесь устройством доставки уровня L2. 

Изменено 13 декабря пользователем mrGhotius

[Parus]

10 часов назад, KeyYerS сказал:

контроллер ему "выдаёт" первый адрес из гостевого пула, настроенного Вами. Следующему ретранслятору "следующий" ip адрес и т.д. 

Честно говоря, не понимаю, о чем Вы. Само собой, что контроллер оставляет за собой начальные ip всех подсетей. Ретрансляторам же жестко назначены адреса. Зачем им адреса из других пулов?А если все-таки они нужны для чего-то, то это нужно где-то прописать и указать, что контроллеры имеют зарезервированные адреса всех остальных подсетей тоже. И уж желательно тоже сделать возможность их назначать, если уж они так нужны! Ведь контроллер даже не предупреждает, когда я назначаю "зарезервированный" ip  какому-то устройству, но устройство тупо просто не подключается без указания ошибки и причины.!

Изменено 14 декабря пользователем Parus

[KeyYerS]

10 часов назад, mrGhotius сказал:

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

Это справедливо при условии, что не активна опция "Изоляция клиентов".   Согласен, контроллер "занимается". Но на уровне логики - как контроллеру отправлять пакеты конкретному клиенту (в гостевой или др сетях), если он не будет знать, через какого именно (по доп ip) ретранслятора клиент к нему подключается?...   Думаете тут тупое "широковещание" в Mesh'ке, в надежде что до клиента "все равно дойдут" нужные ему пакеты?

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

...то это нужно где-то прописать и указать...

Я ж весьма доступно пояснил в ответе (ниже повторю) - так не на форуме этот вопрос нужно задавать, а в ТехПоддержку, лучше сразу почтой..

11 часов назад, KeyYerS сказал:

Соглашусь, что это упущение, но скорее всего будет ответ, что типа "это через CLI преспокойно прописывается" или тому подобное.

 

[Parus]

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

Я ж весьма доступно пояснил в ответе (ниже повторю) - так не на форуме этот вопрос нужно задавать, а в ТехПоддержку, лучше сразу почтой..

Вроде как тут, в отличие от ТГ, --"Форум Keenetic Community поддерживается разработчиками ПО интернет-центров Keenetic (KeeneticOS). Мы активно принимаем участие в беседах на форуме". -- хочется публичного разъяснения) Может, в рабочие дня ответят.. 

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

лучше сразу почтой..

Уже забыл, как письма писать)

[Parus]

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

Это справедливо при условии, что не активна опция "Изоляция клиентов". 

И да, изоляции нет, и сегменты через CLI соединены 

[mrGhotius]

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

Но на уровне логики - как контроллеру отправлять пакеты конкретному клиенту (в гостевой или др сетях)

VLAN ID

 

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

Думаете тут тупое "широковещание" в Mesh'ке, в надежде что до клиента "все равно дойдут" нужные ему пакеты?

Почему же широковещание, конкретно src mac, dst mac. STP и его производные. Допустим у нас нет wifi и мы собрали сеть из коммутаторов в топологию mesh. Вы также предлагаете выделять на каждом коммутаторе адрес(помимо управления) из всех подсетей(vlan'ов)? 

Изменено 14 декабря пользователем mrGhotius

[Denis P]

2 часа назад, mrGhotius сказал:

VLAN ID

 

Почему же широковещание, конкретно src mac, dst mac. STP и его производные. Допустим у нас нет wifi и мы собрали сеть из коммутаторов в топологию mesh. Вы также предлагаете выделять на каждом коммутаторе адрес(помимо управления) из всех подсетей(vlan'ов)? 

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

[mrGhotius]

2 часа назад, Denis P сказал:

то можно увидеть что это не просто vlan, а svi

Теперь понятно, спасибо.

[KorDen]

20 часов назад, mrGhotius сказал:

Зачем ретранслятору адреса из других подсетей?

mtkiappd для работы 802.11r синхронизирует ключи посредством отправки broadcast-пакетов в своем сегменте.

[Parus]

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

для работы 802.11r

а если у меня в гостевой  (для iot) ничего кроме 2,4ггц  нет? Все равно адреса подсетей присваиваются? Было бы здорово, если бы присваивались адреса, в точности повторяющие адреса домашней сети тогда (192.168.1.3 , 192.168.0.3 и т.д.)..

Изменено 14 декабря пользователем Parus

[KeyYerS]

Спасибо @Denis P за научное пояснение к моему "своими словами". Понимаю и знаю, а (как та собака) сказать не могу... 😕

@Parus  Да, было бы здорово...   Но /в третий раз повторюсь/ - это упущение из внимания, коли уж нигде нет про это в "Справке".

Года 3-2 назад "словил эти грабли", опытным путём выяснил про "назначаемый ретранслятору адрес". Тогда обошлось "костылём": делал сначала "узкий пул" на пару адресов, цеплял ретранслятор, потом правил пул до норм значений - устройства спокойно "брали нужный" ip из правленного пула.   Был тикет в ТП, ответ вроде как был какой-то, но мне не запомнилось предложенное ими.

[Parus]

В 14.12.2025 в 23:23, KeyYerS сказал:

Был тикет в ТП, ответ вроде как был какой-то, но мне не запомнилось предложенное ими.

Посмотрим,что ответят на мое обращение)

[Parus]

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

Посмотрим,что ответят на мое обращение)

Поддержка ответила.. Но по видимому там даже не прочитали вопрос. Сказали, что так должно быть! и проблем не должно происходить.. Но реальность выглядит по другому.Да и в инструкции сказано только про ОДИН присваеваемый адрес. Посоветовали скачать какой-нибудь сканер и самому искать эти фантомные адреса. И что потом с ними делать? 

[Denis P]

24 минуты назад, Parus сказал:

И что потом с ними делать? 

не назначать от балды статику клиентам и регистрировать их по маку ручками?

[KeyYerS]

19 минут назад, Denis P сказал:

...регистрировать их по маку ручками...

IoT розетки постоянно генерят фантомные маки. Поди их потом отлови...

44 минуты назад, Parus сказал:

...там даже не прочитали вопрос...

Может и прочитали - но не пОняли суть вопроса...  У Вас в конце видео "подопытный" Омни задвоился с разными ip, и по обоим адресам он якобы активен..  Тоже есть (и всё ещё не устранённой осталась) проблема с задвоением/затроением клиентов на ретрансляторе, подключенным проводом в контроллер.  Был весной тикет в ТП, так ничем и не помогли.

Изменено 16 декабря пользователем KeyYerS

[mrGhotius]

54 минуты назад, Parus сказал:

И что потом с ними делать? 

Как уже сказал уважаемый Denis P:

29 минут назад, Denis P сказал:

не назначать от балды статику клиентам

В таком случае да, не назначайте статические адреса из пула DHCP, выделите отдельный диапазон под статические адреса. Например с x.x.x.200 - x.x.x.254.

Изменено 16 декабря пользователем mrGhotius

[KeyYerS]

21 минуту назад, mrGhotius сказал:

...не назначайте статические адреса из пула DHCP...

Да все тут "уважаемые"...     Простите, но Вы тоже УШЛИ от сути вопроса, озвученного ТС -   в гостевой сети ретранслятор помимо назначаемого ему контроллером статического адреса *.*.1.3  ещё "отбирает себе" доп адрес  *.*.0.81 гостевой сети (как было выше), создавая проблему для подключения клиента на этот ip.

Изменено 16 декабря пользователем KeyYerS

[mrGhotius]

16 минут назад, KeyYerS сказал:

Простите, но Вы тоже УШЛИ от сути вопроса, озвученного ТС -   в гостевой сети контроллер помимо назначаемого ему контроллером статического адреса *.*.1.3  ещё "отбирает себе" доп адрес  *.*.0.81 гостевой сети (как было выше), создавая проблему для подключения клиента на этот ip.

Так вы сами мне объяснили выше, что так реализован mesh. Остается проблема в том, что нигде не сказано об этом. Хотя я полагал, что ТП разъяснит ситуацию. 

Изменено 16 декабря пользователем mrGhotius

[Denis P]

в итоге всё сводится к тому что нет предупреждения при ручной регистрации клиента в не основных сетях, если такой адрес уже занял ретранслятор, для "домашней сети" такое есть @eralde может глянете?

[eralde]

5 часов назад, Denis P сказал:

в итоге всё сводится к тому что нет предупреждения при ручной регистрации клиента в не основных сетях, если такой адрес уже занял ретранслятор, для "домашней сети" такое есть @eralde может глянете?

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

[Leshiyart]

7 часов назад, eralde сказал:

Как только прошивка начнет их где-нибудь показывать

show ip neighbour
show ip dhcp bindings

Изменено Четверг в 05:21 пользователем Leshiyart

[eralde]

6 часов назад, Leshiyart сказал:

show ip neighbour
show ip dhcp bindings

Наверное, оттуда это действительно можно достать. Но, по-хорошему, эта информация должна быть в show mws member. Фронтенд и так содержит изрядное количество логики вида "возьми данные команд xx, yy и zz и склей по <id>, учитывая условия a, b, ..., z". Правильное решение -- не увеличивать количество такой логики, а уменьшать. Как минимум, потому что в противном случае её придется реализовать в каждом фронтенде заново (веб-интерфейс, мобильное приложение, RMM).

Переформулирую свой ответ так: "Как только прошивка будет отдавать эти данные, касающиеся экстендеров MWS, в ответе какой-нибудь команды, которая имеет отношение к MWS, ..."