DHCP tftp option for Grandstream provisioning

Hi Everyone,

We’re accustomed to configuring the “tftp-server-name” DHCP option for use with zero config to provision Grandstream IP phones. We recently swapped out an EdgeRouter at a customer for an Mikrotik CCR, here we specified the IP in the DHCP option 150 (in hex) but it doesn’t appear to be working. We need to specify https and the port number, in the past we used a string in EdgeRouters for this functionality:

set service dhcp-server shared-network-name demo subnet 10.0.0.0/24 tftp-server-name https://10.1.1.60:8089

How can this be achieved with Mikrotik RouterOS?

Thanks in advance!

I think I have it configured correctly now:

/ip dhcp-server
add address-pool=dhcp_pool3 interface=br-sa-wifi lease-time=4h name=dhcp-sa-wifi
/ip dhcp-server option
add code=150 name=tftp-server value="'https://x.x.1.60:8089'"
/ip dhcp-server option sets
add name=grandstream options=tftp-server
/ip dhcp-server
add address-pool=dhcp_pool1 dhcp-option-set=grandstream interface=br-sa-asfo lease-time=4h name=dhcp-sa-asfo
add address-pool=dhcp_pool2 dhcp-option-set=grandstream interface=br-sa-ashv lease-time=4h name=dhcp-sa-ashv
add address-pool=dhcp_pool4 dhcp-option-set=grandstream interface=br-sa-mgmt lease-time=1h name=dhcp-sa-mgmt
/ip dhcp-server network
add address=xx.xx.50.0/24 dhcp-option=tftp-server dhcp-option-set=grandstream dns-server=xxx domain=xxx gateway=xx.xx.50.1
add address=xx.xx.52.0/23 dhcp-option=tftp-server dhcp-option-set=grandstream dns-server=xxx domain=xxx gateway=xx.xx.52.1
add address=xx.xx.54.0/23 dhcp-option=tftp-server dhcp-option-set=grandstream dns-server=xxx domain=xxx gateway=xx.xx.54.1
add address=xx.xx.56.0/22 dns-server=xxx domain=guest.vpco.org gateway=10.3.56.1

But I’m not seeing the option 150 when packet sniffing for DHCP offers on the desired networks:
Screen Shot 2022-03-24 at 11.12.52.png

RouterOS can send such DHCP options, but for now it can only do it when the device actually requests them.
That is how it should work as defined in the standard: devices send a list of options they want to receive, DHCP servers reply with the values of those options.
However, there has been a flood of buggy devices programmed by sloppy programmers, that expect to receive values for options they did not request.
It is a topic that has been discussed over and over and it appears that in RouterOS v7 the capability is being added.
However, don’t just upgrade to v7 just for that and without testing and evaluating it outside of the production environment!

Hi pe1chl,

Thank you for correcting me, I assumed all offers would include the option 150, but apparently only for the devices specifically requesting it. We will proceed by looking more in depth into the device, assuming the above configuration is correct.

We’re running the CCR1009 on 7.1, and thus far we haven’t encountered any issues.

On another topic, someone says than a terminal command can force dhcp to send wanted options on dhcp requests…
http://forum.mikrotik.com/t/feature-request-force-sending-of-dhcp-options-to-clients/84291/1

Force DHCP Server on RouterOS 7.1+ to send all DHCP Options specified on DHCP Network

ip/dhcp-server/option/set force=yes

You can also choose which option to pass (required or not) based on the “vendor” information passed from DHCP Request

/ip dhcp-server vendor-class-id
add address-pool=gigaset-pool name="Gigaset A510-IP" server=dhcp-main vid="A510_IP"

I did this, but I'm still not seeing the option 150 in my DHCP offers when running the packet capture again:

/ip dhcp-server option
add code=150 force=yes name=tftp-server value="'https://xx.xx.1.60:8089'"
/ip dhcp-server option sets
add name=grandstream options=tftp-server

FYI We're running 7.1.3 on an CCR1009.

I have not tested or used that version, but others say that works.

Why are you using a http url for a tftp address? RFC5859 states this needs to be an IP address (or multiple IP addresses) not a URL.

You need to convert each octet of the IP address to HEX and then set the option. For instance if I have two tftp servers: 192.168.6.1 and 10.1.1.1 it would be:

0xC0A806010A010101

nice catch @biomesh, i do not noticed that…

option 150 can contain only IP, not protocol or port,
option 66 can contain server name, but only the server name without protocol or port

Grandstream uses http/https for provisioning. And as stated in the OP. We always use a full string with https:// included and port, as that only seems to work. (proven in Windows and EdgeRouter DHCP environments).

I don’t have anything helpful to give.
When you wireshark sniff a windows/edgerouter setup, does it actually transmit the https://host:port in the clear or does it translate it into an IP address?

Ok, so apparently I was mistakenly using the wrong DHCP option, I’m suppose to use 66, not 150. But yes, it does send the string completely:
Screen Shot 2022-03-24 at 17.39.48.png

Option 66 is tftp server name not tftp server address(option 150). Using that option decodes correctly in wireshark when using a URL. You can use

https://192.168.1.1:8090
s’https://192.168.1.1:8090

I would use the packet sniffer from the router to make sure it is being sent. If wireshark decodes it, then the phone should be able to use it as long as it is in the format the phone needs.

Yes it’s working, similarly to the above screenshot. Thanks everyone!