Re: r288951: ifconfig -alias, arp not removed

On 10/29/2015 16:56, Bryan Drewery wrote:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>> On 10/29/2015 11:25, Bryan Drewery wrote:
>>>> # ifconfig
>>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>
>>>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>>>>         ether c8:0a:a9:04:39:78
>>>>         inet 10.10.0.7 netmask 0xffff0000 broadcast 10.10.255.255
>>>>         inet 10.10.7.2 netmask 0xffff0000 broadcast 10.10.255.255
>>>>         inet 10.10.0.9 netmask 0xffff0000 broadcast 10.10.255.255
>>>>         nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
>>>>         media: Ethernet autoselect (1000baseT <full-duplex>)
>>>>         status: active
>>>>
>>>> # ifconfig igb0 inet 10.10.0.9 -alias
>>>> # arp -an|grep 10.10.0.9
>>>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
>>>> # arp -d 10.10.0.9
>>>> arp: writing to routing socket: Operation not permitted
>>>>
>>>> I swear this is not normal. I'm on an older build as well, r288951.
>>>
>>> That definitely looks abnormal.  See what "route get" says.  I think
>>> that's the error you get when there is a route for that address.
>>>
>>
>> # netstat -rn|grep 10.10.0.9
>> # route get 10.10.0.9
>>    route to: lapbox
>> destination: 10.10.0.0
>>        mask: 255.255.0.0
>>         fib: 0
>>   interface: igb0
>>       flags: <UP,DONE,PINNED>
>>  recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
>>        0         0         0         0      1500         1         0
>> # route get 5.5.5.5
>>    route to: 5.5.5.5
>> destination: default
>>        mask: default
>>     gateway: router.asus.com
>>         fib: 0
>>   interface: igb0
>>       flags: <UP,GATEWAY,DONE,STATIC>
>>  recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
>>        0         0         0         0      1500         1         0
>>
>> For more context, this current system had 10.10.0.9 added to it. I
>> started up a VM which also started using 10.10.0.9 and managed to "win"
>> on the local network for owning it. (I don't know arp and this stuff
>> well). I then came to this system to remove the alias and the arp entry
>> to allow me to connect from it and have gotten into this situation.
>>
> 
> Just saw this in dmesg, which is what I described:
> 
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0

The kernel should have removed the arp entry when you removed the alias.
 I just played with this on r289837 (one week old), and I could not
reproduce the failure.  In particular, r289501 sounds interesting, even
though your interface is up.

Eric