|
I'm debugging the client's DHСP code on winsock and after receiving DHCPACK I want to check the received IP for a conflict. But I don't know how to. Could someone help with example?
|
|
|
|
|
That would probably depend on what you mean by "conflict"?
|
|
|
|
|
I mean to check retrieved from DHCP server IP address is exist a some device in local network with same IP address or not. If exist I have to send DHCPDECLINE to DHCP server and request another IP address
|
|
|
|
|
What are you writing? This is all handled by the network stack, so a normal application wouldn't even know this was going on.
If the IP is already bound to the adapter, you have no way of knowing that because if you try to ping it using the easy and normal methods, you'll only get a response from your own machine, like "ping localhost".
If you try to do this before the IP is bound to the adapter, you don't have an IP yet, so you can't use the easy and normal methods here either because they rely on the IP already being set. So the only way to do this would be digging deeper into the network stack and crafting your own packets, and that take admin permissions to be able to do that. A normal user wouldn't be able to do that.
In the real world, DHCP servers can be setup to do this themselves, and it's also managed by reserving ranges of IP addresses for static allocation, "ad-hoc allocation", and other ranges for dynamic allocation. Today, you would be hard pressed to get an IP that was in use already from the server.
|
|
|
|
|
|
Well, that changes thing just a bit.
You cannot use a PING to see if something else is using the address. It requires a local IP address to work. After all, where would the target machine send the reply packet to if there's no IP?
I don't know how you're going to reliably do this. An ARP query is about the only way you can determine if an address is in use, but that's not guaranteed.
|
|
|
|
|
|
Like I said, it's not guaranteed to work in all cases.
For example, if the other device that has the IP Address doesn't talk to anything before you get the same address, the ARP request can fail to tell you the IP is being used.
|
|
|
|
|
|
Hi,
I have worked with and implemented a system service with the DHCP protocol. After you have received the DHCPACK you need to broadcast an ARP and make sure that no other node on the network has a claim to the address. You can use either the SendArp[^] or ResolveIpNetEntry2 function[^] to accomplish this.
I have a very complete understanding of the DHCP standards so if you have any questions feel free to contact me.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks. I've used the SendArp function
|
|
|
|
|
Eugene Pustovoyt wrote: Thanks. I've used the SendArp function
Nice.
Remember that DHCP is an honor system[^] and that there are no built-in security measures.
I researched and implemented a signed/encrypted DHCP protocol but it's completely non-standard and just something I was experimenting with. All of these old standards are garbage... and need to be replaced.
Oh... here's a pro tip: After you get your address offer and assign the address make sure to close the listening socket. Guess what happens if you leave a listening socket open for 12+ hours without reading the buffer? The socket buffers fill with 12 hours of whatever arrived at the listening port! I made this mistake in my first iteration. 
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks. I did.
In final I'll plan to used this code in the embedded application with hardware ethernet chip. It supports only a little count of sockets and I have to use a single socket for some sequence of tasks (DHCP, PING, SNTP etc).
|
|
|
|
|
I'm having trouble with my system and checked system files, only to find that the file wininet.dll in some unpronouncable folder is corrupted and couldn't be repaired.
So I went to find that folder location, starting with Windows/Winsxs, only to find thousands of subfolders! Many of them appear to contain system dlls, and apparently lots of different versions of the same dlls.
I could understand the need for keeping different versions of some system files - but 20K folders of files???
Is it normal to have so many? Or may that be another symptom, or even the cause of the problems I'm having? Could this be the work of a virus or other kind of malware? Or is that the result of Windows working 'normally' for a couple of years?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I this this is fairly normal - I have just over 15,000 subfolders in mine, and I installed from scratch about a year ago. I was reading someone ranting about this the other day, but I can't remember where now.
I did find this though: Clean Up the WinSxS Folder | Microsoft Docs[^]
|
|
|
|
|
Thanks, that article was rather informative - beyond the topic of the title. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Looks like you have rediscovered DLL Hell[^]. It's a real thing and still a problem in 2020 with no end in sight.
Best Wishes,
-David Delaune
|
|
|
|
|
What I mean is simple but a Google search on the above sentence returns everything that could possibly be senseless about it with the worst at the top.
Grammatically the "install" is the subject. And by the subject I mean nothing to do with "running" the direct object "program" but "installing" it; that's the active transitivity.
Compatibility mode as applied to an executable is determined by the OS on which one's running that executable, in this case, an installer. And I know there's an issue with what gets installed (doesn't "run").
The reason I ask, is because apparently Windows 10 and even Windows 8.1 and Windows 7 can elevate privileges for an installer ... or it can't. And I don't know what the criteria for automatic raising of this security level is nor do I really care. So, adding "best practices" into the mix, and obviously to avoid all the experimentation that has to be done as well as the cleaning up of any clean installing, a laborious tedium I can assure you, does anybody have any experience with this?
This is not a joke. I'm just trying to cut to the chase by avoiding confusion about whether the FAIL is Type I and Type II.
|
|
|
|
|
I have no idea what you're really asking. Perhaps if you described the problem you're having?
You could run an installer in Compatibility Mode but it would pointless. Hell, Compatibility Mode isn't really even used any more unless the software you're running is ridiculously old.
Elevation is only required for installers because of the locations they write to in the file system and the registry. For security reasons today, normal don't have admin access to their machines. They're not able to write to protected parts of the file system, like C:\Windows, or anything under HKEY_LOCAL_MACHINE in the registry. Even Admins, by default, don't run anything using their admin privileges. You have to explicitly launch the app "as administrator", or the app has to request elevation from Windows, and then you're prompted to OK the requested operation.
|
|
|
|
|
But here's the rub. And why I mentioned Win 7. I actually succeeded in installing a piece of hardware after an uninstallation/clean-install but reinstall using compatibility mode Windows 7 SP2. This (running the setup.exe, to unconfuse everybody) after complete run of program (post install with only Administrative rights) FAIL several times.
This after a tip I found, and like you screwed my eyes up at, which is telling me that a driver still needed to be manually dropped into the WOWSys folder. Sounds to me like the old Office disconnect OLEDB 32-bit/64-bit(not really 64-bit yet) deal-from-the-bottom-of-the-deck where the 64-bit library doesn't get registered or used without going to regsrver32 first.
Still doesn't make sense. But like Sergey's understanding of QA questions sometimes, I think not understanding is what help turns out to be. As long somethings works. Then the cheapest answer is the one I understand.
modified 15-Aug-20 16:07pm.
|
|
|
|
|
That made no sense at all. I have no idea what app/driver pack/whatever you're having a problem with.
|
|
|
|
|
RedDk wrote: driver still needed to be manually dropped into the WOWSys folder.
Sounds like an error in the installer. As soon as you find yourself having to drop 64 bit files into the 32 bit system folder (or vice versa) ... it's probably best to not use the software.
Best Wishes,
-David Delaune
|
|
|
|
|
From day one (two years it's seems now), the Computer Management console Device Manager treeview, under my named computer has displayed in the fourth-from-the-top position, "Display adapters" ... by the looks of it, a wide screen monitor ... BUT there's a slight interrupted edge beneath the LCD screen light-blue color which seems to be yellow in color.
The fact of the matter is that it looks like one of those YIELD signs (black/yellow triangle with exclamation mark) is lining up behind the monitor artwork slightly to the right but showing up front because the triangle is not completely obscured by that artwork.
So there's a yellow base-of-a-triangle peeking out beneath the "display". Before I ask why anyone would want to arrange these two objects in close proximity like this to indicate "Display Adapters" (a road sign and a monitor), I know that when a device has problems loading it's driver, the standard icon for YIELD, the yellow caution road sign is the symbol of choice.
I have devices that have icons in the tree that are wholly obstructed by that YIELD overlay and I know why they're that way. But a device that has no problems displays the artwork of an iconic wide display but with a yellow road sign behind it?
modified 16-May-20 18:59pm.
|
|
|
|
|
There's a monitor image with a display adapter card in front of it. The "yellow" part you see is the gold edge connector of the display adapter.
|
|
|
|
|
No joke?
That's all I needed to know. I was about to use the Windows Accessories magnifier. Or repost this in QA tagged as Win10 (but it seems like everything there is REALLY computer stuff).
Installing a new OS is always an adventure. It takes me years to actually run through all the procedures that get a new one up and in a state of "being" and I think the real reason is that my expectations are always changing.
Unlike sleuthing engine knocks using a half-inch-tipped screwdriver with the butt-end pressed to the opening of an ear, these shattered cam followers are not what they used to seem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
