[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #9136] Device takes long to connect with some specif

From: Nirav Desai
Subject: [lwip-devel] [patch #9136] Device takes long to connect with some specific Access Points like Aiport Extreme
Date: Thu, 6 Oct 2016 07:37:23 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36


                 Summary: Device takes long to connect with some specific
Access Points like Aiport Extreme
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: niravisneo
            Submitted on: Thu 06 Oct 2016 07:37:20 AM GMT
                Category: ARP
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None



RFC 2131 : Dynamic Host Configuration Protocol

Here is brief workflow of DHCP address acquistion
1.      Device to AP – DHCP discover
2.      AP – broadcast ARP probe before offering an IPv4 address
3.      AP to Device – DHCP offer
4.      Device – broadcast ARP probe to check if that IPv4 address
        is already in use
5.      If no address conflict found then Device to AP – DHCP request
        confirming that it is ready to use this IP
6.      AP to Device – DHCP ACK
7.      Else part of step 5, if there is some address conflict
        found then Deviceto AP – DHCP Decline

However found an issue with Apple Airport Extreme, where it sends ARP packet
for same IP
while giving DHCP offer (Step 4)

In step 4, additional checks need to be done to correctly isolate "conflicting
ARP probes"
If both of the following conditions hold true, then only the given ARP packet
"may" be a "conflicting ARP Probe"
- Check if Source IP address is all-zero IP address,
    so as to qualify the packet to be called as "ARP Probe"
- Check if sender MAC address is not same as our own
    MAC to ensure that own ARP packet is not received back.
  This can happen with some kinds of Ethernet hub and some WiFi
  APs which may "rebroadcast" any received broadcast packets

If either of the above condition do not hold true, then the given ARP packet
an ARP Probe packet, hence should not be considered for address conflict use

The ARP packets coming from Airport Extreme (mentioned in step 4 above) fall
second category - Source IP address NOT equal to all-zero IP address, as it
to IP address of Airport Extreme.
Hence these packets would not considered for address conflict use case.


File Attachments:

Date: Thu 06 Oct 2016 07:37:20 AM GMT  Name: LWIP-ETHARP-Enhancements.patch 
Size: 4kB   By: niravisneo



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]