Aastra 53i DHCP issue
Submitted by scarr on Fri, 05/02/2008 - 12:56pm.
Hello all. I just received some Aastra 53i phones and tried to set them up the new way (I've updated the Trixbox stuff for Aastra phones, run the setup-aastra-xml and updated the firmware on the phones successfully). If I give the phone a static IP address then everything works like a charm, it picks up all the settings from Trixbox and then asks for the Extension then voice mail password. Once entered everything is just fine. the problem is that I'd prefer not to have to give every phone a static IP, I'd just like DHCP to work but no matter what I try if I switch the phone back to DHCP and reboot it I get "No Service" and when I look at the phone status IP it shows a 169.254.x.x IP (even though I see an entry in the DHCP log showing that the phone did "renew" an IP successfully at the time of the boot (running DHCP on Windows 2003 server). So, somehow the phone decides it doesn't like what it got and changes to the non-useable 169.254.x.x . Any ideas why this is happening (I have Polycom phones that pick up DHCP no problem, this is just with the Aastra 53i).
thanks in advance
Maybe the "dhcp server" is
Sun, 05/04/2008 - 4:07am
No Dice
Mon, 05/05/2008 - 10:31am
well, I tried playing with the setting until I realized it never gets to the config. It gets a DHCP lease from my Windows 2003 server successfully and then something makes it decide to reject it before it can grab the config file (it fails when trying to get the config). Thing is I can't even try to debug it cuz there wouldn't be a way to get the info to a syslog server. No one else is having this issue?
BTW, I tried this on a Windows 2000 DHCP server too on a different network and got the same result
I'm wondering if you've got
Mon, 05/05/2008 - 10:40am
It doesn't get that far
Mon, 05/05/2008 - 12:55pm
if I packet sniff the connection I see a mDNS request from the phone but it comes from a 169.254.x.x IP. There is only one response and it comes from the Asterisk server (with the info) so I don't think mDNS is the issue since the phone has already lost its good IP by the time it looks for a config server.
Well, I did a bunch of
Mon, 05/05/2008 - 3:55pm
Well, I did a bunch of different testing and sniffing and finally figured out that the problem was between the Aastra phone and the Cisco switch it is plugged into (3524XL). It seems that in the middle of the critical handshakes (right after it gets an IP) the port goes down and then back up again (haven't figured out the cause yet) so the phone bails into a 169.254.x.x ip and never gets in contact with the mDNS or TFTP. As soon as I put a hub in between the two (phone and Cisco switch) everything worked like a charm from the factory defaults. I'm going to dig a little more on the Cisco switch and see if I can figure out why the port is "bouncing" and if there is anything to be done.
thanks for all the help pointing me in the right direction
BTW, I do already have spanning-tree portfast on that port (that used to cause DHCP problems for regular workstations) so I'm not sure what else it could be
whoa this is fun. So, it
Mon, 05/05/2008 - 4:12pm
whoa this is fun. So, it turns out that since the Cisco switches we have run the old Cisco-proprietary inline power (we purchased them a long time ago for Access Point power etc) that is where the conflict is. The switch and the phone try to negotiate power even though the phone is already getting it from a plug into the wall. When I set the port on the Cisco switch to have "power inline never" everything worked like a charm. I guess I would've assumed the Aastra would have worked this out better to make it clear to the switch (like any normal workstation does). ANyway, just for everyone's edification, the new auto-config setup for the Aastra phones won't work if you have an old Cisco power switch (not PoE).
Depending on the version of
Tue, 05/06/2008 - 9:53am
Depending on the version of IOS you are running on the Cisco, you should be able to set a configuration parameter on the switch to help with this. It's possible to extend the power shutdown timer on the interface, thus avoiding the power-cycle.
The syntax of the command you need is:
power inline {auto | never} | [delay {shutdown seconds initial seconds}]
What we've found is that you set the delay option and extend the time, then the switch won't reset the power. For example, we've had success using the following on some switches:
power inline delay shutdown 20 initial 30
But you may have to use different values depending on the switch. Also, you'll need to run this command on each of the interfaces.
Member Since:
2006-10-12