I have run into a similar issue.  This turned out to be a Phone firmware bug (TAC never did get me a DDTS).  The solution for us was to add the tftp server as a helper address on the phone vlan.  Once the phones upgraded their firmware, they showed the correct tftp server and we removed the Helper address.  These were 7941/61.  I don't recall the firmware version.  <br>
<br>Hope this helps.<br><br><br><br><div class="gmail_quote">On Tue, Feb 15, 2011 at 3:40 AM, Andy Carse <span dir="ltr"><<a href="mailto:andy@carse.demon.co.uk">andy@carse.demon.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Wes,<br>
Nope these don't have security enabled.<br>
<br>
<br>
On 02/14/2011 02:53 PM, Wes Sisk wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Are these phones with security enabled and CTL files? If so they will take option 150 or option 166 but will refuse to use the provided IP as it is not in the trust list.  The only way to recover them is to manually delete the CTL from the phone.  Navigate the UI on the LCD.<br>

<br>
<a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7962g_7961g_7961g-ge_7942g_7941g_7941g-ge/8_0/english/administration/guide/62614241trb.html#wpmkr1031650" target="_blank">http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7962g_7961g_7961g-ge_7942g_7941g_7941g-ge/8_0/english/administration/guide/62614241trb.html#wpmkr1031650</a> <br>

<br>
Regards,<br>
Wes<br>
<br>
<br>
On 2/14/2011 6:30 AM, Andy Carse wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I guess I already know the answer, but I'll ask any way.<br>
<br>
I have possibly several handsets that have been deployed that out of the box had their tftp server as 255.255.255.255.<br>
<br>
They are setup for DHCP but the tftp server info doesn't seem to get updated, I have seen this before but we found it whilst actually deploying handsets so we checked them as they were rolled out.<br>
<br>
As such they would have booted up ok and worked assuming they didn't have extension mobilty setup.<br>
<br>
No we are in the process of upgrading the firmware for an upgrade due in a couple of weeks.<br>
<br>
These handsets won't be able to upgrade is there an "easy" way of finding these devices?<br>
<br>
They won't show up in the Device Firmware Load info as they don't talk to the cluster in the normal way.<br>
<br>
The only way we have found to recify this is to visit a handset and erase its config.<br>
<br>
we have 10 sites and 4000 handsets, so it could take awhile.<br>
<br>
Currently running 5.1.2 going to 7.1.5su3<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
-- <br>
Rgds Andy<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div><br>