Anyway at all to Factory Reset a K Series Vantage thats admin password to another IPO?

[jamesarbrown]

We have a K175 here and its locked to its previous owner admin password.

The problem is that its trying to reach their 46xxsettings.xml file server instead of the IPO one coughed up on DHCP 242 code and until it has that file, it wont know a new admin password

Steps Taken

Tried default password 27238

Tried to CNAME the fileserver.xyz.co.uk (grabbed from config verifier on phone) via a spoof DNS record (which works in a browser and brings up the self generated 46xxsettings.txt and checked thats the DNS the phone uses), but no luck, but could be they have used https and the phone is unhappy with the IPO self cert.

Tried to move the DHCP to the IPO for that vlan (and that is working as tested with a B179 SIP phone and my PC), to 100% ensure that the DHCP 242 Option is being (hopefully) sent exactly as Avaya want it.

I also did check the 46xx... and it does have SET ADMIN_PASSWORD xxxxxxx in there, but we already know thats only going to work if it will pickup the file and it is not.

 

[jamesarbrown]

BTW its a V1.
The BRM only gives option to Reboot or provide password #catch22

 

[Westi]

I guess you will have to wireshark the phone and see where it tries to get the 46xx file then create a network for it and make it receive the file.

I have no other ideas than that, sorry.

Joe
FHandw, ACSS, ACIS

 

[sizbut]

As Westi says, you setup a PC with a file server app running with the right IP address to answer the phones request with a dummy settings file that sets the password back to default or one you know.

Stuck in a never ending cycle of file copying.

 

[jamesarbrown]

Thanks, but have done that as described originally

Phone is looking for fileserver via fqdn, which i have had to point to ip on ipo via dns entry

Have tested it by using fqdn exactly as shown on K179 screen in a browser. That works on browser, in http and https, but doesnt pickup on device (all same vlan, dhcp server etc)

Either not picking it as the fqdn is https and certificate is not accepted, or its been overridden later on. Avaya books suggesting the dhcp does not have top prioriy.

 

[sizbut]

If it's using FQDN then it will be asking DNS for the IP address. That's why my network has a Synology box that does all the DHCP, and DNS, and acts as a file server.


Stuck in a never ending cycle of file copying.

 

[jamesarbrown]

Yes... Ours has a bind DNS server, with a cname pointing at the fqdn record (faking what phone is looking for) to our ipoffice500

The ipo is running dhcp, the ipo is automatically creating 46xx settings.

And to triple confirm we can use a browser and use the fake fqdn to see 46xx settings. The phone is confirmed to use that dns

But if the phone has been set at the phone for the file server, then according to manuals i think that overrides any provided by dns

I posted here in hope there was another way, faking dns isnt going to work. Tried

 

[ipohead]

Could you edit the hosts file on your server as this should override DNS.

 

[TouchToneTommy]

In the original IPO, the FQDN is also going to be on the VoIP tab of the LAN port, and the 46xxsettings file is generating entries such as:


SET SIPDOMAIN "portal.xyzco.com"

SET SIP_CONTROLLER_LIST "123.211.15.36:5061;transport=tls"

SET FQDN_IP_MAP "portal.xyzco.com=123.211.15.36

Since the phone is also encountering these entries, perhaps edit your IPO's settings file to point everything back to the ipo

 

[jamesarbrown]

Thanks... but rewinding the discussion, the phone is not getting a 46xxsettings.txt from our IPO as it is asking the wrong FQDN

We have tried to spoof it via a CNAME from the wrong FQDN to the IPO FQDN with no luck, which we think is because the phone is trying https and obviously we can not fake a cert of a domain we do not own.

 

[Westi]

you might have to tell the IPO to respond to the wrong FQDN as well (just spit balling here)

the entry would be in System - LAN1 or LAN2 - VoIP - SIP registrar FQDN

the system might otherwise not respond to the request if it comes in via name and not IP

Joe
FHandw, ACSS, ACIS