10-10-2018 04:24 PM
so, the issue i am having is:
there are 2 MAC addresses for my aircube, and it appears as if with every reboot of the device it randomly selects which one it uses to query the dhcp server.
i have fc:ec:da:27:a9:0d and fe:ec:da:27:a9:0d, and when rebooting it selects, seemingly at random,
one of those 2 to request a dhcp address.
it still uses the correct vlan, but since it is requesting an ip from the management dhcp server, with the wrong mac,
the device becomes unreachable.
the device is an aircube-isp, in bridge mode, with a management an data vlan.
the expected behaviour would be to have only 1 macaddress for 1 interface requesting dhcp on the vlan,
therefor this has to be a bug - and its a darn annoying one at that!!
10-10-2018 04:33 PM
since fc:ec:da:27:a9:0d is the registered OUI for ubiquiti, i would assume the alternative (fE....) should never be showing itself to a dhcp server, since in a lookup it would come back as unknown.... (and would be bad for, for example, OUI QOS rules)
and for an example: it registers to the dhcp server with the correct, FC.... mac address.
i subsequently activate the night mode for the led, it reboots (?) and gone is my access.
i hop back over to my dhcp server logs and see it hopped to the FE address:
Oct 11 01:05:11 dhcpd: DHCPACK on 10.0.5.21 to fe:ec:da:27:a9:0d via re1_vlan1005
Oct 11 01:05:11 dhcpd: DHCPREQUEST for 10.0.5.21 (10.0.5.1) from fe:ec:da:27:a9:0d via re1_vlan1005
Oct 11 01:05:11 dhcpd: DHCPOFFER on 10.0.5.21 to fe:ec:da:27:a9:0d via re1_vlan1005
Oct 11 01:02:53 dhcpd: DHCPDISCOVER from fe:ec:da:27:a9:0d via re1_vlan1005: network 10.0.5.0/24: no free leases
Oct 11 00:58:21 dhcpd: DHCPACK on 10.0.5.20 to fc:ec:da:27:a9:0d via re1_vlan1005
Oct 11 00:58:21 dhcpd: DHCPREQUEST for 10.0.5.20 (10.0.5.1) from fc:ec:da:27:a9:0d via re1_vlan1005
Oct 11 00:58:21 dhcpd: DHCPOFFER on 10.0.5.20 to fc:ec:da:27:a9:0d via re1_vlan1005
Oct 11 00:57:58 dhcpd: DHCPDISCOVER from fc:ec:da:27:a9:0d via re1_vlan1005: network 10.0.5.0/24: no free leases
10-18-2018 12:35 AM - edited 10-18-2018 12:40 AM
I have seen this show up in DHCP logs as well, it’s only for AirCubes used in bridge mode. We only use bridge mode for as long as it takes to update them.
it was the second character of the MAC address changed in our case as well, not the normal (in the middle of the MAC string) change between using bridge and router mode.
10-18-2018 05:28 AM
for me, putting it in router mode is not an option as it is meant to be a replacement for the older UAPs,
and it is just meant to be a wifi AP for the home users, behind a network that can be easily controlled through unms and sits behind an opnsense firewall/router setup.
10-22-2018 02:11 PM
@UBNT-Kaledaany more information on this?
i just thought i had stopped seeing the issue, but i was wrong...
- aircube ISP, firmware 2.4.0
- setup as bridge, data vlan and management vlan
the first time i noticed it, i had just enabled the led night mode.
earlier today, i had rebooted the device - still got the correct MAC (and thus dhcp lease)
right now, i modified the led night mode (timezone and hour)... and *poof* it came back with the wrong mac.
thinking it might be related to changing the system/led/hour settings, i tried changing them while registered with the wrong mac/dhcp... but that does not cause the device to go back.
a reboot brings it back to registering with the correct mac address, and subsequently changing the led time/timezone brings it back to the wrong mac.
it seems that this is perfectly reproducible:
- go to the aircube, which has a dhcp lease with its correct mac
- change timezone/led settings : see it re-register with a false mac address
- this stays this way until a reboot, even when changing settings
- after a reboot, all is normal again until you make another change