Using BOOTP for custom network device with Windows clients

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

Reply to
Jim
Loading thread data ...

How about letting the Windoze box pick a zero-configuration address (local link net 169.254.x.y) and take another for the box?

There are some special rules for using the link-local addresses, but it seems suited for your job. The hardest problem is that it is not allowed to make zeroconf addresses show in any kind of name service, but in this case, it seems that the broadcast will do the required effect.

For details, see .

HTH

Tauno Voipio tauno voipio (at) iki fi

Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.