Iphone не получает dhcp

Как установить ручной DHCP и статический IP-адрес на iPad или iPhone

Для определенных сетей Wi-Fi клиенты должны использовать статические IP-адреса или ручную информацию DHCP, чтобы устройство могло правильно подключиться к этой сети. Настройка iPhone, iPad или iPod touch для использования статического IP-адреса или ручных настроек DHCP в iOS очень проста, вот как вы можете это сделать с любой версией программного обеспечения iOS.

Как установить статический IP-адрес и ручной DHCP в iOS

1. Нажмите «Настройки», а затем нажмите «Общие»,
2. Нажмите «Wi-Fi» и найдите сетевое имя, к которому вы подключены, затем выберите небольшую (i) или стрелку рядом с ним, чтобы получить дополнительную информацию об этой сети

Нажмите вкладку «Статические»

Раздел «Статические» — это то, где вы вводите в сеть соответствующую информацию DHCP и статические IP-адреса *

На iPhone и iPod touch ручные настройки сети выглядят так:

На iPad статическая информация IP-сети выглядит следующим образом:

Закройте настройки и запустите Safari или другое сетевое приложение, чтобы подтвердить подключение.

Настройки применяются автоматически после ввода всей информации, если вам нужна простенькая помня DNS, попробуйте использовать сервер 8.8.8.8 от Google, который является быстрым, эффективным и имеет очень высокую надежность.

* Это варьируется. Обязательно выберите ручной IP-адрес, который находится вне диапазона других устройств в сети, чтобы избежать конфликтов. Например, если маршрутизатор «192.168.0.1» и в сети пять устройств, выбор статического IP-адреса за пределами этого диапазона, например «192.168.0.25», скорее всего, будет ясным. Если вы не знаете, какой статический IP-адрес, маску подсети, маршрутизатор и DNS нужно ввести, узнайте у сетевого администратора, sysadmin, ISP или запроса на ввод IP-адреса вручную.

Я должен был установить ручную информацию DHCP, чтобы подключать iPads к некоторым более старым сетям Wi-Fi более чем один раз, что я уже встречал в Mac OS X Lion.

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

На скриншоте выше показано, что это используется на iPad и на iPhone, но метод одинаковый на любом iPad, iPhone и iPod touch, а настройки универсальны для всех версий iOS.

Наконец, если вы назначаете ручную сетевую IP-информацию, вам нужно установить статический IP-адрес на Mac, вы можете сделать это слишком легко.

Источник

ФИШКА Как исправить конфликт IP-адресов на iPhone и Mac

Всего пара нажатий и проблема решена.

Зачем это нужно: когда дома или в офисе к одной точке доступа подключается несколько устройств, есть шанс нарваться на конфликт IP-адресов. Бывает редко, но грозит проблемами с доступом к сети. Лучше заранее запомнить способ решения, чем в самый неподходящий момент шерстить просторы интернета.

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

Решение для iOS

1. Переходим в Настройки -> Wi-Fi;
2. Нажимаем на иконку информации рядом с активным подключением;
3. Выбираем пункт Обновить аренду.

При наличии конфликта IP-адресов устройству будет присвоен новый адрес в локальной сети.

Решение для OS X

1. Запускаем Настройки -> Сеть;
2. Выделяем текущее Wi-Fi подключение и нажимаем Дополнительно;
3. В разделе TCP/IP нажимаем кнопку Запросить адрес DHCP.

P.S.: в сетях, настроенных на базе AirPort, обычно таких проблем не возникает – Apple всё по уму делает 😉

Артём Суровцев

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

ICQ первой научилась шифровать видеозвонки

Все новинки конференции Google I/O. Они сумели удивить

👀 Читайте также . Всё по теме

• 

Facebook и Snapchat продолжают следить за пользователями iOS, даже если они запретили приложению это делать

Почему iPhone так долго живёт на 1% заряда?

Как создать резервную копию iPhone в iCloud, если в облаке нет свободного места

Как пользоваться новой функцией SharePlay на iPhone и iPad. Все возможности совместного просмотра и прослушивания

Как разблокировать iPhone или iPad голосом. Круто, но не очень безопасно

3 функции Пункта управления iOS 15, которые облегчат работу с iPhone. Например, история Shazam

Как в iOS 15 редактировать PDF-файлы. Сторонние приложения больше не нужны

3 полезных фишки Siri в iOS 15. Можно быстро делиться файлами и слушать сообщения

🙈 Комментарии 18

Именно поэтому я и купил себе Airport))) Что б проблем не было)))

У меня получалось проще — выкл/вкл wifi на проблемном устройстве

Конфликт может быть только если на каком-то из клиентов IP вручную введён))

@sonne , нет, у разных ОС свой алгоритм обновления адресов и когда в одной сети есть Mac и Windows компьютеры конфликт адресов возможен. Еще такое происходит при работа на одном компьютере в разных сетях.

@Артём Суровцев , алгоритм обновления не у ОС, а у сервера и не может он дать адрес,если он уже занят, перед выдачей адреса, он проверяет,свободен он или нет, конфликт может быть,если адреса введены вручную оба. Как-то так

@Артём Суровцев , полнейший бред, на работе зоопарк из винды от XP до 10, линуксов разного посола, включая Synology, Макось, Андройды, iOS, Windows phone.
Никогда никаких конфликтов не было – потому что всети только один DHCP сервер и только о решает кому и когда выдать ip, а за кем закрепить постоянный.
Конфликт мог бы случиться, только если воткнуть в сеть устройство с ручными настройками ip совпадающими с уже зарегистрированным в сети устройством.

@iGitlin , всё верно и эйрпорт здесь не при чём

@Артём Суровцев , простите, но это просто ахинея 🙂
А описанная методика равносильна вкл/выкл wi-fi на проблемном устройстве.
В том числе последнее предложение в статье 🙂
Особенно в свете раз через 10 работающего airdrop.

я столкнулся с проблемой, что если через спидтест проверять скорость, то получается Ping через Safari около 30 мс, а через google chrome 2-3 мс, из-за этого safari бывает медленнее (

Вот проблема то, вкл/выкл WiFi на устройстве и точка выдаст при новом подключении новый адрес

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

Телевизоры, сервер и aiplay колонка имеют статические адреса на роутере, т.к. проще запомнить и администрировать удаленно

телефоны и планшеты получают адреса динамически.
Проблема с конфликтом адресов надумана ))

Зачем это? Мой роутер keenetic extra знает мак-адреса устройств и всегда выдаёт каждому свой ip

Очень странная проблема…
Технически поймать дважды один IP что в IPv4 с DHCP что в IPv6(при динамической конфигурации) можно только при наличии двух одинаковых MAC’ов, но тут, как бы, проблемы посильнее начинаются.

Приветствую!
А что вы скажете про такую историю.
Имеется экстрим и экспресс. Новый провайдер, провод (кабель изернет).
При попытке подключения, на каждом устройстве начинается регистрация онного устройства у провайдер.
Таким образом, как я выяснял онлайн, эполовские девайсы провайдеру выдавали мак адрес каждого подключенного устройства подключающегося к точке доступа, соответственно провайдер фиксировал несколько устройств и не мог предоставить мне услугу т.к. для этого требовалось выдавать более 5 услуг по одной на каждое устройство. В чем может быть проблема!?
Более коротенько! apple точка, подключаю по вафле 7 устройств, точка фиксирует и передает провайдеру семь устройств, а не одно (точку). В чем может быть проблема!? Пришлось ставить вместо apple, xiaomi, данный девайс действует четко, отправляет свой мак адрес, а уже внутренние ip раздает устройствам. Все ровно. В итоге точку apple я подключил к xiaomi к нему на 2тб жесткий и у меня вафля расширилась и имеется свое хранилище для тунца и фото, удобно. Но хочется, чтобы все среда была apple и не было посторонних китайских девайсов, хоть это и xiaomi

@fantik83 , у тебя airport в режиме bridge (моста ) работает, поменяй на dhcp и nat режим и будет тебе счастье )

Источник

Iphone не получает dhcp

Вкратце — имеем сеть заведения в которой три точки wi-fi D-Link DWL-2100AP + 1 репитер из такой же точки.
На точках отключено шифрование, на точках отключен DHCP. Точки работают не первый день и даже больше года.
Внезапно, на точках перестали получать ip и соотвестенно интернет все мак девайсы с ios на борту.
Не зависимо от поколения iphone и ipad не получают ip. Все остальные ОС (ведроид и блекбери например) получают свое без проблем.
За день раскуривания ситуации было замечено, что iphone (тестил 3gs и 4s) решили что IP у них 192.168.0.196 и никакой иной. С этим IP они упрямо долбятся в dhcp (логи ниже).
Писать всю топологию сети с vlanами и циками — букв не хватит.
Лог как оно должно быть на примере андроид
Jun 27 15:59:27 m22 dhcpd: DHCPDISCOVER from 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011
Jun 27 15:59:27 m22 dhcpd: DHCPREQUEST for 192.168.0.123 (192.168.0.1) from 50:e5:49:fc:e8:3d via vlan2011: wrong network.
Jun 27 15:59:27 m22 dhcpd: DHCPNAK on 192.168.0.123 to 50:e5:49:fc:e8:3d via vlan2011
Jun 27 15:59:28 m22 dhcpd: DHCPOFFER on 192.168.2.154 to 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011
Jun 27 15:59:28 m22 dhcpd: DHCPDISCOVER from 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011
Jun 27 15:59:28 m22 dhcpd: DHCPOFFER on 192.168.2.154 to 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011
Jun 27 15:59:28 m22 dhcpd: DHCPREQUEST for 192.168.2.154 (192.168.2.254) from 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011
Jun 27 15:59:28 m22 dhcpd: DHCPACK on 192.168.2.154 to 50:e5:49:fc:e8:3d (android_9c21c0da339afb59) via vlan2011

Как ведет себя огрызок
Jun 27 19:22:55 m22 dhcpd: DHCPDISCOVER from 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 27 19:22:56 m22 dhcpd: DHCPOFFER on 192.168.2.115 to 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 27 19:22:56 m22 dhcpd: DHCPREQUEST for 192.168.0.196 (192.168.0.1) from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 27 19:22:56 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011
Jun 27 19:23:12 m22 dhcpd: DHCPREQUEST for 192.168.0.196 from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 27 19:23:12 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011

Меня смущает что и андроид запрашивает что то из сети 192.168.0.x это у в них прошито по умолчанию? Включеный dhcp на точке я пока отвергаю — не мог он включится одновременно на всех и только для яббла.

Моцк сломал уже, может кто-то что-то может подсказать.

UPD
Внезапно на айфоню находит просветленье вот такое
Jun 27 19:39:40 m22 dhcpd: DHCPREQUEST for 192.168.2.115 (192.168.2.254) from 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 27 19:39:40 m22 dhcpd: DHCPACK on 192.168.2.115 to 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011

Но если пыцнуть в «обновить аренду» начинается та же пестня по кругу.

UPD
если отключить dhcp сервер то ноут например — ничего не получает. Мобильные девайсы тупят со своими 192,168,0, .
UPD
Кстати ноут ведет себя вполне корректно
Jun 28 11:10:59 m22 dhcpd: DHCPDISCOVER from 1c:4b:d6:aa:9f:78 via vlan2011
Jun 28 11:10:59 m22 dhcpd: DHCPOFFER on 192.168.2.18 to 1c:4b:d6:aa:9f:78 (W_notebook) via vlan2011
Jun 28 11:10:59 m22 dhcpd: DHCPREQUEST for 192.168.2.18 (192.168.2.254) from 1c:4b:d6:aa:9f:78 (W_notebook) via vlan2011
Jun 28 11:10:59 m22 dhcpd: DHCPACK on 192.168.2.18 to 1c:4b:d6:aa:9f:78 (W_notebook) via vlan2011

UPD Дальше — смешнее достаем и подключаем blackberry
Jun 28 13:50:29 m22 dhcpd: DHCPNAK on 192.168.0.133 to cc:55:ad:34:21:55 via vlan2011
Jun 28 13:50:29 m22 dhcpd: DHCPREQUEST for 192.168.0.133 (192.168.0.1) from cc:55:ad:34:21:55 via vlan2011: wrong network.
Jun 28 13:50:29 m22 dhcpd: DHCPNAK on 192.168.0.133 to cc:55:ad:34:21:55 via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPOFFER on 192.168.2.193 to cc:55:ad:34:21:55 (BLACKBERRY-090F) via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPREQUEST for 192.168.0.133 (192.168.0.1) from cc:55:ad:34:21:55 via vlan2011: wrong network.
Jun 28 13:50:30 m22 dhcpd: DHCPNAK on 192.168.0.133 to cc:55:ad:34:21:55 via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPDISCOVER from cc:55:ad:34:21:55 (BLACKBERRY-090F) via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPOFFER on 192.168.2.193 to cc:55:ad:34:21:55 (BLACKBERRY-090F) via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPREQUEST for 192.168.2.193 (192.168.2.254) from cc:55:ad:34:21:55 (BLACKBERRY-090F) via vlan2011
Jun 28 13:50:30 m22 dhcpd: DHCPACK on 192.168.2.193 to cc:55:ad:34:21:55 (BLACKBERRY-090F) via vlan2011

UPD
Одна из точек находится в подвале, кроме нее там нет никакого вай фай. Будем исключать левый сервер Отключаем все остальные точки кроме подвальной, проверяем (двумя устройствами) наличие любого другого сигнала. Ничего нету. Яббл упрямо
Jun 28 14:25:00 m22 dhcpd: DHCPDISCOVER from 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 28 14:25:01 m22 dhcpd: DHCPOFFER on 192.168.2.115 to 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 28 14:25:01 m22 dhcpd: DHCPREQUEST for 192.168.0.196 (192.168.0.1) from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 28 14:25:01 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011
Jun 28 14:25:16 m22 dhcpd: DHCPREQUEST for 192.168.0.196 from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 28 14:25:16 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011
Jun 28 14:25:16 m22 dhcpd: DHCPDISCOVER from 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 28 14:25:16 m22 dhcpd: DHCPOFFER on 192.168.2.115 to 88:c6:63:dc:de:f6 (iPhone-Roma2) via vlan2011
Jun 28 14:25:17 m22 dhcpd: DHCPREQUEST for 192.168.0.196 (192.168.0.1) from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 28 14:25:17 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011
Jun 28 14:25:27 m22 dhcpd: DHCPREQUEST for 192.168.0.196 from 88:c6:63:dc:de:f6 via vlan2011: wrong network.
Jun 28 14:25:27 m22 dhcpd: DHCPNAK on 192.168.0.196 to 88:c6:63:dc:de:f6 via vlan2011

Финальный UPD.
Виновата оказалась та самая точка которая в подвале. Оно решило рехнутся и раздавать dhcp при отключеном dhcp (залез в настройки).
поймана tcpdump с записью в файл , файл скормлен wireshark.
Непонятым осталось следующее — почему на это реагировал только яббл и почему mac этой точки не светился ни в одной arp таблице.
Всем огромное спасибо за помощь.

Источник