i2004 hangs on "Starting DHCP" 1

[81Cadmin]

I shipped a several working i2004 phase 2 phones from one site to another. The new site would have a different DHCP scope. The working phone now hangs on "Starting DHCP" message.

I suspect the phone is attempting to use a cached IP from the original site, as a result hangs.

Question 1:
Is there a way to clear the cached IP setting.

Question 2:
On some phones I notice 'cacheip' is a configurable option on some i2004's, however this option is also not appearing on all phones regarless of firmware.

Your help / response on both questions is appreciated.

 

[StoneColdphoneman]

I would look at the Data switch and see if you can see DHCP request from the phone, maybe your phone is plugged in to the wrong V-Lan.

 

[81Cadmin]

The problem is with the phone itself. It is not releasing the cached IP that was used at the previous site. The DHCP scope is now changed and as a result the phone will not register with the network.

DHCP through the data port does work.

I need to know how to reset/clear the cached IP settings. Unfortuantely I'm uanble to find any NTP on this.

 

[StoneColdphoneman]

On my 1140e I see Under Network configuration Catched IP is unchecked.
I don’t have I2004 in my office but if I was you I would go to the setting and check.

 

[81Cadmin]

As mentioned earlier the 'Cached IP' setting only is appearing on some i2004 phone, but not this one. Both phones however are running the same firmware which is why it confuses me that the configuration seem to be different.

I've read that there is supposed to be 'special' commands that can be entered on the i2004; one of which forces a factory reset. I haven't however been able to locate any documentation on these 'special features'.

Thanks for your help.

 

[gwebster]

There is no "factory reset" on the 2001/2002/2004.

Try the latest firmware (0604DCD) on the 2004. I realize that you may have to do this from a location where it can retrieve DHCP properly and connect to the switch in order to get upgraded.

 

[81Cadmin]

Yes, this phone was previously working at another location so it does have the current firmware. Now that the phone has been moved the IP scope (of the old location) is still cached and causing the set to fail DHCP. DHCP from a PC connected to the phone works. The phone if statically configured also works.

I believe if I reboot the cisco switch this will correct the issue but I would prefer not to do that everytime a set has been redeployed to a new site/scope.

 

[tnphoneman]

Have you confirmed the DHCP setting in the server. Try using a partial dhcp? If you get a partial then the problem is in the DHCP server and the Nortel-A settings. You have to have this option in the native vlan as well as the phone set vlan.

Signature===========================================

http://www.greatwhitetechnologies.com

 

[curtismo]

Have you tried placing a PC on the port in question to make sure it can get a DHCP address?

I had a situation where on a quick move-in, the cabling vendor did not test their jacks and the TX pair in the cable wasn't any good, yet the i2004 phone was receiving power and powered up OK, but the switch didn't receive the DHCP request.

 

[81Cadmin]

Yes the PC does get an address, the phone does not (hangs 'starting dhcp'). I find it odd that some phone list an option to turn of 'cached IP' and other do not even though the firmware is at the current (same) version.

 

[tnphoneman]

Did you try partial DHCP?

Signature===========================================

http://www.greatwhitetechnologies.com

 

[81Cadmin]

Yes Partial is what we do use (we assign S1/S2 statically).

 

[gwebster]

The "cached IP" option will only appear if DHCP Is turned on and Voice VLAN is NOT configured for Auto.

 

[tnphoneman]

You may be on to something Gene.... If the vlan is set on the phone but not on the poe port then you will have a problem. You could have the vlan set from the other site.

Signature===========================================

http://www.greatwhitetechnologies.com

 

[81Cadmin]

excellent, will look into that option.

 

[81Cadmin]

On the set that is having problems the config menu starts with "DHCP"; on other sets the configuration menu begins with the EAP setting (then LLDP then finally DHCP). I have no idea why this sets configuration menu seems to be different but if figure this out I'm sure my problem will be solved.

Also the set is missing other key configuration options including;

- Speed 10, 100
- PcUntagAll
- CachedIP
- GarpIgnore
- PskSRTP

?? Why do two sets which are running similar firmware present different configuration menu's/options?

 

[gwebster]

If the two sets have different menu/options, then they are NOT running the same firmware.

 

[MagnaRGP]

Also, by definition, with DHCP, the phone will request it's cached IP from the DHCP server. If the DHCP server NAK's the request (for example if the phone had not been moved into a new LAN but unplugged for a while, it's old IP address may have been reassigned), the phone will request a new IP address, so I don't think that the issue is a cached IP here. Seems more like a VLAN issue.

 

[81Cadmin]

We aren't using Vlans at the moment, so VLAN option is off. The problem began when the set was moved from one network to another. This is not the first occurance of this problem as I have had it elsewhere. In those other cases i was able to turn off 'cachedip' to resolve the problem.

I'm going to statically assign the IP to the set and do further testing, including a force download of firmware.

I will update this thread once I've completed this level of testing.

 

[Tman45]

I have had the issue before where the i2004/i2002 was stuck in DHCP as well. If you have enough IP addresses available in your scope it could be possible that something is wrong with the DHCP string. We always use the manual phone config (so use partial and specify S1, vlan, etc) should get it working (because some i2000 series phones had bad dhcp boots and would not grab an IP).

If the network settings are pretty much similiar between the sites I would look at the DHCP at the non-working site.