Как насчет использования скриптов для автоматического назначения нового 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 был бы гораздо лучше, но я не питаю особых надежд на то, что они появятся. –Эрик
