[XuHT]

Переодически отключаются устройства от контроллера. Выглядит это так

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 и т.д.

По логам я не могу понять в чем дело. Ругается на идент, но у апешек иденты разные, маки разные..

[XuHT]

Никто не подскажет?

[BAV_Lug]

Я понимаю, что уже поздно, но так как сам наткнулся на те же грабли, отвечу тут, может кому поможет.

Для избавления от такого поведения необходимо на всех капах установить статические ip, а не по dhcp.

Не очень удобно это конечно, но это решает проблему.

[mrrc]

При подключении одной из новых точек у меня аналогичное сообщение в логе контроллера наблюдается, на работу как таковую вроде никаким образом не влияет.

Точка с контроллером вяжется по статике, кстати.

[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), данное исправление требуется и на других файрволлах.

 

Изменено 15 марта, 2018 пользователем ndv27

[crazylemmy]

В 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), данное исправление требуется и на других файрволлах.

 

Низкий Вам поклон и долгих лет жизни!

Я специально зарегистрировался чтобы сказать огромное вам спасибо за решение!

[ls.lviv]

В 05.09.2018 в 01:12, crazylemmy сказал:

Низкий Вам поклон и долгих лет жизни!

Я специально зарегистрировался чтобы сказать огромное вам спасибо за решение!

+1

[M1nd3r]

В 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:-(

[Evgen86]

Здравствуйте. Целую неделю промучился с подобным отвалом 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 Вы потеряете доступ к устройству, только сброс кнопкой...

[Saab95]

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

[LostSoul]

55 минут назад, Saab95 сказал:

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

Бывают реальные проблемы с CAPами.

У нас на одном "вкусном" обьекте каждый из подрядчиков тянул одеяло на себя,  в итоге один шустрый подрядчик втюхал и смонтировал клиенту 3шт Mikrotik WAP  ( не AC )

одна из них с завидной регулярностью виснет....   а так как шустрый подрядчик еще и poe коммутатор влепил неуправляемый , это стало реальным гемороем.

будем за свой счет переделывать всё :-(

 

[porter_ods]

Всем привет, есть связка роутер Mikrotik 2011 и точка доступа wAP, CapsMan настроен и поднимается отлично как на роутере так и на точке доступа, подключение клиентов к роутеру идет отлично, при подключении к точке доступа CAP отваливается и переподключается заново к контроллеру https://ibb.co/kB9z8fx, буду признателен за помощь, устал мучаться...

Изменено 18 марта, 2019 пользователем porter_ods

[calutiya]

Ребят. Рассказываю про свой случай.

 

Вроде не первый раз настраиваю 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 - все они лишь от того, что не сбрасывают начальную конфигурацию и пытаются что-то там закрывать файрволами. Если настраивать с нуля то никаких проблем никогда не возникает.

Всегда сбрасываю конфу и настраиваю с нуля, но вот какая у меня была проблема (см.выше)

[Maque]

На самом деле, не обязательно отключать все правила фаервола: достаточно разрешить все входящие соединения на UDP-порты 5246 и 5247 (порты CAPsMAN-а). Интерфейс создаётся динамически, поэтому привязать правило к определённому интерфейсу невозможно, а если роутер требуется использовать не только для CAPsMAN-а, то получается, что это небольшая, но дыра в безопасности. Жаль, что разработчики не потрудились сделать своей же службе лазейку в фаерволе или как-то ещё решить эту проблему.

[Корпич]

8 часов назад, Maque сказал:

Интерфейс создаётся динамически, поэтому привязать правило к определённому интерфейсу невозможно

Сделать интерфейс статическим - делов-то

[Корпич]

Вариант описан в вики микротика
поставить перед  правилом defconf: drop all not coming from LAN, правило 
add action=accept chain=input dst-address-type=local src-address-type=local