Привет, Коди! Извини, если не был ясен — у меня один DHCP-сервер, и я обычно использую его для всего, даже там, где нужен статический IP. Но твой вопрос заставил меня перепроверить, и ты прав: я думал, что оставил точки доступа с динамической настройкой, но, видимо, в какой-то момент зафиксировал это как статическую запись непосредственно в Unifi.

Однако... Такая же конфигурация прекрасно работала на версиях 4.x, через множество перезагрузок контроллера и точек доступа. Так что мне интересно, не потерялась ли часть настроек при обновлении до 5.x?

Сейчас мои точки доступа показывают правильные серверы имен и, кажется, корректное время.  
- Но часовой пояс всё ещё сдвинут на час (у нас BST — летнее время, а не UTC). Почему так, если контроллер выставлен на UTC и в Linux, и в Unifi GUI?

Кроме того, в предыдущей переписке были и другие вопросы — самый важный из них: есть ли способ понять, какие изменения в конфигурации действительно атомарные, а какие приведут к перезагрузке точек доступа (или Unifi, что даст тот же эффект)? Хочется лучше планировать disruptive-изменения.

Спасибо за подсказки — очень помогли!  
Джонне

++ После того как время было установлено вручную — хотя часовой пояс сбился и не совпадает с настройкой UTC на Linux-машине с Unifi — у нас есть прорыв: Wi-Fi отключился в полночь Проблема остаётся: точка доступа не выполняет расписание, потому что время не устанавливается. Время не устанавливается из-за того, что не проходит DNS-запрос, видимо из-за отсутствия настройки сервера имён. Помогите! Спасибо

Привет, Коди,  
Когда я установил USG, казалось, что он по умолчанию работает как DNS-переадресатор — все устройства в моей сети используют его в качестве nameserver и всё отлично работает. Он находится на 192.168.10.254, как ты увидишь ниже:  
Например, одна из моих Linux-машин:  
$ cat /etc/resolv.conf  
# Generated by resolvconf  
nameserver 192.168.10.254  

Проблема в том, что у AP в resolv.conf вообще нет записи о nameserver:  
BZ.v3.7.9# cat /etc/resolv.conf  
BZ.v3.7.9#  

Все остальные устройства с удовольствием используют USG как DNS-переадресатор, и все они обслуживаются одним DHCP-сервером, который настроен так в /etc/dhcp/dhcpd.conf:  
subnet 192.168.10.0 netmask 255.255.255.0 {  
 range 192.168.10.101 192.168.10.199;  
 option routers 192.168.10.254;  
 option domain-name-servers 192.168.10.254, 8.8.8.8;  

Это заставило меня перепроверить, не раздаёт ли USG тоже DHCP, но я не вижу, чтобы dhcpd работал на USG.  

Похоже, что проблема в отсутствии записи nameserver на AP — не совсем понимаю, куда копать для решения.  

Спасибо,  
Jhonne

Привет, Коди, спасибо за наводку (да, всё онлайн на контроллере):

Контроллер:  
$ date  
Вт 16 авг 05:37:20 UTC 2016

AP1:  
# date  
Сб 10 янв 12:22:05 GMT 1970

AP2:  
# date  
Чт 1 янв 07:19:06 GMT 1970 — хорошая подсказка, поэтому я проверил логи одного из AP:  
Jan 1 03:56:01 Kitchen cron.info crond[1655]: crond: USER admin pid 2358 cmd syswrapper.sh schedule-action
Jan 1 03:56:01 Kitchen user.notice syswrapper: текущее время ещё не установлено  
Jan 1 03:56:01 Kitchen user.notice syswrapper: текущее время ещё не установлено  
Jan 1 04:01:01 Kitchen cron.info crond[1655]: crond: USER admin pid 2372 cmd syswrapper.sh schedule-action
Jan 1 04:01:01 Kitchen user.notice syswrapper: текущее время ещё не установлено  
Jan 1 04:01:01 Kitchen user.notice syswrapper: текущее время ещё не установлено

... — ntpclient запущен (но флаг 'debug' -d не даёт вывода):  
BZ.v3.7.9# ntpclient -d  
Usage: ntpclient [-c count] [-d] [-f frequency] [-g goodness] -h hostname
[-i interval] [-l] [-p port] [-q min_delay] [-r] [-s] [-t] [-n]
BZ.v3.7.9# ps |grep ntp  
1652 admin 1112 S /sbin/ntpclient -i 86400 -n -s -c 0 -l -h 0.ubnt.pool.ntp.org  
3034 admin 1540 S grep ntp

BZ.v3.7.9# — не удаётся достучаться до NTP-сервера / DNS не разрешается:  
BZ.v3.7.9# ping 0.ubnt.pool.ntp.org  
ping: неверный адрес '0.ubnt.pool.ntp.org'  
BZ.v3.7.9# ping www.google.com  
ping: неверный адрес 'www.google.com'  
BZ.v3.7.9# ping 8.8.8.8  
PING 8.8.8.8 (8.8.8.8): 56 data bytes  
64 bytes from 8.8.8.8: seq=0 ttl=58 time=17.569 ms  
64 bytes from 8.8.8.8: seq=1 ttl=58 time=17.011 ms  
^C  
--- Статистика ping 8.8.8.8 ---  
2 пакета отправлено, 2 получено, 0% потерь  
время в пути min/среднее/max = 17.011/17.290/17.569 мс

BZ.v3.7.9# — проверил обычное место /etc/resolv.conf — файл пустой, неудивительно, что DNS не разрешается и время не устанавливается:  
BZ.v3.7.9# cat /etc/resolv.conf  

BZ.v3.7.9# — nslookup тоже не работает, если не указать адрес моего USG как DNS-прокси — так что предполагаю, что nameserver не просто спрятан где-то в BusyBox, а конфигурация вообще отсутствует:  
BZ.v3.7.9# nslookup  
BusyBox v1.19.4 (2016-08-01 19:35:23 PDT) multi-call binary.

Usage: nslookup [HOST] [SERVER]

Запрашивает у nameserver IP-адрес заданного HOST, можно указать конкретный DNS-сервер

BZ.v3.7.9# nslookup www.google.com  
Server: 0.0.0.0  
Address 1: 0.0.0.0

nslookup: не удалось разрешить 'www.google.com': имя или служба неизвестны  
BZ.v3.7.9# nslookup www.google.com 192.168.10.254  
Server: 192.168.10.254  
Address 1: 192.168.10.254 setup.ubnt.com

Name: www.google.com  
Address 1: 2a00:1450:4001:815::2004 fra15s12-in-x04.1e100.net  
Address 2: 216.58.210.4 fra16s07-in-f4.1e100.net

BZ.v3.7.9# — пытаюсь принудительно задать значение на обоих AP, посмотрим, поможет ли позже (день занят, играться нет времени ):  
BZ.v3.7.9# date --set 2016.08.16-05:58 -u  
Вт Авг 16 05:58:00 UTC 2016

Есть идеи, почему конфигурация DNS-сервера не доходит до AP? Судя по всему, это тянется вечно и особенно чувствительно к версиям пакетов и прочему.  
Спасибо,  
Джон

Обновление — сейчас уже 00:06, а SSID всё ещё доступны Jhonne

Привет, Коди, спасибо, что взялся за это. У меня фиксированный график: с 23:59 до 07:00 каждый день недели. Если я правильно помню, эта настройка исчезла после обновления до версии 5.x, поэтому я перенастроил её за несколько часов до её активации — но она так и не сработала. При обновлении до 5.2.2 конфигурация сохранилась, но всё равно не действует. Скоро попробую убрать её и добавить заново.