AW: zcip repair mechanism

Hi Brad,

> > But I dont understand, which conflicts are solved and which arent?
> Only actual conflicts - not possible conflicts.
> 
> > E.g. I tried the following:
> > - two connected devices and zcip running on both
> > - zcip chooses a unique IP address for both devices
> > - after a while, I mischievously assigned the IP address of 
> the first 
> > device
> >
> > 	to the second device (manually: ifconfig eth0 <IP1>), so that
> > 	both devices had the same IP addresses.
> > In this situation, neither the zcip-process of the first 
> nor zcip of 
> > the second device repairs the conflict. Is this behaviour 
> as expected?
> >
> > Can you tell me: what would be a test situation, where an 
> waiting zcip 
> > process would become active and solves an address conflict?
> As above, but you need to arp for the shared address.
> 
> The reason why this is the case is that you may have a couple 
> of machines that 
> come together for a small time (eg in an ad-hoc wireless 
> network). If they 
> don't communicate, there is no need to change the IP address.


Yes it worked! 

I observed, zcip doesnt realize any changes done
with ifconfig, meaning that zcip thinks that the valid IP address is
the one, that it has chosen last. 

example:
zcip on device1 chooses 169.254.1.1
zcip on device2 chooses 169.254.1.2
setting on device2: # ifconfig eth0 169.254.1.1

zcip on device1 knows, that it's IP is 1.1 but zcip on device2 assumes
wrongly, 
that it's IP is still 1.2

Therefore, pinging from device1 (e.g. # ping 169.254.1.3) has no effect on
device2, which get arps from 1.1, and zcip - still thinking it has 
1.2 address - sees no conflict and doesnt react.
The same ping run on device2, forces zcip on device1 to change its IP,
as intended by zcip.

This means, that the restriction of using zcip is, that no other
program should manipulate the address of the same interface, which is of
course
a justifiable assumption. 
The alternative would be, that zcip must perform periodically look-ups of
the own IP.


Thanks, Matthias
     


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com