New Yealink VoIP phone getting a DHCP lease but not showing up in the Lease list (questions)
-
I have a client that just bought a new Yealink T31P and plugged it into the network. It is on network and shows up in the ARP table:
But looking for it in the DHCP Lease list it just doesn't appear:
Given it's IP number, it should show up between the circled entries in an IP Address ordered list.Yet, it has all the values that would be served by the DHCP server: default gateway, DNS server and 192.168.20.x and the phone itself is set to use DHCP.
Now the really interesting thing is that my non-static range for IP numbers in the DHCP server is 192.168,20.50-192.168.20.250, so how did this phone manage to snag an IP number of x.33 when there is no static entry in the DHCP server for it?
It all works, but I'm trying to understand why I couldn't find the device without having to match its MAC number on the barcode to the ARP table as a first step?
-
@atlassol maybe it just renewed an old lease.. Maybe its set static?
Set a reservation for it, then have it release and renew or reboot it, etc. so it it should grab its new reserved IP.
Had a thermostat that once it got an IP, it would never even renew it - would just continue to use that IP unless you completely reset its network settings. Maybe the phone does something like that.. Its a horrible implementation - but I have seen devices do some stupid stuff.
-
@atlassol same problem here.
The phone was getting an IP but it wasn't showing up under DHCP leases.
Got a copy of it's MAC address in the ARP table and created a static DHCP lease as @johnpoz suggested.
It now shows in the dhcp leases but a very laborious way of doing it.
Thankfully it's only a small site. -
@NiallCon said in New Yealink VoIP phone getting a DHCP lease but not showing up in the Lease list (questions):
The phone was getting an IP but it wasn't showing up under DHCP leases.
The only way that could happen is if the device didn't follow through with the rest of the process.. Like it sends out the discover and dhcp server sends the offer, and vs sending the request it just says oh I will use that.. So the server wouldn't know the client actually used it, so it would never create an actual lease for it.
You would have to do a sniff to see if the clients not sending the request.. But if the request is gotten the dhcp server would send an ack saying ok I gave you this lease. But maybe it sent a nak and the client used the IP anyway which wouldn't actually create a lease.
Or possible the phone got the ip and did follow the full process, and the server did create a lease - but the phone never renewed it, and then at some point the lease would expire and could be handed out to someone else.
Clients that do not follow the full process is going to at some point cause you problems with possible dupe IP handed out... So yeah if you know what client the device got - creating a reservation for it should prevent any future dupes from happening.
There are a few specific scenarios where - like the client did send the request but the server didn't get it, but then the client shouldn't actually use that IP until it sees the ack from the server.
If you are seeing the process fail - any client that gets an IP from dhcp for sure should be listed as a valid lease or something is not quite working how it should. Tracking down that what can be more time consuming vs just worry about it later. Setting a short lease like say 10 minutes or something should help since the client then should then renew like every 5 minutes, etc..
-
@johnpoz good to know.
I did some playing around with the switch this morning. I don't 'think' I changed anything relating to that particular VLAN.
I removed the static ip reservation from the phone and cleared the arp cache but even after restarting the phone, the switch, it was still getting the old reservation. Eventually, I turned off the switch, cleared the ARP cache. Restarted the 4200, waited for it to come back up. Then I turned back on the switch and the phone got a new ip from the dhcp pool.
I'm going to do some further testing with the dhcp timings this afternoon. I want to make sure the dhcp is working before I put it into production.
Thanks for your help and advice.Niall
-
@NiallCon not sure how the switch would have anything to do with it - unless it put the phone in the wrong vlan? If so then it wouldn't be working if it had IP from wrong vlan.
-
As the original poster, I wanted to supply an update. Somehow the Yealink phone "took over" the identity of the Synology NAS device. (I don't have any more precise of a definition than that right now). The effect is that a Datto Backup Appliance that takes incremental backup of the Synology appliance started erroring out in mid-March. When I looked at the Datto appliance, it was trying to connect to the IP# that was (now) the static number of the Yealink phone to initiate the agent to trigger a backup. It's almost like something was using MAC Masquerade...
Apart from that I have nothing more to share on this. I just wanted to get the things working and move on to other tasks.
