[BusyBox 0001005]: zcip does not claim another IP after defending

bugs at busybox.net bugs at busybox.net
Wed Aug 23 04:20:42 UTC 2006


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1005 
====================================================================== 
Reported By:                pnoffke
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   1005
Category:                   Networking Support
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             08-22-2006 17:19 PDT
Last Modified:              08-22-2006 21:20 PDT
====================================================================== 
Summary:                    zcip does not claim another IP after defending
Description: 
I've discovered another problem with zcip.  When an IP address has been
claimed, the defending did not work properly.  When I set another host to
use the claimed IP address, zcip would deconfig the IP, but never grab
another one.

I've tracked it down to improper use of the poll function.  The code had
previously used a return value of 0 (timeout) to trigger state
transitions, and a return value of 1 (packets arriving) for conflict
detection.  However when probing, if a packet arrived, this would result
in the timeout getting set to -1 (infinite) and the probing would never
continue.  I've modified zcip to use a state machine, with 5 states:

PROBE
RATE_LIMITED_PROBE
ANNOUNCE
MONITOR
DEFEND

It moves through these states according to RFC 3927.  For example, three
timeouts (with no conflicts arriving) in the PROBE state cause a
transition to the ANNOUNCE state.  Or if a conflict is detected in the
MONITOR state, it sends a single ARP and moves to the DEFEND state.  If
another conflict arrives in the DEFEND state, we go back to the PROBE
state and start all over again.

I hope the code is easier to follow -- I know it was much easier to debug
this way.

====================================================================== 

---------------------------------------------------------------------- 
 pnoffke - 08-22-06 21:20  
---------------------------------------------------------------------- 
Jason Schoon has pointed out this was fixed here:

http://www.busybox.net/lists/busybox/2006-March/019881.html

I have tested on 1.2.1 and it seems to work.  I upgraded from 1.1.1 to
1.2.1 prior to writing the patch, and did not test after upgrading to
confirm whether the defending worked.

You may still wish to apply the patch if you prefer the state machine
implementation.  Personally I find it easier to follow the code this way,
but whether that is reason enough to patch it isn't my call.  As far as I
can tell everything works correctly with my patch. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-22-06 17:19  pnoffke        New Issue                                    
08-22-06 17:19  pnoffke        Status                   new => assigned     
08-22-06 17:19  pnoffke        Assigned To               => BusyBox         
08-22-06 17:19  pnoffke        File Added: busybox-1.2.1-zcip.patch             
      
08-22-06 17:19  pnoffke        Issue Monitored: pnoffke                     
08-22-06 21:20  pnoffke        Note Added: 0001578                          
======================================================================




More information about the busybox-cvs mailing list