http://mikrotik.moscow Новое в теме Предложение по функциональности: режим 802.11 ad-hoc. форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Mon, 10 Aug 2026 19:36:30 -0400 Предложение по функциональности: режим 802.11 ad-hoc. RouterOS в форуме RouterOS.
В связи с тем, как MT перечисляются WDS (и другие динамические интерфейсы), обычно не сохраняются ссылки на этот интерфейс. IP-адрес и другие настройки, зависящие от интерфейса, оказываются назначены “(unknown)”, когда соединение восстанавливается. Использование статического WDS решило бы проблему (настройки не сбиваются), но я хочу более динамичную систему. Чем меньше административных хлопот, тем лучше. –Eric
23.01.2006 19:57:00, eflanery.]]> http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239738 http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239738 Mon, 23 Jan 2006 19:57:00 -0500 RouterOS Предложение по функциональности: режим 802.11 ad-hoc. RouterOS в форуме RouterOS.
Знаешь, я тут что-то подобное расследовал. Заметил, что ты упомянул блокировку пересылки в файрволе – а почему бы просто не отключить бриджинг совсем и не использовать динамически созданный интерфейс WDS напрямую с IP-адресом?
12.01.2006 05:57:00, DirectWireless.]]> http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239737 http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239737 Thu, 12 Jan 2006 05:57:00 -0500 RouterOS Предложение по функциональности: режим 802.11 ad-hoc. RouterOS в форуме RouterOS.
Как насчет использования скриптов для автоматического назначения нового WDS-соединения неизвестному IP-адресу интерфейса? Скорее всего, это можно сделать именно так, но кажется излишне сложным и будет генерировать ненужные записи в флэш-памяти.  Плюс, будет сложнее для техников понять. У меня сейчас есть другой рабочий, но тоже излишне сложный, вариант (динамический bridge-blocked WDS). Но моя цель — снизить накладные расходы и упростить всё.  Хотя, вероятно, плохой линк вызовет серьёзные проблемы с перераспределением OSPF. Не так уж и плохо в небольшом, изолированном домене OSPF. Перераспределение в ядро сети будет плохим, вероятно, очень плохим. OLSR был бы гораздо лучшим протоколом для этого, но OSPF — ближайший поддерживаемый MT.  Но если говорить о вашей конфигурации, как ваши узлы общаются друг с другом? Может быть, я плохо понимаю OSPF, но не нужно ли каждому узлу иметь IP-пару для общения (например, вот так): Узел 1: wlan1 10.1.1.1/24 wlan1 10.1.2.1/29 Узел 2: wlan1 10.1.5.1/24 wlan1 10.1.2.2/29 Другими словами, 10.1.2.x/29 — это маршрут точка-точка между 10.1.5.1 и 10.1.1.1…? Или OSPF как-то исключает необходимость в этом? Кстати, можно использовать /32 адреса точка-точка под OSPF в режимах NBMA или PtMP (не широковещательные), избавляясь от необходимости в нескольких адресах на узел. То есть: Узел 1: Customer interface - 10.0.0.1/24 net:10.0.0.0 Mesh blocked-bridge interface - 10.0.0.1/32 net:10.0.1.1 Mesh blocked-bridge interface - 10.0.0.1/32 net:10.0.2.1 Узел 2: C - 10.0.1.1/24 net:10.0.1.0 M - 10.0.1.1/32 net:10.0.0.1 M - 10.0.1.1/32 net:10.0.2.1 Узел 3: C - 10.0.2.1/24 net:10.0.2.0 M - 10.0.2.1/32 net:10.0.0.1 M - 10.0.2.1/32 net:10.0.1.1 Я использую другой механизм, где даже при сбое полного мешинга, все узлы имеют IP-адреса в пределах /24, и они запускают широковещательный OSPF между собой. Это приводит к несогласованным представлениям OSPF этой подсети, что делает её по сути сломанной. В большой OSPF-домен это, вероятно, вызовет серьёзный хаос, но в маленьком домене «внешние» маршруты OSPF будут оставаться функциональными. Получаются странные (неправильные) трейсы маршрутов, но на небольшом масштабе это работает. Ни одна конфигурация OSPF в сети такого типа не будет полностью стабильной, и координационная функция 802.11 (даже в режиме ad-hoc) — плохой протокол для этого. OLSR+TDMA был бы гораздо лучше, но я не питаю особых надежд на то, что они появятся. –Эрик
31.01.2006 00:04:00, eflanery.]]> http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239736 http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239736 Tue, 31 Jan 2006 00:04:00 -0500 RouterOS Предложение по функциональности: режим 802.11 ad-hoc. RouterOS в форуме RouterOS.
Как насчет использования скриптов для автоматического присвоения нового соединения WDS новому IP-адресу интерфейса (неизвестному)? Что-то вроде, сначала создавать, скажем, 8 подсетей без интерфейса, а затем, по мере подключения каждого WDS, ему присваивается подсеть, и IP-адрес активируется. При отключении IP-адрес отключается и, конечно же, опять становится неизвестным. Думаю, плохая связь может вызвать серьезные проблемы с перераспределением OSPF. Но, если говорить о вашей конфигурации, как узлы общаются друг с другом? Может, я что-то не понимаю в OSPF, но разве каждому узлу не нужна IP-пара для общения друг с другом (вроде этого): Узел 1: wlan1 10.1.1.1/24 wlan1 10.1.2.1/29 Узел 2: wlan1 10.1.5.1/24 wlan1 10.1.2.2/29 Другими словами, 10.1.2.x/29 – это point to point IP-маршрут между 10.1.5.1 и 10.1.1.1…? Или OSPF как-то вообще избавляет от необходимости этого делать?
24.01.2006 07:27:00, DirectWireless.]]> http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239735 http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239735 Tue, 24 Jan 2006 07:27:00 -0500 RouterOS Предложение по функциональности: режим 802.11 ad-hoc. RouterOS в форуме RouterOS.
У меня небольшая полносвязная сеть, использующая OSPF для маршрутизации, где было бы полезно, чтобы все узлы связывались друг с другом произвольно, без использования бриджей или WDS. 802.11 ad-hoc отлично подходит под это описание. Сейчас я могу добиться похожего эффекта, настроив все узлы в режим точки доступа с динамическим WDS и затем заблокировав всю пересылку в брандмауэре моста. Это работает, но ad-hoc было бы проще и легче. Поскольку весь трафик маршрутизируется на каждом узле, дополнительные MAC-адреса, передаваемые через WDS, излишни, как и накладные расходы на поддержание всех WDS-соединений в мосту, который блокирует весь трафик. Спасибо, что рассматриваете эту возможность, –Eric.
09.11.2005 19:51:00, eflanery.]]> http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239734 http://mikrotik.moscow/forum/forum57/62471-predlozhenie-po-funktsionalnosti_-rezhim-802.11-ad_hoc./message239734 Wed, 09 Nov 2005 19:51:00 -0500 RouterOS