vnkorol Опубликовано 4 июня, 2013 · Жалоба Настроил dhcp client на одном из вланов, адрес не получает. Вот лог на дхцп сервере: Time Jun/04/2013 22:30:12 Buffer memory Topics dhcp warning Message managmentvlan_dhcp offering lease 192.168.77.13 for D4:CA:6D:52:D7:DC without success Что характерно, на этом влане, проброшенном через другие порты на роутер и точки доступа, те устройства вполне себе получают адреса. Где я мог навертеть, не подскажете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 июня, 2013 · Жалоба Трафик через влан в обе стороны проходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 4 июня, 2013 · Жалоба ну посмотрите трафик tcpdump - сразу все понятно будет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 июня, 2013 · Жалоба На микротике есть свой сканер открывается на кнопку Torch в меню сетевого порта, ставите все галочки и жмете старт, смотрите что и как бегает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 5 июня, 2013 · Жалоба Трафик по влану бегает, т.к. на этом влане после несчастного роутера, который не получает адрес и который по сути выполняет роль влан коммутатора и точки доступа, находятся еще три железки, которые получают адрес на этом влане и вполне себе управляются по этому влану. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 5 июня, 2013 · Жалоба Вроде, нашел причину. Этот управляющий влан на нескольких физических портах и они (вланы) объединены в бридж. Так вот, на вланах (на любом из) адрес по dhcp не получается, а если повесить dhcp client на бридж, то всё ок. Так и должно быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sherwood Опубликовано 5 июня, 2013 · Жалоба Так и должно быть? ну конечно, вы объединили интерфейсы в бридж, теперь все операции нужно проводить с бриджем а не с портами в нем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 6 июня, 2013 · Жалоба Всё ясно, спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 21 сентября, 2017 · Жалоба Чтобы не плодить темы, еще один схожий вопрос. Есть роутер нетгир с вайфаем. К вайфаю цепляюсь Грувом в режиме station pseudobridge - всё нормально, connected to ess. Дальше этот вайфай интерфейс бриджую с виланом на эзернете и дальше в сетку погнал. Так вот - почему-то ни бридж на груве ни клиенты дальше не получают адреса от дхцп нетгира. Если напрямую к нетгиру цепляюсь - всё прекрасно работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 22 сентября, 2017 (изменено) · Жалоба В 21.09.2017 в 16:49, vnkorol сказал: Чтобы не плодить темы, еще один схожий вопрос. Есть роутер нетгир с вайфаем. К вайфаю цепляюсь Грувом в режиме station pseudobridge - всё нормально, connected to ess. Дальше этот вайфай интерфейс бриджую с виланом на эзернете и дальше в сетку погнал. Так вот - почему-то ни бридж на груве ни клиенты дальше не получают адреса от дхцп нетгира. Если напрямую к нетгиру цепляюсь - всё прекрасно работает. Потому, что стандарт 802.11 не предполагает наличие других маков за клиентским wifi-интерфейсом. То есть, по стандарту получается "1 wifi client = 1 MAC". В таком чистом 802.11 создание прозрачных беспроводных мостов между L2-сегментами было невозможно. Режим "station pseudobridge" обеспечивает L2-NAT - подстановку маков. По аналогии с L3 (NAT/MASQUERADE) где подменяются IP адреса. Соответственно, для dhcp-сервера все устройства за микротиком будут выглядеть как один мак и им будет пытаться назначиться один IP. Для преодоления ограничений "чистого" стандарта 802.11 каждый вендор создавал собственные "костыли" несовместимые с другими вендорами. WDS - как раз такой костыль. Например, реализация WDS от TP-link несовместима с WDS от MikroTik. Используйте точку и клиента одного вендора в режиме WDS. Либо используйте функционал dhcp-relay Изменено 22 сентября, 2017 пользователем nkusnetsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 22 сентября, 2017 · Жалоба 18 минут назад, nkusnetsov сказал: Потому, что стандарт 802.11 не предполагает наличие других маков за клиентским wifi-интерфейсом. То есть, по стандарту получается "1 wifi client = 1 MAC". В таком чистом 802.11 создание прозрачных беспроводных мостов между L2-сегментами было невозможно. Режим "station pseudobridge" обеспечивает L2-NAT - подстановку маков. По аналогии с L3 (NAT/MASQUERADE) где подменяются IP адреса. Соответственно, для dhcp-сервера все устройства за микротиком будут выглядеть как один мак и им будет пытаться назначиться один IP. Для преодоления ограничений "чистого" стандарта 802.11 каждый вендор создавал собственные "костыли" несовместимые с другими вендорами. WDS - как раз такой костыль. Например, реализация WDS от TP-link несовместима с WDS от MikroTik. Используйте точку и клиента одного вендора в режиме WDS. Либо используйте функционал dhcp-relay Т.е. самым прямым способом будет получить на вайфай интерфейсе айпи и через него натить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 22 сентября, 2017 (изменено) · Жалоба 4 часа назад, vnkorol сказал: Т.е. самым прямым способом будет получить на вайфай интерфейсе айпи и через него натить? Самым прямым будет не натить, а роутить. Тогда все хосты будут доступны по собственным IP Изменено 22 сентября, 2017 пользователем nkusnetsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vnkorol Опубликовано 23 сентября, 2017 · Жалоба 14 часов назад, nkusnetsov сказал: Самым прямым будет не натить, а роутить. Тогда все хосты будут доступны по собственным IP Удалил бридж, навешиваю дхцп-клиент на беспроводной интерфейс микротика - всё равно не получает айпи ни в каком режиме... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 23 сентября, 2017 · Жалоба Клиентский интерфейс вынимаем из бриджа и переводим в режим "station". Если параметры WiFi настроены верно, в окне winbox wireless-interfaces, в стройке интерфейса появится флаг "R". После того, как "R" появилась (клиентский интерфейс подключился к точке доступа), dhcp-клиент на этом интерфейсе должен подучить IP-адрес. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...