How an Access Point Finds Its Controller

Dynamic Host Configuration Protocol (DHCP) option 43 carries vendor-specific information whose meaning the vendor named in option 60 defines, so the same option holds binary addresses for one access point and text for another, while a third reads its controller from option 138 instead. After reading, you can build and decode the value each documented vendor expects byte by byte, get the server to return it to the right vendor class, recognise the silent failure and the rogue-server risk, and read the value back from a capture or a DHCP server.

View as Markdown

A new access point (AP) must find its wireless controller before it can serve anyone, and the Dynamic Host Configuration Protocol () reply that gives it an address (the lease lifecycle) can name the controller too, in option 43. (RFC) 2132 leaves the option's contents to the (RFC 2132, section 8.4), so bytes one AP reads as two controller addresses mean nothing to another. By the end you can build and decode each vendor's value, from a type-length-value (TLV) block of binary addresses to a plain string; match the vendor class identifier (VCI); name the other routes to a controller; explain the silent failure and the rogue-server risk; and read a value back.

A container the vendor fills

RFC 2132 makes option 43, Vendor Specific Information, an opaque object of n octets, minimum length 1, and on meaning gives only a pointer (RFC 2132, section 8.4): "The definition of this information is vendor specific. The vendor is indicated in the vendor class identifier option." That identifier is option 60 (section 9.13). Several items SHOULD travel as encapsulated options in DHCP's own tag and length format (sections 8.4 and 2), the format the DHCP options article decodes, where "Codes other than 0 or 255 MAY be redefined by the vendor" (section 8.4). A single value may travel bare.

RFC 3925 names the consequence: "The vendor identified by option 60 defines the interpretation of option 43, which itself carries no vendor identifier" (RFC 3925, section 1). Kea's manual shows, from a real configuration, two vendor classes giving option 43 incompatible meanings (Kea 3.2.1 manual, section 8.2.13), and network boot relies on the same two options. The Internet Assigned Numbers Authority () registry has the codes (IANA registry):

43,Vendor Specific,N,Vendor Specific Information,[RFC 2132]
55,Parameter List,N,Parameter Request List,[RFC 2132]
60,Class Id,N,Class Identifier,[RFC 2132]
124,V-I Vendor Class,,Vendor-Identifying Vendor Class,[RFC 3925]
125,V-I Vendor-Specific Information,,Vendor-Identifying Vendor-Specific Information,[RFC 3925]
138,OPTION_CAPWAP_AC_V4,N,CAPWAP Access Controller addresses,[RFC 5417]
224-254,Reserved (Private Use),,,

How the access point asks

A client lists the options it wants in option 55, the parameter request list (RFC 2131, section 3.5). Control And Provisioning of Wireless Access Points (CAPWAP), whose Wireless Termination Point (WTP) is the AP and Access Controller (AC) the controller, requires the WTP to request option 138 there (RFC 5417, sections 1 and 2). Option 60 names the client's class: "the parameters MUST be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server" (RFC 2131, section 4.3.1), and the server "MUST omit any parameters it cannot provide" (section 4.3.1). A string one character off still gets a lease, minus option 43.

VCIs are per model: Cisco's table gives Cisco AP c1530 for the Aironet 1530 Series (Cisco document 97066). Extreme gives HiPath AP3965 for an AP3965e and WingAP.AP410 for an AP410i (Extreme, vendor class on Windows), then AP410 for the same AP (Extreme, option 43 on Windows); only one can match, and a capture shows which.

Aruba checks the reply too. Campus APs send ArubaAP (Aruba, AOS-8 campus); unified APs send ArubaInstantAP, and the server can switch one to campus mode by returning option 60 as ArubaAP with option 43 (Aruba, AOS-8 unified). Either way (Aruba, Option implementation): "If the correct option 60 value is not present in the DHCP offer and acknowledgement with the vendor-specific option, the AP will ignore it."

What each vendor puts inside

An address goes in as four binary bytes or as text in (USA Standard Code for Information Interchange):

Vendor	Option, sub-option	Address as	Several
Cisco	43, `f1` (241)	4 binary bytes	yes
Ruckus	43, `06` SmartZone, `03` ZoneDirector	ASCII text	one shown
Ubiquiti UniFi	43, `01`, or `02` (inform address)	4 binary bytes, or text	both in one
Extreme	43, `01`, type text	ASCII text	comma list
Aruba	43, no sub-option	ASCII text	one shown
Lightweight Access Point Protocol (LWAPP), historic	43, no sub-option	ASCII text	comma list
Fortinet FortiAP	138 by default	4 binary bytes	yes, in order

Cisco's rule (Cisco document 97066): "Type is always the suboption code 0xf1. Length is the number of controller management IP addresses times 4 in hex." The addresses follow in hex, and IOS takes option 43 hex <hexadecimal string>, dots allowed (f104.c0a8.010a). Cisco also documents f2, which converts APs to CAPWAP mode (size 4 per address plus 1), and f3 (243), whose last byte picks Meraki (01) or Catalyst (02); APs running -XE 17.15.2 or later also read the address from f3.

Ruckus writes option 43 hex aabb[variable code], aa being 03 or 06, typically 06 for SmartZone, and "bb = length of the IP address including the “.” characters in Hex" (Ruckus, article 000008703); 03 is ZoneDirector's in a Ruckus team member's post (Ruckus forum, secondary source). UniFi's rule is "Start with 0104, then add your static IP (encoded in hex)."; its fully qualified domain name () method, sub-option 02, carries a length and an inform address in text, and both may share one option (Ubiquiti, Remote Adoption (Layer 3)).

Extreme: "The option 43 sub-option code for the ExtremeWireless APs is type 1 (0x1)." Its dhcpd example declares it as text and lists two controllers in one string (Extreme, option 43 on Linux):

option space HAP;
option HAP.HWC code 1 = text;
class "HAP" { match option vendor-class-identifier; }
subclass "HAP" "AP3935" { vendor-option-space HAP; option HAP.HWC "10.100.2.36, 10.100.2.22"; }

Aruba's option 43 is a String, the mobility controller's address (Aruba, AOS-8 campus). LWAPP sent "A comma-delimited, ASCII-encoded list of AC IP addresses" (RFC 5412, section 3.3.2), but RFC 5412 is Historic, its mechanisms obsoleted by CAPWAP, a status the RFC series explains. A FortiAP reads option 138 by factory default (Fortinet, authorising FortiAP units), hex addresses concatenated in order of priority, and "you can use a different option number if you configure the AP units to match", as with cfg -a AC_DISCOVERY_DHCP_OPTION_CODE=139 (Fortinet, controller discovery).

The vendors' own examples, in their numbers:

Cisco     192.168.10.5 and 192.168.10.20   f108c0a80a05c0a80a14
Ruckus    192.168.1.120                    060d3139322e3136382e312e313230
UniFi     192.168.3.10                     0104c0a8030a
UniFi     http://192.168.3.10:8080/inform  02 1f, then 31 bytes of text
Aruba     10.0.2.15                        the string itself
Fortinet  192.168.0.1                      C0A80001, in option 138

Two controllers, byte by byte

The examples use 192.0.2.10 and 198.51.100.20. Binary is four bytes in network byte order (RFC 2132, section 2). Text is one 8-bit byte per 7-bit ASCII character, and RFC 20 puts digits in column 3, rows 0 to 9, hence 30 to 39, the full stop at 2/14 (2e), the comma at 2/12 (2c) and the space at 2/0 (20) (RFC 20, opening note and sections 2 to 4). Ten is 0a in binary, 31 30 in text; the ASCII table explorer lists every code.

                 binary          text
192.0.2.10       c0 00 02 0a     31 39 32 2e 30 2e 32 2e 31 30            (10 characters)
198.51.100.20    c6 33 64 14     31 39 38 2e 35 31 2e 31 30 30 2e 32 30   (13 characters)

Each option is its tag, then a length counting what follows:

Cisco, one           2b 06 f1 04 c0 00 02 0a
Cisco, two           2b 0a f1 08 c0 00 02 0a c6 33 64 14
UniFi                2b 06 01 04 c0 00 02 0a
Ruckus SmartZone     2b 0c 06 0a 31 39 32 2e 30 2e 32 2e 31 30
Ruckus ZoneDirector  2b 0c 03 0a 31 39 32 2e 30 2e 32 2e 31 30
Extreme, two         2b 1b 01 19 31 39 32 2e 30 2e 32 2e 31 30 2c 20
                                 31 39 38 2e 35 31 2e 31 30 30 2e 32 30
Aruba                2b 0a 31 39 32 2e 30 2e 32 2e 31 30
LWAPP, two           2b 19 31 39 32 2e 30 2e 32 2e 31 30 2c 20
                           31 39 38 2e 35 31 2e 31 30 30 2e 32 30
Option 138, two      8a 08 c0 00 02 0a c6 33 64 14

Two Cisco controllers give a sub-option length of 2 × 4 = 8 and an option length of 10; Ruckus counts the dots, 10 characters; Extreme's 192.0.2.10, 198.51.100.20 is 25 characters, 19. Option 138's length "MUST be a multiple of four (4)" (RFC 5417, section 2). In Cisco IOS the pair is option 43 hex f108c000020ac6336414; in dhcpd, option 138 is option capwap-ac-v4 192.0.2.10, 198.51.100.20; (dhcp-options(5)).

When option 43 is absent: the other ways in

CAPWAP expects a WTP and its AC to sit frequently in different subnets, and requires discovery that does not depend on multicast (RFC 5415, section 3.3). Discovery Requests go to 255.255.255.255, 224.0.1.140 or a unicast AC address, all of which ACs MUST accept; a pre-configured AC skips discovery, and DNS service records () such as _capwap-control._udp.example.com are optional (section 3.3). Options 124 and 125 remove the ambiguity: each starts with an IANA enterprise number naming the vendor (RFC 3925, sections 1 and 2).

A FortiAP cycles through static, DHCP, DNS (fortinet-capwap-controller plus the option 15 domain), FortiManagement Cloud (apctrl1.forticloud.com, over HTTPS), multicast and broadcast; multicast to 224.0.1.140 crosses broadcast domains with multicast routing, broadcast does not (Fortinet, controller discovery); see multicast and FortiAP deployment. An Extreme AP reuses its last controller, then tries options 60 and 43, DNS for Controller.domain-name and the Service Location Protocol (SLP) (Extreme, AP discovery). UniFi can use the DNS name unifi (Ubiquiti, Remote Adoption (Layer 3)); a Juniper Mist AP takes only its address from DHCP, then finds the Mist cloud by DNS and connects over HTTPS (Juniper, AP45 onboarding). For a server on another subnet, see the DHCP relay agent.

Why nothing reports the failure

Servers ignore vendor information they cannot interpret, and "Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it" (RFC 2132, section 8.4); a class mismatch drops the class options silently (RFC 2131, section 4.3.1). The lease completes, so nothing in the exchange signals the fault. Nor are the bytes checked: "Kea's ability to validate data correctness in hexadecimal is limited" (Kea 3.2.1 manual, section 8.2.10). Binary where text is expected, or the reverse, is still valid DHCP; in MikroTik's notation '10.10.10.10' is 0x0a0a0a0a and s'10.10.10.10' is 0x31302e31302e31302e3130 (MikroTik, DHCP).

The AP moves on. A FortiAP without a controller changes discovery type after about 3 to 15 seconds until broadcast fails and it sulks (Fortinet, controller discovery). In CAPWAP, after MaxDiscoveries requests (default 10) spaced under MaxDiscoveryInterval (default 20 seconds) (RFC 5415, sections 4.8.5 and 4.7.10), "the WTP enters the Sulking state and MUST wait for an interval equal to SilentInterval before sending further Discovery Request messages" (section 5.1); SilentInterval defaults to 30 seconds (section 4.7.13).

Size is the last limit: an option holds 255 octets, longer ones being split and concatenated (RFC 3396, Abstract), so a Cisco-style option fits 63 controllers in 254 octets.

A rogue server and the defences

RFC 2132's security section reads "Security issues are not discussed in this memo" (RFC 2132, section 13). RFC 5417 describes the attack: if an adversary modifies or inserts a DHCP response, "a WTP could be led to contact a rogue CAPWAP AC, possibly one that then intercepts call requests or denies service" (RFC 5417, section 5). The exchange is, in most networks, neither integrity protected nor origin authenticated; CAPWAP MUST authenticate its peers with Datagram Transport Layer Security (), and in sensitive networks "the options defined in this document SHOULD NOT be the only methods used to determine to which AC a WTP should connect" (section 5).

Switches can stop the rogue server: on Junos, "Untrusted ports drop traffic from DHCP servers to prevent unauthorized servers from providing any configuration information to clients.", and access ports are untrusted by default, trunks trusted (Juniper, trusted DHCP servers), the two roles of VLANs and 802.1Q trunking. On the controller, a FortiGate manages a FortiAP only once an administrator authorises it; automatic authorisation is disabled by default (Fortinet, authorising FortiAP units).

Reading a value back

DHCP uses UDP ports 67 and 68 (RFC 2131, section 4.1). tcpdump's -X prints hex and ASCII, so a text encoding shows its address in the ASCII column (tcpdump(1)); port matches either direction (pcap-filter(7)):

tcpdump -n -v -X -i eth0 udp port 67 or udp port 68

Wireshark's DHCP fields (Wireshark DHCP fields) and contains operator (wireshark-filter(4)) give these display filters, which tshark applies to a file with -Y (tshark(1)); the file name is illustrative:

dhcp.option.type == 43
dhcp.option.type == 138
dhcp.option.request_list_item == 43
dhcp.option.vendor_class_id contains "HiPath"

tshark -r ap-boot.pcapng -Y "dhcp.option.type == 43" -O dhcp
tshark -r ap-boot.pcapng -Y "dhcp.option.vendor_class_id" -T fields -e dhcp.option.vendor_class_id

The AP's DHCPDISCOVER or DHCPREQUEST should carry option 60 (3c) and list 2b or 8a in option 55 (37); the DHCPOFFER or DHCPACK carries 2b, a length and the value. Illustrative, the Cisco pair in an offer:

2b              option 43, Vendor Specific Information
0a              option length: 10 octets follow
f1              sub-option type 0xf1 (241)
08              sub-option length: 2 controllers x 4
c0 00 02 0a     192.0.2.10
c6 33 64 14     198.51.100.20

To decode, drop 2b and its length. A documented sub-option followed by a length equal to the bytes left is a TLV; 30 to 39 with 2e, and 2c 20 in lists, are text; four arbitrary bytes per address are binary. Aruba's 31 39 32 2e ... read as a TLV gives sub-option 31 and length 39, 57, with 8 bytes left: wrong as a TLV, right as text.

dhcpd can store each client's VCI with its lease, which shows the exact string (dhcp-options(5)); Windows Server keeps the VCI as a vendor class's data and reads values back by class (Microsoft Learn, Add-DhcpServerv4Class; Microsoft Learn, Get-DhcpServerv4OptionValue). The vendors' examples:

set vendor-string = option vendor-class-identifier;

Add-DhcpServerv4Class -Name "MSUCClient" -Type Vendor -Data "MS-UC-Client"
Get-DhcpServerv4OptionValue -ComputerName "dhcpserver.contoso.com" -ScopeId 10.10.10.0 -VendorClass MSUCClient

The DHCP option 43 generator builds each vendor's value with a byte breakdown and lines for dhcpd, Cisco IOS, Windows Server and MikroTik, warning about option 60, strings and option 138; its Cisco pair matches Cisco's f108c0a80a05c0a80a14, and its FortiAP output is option 138. Check its Ruckus and Extreme output against the rules above, and give an Aruba reply option 60 ArubaAP. The Base64, Base32, Hex & Percent Codec turns hex back into characters; the Python playground reproduces these bytes.

What to remember

Option 43's meaning belongs to the vendor named in option 60, and the option carries no vendor identifier, so one number holds incompatible formats.
Cisco f1 and UniFi 01 04 carry binary addresses, Ruckus 06 or 03 and Extreme's sub-option 1 carry text, Aruba sends a bare string, and FortiAP reads option 138 by default, under a changeable code.
The AP asks in option 55 and names its class in option 60; class options come back only on an exact match, and Aruba's only beside option 60 ArubaAP.
A wrong value fails silently: the client SHOULD carry on, and the AP tries other methods until it sulks.
To decode, drop 2b and its length: a sub-option matching the bytes left is a TLV, 30 to 39 with 2e is text, four arbitrary bytes per address are binary.
DHCP is neither authenticated nor integrity protected, so a rogue server can steer an AP; DTLS peer authentication and untrusted DHCP access ports defend it.

Sources