---
title: DHCPv4Packet type | Wartiva GraphQL API
description: A DHCP v4 packet header and options. Wartiva GraphQL API reference with arguments, fields, and examples. Browse related operations and types.
url: https://wartiva.com/api-docs/types/dhcpv4-packet.html
updated: 2026-10-07
---

Networks, devices, and sensors · GraphQL type

# `DHCPv4Packet` type

A DHCP v4 packet header and options.

## Fields

| Field Name | Description |
|---|---|
| `opcode` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Operation Code: Specifies the general type of message. A value of 1 indicates a request message, while a value of 2 is a reply message. |
| `hwType` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Hardware Type: Specifies the type of hardware used for the local network. |
| `hwAddrLen` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Hardware Address Length: Specifies how long hardware addresses are in this message, returned as an unsigned 8-bit integer. For Ethernet or other networks using IEEE 802 MAC addresses, the value is 6. |
| `hopCount` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Hops: Set to 0 by a client before transmitting a request and used by relay agents to control the forwarding of BOOTP and/or DHCP messages, returned as an unsigned 8-bit integer. |
| `transactionID` - [`Uint32!`](https://wartiva.com/api-docs/types/uint32.html) | Transaction Identifier: A 32-bit identification field generated by the client, to allow it to match up the request with replies received from DHCP servers. |
| `numSeconds` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Seconds: In BOOTP this field was vaguely defined and not always used. For DHCP, it is defined as the number of seconds elapsed since a client began an attempt to acquire or renew a lease, returned as an unsigned 16-bit integer. This may be used by a busy DHCP server to prioritize replies when multiple client requests are outstanding. |
| `flags` - [`Int!`](https://wartiva.com/api-docs/types/int.html) | Flags: this corresponds ti tge formerly empty two-byte field in the BOOTP message format defined by RFC 951, which was redefined as a Flags field in RFC 1542, returned as an unsigned 16-bit integer. The field presently contains just one flag subfield as follows: B - Broadcast Flag: a client that doesn't know its own IP address at the time it sends its request sets this flag to 1. This serves as an immediate indicator to the DHCP server or relay agent that receives the request that it should sends its reply back by broadcast. |
| `clientIPAddr` - [`IP!`](https://wartiva.com/api-docs/types/ip.html) | Client IP Address: The client puts its own current IP address in this field if and only if it has a valid IP address while in the BOUND, RENEWING or REBINDING states; otherwise, it sets the field to 0. The client can only use this field when its address is actually valid and usable, not during the process of acquiring an address. Specifically, the client does not use this field to request a particular IP address in a lease; it uses the Requested IP Address DHCP option. |
| `yourIPAddr` - [`IP!`](https://wartiva.com/api-docs/types/ip.html) | “Your” IP Address: The IP address that the server is assigning to the client. |
| `serverIPAddr` - [`IP!`](https://wartiva.com/api-docs/types/ip.html) | Server IP Address: The meaning of this field is slightly changed in DHCP. In BOOTP, it is the IP address of the BOOTP server sending a BOOTREPLY message. In DHCP, it is the address of the server that the client should use for the next step in the bootstrap process, which may or may not be the server sending this reply. |
| `gatewayIPAddr` - [`IP!`](https://wartiva.com/api-docs/types/ip.html) | Gateway IP Address: This field is used just as it is in BOOTP, to route BOOTP messages when BOOTP relay agents are involved to facilitate the communication of BOOTP requests and replies between a client and a server on different subnets or networks. See the topic on DHCP relaying. As with BOOTP, this field is not used by clients and does not represent the server giving the client the address of a default router (that's done using the Router DHCP option). |
| `clientHwAddr` - [`String!`](https://wartiva.com/api-docs/types/string.html) | Client Hardware Address: The hardware (layer two) address of the client, which is used for identification and communication. |
| `serverHostName` - [`String!`](https://wartiva.com/api-docs/types/string.html) | Server Name: The server sending a DHCPOFFER or DHCPACK message may optionally put its name in this field. This can be a simple text “nickname” or a fully-qualified DNS domain name. |
| `bootFileName` - [`String!`](https://wartiva.com/api-docs/types/string.html) | Boot Filename: Optionally used by a client to request a particular type of boot file in a DHCPDISCOVER message. Used by a server in a DHCPOFFER to fully specify a boot file directory path and filename. |
| `options` - [`[String!]`](https://wartiva.com/api-docs/types/string.html) | Options: Holds DHCP options, including several parameters required for basic DHCP operation. Note that this field was fixed at 64 bytes in length in BOOTP but is variable in length in DHCP. See the next two topics for more information. This field may be used by both client and server. |

## Used by

- [`DHCPv4`](https://wartiva.com/api-docs/types/dhcpv4.html) type: Dynamic Host Configuration Protocol (DHCP) service.

## Example

### Example

```json
{
  "opcode": 123,
  "hwType": 987,
  "hwAddrLen": 987,
  "hopCount": 987,
  "transactionID": "1073741824",
  "numSeconds": 987,
  "flags": 987,
  "clientIPAddr": "192.168.0.1",
  "yourIPAddr": "192.168.0.1",
  "serverIPAddr": "192.168.0.1",
  "gatewayIPAddr": "192.168.0.1",
  "clientHwAddr": "xyz789",
  "serverHostName": "xyz789",
  "bootFileName": "xyz789",
  "options": ["xyz789"]
}

```

---

Wartiva is in early access. Request access: https://wartiva.com/early-access.html  
All pages: https://wartiva.com/llms.txt