Как исправить ошибку bad address

Обновлено 18.11.2022

DHCP error logoДобрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами производили миграцию отказоустойчивого DHCP сервера с Windows Server 2012 R2 на Windows Server 2019. В момент переноса я уже получал ряд сопутствующих ошибок, что успешно было устранено. Но они были еще не последними, так как на одной из областей DHCP я стал получать много ошибок со статусом BAD_ADDRESS: This address is already in use, что для конечных пользователей было критично, так как пропадала сеть WIFI. Давайте я попробую описать свой опыт и методы диагностики с устранениями.

Описание ошибки BAD_ADDRESS: This address is already in use

На новой паре DHCP-серверов я стал на области WIFI получать много ошибок:

BAD_ADDRESS: This address is already in use

Ошибка получения IP адреса на DHCP. BAD_ADDRESS This address is already in use

Первое, что я сделал это принудительно, удалил такие IP адреса, и отреплицировал область между серверами DHCP. Еще обратите внимание, что на вашем scope появится значок предупреждения, я выделил его стрелкой.

DHCP Server replicate scope

Далее, что я стал делать, это смотреть логи DHCP сервера, для этого в просмотре событий есть соответствующие журналы:

  • Microsoft-Windows-DHCP Server Events/Admin
  • Microsoft-Windows-DHCP Server Events/Operational
  • Microsoft-Windows-DHCP Client Events/Admin

Первое чем были забиты логи, это предупреждение с ID 1063:

There are no IP addresses available for lease in the scope or superscope «WIFI_Pyatilistnik».

There are no IP addresses available for lease in the scope or superscope

Предупреждение ID 1342:

IP address range of scope WIFI is out of IP addresses.

IP address range of scope WIFI is out of IP addresses.

Я увидел, что Ip-адреса из определенного скоупа просто закончились. Остальные клиенты, которые пытались получить от DHCP-сервера IP-адрес, просто дропались, это видно в событии ID 20287.

DHCP client request from F09E40097EC1 was dropped since the applicable IP address ranges in scope

DHCP client request from MAC was dropped since the applicable IP address ranges in scope

Это так же спровоцировало шквал ошибок ID 20292.

ID 20292: A BINDING-ACK message with transaction id: 28044 was received for IP address: 10.xx.xx.82 with reject reason: (Outdated binding information ) from partner server: dhcp04.pyatilistnik.org for failover relationship: dhcp03.pyatilistnik.org-dhcp04.pyatilistnik.org.

A BINDING-ACK message with transaction id

Зайдя в свойства области я лицезрел картину, как свыше 2000 IP-адресов были зарезервированы, и люди просили еще😄

Закончились IP-адреса на области DHCP

Как устранить ошибку BAD_ADDRESS

В данной ситуации у меня наложились два момента:

  • 1️⃣Количество пользователей увеличилось с 1200 до 1600 + их мобильные устройства
  • 2️⃣В момент загрузки информации, об областях и аренде в них, были скопированы записи аренды со статусом Expired, но об этом чуть ниже.

Ранее в другой статье я вам рассказывал интересный момент работы DHCP-сервера Microsoft, там после окончания аренды, если клиент не стал продлевать, данный IP забирает DHCP-сервер, но он его по умолчанию не отдает еще целых 4-часа, это называется льготный период (grace period). Его нужно уменьшать. В моем случае, когда все IP-адреса заняты и куча со статусом BAD_ADDRESS, нужно искать Expired адреса и чистить их. Для этого у вас должен быть ScopeId и мои команды😄. Чтобы посмотреть все IP-адреса со статусом Expired находящихся в льготном периоде, выполните в PowerShell в режиме администратора на первом DHCP-сервере команду:

Get-DhcpServerv4Lease -ScopeId 10.168.31.0 -AllLeases | where-object {$_.AddressState -like «Expired»}

Вывод всех IP адресов со статусом Expired

На дворе было 15 ноября 2022, а записи были аж от 28 октября 2022, это оставшийся мусор после миграции DHCP, который по какой-то причине не почистился сервером из области льготного периода.

Вывод всех IP адресов со статусом Expired-2

Я решил посчитать, сколько у меня так застряло IP адресов, для этого можно использовать вот такой код:

$obj = Get-DhcpServerv4Lease -ScopeId 10.168.31.0 -AllLeases | ? {$_.AddressState -like «Expired»}

($obj | Measure-Object).Count

Таких застрявших оказалось свыше 540 штук, что было 25% от общего пуля.

Количество IP-адресов со статусом Expired

Естественно я попытался их почистить, для этого есть PowerShell код:

$computername = «Тут пишите адрес вашего DHCP»

$scopeid = «Тут пишите имя вашей области»

foreach ($object in Get-DhcpServerv4Lease -ComputerName $computername -ScopeId $scopeid)

{

if ($object.leaseExpiryTime -le (Get-Date))

{

$object.hostname

Remove-DhcpServerv4Lease -ComputerName $computername -IPAddress ($object.IPAddress).IPAddressToString

}

}

или

$computername = «Тут пишите адрес вашего DHCP»

$scopeid = «Тут пишите имя вашей области»

foreach ($object in (Get-DhcpServerv4Lease -AllLeases -ComputerName $computername -ScopeId $scopeid))
{

if ($object.leaseExpiryTime -le (Get-Date))
{
$object.hostname

Remove-DhcpServerv4Lease -ComputerName $computername -IPAddress ($object.IPAddress).IPAddressToString # -WhatIf
}
else
{
# $object.leaseExpiryTime
}
}

Массовое удаление IP-адресов со статусом DHCP

Но у меня повалилась куча ошибок:

Remove-DhcpServerv4Lease : Failed to delete lease 10.xx.xx.142 on DHCP server dhcp03.pyatilistnik.org.
At line:12 char:9
+ Remove-DhcpServerv4Lease -ComputerName $computername -IPAddre …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (10.xx.xx.142:root/Microsoft/…cpServerv4Lease) [Remove-DhcpServerv4Lease], CimException
+ FullyQualifiedErrorId : WIN32 232,Remove-DhcpServerv4Lease

В итоге в области namespaces нет данных Ip-адресов, через netsh так же не удалялось.

Ошибка удаления IP-адресов со статусом Expired

Если на первом сервере выбрать в команде второй DCHP, то ошибка сохранится, а вот если зайти на второй DHCP по RDP ну или удаленно подключиться через PowerShell, то вот там как раз все прекрасно удалится, дошел я до этого не сразу.

Еще оговорюсь, что я мог пересоздать scope, но мне не хотелось делать лишних телодвижений и менять настройки, тем более со скоупом в 2000 клиентов

Успешное удаление Ip-адресов со статусом Expired

В результате 500 IP-адресов снова появились в доступном обращении.

Уменьшение времени льготного периода и очистки базы данных DHCP

В больших сетях, где большое количество клиентов я советую  grace period на небольшой промежуток, то используют два ключа реестра.

  • Интервал очистки базы данных можно сократить, обновив раздел реестра DatabaseCleanupInterval тип DWORD в разделе HKLM/System/CurrentControlSet /Services / DHCPServer/Parameters. Хочу отметить, что по умолчанию значение у ключа DatabaseCleanupInterval  составляет 60 минут, когда он будит проходить и вычищать Expired записи после того, как заканчивается «Льготный период (grace period)«. По умолчанию он создан уже на DHCP сервере, я советую выставить его минут 30. Так же его можно задать и через PowerShell

Set-DhcpServerDatabase -ComputerName «dhcpserver.pyatilistnik.org» -FileName «D:NewDhcpPathdhcp.mdb» -BackupPath «D:NewDhcpPathbackup» -CleanupInterval 30

Смена периода очистки адресов в DHCP через DatabaseCleanupInterval

  • Вы можете сократить льготный период аренды, создав или обновив раздел реестра LeaseExtension тип DWORD в разделе HKLM/System/CurrentControlSet /Services/DHCPServer/Parameters. Значение может быть указано в десятичном формате и должно быть в минутах. Я обычно ставлю 60 секунд.

Создание ключа реестра LeaseExtension

После этого вам необходимо произвести перезапуск службы DHCP, либо через графическую оснастку services.msc, которую можно запустить через «окно Выполнить» или же введите команду в PowerShell.

Restart-Service DHCPServer

Согласование БД DHCP

Еще на уровне scope или всего сервера DHCP, есть такая функция согласования (reconcline), используйте ее когда у вас есть какие-то проблемы на DHCP с БД.

согласования (reconcline) на DHCP сервере

Вы должны добиться того, что у вас БД ответила «The database is consistent«

успешно выполнено согласования (reconcline)

Дополнительные ссылки

  • https://learn.microsoft.com/en-us/powershell/module/dhcpserver/set-dhcpserverdatabase
  • https://windata.ru/windows-world/lokalnaya-set/vosstanovlenie-bd-dhcp-soglasovanie-oblastej/

Надеюсь, что вам удалось решить свою проблему с моим скромным опытом. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

What is Bad Address?

We know that all the computers, servers, mobile devices communicate through the internet via IP address each, and every device has its separate unique IP address. Devices will get the IP address from the DHCP server when it connected to the network. There are two types of IP address allocation, static and Dynamic (DHCP). In some cultivation, devices share the same IP address from the DHCP server, this cause IP address conflict and will get the popup stating an IP address conflict detected. BAD address is if the same address assigned to 2 machines it will conflict and make it as a BAD address in DHCP terms.

How the Bad_address Entry is happening on the DHCP server?

For example, in any multi-project Organization, which handle different project as per the client requirement may have different Project VLAN. Each project may contain 50 users, so while creating a DHCP scope for that project 50 IP range will be created, first and last IPs are automatically omitted by the DHCP server remaining IP address are automatically allocated to the system by the DHCP server. Each IP has a maximum IP release duration Time. For imaging purposes, most of the organization enables Ghost IP after imaging IT will enable Project VLAN. Ghost VLAN IP release duration time maybe 6-8 hours after 8 hours the IP will be automatically released, during this duration, any system picks the IP and not completed 8 hours duration time before that anyone clears the scoop for another set of Reimage. Now the IP will stay in the system and again while the DHCP server tries to allocate the IP within the range the same IP will allocate to some other system this will cause IP address conflict.

How DHCP server Detects the Conflicts?

The DHCP server detects conflicts by pinging an IP address before offering that address to clients. If the ping is successful (a response is received from a computer), a conflict is registered and that address is not offered to clients requesting a lease from the server. The DHCP server pings only address that have not been successfully and previously leased. If a client receives a lease on an IP address that it already had or is requesting a renewal, the DHCP server does not send a ping. If conflict detection is enabled, an administrator-defined number of pings are sent. The server waits 1 second for a reply. Because the time required for a client to obtain a lease is equal to the number of pings selected, choose this value carefully as it directly impacts the overall performance of the server. In general, one ping should be sufficient. A DHCP server receiving a reply to any of the pings (meaning there is a conflict) attaches a BAD_ADDRESS value to that IP address in the scope and will try to lease the next available address. If the duplicate address is removed from the network, the BAD_ADDRESS value attached to the IP address can be deleted from the scope’s list of active leases, and the address returned to the pool. Addresses are marked as BAD_ADDRESS for the length of the lease for which the scope is configured. If your network includes legacy DHCP clients, enable conflict detection on the DHCP server. By default, the DHCP service does not perform any conflict detection. In general, conflict detection should be used only as a troubleshooting aid when you suspect there are duplicate IP addresses in use on your network. The reason for this is that, for each additional conflict detection attempt that the DHCP service performs, additional seconds are added to the time needed to negotiate leases for DHCP clients.

Possible Solutions:

Checking the Old DHCP logs and clearing It. This is caused mostly by a malfunctioning DNS. Delete the BAD IP addresses from your DNS entries, then restart DNS. Delete it on DHCP as well. If the entire IP scoop becomes bad, then completely refresh the scoop this will release all the IP from the range and renew with New IPs.

Причина известна и хорошо документирована тут, тут — искать в тексте BAD_ADDRESS.

Если DHCP-сервер (под MS Windows) обладает резервированием на некий МАС-адрес и некто начинает статически использовать этот адрес (который DHCP-сервер хочет раздавать), то сервер (или клиент) сам это диагностирует и помечает данное резервирование меткой BAD_ADDRESS. При этом в свойствах этого конкретного резервирования стирается ранее прописанный МАС-адрес, и пишется IP адрес в обратном виде в HEX записи.

DHCP BAD_ADDRESS

В итоге — резервирование «портится» и после того, как «оккупант» со статическим адресом исчезает из сети, резервирование остается испорченным и в будущем не выдает адрес тому МАСу, для которого создавалось. Эта «особенность» работы DHCP сервера от Microsoft (по крайней мере в Windows Server 2008 R2 и ранее работало именно так).

Попробовать исправить это можно, включив определение конфликтов DHCP (см. тут). Надо открыть консоль DHCP сервера, нажать правой кнопкой на IPv4, свойства, вкладка дополнительно, выбрать количество пингов для определения конфликта. Ставить надо от 1 до 3, т.к. большие значения приведут к сильным тормозам в работе системы.

DHCP Server Conflict Detection

Варианты решения:

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

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

И еще одно — в системах MS Windows Vista и старше, при каждом запуске системы, ОС пытается найти DHCP сервер, и если не находит, то перестает использовать ранее выданный адрес. Описание и решение проблемы смотреть тут. Если кратко, то в реестре

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters надо создать DWORD Value с именем DontPingGateway, и присвоить ему значение 1. Это решит проблему.

/* Write and rewrite */
#include<stdio.h>
#include<unistd.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>

int main(int argc,char* argv[]){
 int i = 0;
 int w_rw = 0;
 int fd = -1;
 int bw = -1;
 int nob = 0;
 char* file_name = "myfile";
 char buff[30] = "Dummy File Testing";

 w_rw = 1;       // 1 - write , 2 - rewrite
 nob = 1000000;  // No of bytes to write

 printf("n File - Create,Open,Write n");

 for(i = 0; i < w_rw; i++){
        printf("fd:%d line : %dn",fd,__LINE__);
        if((fd = open(file_name,O_CREAT | O_RDWR))< 0){
                perror("Open failed!");
                return -1;
        }

        printf("fd:%d",fd);
        if((bw = write(fd,buff,nob)) < 0){
                perror("Write failed!");
                return -1;
        }
        printf("n Bytes written : %d n",bw);
 }

 return 0;
}

I’m getting a write error, Bad address failure when tried to write 1MB bytes of data. why is that so ?

Devolus's user avatar

Devolus

21.5k13 gold badges66 silver badges112 bronze badges

asked Jan 23, 2014 at 8:59

Angus's user avatar

0

According to man of write write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd so you are overrunning the string buffer.

If you want to just fill the file with that string try fwrite, you can specify the string length and the total number of times to write the buffer (nob/strlen(buff) ?).

answered Jan 23, 2014 at 9:06

Rudolfs Bundulis's user avatar

Rudolfs BundulisRudolfs Bundulis

11.6k5 gold badges31 silver badges69 bronze badges

3

 ssize_t write(int fd, const void *buf, size_t nbytes);

write() system call will read nbytes bytes from buf and write to file referred by the file descriptor fd.

In your program buf is small compare to nbytes so write() trying to access invalid address location, so its giving Bad Address error.

Your buf is buff[30] change to buf[1000000] you can solve your problem.

Bad Address error means that the address location that you have given is invalid.

Wikipedia giving good explanation with example program about write.

answered Jan 23, 2014 at 10:07

sujin's user avatar

sujinsujin

2,7932 gold badges21 silver badges33 bronze badges

Your buff array should be at least nob bytes long for the write call to succeed…

answered Jan 23, 2014 at 9:03

Malkocoglu's user avatar

MalkocogluMalkocoglu

2,4922 gold badges26 silver badges32 bronze badges

Симптомы

Запись «bad_address» может быть создан на DHCP-сервере. Это может происходить, если выполняются следующие условия:

  • У вас есть один многосетевого DHCP-клиент и одного DHCP-сервера.

  • Сетевые адаптеры на стороне клиента DHCP и сетевого адаптера на DHCP-сервере подключены к одному сегменту.

  • Обоих сетевых адаптеров на стороне клиента DHCP настроены на автоматическое получение IP-адреса.

  • Включена функция обнаружения конфликтов на DHCP-сервере.

При выполнении команд на стороне клиента DHCP на DHCP-сервере создается одна запись «bad_address»:

ipconfig /release
ipconfig / renewЭта запись «bad_address» является IP-адрес, который ранее был назначен второй сетевой адаптер на стороне клиента DHCP. При выполнении двух команд, создается другая запись «bad_address» на DHCP-сервере. Таким образом все доступные IP-адреса в области становятся неверные адреса. Это может привести к DHCP-серверу не работает для области.

Причина

Предположим, что nnn. nn.1.1 назначается первый сетевой адаптер клиента DHCP и что nnn. nn.1.2 назначен второй сетевой адаптер на стороне клиента DHCP. После запуска следующей команды на стороне клиента DHCP nnn. nn.1.1 по-прежнему назначается первый сетевой адаптер на стороне клиента DHCP:

ipconfig /release
ipconfig / renewDHCP-сервер пытается назначить nnn. .1.2 nnдля второй сетевой адаптер. Так как на DHCP-сервере включено обнаружение конфликтов, DHCP-сервер пытается опросить nnn. .1.2 nn, прежде чем он назначает nnn. .1.2 nnдля второго сетевого адаптера на стороне клиента DHCP. Следовательно DHCP-сервер направляет пакетов ECHO сообщение протокола ICMP (Internet Control) аппаратный (MAC) адрес второго сетевого адаптера на стороне клиента DHCP. DHCP-клиент получает пакет ICMP ЭХО и передает его на верхнем уровне. DHCP-клиент отправляет ответные пакеты протокола ICMP ЭХО сервера DHCP из первого сетевого адаптера. Затем DHCP-сервер отмечает nnn. .1.2 nnкак «bad_address».

Решение

Сведения о пакете обновления

Чтобы устранить эту проблему, получите последний пакет обновления для Microsoft Windows 2000. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

260910 как получить последний Пакет обновления для Windows 2000

Сведения об исправлении

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.

Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку часовой пояс «Дата и время» панели управления.
Date Time Version Size File name
———————————————————
04-Sep-2002 06:11 5.0.2195.6044 118,896 Afd.sys
04-Sep-2002 09:07 5.0.2195.6020 105,232 Msafd.dll
04-Sep-2002 09:07 5.0.2195.6045 313,296 Tcpip.sys
30-Jul-2001 12:15 5.0.2195.3988 16,240 Tdi.sys
04-Sep-2002 09:07 5.0.2195.4874 17,680 Wshtcpip.dll

Статус

Корпорация Майкрософт подтвердила, что это является проблемой в продуктах Майкрософт, перечисленных в разделе «Относится к». Впервые Эта ошибка была исправлена в Microsoft Windows 2000 Пакет обновления 4.

Дополнительные сведения

Дополнительные сведения о получении исправления для Windows 2000 Datacenter Server щелкните следующий номер статьи базы знаний Майкрософт:

Продукт Windows 2000 Datacenter Server и Datacenter Program 265173

Нужна дополнительная помощь?

Нужны дополнительные параметры?

Изучите преимущества подписки, просмотрите учебные курсы, узнайте, как защитить свое устройство и т. д.

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

Понравилась статья? Поделить с друзьями:
  • Как найти математическое ожидание постоянной величины
  • Как найти штрафы по гос номеру автомобиля
  • Как найти дело которое тебе нравится
  • Как найти оптический центр объектива
  • Как составить бизнес план пример рекламного агентства