01-03-2019 08:32 AM
I am trying to access an aircube set to bridge mode behind a NanoStation in router mode connecting on the WAN via PPPoE.
I have set a DHCP address reservation for the airCube and a port forwarding rule sending TCP on port 8443 of the PPP interface address to port 443 of the internal private address assigned to the airCube in the forwarding rule. This appears to be working now but I had some problems setting it up.
One area where I had difficulty was choosing the MAC address for the DHCP address reservation. When I look on the airCube dashboard I see a certain MAC address, which agrees with what I see when I run a Device discovery scan from the NanoStation. When I check the actual 'DHCP Lease' link from the NanoStation main page however there is a variant.
I previously realized that the airCube would show a different MAC address when in router vs bridge mode but I am surpised that when in bridge mode the airCube dashboard, NanoStation discovery scan and NanoStation DHCP Lease values do not all agree. Can anyone explain how this works?
airCube Dashboard 78:XX:XX:9C:XX:XX
NS Discovery Scan 78:XX:XX:9C:XX:XX
NS DHCP lease 7A:XX:XX:9D:XX:XX
When I had the airCube in router mode the MAC was 78:XX:XX:9D:XX:XX; I think from a discovery scan but I don't actually recall.
thanks for any help offered.
01-03-2019 09:05 AM
I don't understand; clarify how?
Running a Discovery scan from the NanoStation shows the airCube with a different MAC address than what the NanoStation lists as having assigned under 'DHCP Leases'. I am surprised these aren't the same.
01-03-2019 10:56 PM
airCube (and all airMax family devices) answer with that interface MAC address, on which side it is scanned by Discovery utility. Thus you can see different MAC addresses on WAN, LAN and WLAN sides.
01-04-2019 06:52 AM
@UBNT-Kaledaim sorry.. but did you even read the issue?
it seems to be the same as i reported back in november (and am still waiting for an explanation/solution)
ONE, always THE SAME, physical connection (first LAN port in my case) is connected (in bridge mode). but when the aircube reboots (just that, not being replugged or whatever) it tends to *randomly* even report a DIFFERENT mac address...
there is a correct mac (on the sticker, in the dashboard, whatever tickles your fancy) and an invalid/different one,
and the aircube just randomly decides which one it uses to report to the dhcp server.
im slowly starting to lose hope with the aircube, seeing as i keep getting more issues and it doesnt really seem as if the issues are taken seriously.... shame, since i replaced a unifi AP with this because "its gotta be good and can be managed" and have had more issues than ever before.
i can respect that issues exist, but the (lack of actual) answers here make me think nobody really cares
01-04-2019 09:56 AM
@UBNT-SNKthis is surely not directed at you, but i am somewhat disappointed with kaleda's replies -when they happen to occur.
(november 17 is the last i have heard from kaleda in the thread about the mac changes, november 23rd was your last reply)
maybe having a "public" list of issues and some sort of triage-list saying which issue is being worked on and when the last update on that issue has been would help make me (and possibly others) feel more "at ease" about the aircube?
01-04-2019 07:20 PM
The aircube in question has a MAC address listed in the 'Dashboard' and elswhere as described previously
A MAC vendor lookup shows as this assigned to Ubiquiti.
The lease given by the NanoStation DHCP server is to an address beginning
This fails to return any result in the vendor lookup.
Researching a little reveals that MAC addresses of the form:
are recognized as locally adminsterred (LAA, https://en.wikipedia.org/wiki/MAC_address#Address_details) and so I conclude that the airCube has generated this "7A: ..." address from the original for some reason.
Under what circumstances would the airCube be generating a derived address?