ER7206 does not use broadcast at T2 to extend its IP address lease
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
There is a lot of 'SHOULD' and 'MAY' in the DHCP standard (RFC 2131) which may make the interaction between a DHCP server and its clients challenging. A DHCP server should, but may not, provide certain responses according to the standard and DHCP clients need to be prepared for it.
My ISP is not perfect. Its DHCP server can't be contacted through unicast. It can be contacted only through broadcast. That's not nice since DHCP clients use unicast to extend their IP address leases at the T1 time (0.5 * duration_of_lease). However, DHCP clients are supposed to use broadcast at the T2 time (0.875 * duration_of_lease). Unfortunately, ER7206 does not do that and just keeps trying to extend its IP address lease using unicast. Only about 30 seconds before the lease would expire, it finally gives up and uses broadcast. Why does ER7206 delay sending that broadcast so much? That may be the cause of some DHCP client problems reported recently.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @KJK
Thanks for posting in our business forum.
Some findings from you. Great. I will pass this on to the dev team for a look.
BTW, the issue persists on the ER605 V2 per the user who reported it recently. As for an initial conclusion, we think this might be a problem with his ISP.
- Copy Link
- Report Inappropriate Content
I think we have two problems here :-
1) Your scenario where the ISPs DHCP relay agent returns its own IP as dhcp server in the ack to dhcp req, rather than the 'real' dhcp server (presumably because the real one wont accept unicast requests). The relay agent then refuses to accept unicast renewal requests. The 7206 then doesnt attempt a new discover at T2.
So we really have both the ISP and 7206 behaving incorrectly. The ISP relay agent should either return the real server IP in the ack (and accept unicast requests) OR its relay agent should accept unicast renewals. Notwithstanding that, the 7206 ought to attempt discovery at T2.
2) The original thread where the relay agent does return the real dhcp server IP in the ack. The 7206 then sends the unicast renewal req at T1 to the real server, which responds with an ack but the 7206 rejects the renewal. This seems to be a problem purely with the 7206 as it doesnt seem to like the fact that the IP renewal came from a different server to the one which initially allocated the IP i.e the real server as opposed to the relay agent
- Copy Link
- Report Inappropriate Content
Re. 1)
It is clear to me that my ISP has no intention to handle unicast DHCP requests. That doesn't seem to be something unheard of. The IP address of its relay or server is not even a public IP address. It may not be even real. However, DHCP can still work since broadcasts should be used when T2 is reached. It's too bad that the router does not do that. Instead, it sends a broadcast so late that it may not have enough time to wait for an ACK to arrive before the lease expires.
Re. 2)
I suspect a different cause of it. What is a little bit unusual in the DHCP server final ACK is the lack of Options 58 (T1) and 59 (T2). A nice DHCP server would provide them, but it does not have to. If those options are not provided, they can be easily calculated. However, if a router does not want to do the math and expects those options to be there, there is an obvious problem. That's something to verify, but I don't have an environment to do that.
- Copy Link
- Report Inappropriate Content
So, I dusted off the router I had received from my ISP and replaced ER7206 with it. I set up a packet capture for DHCP again and guess what? That router behaves the same as ER7206. The only difference I see is that it sends a second broadcast right away after the first one. It looks like that router, ZTE H196Q, and ER7206 use the same public domain code so I do not expect any changes in ER7206 any soon if at all.
- Copy Link
- Report Inappropriate Content
That's something to verify, but I don't have an environment to do that.
im afraid I dont have the environment to test any of it, my ISP uses PPPoE!. I'm just working on theories...
It is clear to me that my ISP has no intention to handle unicast DHCP requests. That doesn't seem to be something unheard of. The IP address of its relay or server is not even a public IP address.
The relay server doesnt need a publicly routable IP , its not designed to receive unicast requests. Until your connection is allocated an IP then the only device you can communicate with is the ISP gateway/access concentrator which is where the relay agent is. It can communicate internally on the ISP network to the DHCP server. What it (the relay agent) should be doing is supplying the IP address of the DHCP server (which is publicly routable) so that unicast DHCP requests for renewal can be made. In your ISP case it seems their relay agent is not configured properly (either accidentally or deliberately) and they are relying on a DHCP client reverting to broadcast a DHCPDISCOVER before the lease has completely expired
- Copy Link
- Report Inappropriate Content
"The relay server doesnt need a publicly routable IP "
Of course, it doesn't. A DHCP relay is never addressed directly by DHCP clients. I actually use a DHCP relay on my LAN since I do inter-VLAN routing on a L3 switch, not ER7206. But here, the same private IP address is given for a DHCP server. People could've had it, or its subnet, on their own LANs. I don't think any ISP would make such a big mistake if they intended it to be used with unicast.
BTW, I've run another test, but this time with an old ASUS router. I always considered ASUS routers to be very reliable. Too bad, ASUS just started to offer a router without Wi-Fi and unfortunately with a very limited set of features. Anyways, that old ASUS router handles DHCP as it is supposed to be. It sends a broadcast request exactly at T2.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 491
Replies: 6
Voters 0
No one has voted for it yet.