Bad address dhcp windows — Ваш верный помощник с OS Windows

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

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

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

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

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

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters надо создать DWORD Value с именем DontPingGateway, и присвоить ему значение 1. Это решит проблему.

Источник

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.

Post Views: 5,149

Источник

: April 14 2010, 13:17

Category:

Компьютеры
Cancel

После того, как наша контора купила в прошлом году несколько новых компов с предустановленной MS VIsta, начался тихий админский ад
Первой заметила неладное главбух. 1С-ка не открывается. Ладно, смотрим. Ага, почему-то IP-адрес не получила. Лезу на основной DHCP-сервер… маааама дорогая!!! Чтож это творится-то?!?! Пул адресов заполнен больше чем на половину, причем основная масса выданных адресов стоит в статусе BAD_ADDRESS! Начал грешить на сам DHCP-сервер, ладно, убил область, создал заново, на следующее утро — та же история. Причем страдают от этого в основном компы с Vista. Великий Гугл на тот момент ничего мне не смог подсказать. Временно вышел из положения сокращением времени аренды до 1 часа, что, конечно не есть гуд, ибо каждые полчаса компы заваливают сервер просьбами продлить аренду. Но хотя бы решилась проблема с переполнением пула. Ну и раз в неделю примерно, искал пути решения. И наконец нашел!
Оказывается, Майкрософт, начиная с Vista решил изменить способ получения адреса, что реализовано в Windows Server 2008. Типа такой намек, что 2003 пора бы уже списать в утиль
Вот какое решение предлагает сама Microsoft:
Чтобы устранить эту проблему самостоятельно, в системе Windows Vista отключите флаг DHCP BROADCAST. Для этого выполните действия, описанные ниже. Откройте меню Пуск, введите regedit в поле Начать поиск, затем выберите regedit в списке Программы.

При получении запроса на ввод пароля администратора или подтверждения введите пароль или нажмите кнопку Продолжить.
Найдите и выберите следующий раздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}
В этом разделе выберите подраздел (GUID), соответствующий сетевому адаптеру, который подключен к сети.
В меню Правка выберите пункт Создать, а затем — Параметр DWORD (32 бита).
В поле Новый параметр #1 введите DhcpConnEnableBcastFlagToggle и нажмите клавишу ВВОД.
Щелкните правой кнопкой мыши параметр DhcpConnEnableBcastFlagToggle и выберите команду Изменить.
В поле Значение введите 1 и нажмите кнопку ОК.
Закройте редактор реестра.
После установки значения 1 для этого раздела система Windows Vista будет сначала пытаться получить IP-адрес, используя флаг BROADCAST в DHCP-пакетах обнаружения. Если это не удастся, система попытается получить IP-адрес без использования флага BROADCAST в DHCP-пакетах обнаружения.

Источник

In this post, we are going to discuss on How to fix bad address entry on a DHCP server. You will be guided with easy steps/methods to resolve the issue. Let’s starts the discussion.

‘Bad address entry on a DHCP server’:

‘DHCP server’: DHCP server is network server that automatically provides and assigns IP addresses, default gateways and other network parameters to client devices. It sends the required network parameters automatically for the clients to properly communicate on the network. DHCP servers usually assign each client with a unique dynamic IP address, which changes when the client’s lease for that IP address has expired. There are numerous companies who are still using DHCP for IPv4 on their routers/switches. Most routers/switches have the ability to provide the following DHCP server support.

If you are not aware, devices will automatically get IP address from DHCP server when it connected to network. There are two types of IP address allocation including static and dynamic (DCHP). However, when devices share the same IP address from DHCP server, this cause IP address conflict and will getting the error prompt an IP address conflict detected. This issue indicates this IP conflict issues are caused by bad addresses on DHCP server.

This issue can be occurred due to IP address allocation conflict issue on DHCP server. For example, an organization is working on different project and each project may contains 50 users, so while creating DHCP scope for that project 50 IP range will be created, first and last IP address are automatically omitted by DHCP server and remaining IP address are automatically allocated to the system by DHCP server.

IP will stay in system and again when the DHCP server tries to allocate IP within the range, the same IP address will allocate to some other system and this will cause IP address conflict. DHCP server detects the conflicts by pinging an IP address before offering that address to clients. It is possible to fix the issue with our instructions. Let’s go for the solution.

How to fix bad address entry on a DHCP server?

Method 1: Stop DHCP server

This issue can be occurred if someone has setup another DHCP server on the network. You can fix the issue by stopping DHCP server.

Step 1: On DHCP client computer, type ‘cmd’ in Windows Search Box and press ‘SHIFT + ENTER’ keys on keyboard to open ‘Command Prompt as Administrator’

Step 2: Type the following command and hit ‘Enter’ key after each to execute.

ifconfig /release

ifconfig /renew

ifconfig /all

Step 3: Look for IP of DHCP server it is using, that’s your culpit.

Method 2: Enable DHCP server Conflict Detection

Step 1: Open ‘DHCP Snap-in’ and right-click on ‘DHCP’, and select ‘Add Server’

Step 2: Type in the name of DHCP server you want to target and click ‘Ok’ button

Step 3: Right-click on the server in left pane, and select ‘Properties’

Step 4: Click ‘Advanced’ tab and enter the number of ping attempts beside Conflict Detection Attempts.

Method 3: Look for DHCP Logs

Step 1: Log into DHCP server and start DHCP MMC console

Step 2: Expand the DHCP server instance we are wanting to audio and expand the IPv4 list

Step 3: Right-click on IPv4 and select ‘Properties’. Under ‘General’ tab, check ‘Enable DHCP Audit logging’ to enable auditing.

Fix Windows PC issues with ‘PC Repair Tool’:

‘PC Repair Tool’ is easy & quick way to find and fix BSOD errors, DLL errors, EXE errors, problems with programs/applications, malware or viruses infections in computer, system files or registry issues, and other system issues with just few clicks.

Conclusion

I am sure this post helped you on How to fix bad address entry on a DHCP server with easy ways. You can read & follow our instructions to do so. That’s all. For any suggestions or queries, please write on comment box below.

Источник

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

I have a scope of 150 addresses and it is constantly getting filled with BAD_ADDRESS which causes the scope to be full and not have any addresses to give out..

I’ve run the roque server check and there are none. I’ll delete all the «BAD_ADDRESS» entries and within 10 minutes they will be back..

Looking in the DHCP log it has the router over and over like it’s requesting an IP address??

10,08/17/12,00:27:47,Assign,192.168.1.163,main.abcinc.com,636973636F2D303031392E353630342E616163392D4769302F31,,1746141184,0,,,
13,08/17/12,00:27:47,Conflict,192.168.1.163,BAD_ADDRESS,,,0,6,,,

Some info:

Not a new network. I guess this issue has been happening for years (so she says).. She goes in every day and clears out the «BAD_ADDRESS» so users can get an address to get on the network..

Lease is limited to 1 day.

Scope is 192.168.1.100 — 192.168.1.250.. Today I found that there was a wireless access point (not doing DHCP) with a static address of 192.168.1.250 so I changed the scope to end at 1.249..

No other devices that I checked had DHCP enabled (checked the router, the switches (that I knew of), the WAP, and other servers).

There are static addresses for printers and servers and a few PC’s.

There is an IP Phone VLAN but this DHCP server doesn’t serve those. It does, however, have a scope option of «150 PHONE TFTP» that appears to be for Cisco Callmanager..

Server is on same subnet as clients.

I would harbor a guess of: use has bridged their wireless to the internal nic and the DHCP server is seeing its own IP check and marking it bad. Had this at several customers.

9/10 this is because at home they want to share the work network with a Phone or are trying to use the laptop as a wireless AP at home.

I did see in DHCP the same computer name with two IPs and figured one was just on the wifi network and one was on the wired network (both subnet)..

I’m not sure how this would cause an issue though because I do this at work as well.

Thanks for the reply.

Can you ping the bad addresses? That’s all Windows should be doing before handing out a lease, so if it’s marking them bad it’s getting a ping reply back.

No, the addresses aren’t pingable..

Then you need to figure why the server thinks they are. Maybe install Wireshark on it and let it run the next time you clear out the bad addresses and see if it catches any clues.

I have installed and run wireshark on it.. It’s really not leading me to anything.. I’ll post a capture tomorrow.

Here’s a wireshark screen.. I can provide the actual file if someone is willing to look at it..

I really think you have a loop some place. Do you have wireless in the building? The duplicate frames with the same Transaction ID indicate it. If you do have wireless try unplugging it and seeing if the issue «automagically» goes away. If so someone bridged a wired and wireless adapter in their computer or some other form of a wireless loop.

They do have a Cisco Aironet 1130AG AP..

Also, in DHCP I see (2) workstations that have (2) IP addresses each. I’m assuming their wireless adapter has one and the physical has the other.. I don’t see that as being an issue, right? I mean, at the office here I often get on the network with both my wifi and ethernet..

I’ll have to contact them regarding taking down their wifi for a few..

Can you explain to me what you’re thinking is the issue with the bridged adapter?

Thanks for the help.

Windows can bridge network adapters, this is not the same as having 1 workstation with 2 addresses (one for the WLan and the other on LAN.) A bridge bonds the 2 network adapters together and makes them appear as one. Simple example: If you have 2 LAN connections and bridge them together, you could then plug a laptop in to port 2 and connect to the same network as the workstation. With wireless this results in a network loop when the wireless NIC connects to the AP and the cable is plugged in to the wall. The issue with the wireless is that the loop is often throttled by the fact that wireless is much slower and error prone than wired. This means the loop may not take the network down.

The issue is the DHCP servers conflict detection method can see the address it just assigned due to wireless latency. IE the broadcast goes out and the wired port sees it, responds and accepts that address and then sees the request come in again (via wireless) where the adapter announces it has that address causing the bad address issue.

Ways to fix it: Enable spanning tree and 90% of the time the wireless will get knocked off the network (port will go in to blocking) or the other 10% of the time the end users cable will get dropped. Most switches will tell you which STP token was received (includes the port ID) so you have the port to locate the user.

DHCP guard: Protects the ports from the loops but doesn’t resolve the loop.

Give wireless another IP range entirely. A loop will cause odd issues like people getting IP address for the wired range (again DHCP Guard is really handy here) but it won’t take the network down.

Hope this answers the question… I am bit brain dead this morning.

Thank you for the explanation..

I’m a little confused though.. Say PC1 has a bridged adapter.. It plugs in via ethernet and gets an address.. It then connects to the wifi and requests an address but the wired says it has it.. Wouldn’t it just go to the next available and actually get the address?

I delete all the bad addresses and within minutes the pool of over 100 free addresses gets filled up with the bad_addresses.

Thank you for the explanation..

I’m a little confused though.. Say PC1 has a bridged adapter.. It plugs in via ethernet and gets an address.. It then connects to the wifi and requests an address but the wired says it has it.. Wouldn’t it just go to the next available and actually get the address?

I delete all the bad addresses and within minutes the pool of over 100 free addresses gets filled up with the bad_addresses.

Yes and no. In a bridge you have a cable loop, this means there are two paths to that adapter and 2 sets of broadcast frames appear. The first set the adapter accepts the IP on the second set of requests the adapter says «hey I have this address.» The DHCP server will mark the address bad because it thinks a device out there has the IP and that IP is not in its internal list so it must have been assigned «somewhere else.»

With wireless the second set are typically delayed due to latency / retransmits etc.

I would recommend that you go read about «broadcast storms» and what happens on a looped Ethernet network.

http://computer.howstuffworks.com/lan-switch13.htm

Just remember that wireless is lossy and has latency so tends to «control» the storm and not take the entire network down like a true cable loop would.

Also, in the DHCP server log, it shows the router doing the requesting.. Is that normal?

10,08/20/12,00:29:26,Assign,192.168.1.105,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:26,Conflict,192.168.1.105,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:30,Assign,192.168.1.107,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:30,Conflict,192.168.1.107,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:31,Assign,192.168.1.108,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:31,Conflict,192.168.1.108,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:32,Assign,192.168.1.109,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:32,Conflict,192.168.1.109,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:33,Assign,192.168.1.110,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:33,Conflict,192.168.1.110,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:34,Assign,192.168.1.111,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:34,Conflict,192.168.1.111,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:35,Assign,192.168.1.115,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:35,Conflict,192.168.1.115,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:36,Assign,192.168.1.116,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:36,Conflict,192.168.1.116,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:37,Assign,192.168.1.117,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:37,Conflict,192.168.1.117,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:38,Assign,192.168.1.118,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:38,Conflict,192.168.1.118,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:39,Assign,192.168.1.119,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:39,Conflict,192.168.1.119,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:40,Assign,192.168.1.120,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:40,Conflict,192.168.1.120,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:41,Assign,192.168.1.121,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:41,Conflict,192.168.1.121,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:29:42,Assign,192.168.1.125,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4246732800,0,,,
13,08/20/12,00:29:42,Conflict,192.168.1.125,BAD_ADDRESS,,,0,6,,,
30,08/20/12,00:30:20,DNS Update Request,192.168.1.224,PC2.abc.com,,,0,6,,,
11,08/20/12,00:30:20,Renew,192.168.1.224,PC2.abc.com,001E4FDCEDAC,,3203546719,0,,,
32,08/20/12,00:30:20,DNS Update Successful,192.168.1.224,PC2.abc.com,,,0,6,,,
10,08/20/12,00:30:46,Assign,192.168.1.126,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4263510016,0,,,
13,08/20/12,00:30:46,Conflict,192.168.1.126,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:30:47,Assign,192.168.1.148,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4263510016,0,,,
13,08/20/12,00:30:47,Conflict,192.168.1.148,BAD_ADDRESS,,,0,6,,,
10,08/20/12,00:30:48,Assign,192.168.1.149,MainRouter.abc.com,636973636F2D303031392E353630342E616163392D4769302F31,,4263510016,0,,,
13,08/20/12,00:30:48,Conflict,192.168.1.149,BAD_ADDRESS,,,0,6,,,
14,08/20/12,00:30:48,Scope Full,192.168.1.0,,,,0,6,,,

And another question.. Is there anyway (wireshark, logs, etc) to find out what PC(s) (mac address) is / are causing this?

If the router’s doing the requesting that means it has an «ip helper» (e.g. DHCP forwarding) enabled so the requests are really coming from the other interface.

I’ve looked in the router, switch, and ASA and can’t find anything related to an IP helper.. I searched for «Help» in the configs of all three.. Nothing..

What I did find, may / may not be something, is on the router (which is what is in the DHCP logs over and over):

!
interface GigabitEthernet0/1
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address dhcp
ip inspect SDM_LOW out
ip virtual-reassembly
ip tcp adjust-mss 1452
no ip mroute-cache
duplex auto
speed auto
!

Then it looks like it’s just the router asking for an address for that interface and the DHCP server going through the list to find the next truly free one and marking all of those that ping as bad until it finds one open. But it never gets to that point because all of the available addresses in that pool ping.

But none of the addresses ping.. They are all open.. I still think that may be the issue because I’m not sure why that interface would be requesting DHCP at all..

Are you doing DHCP in other scopes? IE the DHCP server is 192.168.1.10 but you are giving ips to 10.10.10.0/24? Whatever MainRouter.abc.com is it seems to be requesting addresses. It might just be a casualty…

I believe I got it.. I had one of our network admins change that interface to no ip instead of DHCP and the bad_address hasn’t appeared back, yet..

Thanks again for all the help fellas..

I believe I got it.. I had one of our network admins change that interface to no ip instead of DHCP and the bad_address hasn’t appeared back, yet..

Thanks again for all the help fellas..

That may stop the request(s) from the router from causing the DHCP server to ping all of them, but it doesn’t explain why the DHCP server thinks they’re all responding to ping.

That may stop the request(s) from the router from causing the DHCP server to ping all of them, but it doesn’t explain why the DHCP server thinks they’re all responding to ping.

As long as all the addresses aren’t taken up and users can get on they’ll be happy..

What are you suggesting on the second part?

As long as all the addresses aren’t taken up and users can get on they’ll be happy..

What are you suggesting on the second part?

If a DHCP request from a PC comes in won’t it cause the same thing to happen?

The DHCP server would hand out addresses to devices when it had addresses to give out.. The problem was the BAD_ADDRESS would fill up all available IPs.. When they were cleared out the machine(s) were able to get on..

The fact that the DHCP server logs had the router as the device doing the requesting and then following up with the bad_address in the log makes me believe it was the router, and only the router, that was the issue..

Also the fact that the subinterface on the router had DHCP enabled but didn’t have an IP address also backs up what I’m thinking was that it kept trying to request and address but didn’t get one (which matches up with the logs).

The router itself wasn’t forwarding requests via IP helper so I think just that sub interface being setup as DHCP was the issue.. Why Windows wouldn’t give it one and instead marked all those as bad I have no idea and would love an explanation.

Advertising
Cookies Policies
Privacy
Term & Conditions

This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Источник