NetKit

DHCP Option 43 Generator

betaCommunity-reported — verify on your own hardware

Build the DHCP option 43 value that points access points at their wireless controller, with the per-sub-option breakdown, the Cisco dotted hex, a per-vendor CLI, and a generic TLV builder for anything not covered.

Input

Encoding

One IPv4 address per line. Blank lines and lines starting with #, ! or // are ignored.

Option 138 is a raw list; option 43 is TLV-encoded

This is the single most common implementation error. Option 138 is a bare list of controller IPv4 addresses: two controllers are exactly 8 bytes with no header of any kind. Option 43 is TLV data, so the same two addresses become an f1 08 header followed by the same 8 bytes.

Right now option 43 is 10 bytes and option 138 is 8 bytes — the difference is the TLV header.

Vendor notes

documentedsub-option 241

Stated in first-party vendor documentation, but not reproduced on hardware here.

Sub-option 241 (0xF1) holds a raw IPv4 address list: the same bytes as option 138, but with a 0xF1 <length> header in front of them.

Source: Cisco IOS DHCP "option 43 hex" WLC example; Cisco WLC configuration guide — option 43 sub-option 0xF1 (241) carries a raw IPv4 address list

Option 43 value

Hex (bare)
f108c0a80101c0a80102
Hex (Cisco dotted)
f108.c0a8.0101.c0a8.0102
Hex (octets)
f1:08:c0:a8:01:01:c0:a8:01:02
Total bytes
10

Including the 2-byte TLV header

DHCP server configuration
ip dhcp pool WLC-APs
 option 43 hex f108c0a80101c0a80102
CLI: documentedWritten as a bare hex string on one line. IOS does not accept the dotted form here — strip the dots.

Source: Cisco IOS IP Addressing Services Command Reference — "option 43 hex"

Sub-option breakdown

CodeNameLengthValueDecoded
241 (0xf1)Controller IPv4 address list (Cisco WLC sub-option 241)8c0a80101c0a80102192.168.1.1, 192.168.1.2 — 2 × 4 bytes

Sub-option 241 (0xF1) is documented for Cisco and reproduced by other vendors in the wireless space; the length byte is the byte count of the address list, not the address count.

Generic TLV builder

For any vendor or sub-option not covered above — build the bytes from the code your AP expects

0–255, decimal

Hex, any separator: 3139322e3136382e312e31 or 31:39:32…

Hex (bare)
030b3139322e3136382e312e31
Hex (Cisco dotted)
030b.3139.322e.3136.382e.312e.31
Hex (octets)
03:0b:31:39:32:2e:31:36:38:2e:31:2e:31
Server configuration
ip dhcp pool WLC-APs
 option 43 hex 030b3139322e3136382e312e31

Parsed back: sub-option 3 is 11 byte(s) — 3139322e3136382e312e31

Export

Frequently asked

What is the difference between DHCP option 43 and option 138?
Option 138 (RFC 5417) is a raw list of controller IPv4 addresses with no header at all: two controllers are exactly eight bytes. Option 43 is TLV-encoded vendor data, so the same two addresses become f1 08 followed by the eight bytes. Mixing the two up is the most common failure in AP provisioning.
Why is the generated value marked needs-validation for Huawei, H3C and Ruijie?
Because we are not certain. Huawei examples show sub-option 3 as ASCII on some AC families and sub-option 241 as a binary list on others, and H3C and Ruijie vary the same way. We would rather show "verify this on your hardware" and give you a generic TLV builder than print a confident wrong byte sequence.
For an Aruba deployment, should I use option 43?
Usually not. ArubaOS APs discover controllers through DNS (arang-<domain>) or ADP multicast; option 43 is not the documented path. The tool generates a value for environments that require option 43 but labels it unverified.
Why does the length byte not equal the number of controllers?
Because it is a byte count, not a count of addresses. Cisco sub-option 241 wraps a raw IPv4 list, so two controllers give a length of 8, not 2. Getting this wrong makes the AP read garbage and either ignore the option or reboot in a loop.
Can I generate an option 43 value for a vendor that is not listed?
Yes — use the generic TLV builder. Enter the sub-option code and its payload, and the tool emits the code/length/value bytes and the matching DHCP server syntax, without claiming to know what your AP expects.

Verify before you deploy

Vendor-specific details here are community-reported rather than confirmed on hardware. Check them against your own platform before pushing configuration.

Next