Hello,
I have developed a network device (used in a private LAN environment, not public WAN -- simple stuff) and Windows client software that connects to it via TCP/IP to do application/device stuff. The Windows application user configures the IP address of the network device, and everything works fine.
Now I want to add the capability to auto-detect the network device, and offer the IP address as a configuration default in the Windows application setup. This should normally relieve the user from having to go find out what IP address was assigned to the network device.
I can implement a custom UDP messaging scheme to broadcast a device discovery message from the Windows application and let the network device identify itself, but the UDP broadcast packet will only reach the network device if it is on the same subnet.
Since routers will typically pass DHCP/BOOTP broadcast packets across subnets so the site does not have to install a dedicated DHCP server on each segment, I am tempted to use the BOOTP protocol to discover my network device. I would populate the BOOTP server name field with some device specific name so the packets would be ignored by real DHCP servers, and recognized only by my network device.
This raises a couple of questions.
If my network device sees the BOOTP request packet arrive at well known port 67, and responds to the Windows client IP address using port 68, I assume that packet will arrive at the Windows client PC. But will my application be able to listen on port 68 and actually receive that response packet, or will a Windows layer intercept all inbound packets on port 68 thinking that they are intended for Windows DHCP configuration?
I am running into more and more problems getting my existing application packets through new tighter firewall defaults on Windows PCs. Is a BOOTP response special? Should it get through the PC firewall? I assume that since the PC would have obtained its own IP address from the site DHCP server by the time my Windows application is run by the user, the firewall software could not have prevented the port 68 response from getting through. But perhaps the Windows firewall/DHCP client software is somehow smart enough to only let the port 68 response get through until the DHCP assignment is complete, and then locks down the port.
This is all speculation on my part. I plan to experiment with this the next few days. Any comments or fresh ideas are welcome.
Thanks.
Jim