Eric Fausett
|
DHCP and autodetection of physical network change
|
Eric Fausett
08/13/2009 2:25 AM
post35872
|
DHCP and autodetection of physical network change
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.
Cheers,
Eric
|
|
|