We have an IP system that makes use of BOOTP for updating our embedded devices over IP. The main app uses DHCP for its IP configuration.

Our devices are usually on the network of the customer, the customer manages the network infrastructure. We provide a server machine that hosts a DHCP and BOOTP server, thus our ownership. Till recently we never had any issues. There's one customer where BOOTP communication doesn't work while DHPC is working perfectly between same endpoints. I wiresharked the interface of our server machine: BOOTP- packet isn't received. This while DHCP- is coming in OK. Both packets have ethernet-destination broadcast. Bot UDP on destination port 67. No firewall on our server machine. In fact DHCP is an extension of BOOTP.

If I tell this to the customer that I think their equipment is probably blocking this, I get a negative response. In my opinion there must be something - I believe a managed switch - that blocks this BOOTP packet. Does someone has any tips:

  1. Is it a common practice to block BOOTP on a managed enterprise network?
  2. How defend/elaborate this towards the customer in order to make him take (more) actions. Can I push him in the right direction, what to verify?
  3. Any other remarks suggestions, experiences...
  • network boot does offer the ability to bypass some enterprise security controls, by booting from an potentially unknown or unblessed image, so yes, many orgs that don't use network boot functionality might do well to disable it. – Frank Thomas Jan 14 '14 at 12:47
  • If your server isn't on the same IP network as your customers, then your server is only receiving DHCP because they had to specifically configure a 'helper ip address' on a router or host's network interface that is a member of the broadcast domain, such that when an unconfigured system sends a BOOTP/DHCP DISCOVER to the broadcast, the router(usually) can proxy that packet to the remote DHCP server, and broker the DISCOVER/OFFER/REQUEST/ACK transaction: The booting host won't have an IP address to be able to communicate with a remote server until the transaction's completed. ...cont... – Nevin Williams Mar 12 '14 at 1:30
  • If your customer is in charge of the network, then the onus is on them to have the helper IP proxy service configured properly. As I understand, you're able to process DHCP from the same physical network that you're not getting bootp DISCOVERs. The UDP transaction for DHCP is the same as for bootp, except DHCP packets have extra fields, and thus, are larger. Only a device that's processing packet contents could tell what's BOOTP or DHCP, which implies the router doing the helper-ip proxy for DHCP needs to be told to also do so for BOOTP, or there's a firewall with a DENY Bootp rule. – Nevin Williams Mar 12 '14 at 1:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.