HTML App Upgrade (w/o MBG)

[JoeShmo]

We went from 4.2 to 5.0.  After the upgrade, phones are taking about 5-10 minutes to get past the HTML App Upgrade screen.  Rebooting the phone, sometimes it goes past that screen in 2 seconds, other times in 10 minutes.  We have a remote campus where it hangs on that screen forever (well, 8 hours so far).  While on that screen, the phone does work as far as making/receiving calls.

We are not using teleworker (or MBG).
there are no firewalls between the phones and the controllers.
we are only specifying the vlan once in dhcp.
We have 4 MXe-IIs and 2 vMCDs.  No matter what we point the phones at for tftp or icp, we get the same results.

anyone seen anything like this?

[x-man]

Yup, similar. I am seeing boot times from a few seconds to 10 minutes (according to the maintenance logs) without the HTML (all on 5324 phones). All the 5304's on the same system boot normally. Nothing in the logs to indicate why......this is not an upgrade though, built as 5.0.  I wonder, in my case, whether it has something to do with the DHCP settings as my sets hang on DHCP settings...I've looked and can see nothing amiss and the 5304's don't have any problem.

[JoeShmo]

Mitel had us verify that the 2nd DHCP server was not assigning the vlan, as apparently there is an issue with 5.0 that if the vlan is assigned on both requests (even the same vlan), this can happen.  This of course assumes that you are running a separate voice vlan.  The phone requests an address via DHCP, the DHCP server gives it a "normal" IP, and assigns a vlan (say 800), the phone then releases the address, then re-asks for DHCP on vlan 800.  If the DHCP server on vlan 800 also supplies the option (either in option 43 or 125) and tells it 800, apparently the phone keeps switching vlans around, and can cause this issue.
However, with us, this is not the case.  The DHCP server on vlan 800 does not re-iterate that we're talking on vlan 800.

Also, we're using option 43 in DHCP to assign l2p, diffserv, callserver, and tftp server.  This is via a Linux ISC-DHCP server.  We formulated the string by configuring an MXe-II for DHCP, then just copying the string to the Linux server.

We could probably live with the excessively long HTML App Upgrade times, but that other campus where it NEVER leaves that screen is a bit much.  It must be doing something odd for that Upgrade, which its timing out on, or something silly.  Will be messing with it more today to get those other 100+ phones on that campus working properly.

[x-man]

No vlans on my install, flat network.

[JoeShmo]

Are you by chance blocking multicast?  I'm wondering if that has anything to do with it.  We've blocked multicast on a few of our core routers, as it was leaking out of various vlans, and flooding the network.  Wasnt a problem with 4.2, but maybe in 5 they do something with multicast to "upgrade html apps".?