Yealink Forums

Full Version: Unable to obtain IP Address over DHCP
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

We have a number of Yealink T22P phones, including a new batch.

We have determined that the phones are unable to get an IP address over DHCP when plugged into some switches around the office.

I can see that the phone is sending out a lot of discover messages and getting some responses, but never sending out a request message as far as I can tell:

Code:
23764 779.088203000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xd11fdc42
  23796 781.035201000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0xb25c3e3d
  23797 781.036463000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xb25c3e3d
  23817 782.177730000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xd11fdc42
  23861 784.131779000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0xb25c3e3d
  23862 784.132857000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xb25c3e3d
  23944 785.268454000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xd11fdc42
  23988 787.255461000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0xb25c3e3d
  23989 787.256554000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xb25c3e3d
  24646 808.549804000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xe943470a
  24713 810.721273000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0x56b26e7a
  24714 810.722178000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0x56b26e7a
  24739 811.645492000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xe943470a
  24776 813.829975000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0x56b26e7a
  24777 813.831205000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0x56b26e7a
  24800 814.729657000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0xe943470a
  24866 816.975310000  0.0.0.0               255.255.255.255       DHCP     590    DHCP Discover - Transaction ID 0x56b26e7a
  24867 816.976544000  10.1.1.8              255.255.255.255       DHCP     388    DHCP Offer    - Transaction ID 0x56b26e7a

I can also see that some of them are getting jumbled up.

It seems to be giving up on DHCP discovers very quickly, so it could be getting very confused.

Windows machines are getting addresses fine, but I believe that the wait a while for responses and then use longer and longer timeouts.

We do go through a couple of layers of switches, which I think might be contributing to the problem by slightly delaying responses. We did make changes to the switches a couple of weeks ago.

Is there a way to make the phones wait longer for a response from a DHCP server?

Has anyone else seen similar problems?

Thanks for any insight anyone can offer.

Ashley
I encountered this with a switch that had a few ports configured not to use RapidSTP. Without RapidSTP it took about 30 seconds for the link to come up and so as a result it timed out and DHCP timed out before the link as up. Enabling it fixed it right up.

Might want to double check both that the switches have RapidSTP enabled and all the ports that have phones plugged into them have RapidSTP enabled.

I do agree it is annoying that it is pretty much required but in fairness users and Windows expects it these days as well - Windows will time out reconnecting network shares as well if RapidSTP isn't enabled.

-Rob
Reference URL's