проблемы с DHCP и мысли о нем.

[tes+or]

вобщем проблема такая. есть DHCP и он работает. в виду исторически сложившегося отсутствия архитектуры у нашей сети, когда юзер из определенной подсети по своей криворукости получает айпишник по DHCP, присваивается ему совсем не то, что хотелось бы, а то что ему присваивать совсем и очень даже не стоит - а именно айпишник бездискового сервака, в случае если последний был зачем-то выключен. а т.к. одна из подсетей у нас на ethernet уровне является частью управляющей подсети(знаю, ужас, буду боротся), то когда юзер получает айпишник сервака начинаются огромные проблемы.

у меня указана директива subnet с диапазоном из одного адреса, потому что даже при наличии директивы host с жесткой привязкой айпишника к маку, он всеравно зачем-то требует директиву сабнет, и если в отсутствие обладателя мака кто-то попросит айпишник, то DHCP не долго думая даст ему единственный айпишник из диапазона не глядя на привязку в директиве host, а когда после этого реальный хозяин этого айпишника спросит его, то сервак скажет что извините занято.

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

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

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

[tes+or]

решил еще почитать ман пока ктонибудь чтонибудь ответит и нашел вот:
deny unknown-clients;
помогло

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

Mar 16 12:17:43 nano dhcpd: DHCPREQUEST for 192.168.111.8 from 00:14:85:e7:0f:7d via eth0
Mar 16 12:17:43 nano dhcpd: DHCPACK on 192.168.111.8 to 00:14:85:e7:0f:7d via eth0
это виндовая машина и это работает

Mar 16 12:30:37 nano dhcpd: DHCPDISCOVER from 00:0f:3d:e9:3a:82 via eth0
Mar 16 12:30:37 nano dhcpd: DHCPOFFER on 192.168.111.164 to 00:0f:3d:e9:3a:82 via eth0

так оно общается с бездисковым, но предложенный айпишник он не берет. в чем может быть дело теперь?

[tes+or]

а знаете в чем дело было?

а память глючила=)

вот и поговорили