Кто может дать понятное объяснение нижеследующего?

Имеется ДЛинковская мыльница DIR-300 старого образца, еще до рестайлинга, с оранжевой web-мордой.
Hardware Version : B1, Firmware Version : 2.01, Wed 08 Jul 2009
Прошивать чем-то новым не хочу, работает нормально, стоит на другом конце страны.

На роутере пул DHCP-адресов: 192.168.202.100-150
Имеется Андроид-смартфон, которому прописана резервация
mac 50:3c:c4:5c:18:bc ---> адрес 192.168.202.108

Прописано при помощи кнопки в менюшке DHCP-сервера, так что ошибка при вводе исключается.
На удивление, Интернет на смартфоне есть, все нормально работает.

Но при этом, очень странные ругательства наблюдаются в ЛОГах:

Nov 3 16:51:34 | DHCP: Server sending NAK to 50:3c:c4:5c:18:bc
Nov 3 16:51:34 | DHCP: Server sending NAK to 50:3c:c4:5c:18:bc
Nov 3 16:51:34 | DHCP: Server sending ACK to 192.168.202.108. (Lease time = -1)
Nov 3 16:51:34 | DHCP: Server receive REQUEST from 50:3c:c4:5c:18:bc
Nov 3 16:51:34 | DHCP: Server sending ACK to 192.168.202.108. (Lease time = -1)
Nov 3 16:51:34 | DHCP: Server receive REQUEST from 50:3c:c4:5c:18:bc
Nov 3 16:51:34 | DHCP: Server sending OFFER of 192.168.202.108 for static DHCP client.
Nov 3 16:51:34 | DHCP: Server receive DISCOVER from50:3c:c4:5c:18:bc
Nov 3 16:51:34 | DHCP: Server sending OFFER of 192.168.202.108 for static DHCP client.
Nov 3 16:51:34 | DHCP: Server receive DISCOVER from 50:3c:c4:5c:18:bc
Nov 3 16:51:33 | DHCP: Server sending NAK to 50:3c:c4:5c:18:bc
Nov 3 16:51:33 | DHCP: Server receive REQUEST from 50:3c:c4:5c:18:bc
Nov 3 16:51:33 | DHCP: Server sending NAK to 50:3c:c4:5c:18:bc
Nov 3 16:51:33 | DHCP: Server receive REQUEST from 50:3c:c4:5c:18:bc

Если снимаю с резервации mac-адрес, то выдается тот же адрес 192.168.202.108 и в логах Lease time = 600 сек

С другими зарезервированными адресами таких фокусов нет.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Ну если у Вас планшет с андроидом постоянно посылает широковещательные запросы для поиска DHCP, то тот вынужден постоянно отвечать, ну и дальше по цепочке. Судя по всему ему (планшету) очень хочется подсесть на какой-то определённый адрес, но его насильно пихают на другой (тот который зарезервирован для его MAC). У меня тоже пара таких планшетов аналогично себя ведут на разных прошивках и железках (аналогичные записи в логе) - как только отключаешь резервацию, то срач в логах исчезает - устройство посылает один DISCOVER, получает OFFER от сервера, ну потом как обычно REQUEST -> ACK и дальше не аноет до истечения времени аренды. Предположение о том, что андроид всё время пытается запросить у DHCP конкретный адрес строится на повторяющихся сообщениях NAK (видимо DHCPNACK) - то есть DHCP сервер отказывает в предоставлении адреса запрашиваемого клиентом, а тот продолжает посылать реквесты.

Непонятно только, с какого перепугу у него (смартфона) такая страстная любовь к определенному адресу. (Андроид 4.2)
Принудительно в его крошечной зеленой извилине ему никто ничего не прописывал, за исключением SSID, разумеется.
И что самое любопытное - если ему резервацию привязать к другому IPшнику, то он, сцука, все равно каким-то немыслимым фантастическим образом выцепляет у роутера свой любимый адрес! - И вот это уже за гранью логического объяснения!

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

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

В списках клиентов DHCP этот смартфон фигурирует как "android- и потом туевахучабуковокициферекотбалды" (что-то типа такого: "android-1bd34f6208eaf06543ab")
Потом, когда В консоли DHCP-сервера его ставишь на резервацию, прописываешь название этой записи в списке резервации, например, "Phone-01"
Могу только предположить, что каким-то образом и непонятно для чего мыльница пытается сопоставить эти два названия (хотя они вообще из разных записей и абсолютно никак не соотносятся между собой), после чего у нее рвет крышу и она отдает смартфону тот адрес, который давала при первичной регистрации девайса.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Хм.. Странно это все, но симптоматика схожая - идей пока нет. Заметил, что если вручную обновить файл udhcpd.conf и рестартануть DHCP, то выдает нужный адрес по привязке, но после обновления прошивки такая же котовасия т.е. привязка уже есть, но берет свой любимый адрес - удаляешь из udhcpd.conf привязку, сохраняешь, потом снова открываешь и вставляешь обратно тот же адрес и мак, сохраняешь и рестартишь демона - работает до следующего планового обновления прошивки. Такая вот мистика (если просто ребутнуть, то будет все равно свой адрес запрашивать пока не поправишь udhcpd.conf не важно по телнету/SSH или через вебморду).