BOOTP [Malformed Packet]

Question

Hello Guys

I'm troubleshooting an issue where boop server responses are being dropped at some point in the topology In a capture taken from the interface where the bootp server is attached I see the below message:

428 Unknown BOOTP message type (0) [Malformed Packet]

I'm guessing it means corruption but can any of you let me know what it means o where can I find more information about it.

Thanks

Answer 1

The BOOTP protocol, as described by RFC 951, has an opcode field in it; the RFC specifies that it can either have the value 1 for a request and 2 for a reply. 0 is not a valid value for the opcode, so Wireshark reports the packet as having an unknown message type.

RFC 2131 describes DHCP; section 3 "The Client-Server Protocol" says

 DHCP uses the BOOTP message format defined in RFC 951 and given in
 table 1 and figure 1.  The 'op' field of each DHCP message sent from
 a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
'op' field of each DHCP message sent from a server to a client.

so, again, the only valid opcode values are 1 and 2.

Either a client is sending out a BOOTP/DHCP message with an invalid opcode, and no server is sending a reply to that, or the server is sending out the message with the invalid opcode, and the client is ignoring it.

Answer 2

BOOTP is the Wireshark name for DHCP. Both protocols run on the same UDP ports (67 and 68). DHCP is based on the BOOTP frame format and added a few option.

A DHCP or BOOTP message starts with a fixed block of parameters and is followed by a series of options. Each option is a tuple of a numeric identifier, a length and a value field.

Virtually every DHCP message should have the option 53 present. This is the message type. The majority of DHCP frames have a types of Discover, Offer, Request or Acknowledge, but there are more.

The error message indicates that the dissector encountered the option number 0. As Wireshark does not know about this option number you get your error message.

Either the frame was corrupted during transmission or the sender (or DHCP relay agent) has a bug in it's DHCP implementation. A tracefile or at least screenshot would grately aid my curiosity.

Good hunting.