On Thu, Aug 13, 2009 at 02:25:38AM -0400, Eric Fausett wrote:
> I think some of this is really in NOOB territory, but your assistance would be appreciated to help deepen my 
understandng.  The following has been asked.
> 
> Suppose two networks A and B.
> Network A is running a DHCP server configured for 192.168.0.0/24
> Network B is not running DHCP but there are some clients on it using AutoIP configured local link addresses 169.154.0.
0/16
> 
> A QNX box is plugged into Network A and has dhcp.client running which configured an IP address on the interface en0.  
AutoIP has also been mounted with:
> mount -T io-pkt -oif=en0,abandon,delay=10 lsm-autoip.so
> 
> Now say that we unplug the network cable from Network A and plug it into Network B.
> 
> I understand that dchp.client doesn't have a mechanism to detect such changes.  My own testing using a USB dongle and 
the 'devn-asix.so' driver seems to indicate that the DHCP address would be kept until dhcp.client was manually slayed at
 which point AutoIP will take over and assign a new local link address that can be used on the new network.  Swapping 
the network cable back to Network A would again have to be accompanied by manually running dhcp.client which would 
overide AutoIP and assign an IP address obtained from a lease from the DHCP server running on Network A.
> 
> **** QUESTION 1 ****
> The question is, is there any standard way or utility that can be used to accomplish such physical switching 
automatically?  I'm guessing that the user would have to write such a utility to perhaps detect the state of the link 
and do other tests to automatically run and kill dhcp.client.  Any other ideas?
> 
> 
> The user on the other hand reports that after some time having the cable disconnected from Network A the following 
change can be seen on the interface:
> ** Network A connected:
> en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500
> 	address: 00:0a:79:13:95:6a
> 	inet 192.168.100.5 netmask 0xffffff00 broadcast 192.168.100.255
> 
> ** Disconnected:
> en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500
> 	address: 00:0a:79:13:95:6a
> 	inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
> 	inet alias 169.254.222.46 netmask 0xffff0000 broadcast 169.254.255.255
> 
> ** Network A Reconnected:
> en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500
> 	address: 00:0a:79:13:95:6a
> 	inet 169.254.222.46 netmask 0xffff0000 broadcast 169.254.255.255
> 	inet alias 192.168.100.7 netmask 0xffffff00 broadcast 192.168.100.255
> 
> 
> **** QUESTION 2 ****
> I can't reproduce this on the hardware I have available and can only guess that the behavior of dhcp.client in this 
case is dependent on some support in the driver that differs.  I'm not sure what driver this user is utilizing.  Could 
this be the case?  Why on disconnection does it seem that dchp.client is assigning an address of 0.0.0.0, this detected 
by AutoIP and AutoIP taking over with an alias?  And then the funkyness with DHCP using an alias upon reconnect?  
(AutoIP isn't using 'force')
> 
> Any assistance or additional information about the above would be greatly appreciated.
> 

Sounds like ifwatchd can accomplish this with a
carrier detect / no detect script assuming you're
running io-pkt with a native driver.

Regards,

-seanb