[lwip-devel] [patch #9136] Device takes long to connect with some specific Access Points like Aiport Extreme

[Nirav Desai]

URL:
  <http://savannah.nongnu.org/patch/?9136>

                 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

    _______________________________________________________

Details:


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
is
NOT
an ARP Probe packet, hence should not be considered for address conflict use
case.

The ARP packets coming from Airport Extreme (mentioned in step 4 above) fall
in
the
second category - Source IP address NOT equal to all-zero IP address, as it
is
set
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

<http://savannah.nongnu.org/patch/download.php?file_id=38669>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?9136>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/