ifconfig: side effects of new lladdr feature

[Andreas Bartelt <obsd_(_at_)_bartula_(_dot_)_de>]

Hi,

I've tested the new feature for changing the MAC address of an interface 
today. Most of the time it works with my CURRENT box, but sometimes 
there are problems. The problem is not changing the MAC address (this 
always works), but the network traffic after the change.

(IP was not changed in the following example)
example: #ifconfig fxp0 192.168.1.5 netmask 255.255.255.0 lladdr 
11:11:11:11:11:11

#tcpdump -nevvvSi fxp0
...
00:55:20.285173 11:11:11:11:11:11 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 
192.168.1.5 tell 192.168.1.5

After changing the MAC address, the interface always sends at least one 
ARP request for itself, but doesn't answer. Curiously, sometimes there 
are no problems with this, although there's never a visible reply to 
these ARP requests. I haven't found out the reason why new traffic after 
changing the MAC address sometimes works without problems and sometimes 
not yet.

Sometimes (but not always) other hosts (OpenBSD 3.6 stable) begin to use 
a multicast ethernet address (i.e. 1:0:5e:28:1:5; which is the correct 
mapping to the IP 192.168.1.5) to send packets to the host which 
recently changed the MAC address (TCP traffic). The host doesn't respond 
to these packets. Perhaps this is related to setting the interface with 
the changed MAC to promiscous mode (no -p option for tcpdump; I always 
started tcpdump on the host with the changed MAC address):

#tcpdump -nevvvSi fxp0
...
00:55:36.173196 0:60:8:69:8b:5d 1:0:5e:28:1:5 0800 78: 192.168.1.3.22 > 
192.168.1.5.43577: S [tcp sum ok] 2739091304:2739091304(0) ack 
3408283359 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 
0,nop,nop,timestamp 318258886 1474066462> (ttl 61, id 486, len 64)
00:55:36.173276 0:40:63:c9:d8:6 1:0:5e:28:1:5 0800 78: 192.168.1.3.22 > 
192.168.1.5.43577: S [tcp sum ok] 2739091304:2739091304(0) ack 
3408283359 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 
0,nop,nop,timestamp 318258886 1474066462> (ttl 60, id 486, len 64)
00:55:36.173399 0:60:8:69:8b:5d 1:0:5e:28:1:5 0800 78: 192.168.1.3.22 > 
192.168.1.5.43577: S [tcp sum ok] 2739091304:2739091304(0) ack 
3408283359 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 
0,nop,nop,timestamp 318258886 1474066462> (ttl 59, id 486, len 64)
00:55:36.173459 0:40:63:c9:d8:6 1:0:5e:28:1:5 0800 78: 192.168.1.3.22 > 
192.168.1.5.43577: S [tcp sum ok] 2739091304:2739091304(0) ack 
3408283359 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 
0,nop,nop,timestamp 318258886 1474066462> (ttl 58, id 486, len 64)
00:55:36.173590 0:60:8:69:8b:5d 1:0:5e:28:1:5 0800 78: 192.168.1.3.22 > 
192.168.1.5.43577: S [tcp sum ok] 2739091304:2739091304(0) ack 
3408283359 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 
0,nop,nop,timestamp 318258886 1474066462> (ttl 57, id 486, len 64)

Even more curiously, the MAC address of 192.168.1.3 ist 0:40:63:c9:d8:6, 
but 0:60:8:69:8b:5d is 192.168.1.6. So apparently tcpdump gives false 
output in this case.

When the interface isn't set to promiscous mode, I didn't see other 
hosts addressing the box with a multicast ethernet address yet, and I 
didn't see false IP/MAC mappings, too. But sometimes the box seems to 
ignore all frames addressed to the new MAC, although it sends out 
packets with the new source MAC address (i.e. when I try to establish a 
new ssh session).

I know this problem description is a little bit vague, but I've seen it 
several times now (and I've seen it working without problems several 
times, too). Can anybody reproduce these problems?

Regards,
Andreas