Dhcp offering lease without success apple

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

Offering lease without success. Странная проблема с DHCP.

Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.

1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку «Действия до настройки роутера».
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.

Есть вариант, что в сети есть второй DHCP сервер, который отдал клиенту IP раньше, чем это успел сделать микротик.

Еще есть вариант, что на микротике включен DHCP клиент, который что-то там не получает. А должен ли?

Вот здесь это обсуждается https://forum.mikrotik.com/viewtopic.php?t=130176
однозначно эффективного решения нет.

Хотя, справедливости ради, надо сказать, что с моим парком микротиков (наверное уже более 100 единиц) ни разу с такой ошибкой и проблемой не сталкивался. Надо искать проблему в физической организации сети.

Еще есть вариант, что на микротике включен DHCP клиент, который что-то там не получает. А должен ли?

Вот здесь это обсуждается https://forum.mikrotik.com/viewtopic.php?t=130176
однозначно эффективного решения нет.

1-е Правило WiFi — Везде где только можно откажитесь от WiFi!
2-е Правило WiFi -Устройство, которое пользователь не носит с собой постоянно, должно подключаться кабелем!!

Микротики есть разные: черные, белые, красные. Но все равно хочется над чем нибудь заморочится.

Источник

Dhcp offering lease without success apple

Thu Apr 02, 2015 10:11 pm

I’m having a strange issue with my RB 2011UiAS 2HnD on RouterOS 6.27. I’ve setup a DHCP server using the wizard. This as resulted in the following settings:

Yet I can’t get most of my devices to accept DHCP offers from my RB device. Either the addresses are assigned only to be deassigned 10 seconds later or the DHCP offer expires.

Any thoughs on what this could be and how I should solve this?

Re: DHCP offering lease [ip] for [mac] without success

Thu Apr 09, 2015 9:52 am

Re: DHCP offering lease [ip] for [mac] without success

Thu Apr 09, 2015 10:35 am

Re: DHCP offering lease [ip] for [mac] without success

Thu Apr 09, 2015 8:16 pm

This sounds like the clients’ replies are not getting to the server.
Is there a firewall rule on the bridge interface which blocks traffic in the input chain, and would apply to traffic coming in from bridge-local interface?

The default IP is 192.168.88.1/24 on Mikrotiks, (or it was the last time I took one out of a box), and if you changed the IP more recently, there might be firewall rules left around which allow 192.168.88.x but not 188.x

Also — make sure the network=192.168.188.0 on the IP address setting — I don’t know if Mikrotik’s fixed this, but if you change the IP address to a different network and hit OK or Apply, it doesn’t update the network setting.

Re: DHCP offering lease [ip] for [mac] without success

Wed Mar 30, 2016 11:42 pm

Yes i have a filter in bridge to prevent my network from software that scan mac, and there is slow in connect with my network , device taking time to obtain ip , can you help me ?

this is the filter :

/interface bridge filter
add action=drop chain=forward dst-port=10001 ip-protocol=udp mac-protocol=ip
add action=drop chain=input dst-port=10001 ip-protocol=udp mac-protocol=ip
add action=drop chain=output dst-port=10001 ip-protocol=udp mac-protocol=ip

/interface bridge filter
add action=drop chain=forward mac-protocol=arp in-interface=vlan100
add chain=forward mac-protocol=!arp out-interface=vlan100
add action=drop chain=forward mac-protocol=arp in-interface=vlan101
add chain=forward mac-protocol=!arp out-interface=vlan101
add action=drop chain=forward mac-protocol=arp in-interface=vlan102
add chain=forward mac-protocol=!arp out-interface=vlan102
add action=drop chain=forward mac-protocol=arp in-interface=vlan104
add chain=forward mac-protocol=!arp out-interface=vlan104
add action=drop chain=forward mac-protocol=arp in-interface=vlan105
add chain=forward mac-protocol=!arp out-interface=vlan105
add action=drop chain=forward mac-protocol=arp in-interface=vlan106
add chain=forward mac-protocol=!arp out-interface=vlan106
add action=drop chain=forward mac-protocol=arp in-interface=vlan107
add chain=forward mac-protocol=!arp out-interface=vlan107
add action=drop chain=forward mac-protocol=arp in-interface=vlan108
add chain=forward mac-protocol=!arp out-interface=vlan108
add action=drop chain=forward mac-protocol=arp in-interface=vlan109
add chain=forward mac-protocol=!arp out-interface=vlan109
add action=drop chain=forward mac-protocol=arp in-interface=vlan110
add chain=forward mac-protocol=!arp out-interface=vlan110
add action=drop chain=forward mac-protocol=arp in-interface=vlan111
add chain=forward mac-protocol=!arp out-interface=vlan111

Источник

Dhcp offering lease without success mikrotik

13/07/2015 . Written by . Posted in Mikrotik

Простенький скрипт, который можно запускать раз в минуту. Если будут обнаружены устройства, которые не могут получить адрес по dhcp, и статус offered то они будут заблокированы. При поступлении жалов можно выяснить причину и снять блокировку.

Возникла задача получать уведомления при подключении новых (не санкционированных) клиентов к сети и автоматически добавлять их в списки блокировки (adress-list=lock). Все зарегистрированные клиенты, у меня, имеют статическую запись в dhcp leases. Новые клиенты автоматически регистрируются как динамические, поэтому нам надо при очередной выдаче IP проверить является ли запись статической или динамической. В настройках DHCP сервера имеется параметр: Lease Script.

Этот скрипт выполняется при каждой выдаче IP. В этом скрипте определены глобальные переменные:

leaseBound – 0 если клиент не привязан к IP, 1 – если привязан;
leaseServerName – имя сервера DHCP который выдал IP;
leaseActMAC – MAC адрес клиента;
leaseActIP – IP адрес присвоенный клиенту;

Далее нам понадобится php скрипт отправляющий SMS по параметрам, который будет вызываться при выдаче очередного IP. Для примера это будет: http://mysite.ru/sms.php?text=testmessage.

Если не хотите заморачиваться со скриптом на своем хостинге рекомендую зарегистрироваться на сервисе отправки smsc.ru и отправлять SMS используя простой HTTP запрос формата:

Если у вас есть сайт (любой) можете разместить у себя кнопку сервиса smsc.ru и через службу поддержки (они проверят линк) вам установят тариф “6” уровня, что сделает отправку сообщений дешевле. Так же после подтверждения вашего номера телефона на счете появится бонус – 15 руб., которых достаточно для отладки скрипта. Так что денег не понадобится.

В Lease Script приписываем саму логику:

Данный скрипт будет делать уведомления по каждой выдаче нового динамического IP. Выдача будет происходить при каждом запросе клиента даже если адрес будет тот же, что и в прошлой сессии.

Проблему постоянных уведомлений решит список блокировки в Firewall. Если выделенный IP уже в списке блокировки то не стоит повторно уведомлять. Итоговый вид скрипта будет таким:

Добавляем в начало firewall правила блокировки всех пакетов входящих в Adress-List “lock”:

В принципе можете нагрузить php скрипт дополнительным функционалом, который будет добавлять события в БД или через Router OS API разносить блокировку по другим узлам.

PS: Усилить блокировку можно сменив в настройка интерфейса бриджа (по умолчанию) arp=reply-only, и в настройках сервиса dhcp: add-arp=yes. Эти настройки позволяют передать “управление” ARP – DHCP серверу. Если во время настройки отвалится Микротик, подключайтесь к нему по MAC (для этого в списке найденных роутеров надо щелкнуть по МАС а не по IP адресу роутера).

26 мыслей о “MIKROTIK уведомления о новых узлах (DHCP LEASE)”

Спасибо, за статью пригодилась 🙂

Статья очень помогла. Не понравился костыль с фаерволом.
Использую GSM модем для оповещения о подключении.
Новую неизвестную запись делаю статической и вношу в список unknown. В фаерволе блокируется весь трафик для клиентов из списка unknown.

:if ($leaseBound = 1) do= Читайте также: Asus z 270 prime

Господа, не поможете со скриптом для выдачи одного статического адреса из пула dhcp для конкретного устройства с известным именем, например server.

У Микротика есть понятие статический Lease. Не видя вашей задачи не ясно какое решение предложить. Например, если вам нужно чтобы определенный клиент всегда получал один и тот же IP, то достаточно просто подключить его к сети, дождаться выделения ему IP, после чего, зайти в ip dhcp server leases открыть нужную запись и нажать Make Static. Другой вариант можно создать статическую запись заранее, указав MAC и нужный IP. Так же если указать другой IP в статической записи, то при следующем переподключении (lease update) клиент получит новый указанный IP (это на тот случай если не нравится какой IP был выделен из пула автоматом). Как видите скрип тут не уместен. Если ваша задача сложнее, то опишите ее подробнее.

Задача состоит в том, что есть несколько устройств, получающих адреса по dhcp от микротика через неуправляемый свич. Одно из устройств с host-name server должно получать всегда адрес с двоечкой на конце х.х.х.2. Сетей таких много и постоянно добавляются. Мак адреса соответственно разные у каждого устройства с именем server в другом филиале.

Задача экзотическая, единственное что может сделать скрипт: сменить IP уже выделенный IP на другой по имени записи, что даст при повторном подключении нужный вам результат. События (скрипт) позволяющее переопределить выделяемый IP в Микротике нет.

Повторное подключение можно организовать выключением порта етн. Как будет выглядеть такой скрипт? Ни как не получается вычленить мак и назначить ему ИП адресс.

Отключив порт микротика вы уберете линк с неуправляемым коммутатором, а не с server. Но если интересно то так: /interface ethernet disable [find name=»ether9-slave-local»] . В DHCP скрипте есть глобальные переменные, которые предопределены для скрипта (события):
leaseServerName – Имя DHCP сервера (микротик);
leaseActMAC – MAC клиента;
leaseActIP – Назначенный клиенту IP.

Вставьте в скрипт следующее:
/log info «dhcp script»;
/log info $leaseBound;
/log info $leaseServerName;
/log info $leaseActMAC;
/log info $leaseActIP;
И смотрите лог при подключении клиента.

Вообщем получилось вот так
:local c;
:local m;
:set c [/ip dhcp-server lease get value-name=address from [find leaseActIP=server]];
:set m [/ip dhcp-server leaseget value-name=mac-address from [find leaseActMAC=server]];
/ip dhcp-server lease add address=10.х.х.2 client- > /log info “dhcp script”;
/log info $leaseBound;
/log info $leaseServerName;
/log info $leaseActMAC;
/log info $leaseActIP;

При этом должна появится статическая запись в списке dhcp-server lease, но ее нет. Скрипты пишу впервые. Возможно проблема с синтаксисом.

А для ревнивых мужей можно что то подобное реализовать ?)))
типа приходит жена домой ее тел регистрируется в сети а микротик сразу кидает смс и когда исчезает из сети тоже кидает смс…или так типа подходит нашальнике к офису а микротик весело начинает пикать при регистрации телефона нашальнике в сети ))) заранее благодарю , крайне нуждаюсь))

Да можно. Сделайте lease-time (время аренды IP) не большим 5-10 минут, в зависимости от необходимой точности. В начале скрипта добавьте /log info “dhcp event” и смотрите что происходит с переменными при выделении IP, повторном выделении и завершении аренды.

а не могли бы вы мне помочь на возмездной основе , нужно чтобы при появлении.исчезновении мака в сети микротик пикал (1вареант) и например как 2й вареант просто на почту уведамление или в телегу или смс .

Господа, не поможете у меня проблема несколько mac адресов забирает все ip адреса которые может раздать dhcp сервер , я их блокирую но заново появляется новые mac адреса тоже самый цикл повторяется вот так банит dhcp

Нужно сделать статичную запись для проблемного узла и поставить 2 галочки:
1. Usr Src. MAC address
2. Block Access (если вам нужно полностью залочить клиента)

да я таки делаю, mac блокируется
но появляется новые
я штук 200 сделал так все равно выходить

Если вы поставили галочку “Use Src. MAC” то у вас в принципе не может выделится 2 IP на один MAC. Проверьте внимательно.

Добрый день!
У меня Mikrotik выдает IP по DHCP, адреса получаем с сервера по Radius.
В случае падения Radius на сервере, клиент не может получить IP.
Через Netwatch реализовал проверку IP сервера. В случае не доступности, рапускаем /ip dhcp-server lease make-static [/ip dhcp-server lease find]
НО есть минусы:
1) Сервер может быть в сети, а Radius не запущен. И клиенты не могут получить IP.
2) Netwatch стоит проверка в 5секунд. Довольно часто бывает, что в эти 5секунд(между падением сервера и назначением всем статических адресов), у когота закончилось время аренды. И он не получит адрес,пока не поднимется Radius на сервере.
Подскажите как реализовать:
Проверку ответов от Radius, и если нет ответа,выдавать клиенты IP, который выдавался ему ранее
?
Возможно это можно реализовать через скрипт, который будет запоминать все выданные IP+MAC. И в случае появления адреса 0.0.0.0 в IP-DHCP server-Leases, будет выдавать всем адреса статически?

Mikrotik вряд ли вам поможет с тем что у вас происходит за пределами его “владений”. Скрипты DHCP выполняются асинхронно и вы не сможете им управлять. Попробуйте найти watchdog со стороны вашего RADIUS сервера и при помощи Mikrotik API управляйте им. Или же не дожидаясь падения в реальном времени, при выделении IP RADIUSом, сразу его переносите в Mikrotik при помощи того же API, т.е. формируйте backup схему в автомате. Думаю, это самый перспективный вариант.

Маленько некропост, но всё же не удержусь. Несколько загадочно выглядит код в статье.
….
:foreach i in=[find dynamic=yes] do=

В микротике новичек, если можно поледовательность действий установки с уведомлением на почту.
Спасибо

Читайте также: What is apple font type

Script находится в конкретном DHCP сервере, висящем на конкретном интерфейсе. Список этих серверов здесь: IP / DHCP Server / DHCP (вкладка Alerts не нужна).

Выглядить он будет так (уведомление на почту)
Я заменил вот эту строку
/tool fetch host=”mysite.ru” keep-result=no mode=http address=”mysite.ru” src-path=”/sms.php?

на вот эту
/tool e-mail send to=”$emailAddress”

Измененный скрипт
:if ($leaseBound = 1) do=
>

:if ($recfound = 0) do=

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

О проблеме отсутствия функции полноценного DHCP-snooping в устройствах MikroTik уже было сказано и написано слишком много. И везде для отлова злодейских DHCP предлагают нагружать CPU. Я же расскажу, как убить чужой DHCP-сервер с помощью свитч-чипа интегрированного в коммутаторы MikroTik CRS.

Распространенные в сети материалы касаются работы именно маршрутизаторов MikroTik. И все они для отлова DHCP используют скудные ресурсы CPU. При этом, относительно свежая линейка коммутаторов хронически остается без внимания. Между прочим, совершенно напрасно.

Итак, подопытный аппарат CRS125-24G-1S установлен на доступе. С некоторых пор изредка на пользовательские устройства стали выпадать посторонние IP-адреса. Естественно возникла задача «найти и обезвредить». В стандартном арсенале RouterOS есть инструмент «DHCP-server Alert», способный вызывать некие действия при обнаружении в сети стороннего DHCP-сервера.

Отлично? Пожалуй. Только инструмент при ближайшем рассмотрении оказался не слишком информативный. Чтобы понять почему, рассмотрим типичную архитектуру маршрутизирующего оборудования MikroTik (картинка из вики):

По сути основная часть устройства делится на две:

1) програмно-конфигурируемый свитч, осуществляющий коммутацию на максимальной скорости;
2) CPU отвечающий за маршрутизацию, фильтрацию а также умеющий осуществлять коммутацию на программном уровне, медленнее и более ресурсоёмко.

IP-сервисы на таком устройстве, само собой висят на верхнем уровне. На Master-интерфейсе восходящем к CPU Routerboard или на программном бридже. Там и живет DHCP-сервер и его служба алертов. Все виденные мною ранее решения имели также два недостатка вытекающие из этой архитектуры:

1) Фильтрация трафика от злодея выполнялась на бридже, через «use ip firewall» и отнимала без того скудные ресурсы CPU;
2) Злодей подключенный к свитчу продолжал неконтролируемо пакостить абонентам на соседних портах этого свича.

Например, абоненты висящие на port2 и port3 всё равно продолжали получать бяку прилетающую со стороны port4. Но всё изменилось, когда у MikroTik появилась линейка CRS — ребята установили более мощный и функциональный свитч-чип, который я и решил попытаться использовать, победить и сохранить ресурсы CPU.

Шаг №1

Настраиваем «DHCP-server Alert». Настройка сама по себе не сложная, почти всё описано в вендорской вики — включаем, задаем интерфейс на котором следить (например bridge-local), указываем доверенный наш DHCP. Можем добавить скрипт, который вызывать в случае чего. Ура — скрипту автоматически передаются параметры: $interface $mac-address $address обнаруженного злодея! Ура? Так легко? Но вот тут-то и спрятаны первые подводные грабли. И не одни.

Грабли первые: в $interface передается имя интерфейса на котором сидит сам алертер. Потому, если даже злодей подключен к интерфейсу «port4» (см. картинку выше), в переменной всё равно будет «bridge-local». В логе видим почти то же самое:

Кхм. Сколько у нас портов? 24? Ладно. Я иду искать…

Шаг №2

По граблям. Искать приходится в unicast-fdb свича, по переменной $mac-address. И вот тут-то меня ждали вторые грабли. Настоящие подводные. Скрипт вызывался, но никак не хотел работать. Кто занимается скриптописательством для MikroTik подтвердит — отладка автоматически запускаемого скрипта сама по себе задача нифига не тривиальная. Да еще и обработчик on-error<> почему-то молчал. Опытным путём было обнаружено, что код

отлично отрабатывает в командной строке терминала и только в ней. В теле скрипта не желает. Причина — странная интерпретация имени собственной (определенной вендором!) переменной $mac-address.

Фича: интерпретация команд в скрипте идет ~~через.~~ иным путём. Для успешной работы, имя системной переменной надо экранировать: ($»mac-address») . При этом в дальнейшем использовании тоже не исключены фокусы.

Я пошел другим путем, создав локальную переменную с нормально интерпретируемым именем:

Стало легче. Появилась возможность видеть название реального интерфейса на свитче, к которому подключен вредитель. Осталось придумать как его убить.

Как известно, настоящий джедай использует силу, а настоящий инженер использует мозг. Поэтому, идея тупо полностью отрубить найденный порт была мною отброшена — а вдруг за этим портом сидит несколько пользователей и/или устройств? К счастью свитч-чип в MikroTik CRS позволяет делать MAC-Based-Vlan. Решение пришло тут же — выделить трафик от злодея по MAC и завернуть в отдельный неиспользуемый Vlan. В итоге, получился компактный скрипт, надежно отключающий от сети чужое устройство с поднятым на нём DHCP-сервером.

Переменная $stubvid, как должно быть понятно из названия — номер Vlan-заглушки. Переменная $imac — массив. MikroTik зачем-то позволяет делать несколько записей с одинаковым MAC в таблице mac-based-vlan, что вызывало сбой при попытке получить единственное значение. Предупреждения просто пишутся в log error, но ничто не мешает дописать более настойчивое информирование администратора сети.

Вызов алерта и скрипта у меня прописан следующим образом:

Спасибо, что дочитали до конца. Надеюсь, вам это когда-нибудь пригодится.

Источник