New Mitel 5360 Won't Pull DHCP - All other phones ok.

[A D]

Have a HX5000 with about 70% older digital phones and about 30% IP phones, mostly 5340's. Recently needed another phone so I bought a 5360 refurbished. First thing I did was plug it in with 8+9 pressed then did a restore to defaults. Phone rebooted, found the server, and did a firmware update. After the update it rebooted again but now won't get past DHCP Discovery. Just says:

DHCP: Discovery
Using Options 43:43

We have a VLAN setup for phones and all phones come into the switch untagged and we tag them at that level. I have both options 43 and 125 set (identical). I tried turning one off, rebooting the phone, then switching them, rebooting the phone, but no change. All other IP phones are fine. So I checked the DHCP server and there is a lease in there for it's MAC address and it's valid from when it first connected to the network (for its update). Tried deleting the lease and rebooting the phone again but same thing, stuck in discovery. Eventually goes to "DHCP Timeout" and tries again.

Just for the heck of it I manually assigned it a IP address on that subnet and the phone came right up and went into Calibration mode. Afterward it worked fine. Did a reset to defaults again, same issue.

Any ideas?

 

[A D]

Little more info. Played around with it today and realized it IS pulling DHCP and a lease is being entered in for it but the phone doesn't seem to acknowledge it or use it. I can delete the lease, reset the phone, and see it come back up in DHCP but the phone just hangs on discovery.

 

[Billz66]

what options do you have configured in DHCP - have you added 43 - set it the same as 125

If I never did anything I'd never done before , I'd never do anything.....

 

[Valamagules]

Have you tried adding the ASCII string in the Data (native) VLAN

Clever men learns what Wise men shares!

 

[A D]

what options do you have configured in DHCP - have you added 43 - set it the same as 125

We have a mix of older and newer phones so everything from 86xx through this 5360. We have had both option 43 and 125 set for a while, both identical:

id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;l2p=6s3m4v6;dscp=46s24m34v46

I tried shortening it also to see if it mattered but it didn't:

id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;l2p=6;dscp=46

Have you tried adding the ASCII string in the Data (native) VLAN

Not sure how that would help. All data incoming to our switches is tagged so the phone already has a VLAN assigned before it makes the DHCP request. DHCP Helper is setup on the switch to point to the server and as mentioned the server seems to be replying and assigning a IP address but the phone isn't using it.

 

[Valamagules]

We have been this industry long enough to know that sometimes even tagging a port, some devices defy the odds and just don't accept it.
So usually when we build DHCP for the phones, here is a way to overcome these odd behaviours:

Data Native VLAN
Add ASCII string - id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;vlan=XXX;l2p=6s3m4v6;dscp=46s24m34v46
This helps those devices that does not recognise the VLAN tag on the switch, so when they boot off the Native Vlan they are redirected to the Correct Vlan=XXX, together with the correct DSCP markings

On the Voice VLAN
Add ASCII string: id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3
When the devices are redirected here, they pick up this string and retain DSCP markings from earlier on.

Worth the short.



Clever men learns what Wise men shares!

 

[A D]

We have been this industry long enough to know that sometimes even tagging a port, some devices defy the odds and just don't accept it.

So I can definitely try this but it's going to take a bit of work and I can't see how it will change anything. We don't have a "native" VLAN, we are using access ports on the switch to set tags. So without restructuring everything there isn't a easy way to add the initial string that sets the VLAN for the phone. Second issue is since we are using access ports they don't accept tagged data so even if I did get the first part working the switch would then deny the phones traffic because it's already tagged and all our switches only accept non-tagged data.

I can try it but logically it's going to fail. And the fact that a DHCP lease is being entered each time the phone reboots tells me it's correctly sending its request out and the DHCP server is correctly replying. The phone just doesn't seem to acknowledge it or use it. With that said I rather manually set a static IP on this phone then reconfigure the network especially with 30+ IP phones working correctly. Or I'll ditch the phone and go back to a older model.

The other issue is I know it pulled the IP address correctly on the first boot since it updated it's firmware so maybe the firmware update fails somewhere? Is there a way to revert without using the phone system?

 

[Valamagules]

Yes, agree with you, If this affecting only 1 single handset then yes, static settings is a more logical solution.
If you are thinking of investing more time on a solution, can you try this string - id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;l2p=6v4s6;dscp=46v24s46;

You can revert phone firmware (upgrade/downgrade) using an external TFTP server I suppose.


Clever men learns what Wise men shares!

 

[AlphaMann]

Some of the older none E self labeling 53XX series would hang on DHCP for 30 minutes (plus) if you do not have option 6 DNS configured to a valid DNS server.

 

[A D]

If you are thinking of investing more time on a solution, can you try this string - id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;l2p=6v4s6;dscp=46v24s46;

Yup, I'll try this tomorrow.

Some of the older none E self labeling 53XX series would hang on DHCP for 30 minutes (plus) if you do not have option 6 DNS configured to a valid DNS server.

That is set (006) along with NTP & time server (same machine) and router.

 

[A D]

If you are thinking of investing more time on a solution, can you try this string - id:ipphone.mitel.com;sw_tftp=10.1.2.3;call_srv=10.1.2.3;l2p=6v4s6;dscp=46v24s46;

Slightly different result although I have seen this. Instead of 43:43 it now says 43:125. Sequence:

Waiting for LLDP

Main Ver 06.05.00.19
Boot Ver 04.01.01.04

Waiting for DHCP
Main Ver 06.05.00.19

VLan None Pri None
Main Ver 06.05.00.19

DHCP: Discovery
Main Ver 06.05.00.19

DHCP: Discovery
Using Option 43:125

Then hangs. Just to be sure I defaulted a 5340 in the office and it went through the exact same pattern (version was different) and as soon as it hit Using Option 43:125 it blinked and said Starting Minet and booted up properly.

Could I have a bad phone or a bad firmware update? Is there anything else to check or change?

 

[A D]

(snip)

After a bunch of google searching I found this thread:

https://forums.asterisk.org/viewtopic.php?f=13&t=89955

and in it they listed a publicly available Mitel system for firmware updates. It was 5 years old but I figured can't hurt at this point. Statically set up the phone to use that and sure enough on a reboot it went through a firmware update and reset. So afterward it was on Main ver 06.05.0.26 and Boot ver 06.04.01.02 and the copyright moved from 2018 to 2020. On a reboot I defaulted the phone again but it did the exact same thing. DHCP server gets the request, puts a IP address into the Address Leases list, but the phone doesn't seem to use it.

So at this point I went a different direction. I added a DHCP lease on the server for the phone using a different IP address then it's been pulling (it was pulling .105 and I made the reservation for .201). Rebooted phone, exact same issue however the DHCP server now says the reservation is active. So same results, the phone is requesting, DHCP is replying, but the phone isn't using it and the DHCP server thinks it's job is done.

Finally I put a static IP back in and pointed it back to our server. It went through a flash update (downgrade assuming to match server). Afterward the main version went back to 06.05.00.19 but the boot version stayed the updated version. Reset to defaults one last time to see if it would pull DHCP and it did not.

So now I'm debating returning the phone as I can't see it being a issue with our system unless anyone has any other ideas.

 

[Valamagules]

I would say you have a faulty 5360 phone.
I am not sure if whoever sold you that phone will be willing to take it back being already a refurbished phone.

In anycase, Good Luck!

Clever men learns what Wise men shares!