Using BOOTP for custom network device with Windows clients

From: Jim (jfathman_at_aol.com)
Date: 09/30/04 

Date: 29 Sep 2004 15:35:05 -0700

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

Relevant Pages

  • Re: Using BOOTP for custom network device with Windows clients
    ... > I have developed a network device (used in a private LAN environment, ... > and offer the IP address as a configuration default in the Windows ... but the UDP broadcast packet will only reach ... > port 68, I assume that packet will arrive at the Windows client PC. ...
    (comp.arch.embedded)
  • Re: Network device
    ... No such thing as Windows CE 4.5. ... Each network device driver has its own ... settings wouldn't make sense for a wired Ethernet card). ... to set the speed of the embedded network device, ...
    (microsoft.public.windowsce.embedded)
  • Return ICMP port unreachable on nonlistening socket
    ... when somobody send packet to port where no server is listening. ... However Windows Vista Business SP2 behaves differently. ...
    (microsoft.public.windows.vista.security)
  • Re: Only some websites will open - Ubuntu
    ... I recently put together a new computer and installed Kubuntu ... However it MAY be to do with window sizes..in addition to the MTU - which is the MAX size of each data packet - there is a window size that is negotiated for a TCP connection..that specifies how much data can be sent without waiting for an ACK. ... I have no idea how t tune a Linux kernel for windows size tho. ...
    (comp.os.linux.misc)
  • Re: Return ICMP port unreachable on nonlistening socket
    ... when somobody send packet to port where no server is listening. ... However Windows Vista Business SP2 behaves differently. ... A drop message by the FW wouldn't be logged, as IPsec sits in front of the FW and blocks. ...
    (microsoft.public.windows.vista.security)