Customer's UC500 system is set for US Central time, using NTP to update. Times are correct everywhere except on one 7945 phone, which displays Pacific time. How can I fix this?
I ran into a similar problem and it was a combination of problems. One was the phone loads were outdated, the other was the IOS, we ran one of the early releases of the IOS to get the one button LiveRecord feature to work. Apparently there was a conflict with this and the CCA. I ended up rolling back to the latest working IOS, upgrading to CCA 2.0.1 and uploading the latest phone builds and things are working now.
I've updated the phone loads for the 7945 to 8-4-2, but the phone will not update its firmware when rebooted; it remains at 8-3-5. I updated the 7945-7965 phone load files, the tftp-server commands and the load command via CLI. What did I miss to get the phone to update its firmware?
Found the problem with the firmware update (and probably the original time problem). The phone is connected through a switch (not a Cisco switch), causing it to be assigned a 192.168.0.x ip address, rather than a 10.1.1.x address. The phone registers and works perfectly, but the update doesn't happen. When connected to the UC520 directly, however, it gets a 10.1.1.x address and updates properly. When reconnected through the switch, it now has the correct time and firmware, even though it again has a 192.168.0.x address.
So, is there a way to have the phone automatically assigned a 10.1.1.x address, even though it's not directly connected?
If the switch can support trunks and that switch is connected to the expansion port, you could do it. I would have thought TFTP would still have worked here though. You might want to look into why TFTP wasn't working.
I'm not sure what the switch can support; I didn't install it. I believe it is connected to the expansion port, though. Where would I start looking to try to find out why tftp wasn;t working?
debug tftp events
debug tftp packets
See what the output is when you reboot the phone. Unfortunately, you need the phone to be trying to upgrade. You could also see if there are any ACL's on the vlan or bvi interfaces.
Is 192.168.0.X your UC500 Data VLAN? Assuming it's not, then the phone is getting DHCP from somewhere else. This comment is not realted to your problem, but just make sure your data DHCP server on the UC500 is disabled if you are using another one.
The BVI interfaces each have an ACL which excludes the other; i.e., BVI1 (data) ACL 102 has a "deny ip 10.1.1.0 0.0.0.255 any" and BVI100 (phones) ACL 103 has a "deny ip 192.168.0.0 0.0.0.255 any". Can the BVI100 ACL safely have the deny ip 192.168.0.0 removed?