LAN-to-WLAN ARP Issue with UAP-AC-LR

[SMCITDept]

Brilliant, I’m glad this is being looked at. Please keep us informed 

Many thanks.

[daisaa]

I think I'm having the issue.  I've been watching this thread and others waiting for some answers or a solution.

I have a Unifi Switch 8 POE-150W connected to a Unifi AP-AC-Pro.  My firewall/gateway is a Ubiqutiy ERX connected to the Unifi Switch 8.

Frequently I can't get a Google Pixel or a Samsung Galaxy Tab S2 to connect to a Google Chromecast.

All devices are on the same vlan and the same SSID.

Guest Policy is unchecked.

Multicast and broad cast filtering is unchecked

Multicast Enahancement is checked

When the issue occurs all devcies have access to the Internet.

Once while my Pixel was failing to connect to the Chromecast, I watched ARP requests off of a Mirror port that the Unifi AP-AC-Pro is connected to.  I saw the Chromecast ARPing for the IP of the Pixel "Who as 192.168.0.24? Tell 192.168.0.50"

  Ethernet Source: 08:93:08:aa:bb:cc .  <-- Chromecast mac address redacted

  Etherent Destinaton: ff:ff:ff:ff:ff:ff

    VLAN: 63

      ARP Sender MAC address: 08:9e:08:aa:bb:cc   <-- Chromecast mac address redacted

      ARP Sender IP address: 192.168.0.50               <-- Chromecast IP

      ARP Target MAC address: 00:00:00:00:00:00

      ARP Target IP address: 192.168.0.24                 <-- Pixel IP

I did not see an ARP responce

Restarting the Chromecast will sometimes fix the issue

Disconnecting and reconnecting the Pixel or Galaxy Tab will sometimes fix the issue.

Rebooting the AP always fixes the issue.

[AmazedMender16]

Hello @daisaa,

Please try firmware version 4.0.10

Regards,

Glenn R.

[ps105322]

Hi @AmazedMender16

Can you point us to what bug was fixed in version 4.0.10 that addresses the issues we are seeing here?

Thanks

[daisaa]

My unifi controller just notified me of the 4.0.9 update on Saturday Dec 8th, (a day after my post).  I upgrade the switch and AP to 4.0.9, I was on 3.9.54 for 70 days.

I will run 4.0.9 for a while first, since 4.0.10 appears to be a release candidate.

I didn't see anything specific in the 4.0.9 or 4.0.10 release notes specifically indicated there was a fix either.

If the bug fix is listed under "[HW] Miscellaneous bug fixes and improvements." I want to be able to explicity report that 4.0.9 or 4.0.10 GA resolved the issue.  Hopefully a developer is able to pinpoint what part of code was the culpruit.

I'l try to report back if anything has changed.

Happy Holidays

[SMCITDept]

Can confirm that 4.0.10 still does not fix this issue for me.

Please Ubiquiti? 

[ps105322]

4.0.10 did not fix the issue for us either.

[daisaa]

I can confirm the issue is still present in 4.0.9 and 4.0.10 stable.

[ps105322]

Its a sad ending to 2018.   Ubiquiti Support has been unable to provide a fix for this long-standing issue and we've moved on to a more reliable wireless infrastructure vendor (this issue has gone away with different hardware).  

Good luck on getting this fixed.

[SMCITDept]

It sure is sad.  I've pretty much given up hope too, especially when you look back at similar threads describing (what they don't know is) the same problem, from YEARS back.

What i can't understand is, how is something so fundamental to networking gear (the ability for ARP to even work correctly) broken, and why aren't far more users outraged?  I suspect average users notice the bug manifest in different ways, heavily dependant on setup and cirumstance no doubt, but this cannot be brushed under the carpet!

The issue has rendered us unable to remotely connect in to clients on the WLAN, in the company i work at, rendering support tickets a 'get-up-and-walk' job, wherever they are in the building.  Short of workaround solutions at least, but we've yet to implement any (and quite frankly, i'd just prefer the root cause be fixed!).

Any further comments, Ubiquiti, would be very much appreciated.

[SMCITDept]

I'm fairly certain this is looking to be fixed in latest firmware, i'm on 4.0.15.9872 after updating today, and i can't currently replicate the issue!  (controller version 5.9.29.0)

I see they've moved to the LEDE framework in the latest firmwares, i wouldn't be surpirsed if they've accidentally fixed the issue due to this, as i couldn't see the fix listed under the change log.

Others please post if you're seeing the same fixed for you

Update: appologies but the after a day, it seems to be resulting in the same old bug 

[daisaa]

I've been running it for 13 days, and I have had no issues yet.

[SMCITDept]

Scratch this.  Issue persists    Though it does seem improved, no longer does the issue begin after expiry of the ARP cache timer (60 secs), but i've seen wireless clients remaining pingable for well over 10-minutes.