MiVoice Business Express as DHCP server

[acejavelin]

I have been working on a new installation of MiVB Express (the small MiCollab/3300 all in one VM) v7.0.0.102, and for the most part I have it working, but can't get DHCP to work for the phone from the server... Due to security constraints of the customer, the voice VLAN and data VLAN do not talk to each other, they are completely separate logically which is fine but I need DHCP services for the phones to be provided by MSL.

I had done this several times before on older versions with no issues, just add the options in DHCP and start the service and plug in phones and go, but with the latest version it is giving me nothing but problems. I set it up like always, and the options appear correct, but the DHCP service complains to no end with log entries like this repeated over and over:

2016-03-14 17:28:50.440072500 Internet Systems Consortium DHCP Server 4.1.1-P1
2016-03-14 17:28:50.440118500 Copyright 2004-2010 Internet Systems Consortium.
2016-03-14 17:28:50.440151500 All rights reserved.
2016-03-14 17:28:50.440180500 For info, please visit https://www.isc.org/software/dhcp/
2016-03-14 17:28:50.440987500 /etc/dhcpd.conf line 35: Bogus number id: digit 18 not in base 16
2016-03-14 17:28:50.441001500 option vendor.eid-1027 id:
2016-03-14 17:28:50.441012500                         ^
2016-03-14 17:28:50.441291500 /etc/dhcpd.conf line 35: expecting hexadecimal number.
2016-03-14 17:28:50.441304500 option vendor.eid-1027 id:ipphone.
2016-03-14 17:28:50.441313500                           ^
2016-03-14 17:28:50.441390500 /etc/dhcpd.conf line 35: semicolon expected.
2016-03-14 17:28:50.441402500 option vendor.eid-1027 id:ipphone.mitel.com;call_srv=10.
2016-03-14 17:28:50.441411500                                                         ^
2016-03-14 17:28:50.441477500 /etc/dhcpd.conf line 35: semicolon expected.
2016-03-14 17:28:50.441489500 option vendor.eid-1027 id:ipphone.mitel.com;call_srv=10.0.5.6;sw_tftp=10.
2016-03-14 17:28:50.441499500                                                                          ^
2016-03-14 17:28:50.444048500 Configuration file errors encountered -- exiting

Trying to setup Option 43 gives similar results, but I need 125 because we have several 5485 IP Page adapters.

Any thoughts?

[acejavelin]

Hmm... I deleted everything and rebuilt it all again, but this time I built option 125 as a 'text option' instead of the default of hex, and the service isn't crashing constantly. I can see the 5485's being offered an IP address in the Lease Viewer, but they don't seem to be accepting it (they are retying every 15 seconds or so) and they are not connecting to the MiVoice Business server. Progress is progress I guess.

[lundah]

I think 5485's have to use the old DHCP options 128-135.

[acejavelin]

I think 5485's have to use the old DHCP options 128-135.

Yeah, I had heard that too... Problem is the DHCP server is MSL doesn't have these anymore, and tech support doesn't think that is the issue (they said newer 5485's support 125, these are dated 37th week of 2015). I am still doing their simple things with VLAN tags and stuff at the moment, but I know that isn't the issue. The network is solid, if I manually put the info in the phones, they boot fine, if I take the info out, the get an IP in the native VLAN, jump to VLAN 6 and make the request, then say there is no option 125.

[Dutch]

My experience with the IP Page units is that I have to agree on the old options I am afraid. I did a rollout last december and I used the customers Windows DHCP to provide the service but with only the 125 option they wouldn't start up. When we added the old options the units work like a charm. The Cisco's they use let the phones auto hop and use 125 options and I believe they have the page units connected to untagged ports with a relay to the windows DHCP using the old options.

Since we are talking about the 5485 units, one issue I am currently having with these is that whenever they lose connection even though for less then a second, you have to manually hard reset them to restart them is my experience. I wish they would auto return to service like the normal phones do.

Also the environment I programmed them is a resilient environment and the units don't support resiliency. I tried to cheat with creating local-only units in order to make routes to the group pages the same in both controllers (this will make sure SDS doesnt crash on the group page buttons you see ) but even with a resilient operation I first need to reboot them to get them to work.

We are even looking into using analog relais in order to reset those units remotely if need be but maybe I am missing something