Following up with a test case which shows what I think is a kernel bug. I've tested this on NetBSD-4.0.1, 5.0BETA and 5.99.4 - all the same. # ifconfig re0 alias 192.168.1.10/24 # ifconfig ral0 alias 192.168.1.20/24 # route change 192.168.1.0/24 -ifp ral0 change net 192.168.1.0 # ifconfig re0 -alias 192.168.1.10/24 # ifconfig re0 alias 192.168.1.10/24 ifconfig: SIOCAIFADDR: File exists # ifconfig re0 re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 1 mtu 1500 capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx> enabled=0 address: 00:50:8d:bb:da:f8 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::250:xxxx:xxxx:xxxx%re0 prefixlen 64 scopeid 0x1 As you can now see, it's impossible to add or remove any address in the 192.168.1.0/24 range to re0 until the subnet route itself is removed. If this is NOT considered to be a kernel bug then could someone please tell me how I should go about changing the connected route (as it's described in the source)? Attached is a simple shell test program. Thanks Roy
#!/bin/sh -x ifp1=re0 ifa1=192.168.1.10/24 ifp2=ral0 ifa2=192.168.1.20/24 snr=192.168.1.0/24 # Configure ifa's ifconfig $ifp1 alias $ifa1 ifconfig $ifp2 alias $ifa2 # Connect ifp2 route change $snr -ifp $ifp2 # Remove and then add ifa1. The add should fail - this is a bug. ifconfig $ifp1 -alias $ifa1 ifconfig $ifp1 alias $ifa1 ifconfig $ifp1 # Remove all aliases now route delete $snr ifconfig $ifp1 -alias $ifa1 ifconfig $ifp2 -alias $ifa2
Attachment:
signature.asc
Description: This is a digitally signed message part