Here's what worked for my Mitel phones (note that I used option 43):
"client-classes": [
{
"name": "mitel",
"test": "substring(option[60].hex,0,17) == 'ipphone.mitel.com'",
"option-def": [
{
"name": "vendor-encapsulated-options",
"code": 43,
"type": "string"
}
],
"option-data": [
{
"name": "vendor-encapsulated-options",
"data":
"id:ipphone.mitel.com;sw_tftp=10.151.75.34;call_srv=10.151.75.32"
}
]
},
From: Kea-users <[email protected]> On Behalf Of Evan Carson
Sent: Wednesday, November 6, 2019 4:00 PM
To: [email protected]
Subject: [Kea-users] Vendor-Identifying option 125 vivso-suboptions
Hello,
We are running Kea 1.4.0 and are having trouble getting the server to hand out
option 125 to a Mitel phone. The Kea server is replying to the client with this
data in the DHCP offer with an empty option 125 containing only the Mitel
enterprise option but no data.
We have this option definition specified in the Dhcp4 config:
"option-def": [
{
"array": false,
"code": 130,
"encapsulate": "",
"name": "mitel-option",
"record-types": "",
"space": "vendor-1027",
"type": "string"
}
],
We then placed this option in the subnet["pools"]["option-data"] for our phone
subnet
{
"name": "vivso-suboptions",
"data": "1027"
},
{
"name": "mitel-option",
"space": "vendor-1027",
"data":
"id:ipphone.mitel.com<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipphone.mitel.com&data=02%7C01%7CRobert.B.Sutherland%40windstream.com%7Cfe63ef71459047eeb95b08d762fc465b%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C1%7C637086707970887653&sdata=ybRRfpPu13cnOyzXLUV2ojFqrTIFjusuUu%2BijhCjs1s%3D&reserved=0>;sw_tftp=10.78.182.2;call_srv=10.78.182.2;vlan=71;l2p=6;dscp=46;"
}
Here is the DHCP Offer pcap coming back from server:
Frame 15952: 332 bytes on wire (2656 bits), 332 bytes captured (2656 bits)
Ethernet II, Src: RealtekU_e9:ea:63 (52:54:00:e9:ea:63), Dst: SmcStand_9c:c6:36
(08:00:0f:9c:c6:36)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x99cc086f
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.1.102
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
Client hardware address padding: 00000000000000000000
Server host name: KVM_128T_Remote
Boot file name not given
Magic cookie: DHCP
Option: (1) Subnet Mask
Option: (3) Router
Option: (6) Domain Name Server
Option: (51) IP Address Lease Time
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier
Option: (61) Client identifier
Option: (125) V-I Vendor-specific Information
Length: 5
Enterprise: Mitel, Corp. (1027)
Length: 0
Option: (255) End
It looks like the configuration for the enterprise ID is working correctly
however the custom "mitel-option" string doesn't seem to be contributing. Is
there anything wrong with the way we have this configured?
We aren't using any client-class configuration to restrict this option to only
the clients requesting a given Vendor-Identifying Vendor Class option. Is it a
requirement that the client-classification be used to specify the vendor class
option?
Thank you for your help,
Evan Carson
Sensitivity: Internal
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
