buglwIP - A Lightweight TCP/IP stack - Bugs: bug #49610, Sometimes, autoIP fails to reuse...

 
 

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

bug #49610: Sometimes, autoIP fails to reuse the same address

Submitted by:  Roberto Barbieri Carrera <sebulain>
Submitted on:  Tue 15 Nov 2016 12:22:49 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Fixed
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: 1.4.1

Wed 16 Nov 2016 11:25:22 AM UTC, comment #2:

Pushed, thanks for the patch.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 15 Nov 2016 12:35:39 PM UTC, comment #1:

I'd have to double test this before pushing a fix, but I think you're right.

Too bad this came in just days after the 2.0.0 release :-/

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 15 Nov 2016 12:22:49 PM UTC, original submission:

Hello

I use lwIP 1.4.1, but I compared the code and think that the new 2.0 should show the same fault.

If the machine uses its assigned autoIP address for a while, in which some network traffic with others is established, and then it restarts, sometimes the newly assigned autoIP address is not the previous one.

I think I tracked this down to the autoip.c file not exactly implementing what RFC3927 says.

The code is (autoip.c):

But it whould be:

The RFC states:
If during this period, from the beginning of the probing process
until ANNOUNCE_WAIT seconds after the last probe packet is sent, the
host receives any ARP packet (Request or Reply) on the interface
where the probe is being performed where the packet's 'sender IP
address' is the address being probed for, then the host MUST treat
this address as being in use by some other host, and MUST select a
new pseudo-random address and repeat the process.

Which is correctly implemented.

But then it says:
In addition, if
during this period the host receives any ARP Probe where the packet's
'target IP address' is the address being probed for, and the packet's
'sender hardware address' is not the hardware address of the
interface the host is attempting to configure, then the host MUST
similarly treat this as an address conflict and select a new address
as above. This can occur if two (or more) hosts attempt to configure
the same IPv4 Link-Local address at the same time.

The code checks this without making sure that the received packet is strictly a PROBE.

Probes must have the own address set to zero.

Any other node might send an ARP request with this address as the target, without saying that it wants to use the address. This is normal in IP exchanges.

A collision happens in this case only when the received packet is actually a probe.

Kind regards,
Roberto Barbieri Carrera

Roberto Barbieri Carrera <sebulain>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 16 Nov 2016 11:25:22 AM UTCgoldsimonStatusNone=>Fixed
      Assigned toNone=>goldsimon
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1