Tony Hoyle wrote:
Philip Edelbrock wrote:
18 17.161118 Grandstr_05:a9:bf -> Broadcast ARP Who has
206.228.191.144? Gratuitous ARP
19 17.609869 3com_96:2f:eb -> Grandstr_05:a9:bf ARP 206.228.191.144
is at 00:10:4b:96:2f:eb
20 20.155260 206.228.191.144 -> 206.228.191.7 DHCP DHCP Decline -
Transaction ID 0xffffced0
It looks like your DHCP server is in fact broken. It's passing out
duplicate addresses - the device 00:10:4b:96:2f:eb already has
206.228.191.144, so the Grandstream (correctly) declines the offer.
The server then tries to send the same address *again* instead of
selecting a new one, and the same sequence ensues. It should give a
different address if the original one is declined.
Ah, you are close!
I figured it out (*hurray!*). It was in fact a misconfiguration on my
part. 144 isn't the end of my subnet, 143 is. So, packet 18 is the
phone confirming that it owns IP 144. Packet 19 is from the router
saying, "no you don't, I own that" (this is a proxy arp setup). So, the
phone declines and requests a new IP. The head scratcher was that for
the next request, it requests 144 again, so the DHCP server says (again)
"OK, you got it" and the loop continues.
Once I adjusted my dhcp config to end my dynamic pool at 143 instead of
144, all was well.
Additionally, I noticed that the phone requests these pieces of info in
the dhcp response:
- Subnet
- Router
- DNS server(s)
- Time Server(s) <--- !!
So, I additionally put in the dhcp config a time server (the ip for
time.nist.gov for now). And after the first reboot, the phone gets an
IP, pings the dhcp server once, registers, sets it's time, checks for
firmware updates, and seems perfectly happy.
Hurray!
Phil
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
