<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 10pt; color: #000000'>Just curious, have you tried asking the users to perform a "factory reset" on these phones? It's usually pretty painless and could help.<span><br><br><span name="x"></span>---<br>Lelio Fulgenzi, B.A.<br>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>Cooking with unix is easy. You just sed it and forget it. <br> - LFJ (with apologies to Mr. Popeil)<br><span name="x"></span><br></span><br><hr id="zwchr"><b>From: </b>"Andy Carse" <andy@carse.demon.co.uk><br><b>To: </b>cisco-voip@puck.nether.net<br><b>Sent: </b>Wednesday, February 16, 2011 9:04:04 AM<br><b>Subject: </b>Re: [cisco-voip] tftp server 255.255.255.255<br><br>Thanks to all that replied to this<br><br>We are going to use 3rd party app suggested by Lelio and others as 350 <br>handsets to do across the patch.<br><br><br>On 02/15/2011 09:54 AM, Andy Carse wrote:<br>> Hi James,<br>> The phones were delivered in this state from the reseller all we've <br>> done is unboxed them and connected them to the network.<br>> I suppose if we ungraded to v8 then we could find all the duff <br>> handsets rather quickly as they would fail to register (but I don't <br>> expect the field guys would like that senario ;-).<br>> I guess that as there isn't any indication from the web admin that <br>> things are broken then maybe this is something that may crop up in <br>> other deployments.<br>><br>> I've done the following:-<br>> reset the handset<br>> reset the dhcp scope, including expiring the leases<br>> changed to a different vlan<br>> sniffer traces show the dhcp options being given to the handset (other <br>> handsets that don't have this set that are on the same vlan all work <br>> correctly)<br>> checked for ctl<br>> The only thing that seems to work is to erase the config and then when <br>> the handset restarts it downloads the correct code.<br>><br>> I've tried your suggestion about the show risdb and it works on my lab <br>> setup but on site its completely wrong, in that it doesn't match what <br>> the handset actually says.<br>> So I'm wondering if resetting the ris database service may at least <br>> clear this database up otherwise its going to be a long march for <br>> whoever gets to check the handsets..........<br>><br>><br>> On 02/14/2011 12:49 PM, James.Brown@barclayswealth.com wrote:<br>>> Hi Andy,<br>>><br>>> Out of interest, how did the phones end up with this TFTP server <br>>> address? Have you hard-coded it on the CCMadmin device page, or is it <br>>> some bug that I narrowly avoided over the years ;-)<br>>><br>>> My suggestions would be:<br>>><br>>> 1. Does a reset help pick up the Option-150 setting? If so, I guess <br>>> you would have to do this en-masse from CUCM or by disabling POE on <br>>> the switch-port then re-enabling<br>>><br>>> 2. You could obtain a full list of registered phones via "show risdb <br>>> query phone" on each subscriber CLI. Then feed this list into CURL <br>>> via a shell script<br>>><br>>> <br>>> http://$IPPHONE/CGI/Java/Serviceability?adapter=device.statistics.configuration<br>>><br>>> Just pipe all the output into a file and filter it using vim (or <br>>> similar) to narrow down to just those phones which are affected.<br>>><br>>> Hope this helps<br>>><br>>> James.<br>>><br>>> -----Original Message-----<br>>> From: cisco-voip-bounces@puck.nether.net <br>>> [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Andy Carse<br>>> Sent: 14 February 2011 11:30<br>>> To: cisco-voip<br>>> Subject: [cisco-voip] tftp server 255.255.255.255<br>>><br>>> 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 <br>>> 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 <br>>> updated, I have seen this before but we found it whilst actually <br>>> 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 <br>>> have extension mobilty setup.<br>>><br>>> No we are in the process of upgrading the firmware for an upgrade due <br>>> in a couple of weeks.<br>>><br>>> These handsets won't be able to upgrade is there an "easy" way of <br>>> finding these devices?<br>>><br>>> They won't show up in the Device Firmware Load info as they don't <br>>> 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 <br>>> 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>>> -- <br>>> Rgds Andy<br>>><br>>> _______________________________________________<br>>> cisco-voip mailing list<br>>> cisco-voip@puck.nether.net<br>>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>>> Barclays Wealth is the wealth management division of Barclays Bank <br>>> PLC. This email may relate to or be sent from other members of the <br>>> Barclays Group.<br>>><br>>> The availability of products and services may be limited by the <br>>> applicable laws and regulations in certain jurisdictions. The <br>>> Barclays Group does not normally accept or offer business <br>>> instructions via internet email. Any action that you might take upon <br>>> this message might be at your own risk.<br>>><br>>> This email and any attachments are confidential and intended solely <br>>> for the addressee and may also be privileged or exempt from <br>>> disclosure under applicable law. If you are not the addressee, or <br>>> have received this email in error, please notify the sender <br>>> immediately, delete it from your system and do not copy, disclose or <br>>> otherwise act upon any part of this email or its attachments.<br>>><br>>> Internet communications are not guaranteed to be secure or without <br>>> viruses. The Barclays Group does not accept responsibility for any <br>>> loss arising from unauthorised access to, or interference with, any <br>>> Internet communications by any third party, or from the transmission <br>>> of any viruses. Replies to this email may be monitored by the <br>>> Barclays Group for operational or business reasons.<br>>><br>>> Any opinion or other information in this email or its attachments <br>>> that does not relate to the business of the Barclays Group is <br>>> personal to the sender and is not given or endorsed by the Barclays <br>>> Group.<br>>><br>>> Barclays Bank PLC. Registered in England and Wales (registered no. <br>>> 1026167).<br>>> Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.<br>>><br>>> Barclays Bank PLC is authorised and regulated by the Financial <br>>> Services Authority.<br>>><br>><br><br>-- <br>Rgds Andy<br><br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br></div></body></html>