Проблема с DHCP сервером

0

0

В логах происходит какая то странность
dhcp.log

Feb 18 20:10:31 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:31 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:10:31 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:32 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:32 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:32 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:10:32 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:33 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:33 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:10:33 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:10:33 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:11:59 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:00 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:00 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:12:00 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:01 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:01 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:01 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:12:01 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:02 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:02 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:02 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:12:02 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:03 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:03 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:12:03 gate dhcpd: DHCPREQUEST for 172.23.1.4 (172.23.0.1) from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2)
Feb 18 20:12:03 gate dhcpd: DHCPACK on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:14:45 gate dhcpd: DHCPDISCOVER from 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1
Feb 18 20:14:46 gate dhcpd: DHCPOFFER on 172.23.1.4 to 5c:b5:24:08:3b:85 (android_7add06fb2a997fc2) via eth1

dhcpd.leases

lease 172.23.1.4 {
  starts 3 2015/02/18 13:10:33;
  ends 1 2015/02/23 13:10:33;
  cltt 3 2015/02/18 13:10:33;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 5c:b5:24:08:3b:85;
  option agent.circuit-id 0:4:3:a8:0:b;
  option agent.remote-id 0:6:90:94:e4:bb:d1:a0;
  client-hostname «android_7add06fb2a997fc2»;
}
lease 172.23.1.4 {
  starts 3 2015/02/18 13:12:00;
  ends 1 2015/02/23 13:12:00;
  cltt 3 2015/02/18 13:12:00;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 5c:b5:24:08:3b:85;
  option agent.circuit-id 0:4:3:a8:0:b;
  option agent.remote-id 0:6:90:94:e4:bb:d1:a0;
  client-hostname «android_7add06fb2a997fc2»;
}
lease 172.23.1.4 {
  starts 3 2015/02/18 13:12:01;
  ends 1 2015/02/23 13:12:01;
  cltt 3 2015/02/18 13:12:01;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 5c:b5:24:08:3b:85;
  option agent.circuit-id 0:4:3:a8:0:b;
  option agent.remote-id 0:6:90:94:e4:bb:d1:a0;
  client-hostname «android_7add06fb2a997fc2»;
}
lease 172.23.1.4 {
  starts 3 2015/02/18 13:12:02;
  ends 1 2015/02/23 13:12:02;
  cltt 3 2015/02/18 13:12:02;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 5c:b5:24:08:3b:85;
  option agent.circuit-id 0:4:3:a8:0:b;
  option agent.remote-id 0:6:90:94:e4:bb:d1:a0;
  client-hostname «android_7add06fb2a997fc2»;
}
lease 172.23.1.4 {
  starts 3 2015/02/18 13:12:03;
  ends 1 2015/02/23 13:12:03;
  cltt 3 2015/02/18 13:12:03;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 5c:b5:24:08:3b:85;
  option agent.circuit-id 0:4:3:a8:0:b;
  option agent.remote-id 0:6:90:94:e4:bb:d1:a0;
  client-hostname «android_7add06fb2a997fc2»;
}

К сожалению не могу сказать что пишет насчет подключение само устройство андройд, но может кто подскажет почему так происходит и как это можно исправить
dhcpd.conf

ddns-update-style none;
option domain-name «test»;
option domain-name-servers 172.23.0.1;
option time-offset 7;
default-lease-time 432000;
max-lease-time 604800;
option netbios-node-type 1;
authoritative;
log-facility local7;
subnet 172.23.0.0 netmask 255.255.240.0 {
        option broadcast-address 172.23.15.255;
        option routers 172.23.0.1;
        option subnet-mask 255.255.240.0;

        range 172.23.1.1 172.23.15.254;
        option ntp-servers 172.23.0.1;
}

Ссылка

←	Как заблокировать узел по доменному имени, перехватывая DNS-пакеты

Блокировка яндекс.метрики

→

может из-за этого:

option time-offset int32;

The time-offset option specifies the offset of the client's subnet in seconds
 from Coordinated Universal Time (UTC).

или проблема на клиенте, т.к. он постоянно перезапрашивает настройки, хотя сервер их выдает

entony ★
(18.02.15 17:16:46 MSK)

Ответ на: комментарий от entony 18.02.15 17:16:46 MSK

Сомневаюсь, эта опция отвечает за смешение относительно UTC. Мой регион находиться в UTC +7, поэтому думаю параметр задан верно. Насчет клиента тоже думал, но не думаю, не может же быть что у большенства андройдов такая проблема. Так же знаю что подобная ситуация есть с ip-телефоном grandstream, причем данный аппарат может подключиться быстро а может и через три часа, и все это время будет подобная ситуация. Еще заметил что некоторые Windows хосты очень долго получают ip, все это время у них указано что идет инициализация.

operatornk
(18.02.15 18:58:01 MSK) автор топика

Ответ на: комментарий от operatornk 18.02.15 18:58:01 MSK

какой еще часовой пояс? Там смещение в секундах указывается, написано же. +7 = 25200

entony ★
(19.02.15 10:42:08 MSK)

это только для хоста android_7add06fb2a997fc2 или и для других? Похоже что клиент постоянно запрашивает.

что если временно упростить конфиг dhcp

option domain-name «test»;
option domain-name-servers 172.23.0.1;
default-lease-time 432000;
max-lease-time 604800;

subnet .....
...

samson ★★
(19.02.15 12:01:21 MSK)

Ответ на: комментарий от entony 19.02.15 10:42:08 MSK

Спасибо за замечание, немного не правильно перевел man

operatornk
(19.02.15 12:48:14 MSK) автор топика

Ссылка

Ответ на: комментарий от samson 19.02.15 12:01:21 MSK

Для всех хостов. Причем один и тот же хост, может получить и успокоиться, а может вести себя как описано выше. Так же предполагаю, что переодически создается ситуация, что даже если хост получил настройки и успокоился, то он может повторно их запросить спустя какое то время (час, два, ...).
Насчет упростить конфиг, не думаю что поможет, он и так практически минимальный, единственное что еще добавил это

option wpad code 252 = text;
option wpad «\n\000»;

так как с некоторых win хостов стали часто приходить DHCPINFORM запрашивающие 252 опцию. Причем впечатление что эти хосты запрашивают исключительно после того как все остальные хосты отключатся.
Еще странность что точно такой же конфиг корректно работает на «стенде», единственные отличия от боевой, что к нему подключается 3 клиента и все по проводу, а в боевой чуть больше 100 клиентов и из них 20-30% беспроводные

operatornk
(19.02.15 12:58:54 MSK) автор топика

Ответ на: комментарий от operatornk 19.02.15 12:58:54 MSK

Может проблема вообще не в DHCP сервере, а в сети... только тогда как это выявить... отключить всех и по одному подключать и смотреть как будет себя вести нет возможности...

operatornk
(19.02.15 13:01:22 MSK) автор топика