DHCP server: improve Wi-Fi client IPv4 IP assignment (at the edge of radio range) and/or DORA debug

Product Discussion Feature Requests
1

In our case we have an open Wi-Fi SSD for guest internet access. Sometimes the Peplink Balance its DHCP server assigns IPv4 addresses to DHCP client request. However the client doesn’t seem to be receiving the corresponding UDP answer packet for their request, at least the IP is not assigned. I have the idea that this happens as soon as clients enter the edge of the Wi-Fi radio reach, where signal is low, usable bandwidth is low, and a lot of packet loss occurs.

A possible solution (I haven’t checked for technical sensibility) to retry sending server to client packet(s) for DHCP assignment requests, until the IP address does respond to a ping request (and before the client sents out a new DHCP assignment request because a time-out timer is expiring).

Or way more detailed debug possibilities that give insight in what happens in the “DORA process”.

An example Wi-Fi client device with failure to acquire an IPv4 address and Peplink Balance logs the “DHCP Server: 192.168.x.x assigned 192.168.x.x to eX:fX:eX:7X:5X:7X, lease time 2678400” message:
Channel: 124 (11na)
Signal: 7.4% (-87 dBm)
TX Rate: 13 Mbps
RX Rate: 13.5 Mbps

Though there are also Wi-Fi client devices for which the Peplink Balance DHCP server doesn’t log an assignment message:
Channel: 11 (11ng)
Signal: 32% (-77 dBm)
TX Rate: 0 bps
RX Rate: 0 bps

Channel: 11 (11ng)
Signal: 7.4% (-87 dBm)
TX Rate: 0 bps
RX Rate: 1 Mbps

Channel: 6 (11ng)
Signal: 15% (-84 dBm)
TX Rate: 0 bps
RX Rate: 1 Mbps

2

Thanks for the suggestion. The suggested DHCP enhancement will help on IP assignment but doesn’t solve the problem. The provided info indicate that the Wifi signal strength is not good and you might have interference there. In fact, the description above indicated that the core problem is residing at your Wifi connection. You may face another issue (besides IP assignment) in future.

I suggest doing wireless site survey to check the Wifi connection there.

Hope this help.

3

The access point is a long range version. According to the manufacturer the (UAP-AC-LR) range is: 183 meters (600 feet)
I did see the SSID name on an iPhone4 at 206 meters (676 feet) away and MacBookAir6,1 even at 330 meters (1083 feet; -84dBm Signal level; SNR 8dB) in a densely populated inner city with water ways (canals) and full of buildings.

As the signal level (RSSI: Received Signal Strength Indicator; RSSI can be measured from -120 to 0 dBm) relates somewhat logarithmical to the distance between the transmitter and receiver (access point and client device). See the inlined chart from Cisco:

For Free Space Path loss (FSPL), excluding Rx/Tx antenna gain, this formula for outdoor environments is used: ( 4 × π × d ÷ λ )² where:
d is the distance of the receiver from the transmitter (metres), λ is the signal wavelength (metres); for 2.4 Ghz λ is 0.125 meters. The transmitter is at (-)20 dBm / 100 mW for 2.4 GHz. To convert that FSPL value into a dBm scale, apply 10 × log10 (FSPL). That results in these theoretical signal levels (excluding antenna gains):

0 meter: -20 dBm
1 meter: -60 dBm
3.3 meters: -70 dBm
10 meters: -80 dBm
33 meters: -90 dBm
100 meters: -100 dBm
252 meters: -108 dBm
330 meters: -110 dBm

This remark isn’t about the absolute dBm values, though regarding the relative changes. At a walking speed of 1.3 meters per second, and a DHCP timeout of 60 seconds, the result is 1.3 × 60 = 78 meters. When the client device sees the SSID first, the SNR might still only be improved from 8dB to 10dB. That is still an unusable bad quality.

Because there is no authentication, the WPA2 authentication process cannot be used to filter out clients that are not close enough to the access points.

While the network connection is still so lossy that one UCP DHCP is easily lost during transmission, and it seems to take 60 seconds before a new DHCP address assignment trial will be started (timeout), that results in a bad user experience.

DHCP client default values:
timeout: 60 seconds (=too long)
retry: 300 seconds (=too long too)

I do see Android devices that automatically (because it is an open SSID) start accessing (initiating DHCP requests) the Wi-Fi network between -95 dBm and -74 dBm, still failing to acquire an IP address. Even then the only issue it that only a DHCP UDP packet might be lost during transmission. My wish here is an improved DHCP packet handling with some more advanced retry on the DHCP server site, that involves retransmitting DHCP packets from server to client (DHCPOFFER and/or DHCPACK) at short TTL’s (admin configurable). Note: DHCP offer, when there is no DHCPREQUEST within timeout; DHCPACK when there is no traffic within timeout.

This also happens for iPhones and Windows phones. However in the Ubiquiti Unifi controller 5.0.7.3093
, these Windows and iPhones will show up with self-assigned 169.254.x.y addresses.