patchlwIP - A Lightweight TCP/IP stack - Patches: patch #9136, Device takes long to connect with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #9136: Device takes long to connect with some specific Access Points like Aiport Extreme

Submitter:  Nirav Desai <niravisneo>
Submitted:  Thu 06 Oct 2016 07:37:20 AM UTC
   
 
Category:  ARP Priority:  5 - Normal
Status:  Invalid Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Planned Release:  None

Thu 03 Nov 2016 09:49:15 AM UTC, comment #5: 

I would have preferred to know what the actual problem is, but without your help, I'll close this as invalid.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 13 Oct 2016 10:13:44 AM UTC, comment #4: 

Hi
As you  mentioned it is Access Point specific we are trying to figure out a better way to resolve it.

Nirav Desai <niravisneo>
Thu 13 Oct 2016 09:32:25 AM UTC, comment #3: 

Any progress on this?

Simon Goldschmidt <goldsimon>
Group administrator
Thu 06 Oct 2016 08:05:23 AM UTC, comment #2: 

I am using  LWIP port which is available around mid Sept

I will update with packet trace when I get it.
Also will update an improved  patch and description for the mentioned  issue.
It is some what Apple specific but having extra checks is good

Will keep you posted with 
   1. new  clear patch
   2. packet capture





Nirav Desai <niravisneo>
Thu 06 Oct 2016 07:58:01 AM UTC, comment #1: 

I cannot follow your description. Plus the patch does not seem to make sense (handling DHCP internals like state in etharp.c is not a good approach; variable 'conflicting_probe' seems unused?).

Could you attach a packet trace showing the time and contents of the packets you describe?

In general, feedback packets (src mac == our mac) must be filtered out (to prevent some endless loop conditions), so the patch does target specific AirPort behaviour instead of targeting generic wifi behaviour (as you describe it).

BTW: Which version of lwIP are you using?

Simon Goldschmidt <goldsimon>
Group administrator
Thu 06 Oct 2016 07:37:20 AM UTC, original submission:  


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.


Nirav Desai <niravisneo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by niravisneo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-03 goldsimon StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2016-10-06 goldsimon StatusNone Need Info
    2016-10-06 niravisneo Attached File- Added LWIP-ETHARP-Enhancements.patch, #38669

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code