XuHT Posted July 18, 2015 Переодически отключаются устройства от контроллера. Выглядит это так 19:01:56 caps,error removing stale connection [::ffff:10.10.2.12:58107,Run,[4C:5E:0C:DC:D7:19]] because of ident conflict with [::ffff:10.10.2.12:40153,Join,[4C:5E:0C:DC:D7:19]]18:57:53 caps,error removing stale connection [::ffff:10.10.2.12:39540,Run,[4C:5E:0C:DC:D7:19]] because of ident conflict with [::ffff:10.10.2.12:57997,Join,[4C:5E:0C:DC:D7:19]] 18:56:47 caps,error removing stale connection [::ffff:10.10.2.14:38367,Run,[4C:5E:0C:A6:AC:FF]] because of ident conflict with [::ffff:10.10.2.14:36876,Join,[4C:5E:0C:A6:AC:FF]] Судя по названию интерфейсов, дисконекты происходят часто. После первого подключения контроллер дает название по порядку- cap1, cap2 и т.д. По логам я не могу понять в чем дело. Ругается на идент, но у апешек иденты разные, маки разные.. Share this post Link to post Share on other sites More sharing options...
XuHT Posted July 27, 2015 Никто не подскажет? Share this post Link to post Share on other sites More sharing options...
BAV_Lug Posted February 17, 2016 Я понимаю, что уже поздно, но так как сам наткнулся на те же грабли, отвечу тут, может кому поможет. Для избавления от такого поведения необходимо на всех капах установить статические ip, а не по dhcp. Не очень удобно это конечно, но это решает проблему. Share this post Link to post Share on other sites More sharing options...
mrrc Posted June 9, 2017 При подключении одной из новых точек у меня аналогичное сообщение в логе контроллера наблюдается, на работу как таковую вроде никаким образом не влияет. Точка с контроллером вяжется по статике, кстати. Share this post Link to post Share on other sites More sharing options...
ndv27 Posted March 15, 2018 (edited) Напишу, может кому-то понадобится еще. Столкнулся с той же проблемой на прошивке 6.41.3 при построении WiFi-роуминга на сети из 2-х hAP ac в доме. Но при этом интервал между рождениями новых интерфейсов CAPxx был всего несколько секунд, так как ответа от интерфейса CAP не было (как выяснилось позже). Удалось победить. Причина была в том, что преднастроенный из коробки файрволл блокировал общение менеджера CAP с точкой WiFi (даже если она на том же роутере!). Диагностика в логе описана в постах выше, но при этом говорит вроде бы совсем про другое, уже о последствиях - видимо новые интерфейсы рождаются и блокируются файрволлом не мгновенно. Все было от правила "drop all input from !LAN", при этом интерфейсы CAPxx подпадают под это правило и Микротик блокирует нормальное общение между менеджером и точкой. Вылечилось заменой правила на "drop all input from WAN" Кажется аналогичный ответ был в поддержке Mikrotika. Также если и другие WiFi- точки также живут на полноценных роутерах, как у меня например ( 2х hAP ac), данное исправление требуется и на других файрволлах. Edited March 15, 2018 by ndv27 Share this post Link to post Share on other sites More sharing options...
crazylemmy Posted September 4, 2018 В 15.03.2018 в 10:55, ndv27 сказал: Напишу, может кому-то понадобится еще. Столкнулся с той же проблемой на прошивке 6.41.3 при построении WiFi-роуминга на сети из 2-х hAP ac в доме. Но при этом интервал между рождениями новых интерфейсов CAPxx был всего несколько секунд, так как ответа от интерфейса CAP не было (как выяснилось позже). Удалось победить. Причина была в том, что преднастроенный из коробки файрволл блокировал общение менеджера CAP с точкой WiFi (даже если она на том же роутере!). Диагностика в логе описана в постах выше, но при этом говорит вроде бы совсем про другое, уже о последствиях - видимо новые интерфейсы рождаются и блокируются файрволлом не мгновенно. Все было от правила "drop all input from !LAN", при этом интерфейсы CAPxx подпадают под это правило и Микротик блокирует нормальное общение между менеджером и точкой. Вылечилось заменой правила на "drop all input from WAN" Кажется аналогичный ответ был в поддержке Mikrotika. Также если и другие WiFi- точки также живут на полноценных роутерах, как у меня например ( 2х hAP ac), данное исправление требуется и на других файрволлах. Низкий Вам поклон и долгих лет жизни! Я специально зарегистрировался чтобы сказать огромное вам спасибо за решение! Share this post Link to post Share on other sites More sharing options...
ls.lviv Posted December 7, 2018 В 05.09.2018 в 01:12, crazylemmy сказал: Низкий Вам поклон и долгих лет жизни! Я специально зарегистрировался чтобы сказать огромное вам спасибо за решение! +1 Share this post Link to post Share on other sites More sharing options...
M1nd3r Posted December 9, 2018 В 15.03.2018 в 17:55, ndv27 сказал: Напишу, может кому-то понадобится еще. Столкнулся с той же проблемой на прошивке 6.41.3 при построении WiFi-роуминга на сети из 2-х hAP ac в доме. Но при этом интервал между рождениями новых интерфейсов CAPxx был всего несколько секунд, так как ответа от интерфейса CAP не было (как выяснилось позже). Удалось победить. Причина была в том, что преднастроенный из коробки файрволл блокировал общение менеджера CAP с точкой WiFi (даже если она на том же роутере!). Диагностика в логе описана в постах выше, но при этом говорит вроде бы совсем про другое, уже о последствиях - видимо новые интерфейсы рождаются и блокируются файрволлом не мгновенно. Все было от правила "drop all input from !LAN", при этом интерфейсы CAPxx подпадают под это правило и Микротик блокирует нормальное общение между менеджером и точкой. Вылечилось заменой правила на "drop all input from WAN" Кажется аналогичный ответ был в поддержке Mikrotika. Также если и другие WiFi- точки также живут на полноценных роутерах, как у меня например ( 2х hAP ac), данное исправление требуется и на других файрволлах. Приогромнейшее спасибо, промаялся с этим весь день, прежде чем полез в интернет, но начиналась подобная проблема даже при всех отключенных правилах, в итоге сброс на заводские (последние пару обновлений сброс не делал, думал это не будет критичным) и перенастройка по умолчанию. Всё заработало кроме стабильного интернета, без FastTrack много проблем было. Повторный сброс с конфигом по умолчанию и настройкой CapsMan привёл к описанной проблеме, но ваш совет, добрейший, спас мой сон! P.S.:Думаю разработчикам нужно ссылку кинуть на ваше описание, с решением проблемы, что бы очередную прошивку выпустили. P.P.S: Кажется, совет тренеров и учителей по MikroTik, делать сброс на заводские после каждой прошивки и перенастройку под себя, снова стал актуальным. O:-( Share this post Link to post Share on other sites More sharing options...
Evgen86 Posted February 8, 2019 Здравствуйте. Целую неделю промучился с подобным отвалом CAPов, за день номер капов был несколько тысяч на 6.43.11 прошивке. Контроллер -2011, Остальные 9шт SXT c купленной лицензией 4 уровня. 1. Полный сброс клиентов. 2. Отключить все dropы в файрволле. На устройствах, изначально рассчитанных под CAPы, правил вообще нет. 3. Если Вы переделывали уровень 3 в 4, quick setup cap не запускать сразу. Отключаете обязательно dhcp сервер и клиент, а затем через quick setup поставить, что устройство- CAP, и прописать там статический IP, шлюз, DNS. 4. Перезагрузить устройство и зайти по новому адресу, Winbox, пункт WiFi, кнопка CAP для соответствующего интерфейса, убрать все из discovery interfaces, а в capsman adresses поставить адрес контроллера, bridge - bridge, interfaces -wlan1, может немного отличаться на других устройствах (подсмотрел на другом форуме). 5. Мигания CAPов и конфликт identов исчезли !!! 6. Если Вы не отключите dropы в файрволле в пункте 2, то после запуска quick setup и выбора cap Вы потеряете доступ к устройству, только сброс кнопкой... Share this post Link to post Share on other sites More sharing options...
Saab95 Posted February 10, 2019 Сколько не видел на форуме жалоб про работы CAP - все они лишь от того, что не сбрасывают начальную конфигурацию и пытаются что-то там закрывать файрволами. Если настраивать с нуля то никаких проблем никогда не возникает. Share this post Link to post Share on other sites More sharing options...
LostSoul Posted February 10, 2019 55 минут назад, Saab95 сказал: Сколько не видел на форуме жалоб про работы CAP - все они лишь от того, что не сбрасывают начальную конфигурацию и пытаются что-то там закрывать файрволами. Если настраивать с нуля то никаких проблем никогда не возникает. Бывают реальные проблемы с CAPами. У нас на одном "вкусном" обьекте каждый из подрядчиков тянул одеяло на себя, в итоге один шустрый подрядчик втюхал и смонтировал клиенту 3шт Mikrotik WAP ( не AC ) одна из них с завидной регулярностью виснет.... а так как шустрый подрядчик еще и poe коммутатор влепил неуправляемый , это стало реальным гемороем. будем за свой счет переделывать всё :-( Share this post Link to post Share on other sites More sharing options...
porter_ods Posted March 18, 2019 (edited) Всем привет, есть связка роутер Mikrotik 2011 и точка доступа wAP, CapsMan настроен и поднимается отлично как на роутере так и на точке доступа, подключение клиентов к роутеру идет отлично, при подключении к точке доступа CAP отваливается и переподключается заново к контроллеру https://ibb.co/kB9z8fx, буду признателен за помощь, устал мучаться... Edited March 18, 2019 by porter_ods Share this post Link to post Share on other sites More sharing options...
calutiya Posted April 23, 2019 Ребят. Рассказываю про свой случай. Вроде не первый раз настраиваю CAPsMAN. Вот, пару дней назад настроил человеку CAPsMAN на 4х устройствах. Для частного дома. 3 х RB951Ui-2HnD и одна какая-то WAP-антенна. Всё работает чётко, тьфу-тьфу. И вот еще один аналогичный заказ. Только попроще: всего лишь два RB951Ui-2HnD. Настраиваю по одной схеме, ничего не эксперементирую, не меняю. Версии RouterOS везде одинаковые, всегда делаю Check for Updates перед настройкой. Ну и обновляю есть есть обновление. На момент написания поста версии были 6.44.2. Так вот. Начал настройку, bridge, NAT, DHCP-сервер, туда-сюда. Дошел до wi-fi. И тут началось описанное выше: "прыгающие" туда-сюда CAP'ы, ругается на сертификат при попытке зайти через вай-фай на какие-то сайты (а по кабелю всё ок), невозможность зайти по вай-фаю на Микрот. Причем, часть глюков проявлялась при подаче инета в wan-порт. В общем. Всё решилось через System - Routerboard - Upgrade. Как мне подсказал мой друг - очень часто (а у него ж опыта больше (с) ) когда все делаешь правильно, перепроверяешь ни один раз, а что-то глючит - сделай System - Routerboard - Upgrade! Бился я с этими необъяснимыми глюками вчера пол-дня. Пока не сделал System - Routerboard - Upgrade. После этого всё как часы! On 2/10/2019 at 3:26 PM, Saab95 said: Сколько не видел на форуме жалоб про работы CAP - все они лишь от того, что не сбрасывают начальную конфигурацию и пытаются что-то там закрывать файрволами. Если настраивать с нуля то никаких проблем никогда не возникает. Всегда сбрасываю конфу и настраиваю с нуля, но вот какая у меня была проблема (см.выше) Share this post Link to post Share on other sites More sharing options...
Maque Posted June 26, 2019 На самом деле, не обязательно отключать все правила фаервола: достаточно разрешить все входящие соединения на UDP-порты 5246 и 5247 (порты CAPsMAN-а). Интерфейс создаётся динамически, поэтому привязать правило к определённому интерфейсу невозможно, а если роутер требуется использовать не только для CAPsMAN-а, то получается, что это небольшая, но дыра в безопасности. Жаль, что разработчики не потрудились сделать своей же службе лазейку в фаерволе или как-то ещё решить эту проблему. Share this post Link to post Share on other sites More sharing options...
Корпич Posted June 26, 2019 8 часов назад, Maque сказал: Интерфейс создаётся динамически, поэтому привязать правило к определённому интерфейсу невозможно Сделать интерфейс статическим - делов-то Share this post Link to post Share on other sites More sharing options...
Корпич Posted August 5, 2019 Вариант описан в вики микротикапоставить перед правилом defconf: drop all not coming from LAN, правило add action=accept chain=input dst-address-type=local src-address-type=local Share this post Link to post Share on other sites More sharing options...
