Reply
Ubiquiti Employee
Posts: 4,009
Registered: ‎01-11-2016
Kudos: 1196
Solutions: 29

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@mrjmc99 This is actually an issue that seems to happen randomly on firmware upgrades for quite some time now (years?). We are still working on a proper fix (both on AP and switch sides), but it can be resolved by rebooting the AP, for now Man Sad
Want to try out new features or fixes before they're released as Stable? Sign up for Beta here: https://help.ubnt.com/hc/en-us/articles/204908664-How-To-Signup-for-Beta-Access
Having connectivity issues? See: https://help.ubnt.com/hc/en-us/articles/221029967-UniFi-Debugging-Intermittent-Connectivity-Issues-on-your-UAP
New Member
Posts: 25
Registered: ‎06-28-2017
Kudos: 1

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

I see random reboot on US8 :-(

 

unifias

New Member
Posts: 44
Registered: ‎05-10-2016
Kudos: 17
Solutions: 1

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@UBNT-jeff wrote:
@mrjmc99This is actually an issue that seems to happen randomly on firmware upgrades for quite some time now (years?). We are still working on a proper fix (both on AP and switch sides), but it can be resolved by rebooting the AP, for now Man Sad

@UBNT-jeff With all the respect for your great work I like to remind UBNT there are many small customers that are not so deep in all the release details an forum conversations. They rather buy a product which is promissing great experience out of the box. They unbox it, uprade to latest firmware, configure it and are disapointed e.g. about the speed. And than the journey beginns: Reading hundreds of threads in the communitiy forums. Installing Beta Software and workarounds. Just trial and error. This is just annoying and frustrating. Not everybody is a tech nerd. There are "standard" consumers too (I don't mean my grandma by that).

 

This is an excellent example here. Many users feedbacked the 100FX issue. For good luck you gave a statement. But unfortunately it does not make things better. "Reboot it and we are working on it" (for another year?) is just not the solution we are waiting for.

 

I would expext UBNT to follow this priorities in realease planning and put their energy into the topics in that order:

1. Stable & Relaiable -> I want the things to be working that I have paied for.

2. Simple -> I want the tings to just work. No digging in forums and searching for workarounds, partially promised for years (e.g.  IGMP-Proxy can't be configured via the GUI)

3. Innovative -> I want MY products I have paied for to be stable, relaiable and feature complete BEFORE you release new products. I paied for that and I think it should be an obligation and a question of honor for UBNT to provide what was promised and sold. Even if the money was received already.

 

Please make sure that stable releases are in a high quality before they get realeased. And if possible please finally add the features you committed years ago and people are waiting, hopeing and bagging....

 

I'm very sorry to hijack the thread for complaining. But as I believe there is much more like bits and bytes to make a product and a release great. It's also a question of focus, quality, output and trust.

 

Thanks for hearing me.

Regular Member
Posts: 343
Registered: ‎10-23-2016
Kudos: 93
Solutions: 2

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@UBNT-jeff I understand that there might be more than 1 root cause to this issue. The amount of users reporting it spiked with this build. A few of us were able to consistently reproduce the issue. Here is the scenario used:

 

AP connected to poe injector:

 

Pull lan cable while leaving power to ap, this causes a link loss and when plugging the cable back in, say after 30 seconds, the AP gets stuck on 100FDX. This would simulate a switch reboot on the other end of a poe injector.

 

AP connected to unifi poe switch:

 

Reboot a unifi switch, poe stays on, but the switch port link is lost, same occurs as above, ap gets stuck on 100FDX.

 

A reboot of the ap resolves the issue.

 

@UBNT-schmid saw some of the conversation when we were testing this out last week. 

 

Hope this helps.

Emerging Member
Posts: 90
Registered: ‎04-09-2016
Kudos: 25
Solutions: 3

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

There are a lot of comments in the Beta forum about DHCP failing to renew when clients roam between APs and clients end up with a 169.x.x.x address. Since most of my devices are Apple devices, I assumed that they were to blame but the issue seems more widespread.
Senior Member
Posts: 3,333
Registered: ‎05-19-2013
Kudos: 1451
Solutions: 33

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@mrjmc99

I have done my fair share of deployments and maintenance. Not once have I encounter this '100FDX' issue over the years and almost testing out every single firmware released (skipped a few which had deadly bricking risk or pulled before I get the chance to update in test environments) until today. Of the handful I was rolling out this 4.30.10217 firmware over these two days, only the new deployment I was doing the final tests and decided to update the firmware to 4.30.10217 which exhibited on 2 out of 3 UAPs (happened that both affected are AC-LR, the only which did not get affected is AC-PRO).

I do believe what jeff has shared - it is random, very random. For this particular (first) instance I have just experienced, there is nothing usual about the entire setup from many others I have done and have been updating. The sequence of update is UAPs first then US-8-60. However, subsequent reboot of USW was unable to reproduce this '100FDX' issue.

Come to think of it. The only difference I can think of is that this is the only deployment I have not personally inspected the termination points. Normally I will inspect them given many of the electricians or cable pullers often do not have decent networking knowledge and tends to strip the CAT6 of its outer skin for extra length than really necessary + untwisting the pairs for extra length than really necessary to crimp or punch down.
Senior Member
Posts: 3,333
Registered: ‎05-19-2013
Kudos: 1451
Solutions: 33

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@wavesound wrote:
There are a lot of comments in the Beta forum about DHCP failing to renew when clients roam between APs and clients end up with a 169.x.x.x address. Since most of my devices are Apple devices, I assumed that they were to blame but the issue seems more widespread.

While there are posts on this, I just want to share that there are also non-posted instances where this does not happen at all. In short, the real cause of it does not seem to be a single factor.

 

I have tens of deployments and none are experiencing this for those under our maintenance, and no feedback for those not under our maintenance so far. One difference I can think of is use of USG and perhaps a set of features enabled on UniFi platform (be it on USW or UAP). Reason being ~95% of our deployments do not use USG (a long topic to share on why). They are either on ISP's ONR or EdgeRouter. Perhaps the simplicity setup of all these deployments helped avoid facing this 'DHCP-related' issue.

New Member
Posts: 44
Registered: ‎05-10-2016
Kudos: 17
Solutions: 1

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@chaicka wrote:
@mrjmc99

.... often do not have decent networking knowledge and tends to strip the CAT6 of its outer skin for extra length than really necessary + untwisting the pairs for extra length than really necessary to crimp or punch down....

I would of course agree the correct cabling is of great importance. How ever. A reboot solves the problem. So there must be a different signal state on the according ports before and after the reboot. Or the Firmware is buggy or its maturity does not allow to effectively analyse the signal quality comming along with the cable and take the right decisions. I would recommend to put some more analysis into this issue to further narrow down the cause.

 

Same with DHCP. Some releases ago it was working properly. Now it doesn't. So a change must have make things worse in the past. 

 

 

New Member
Posts: 7
Registered: ‎02-01-2017
Kudos: 3

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

[ Edited ]

I am seeing very long and fluctuating ping spikes up to 1200ms on different clients. Using UAP-AC-LR.

New Member
Posts: 10
Registered: ‎03-24-2018
Kudos: 9

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

Hiya,

 

Pleased to report - 4.0.30 is more stable in many ways, however, it seems to not forward broadcast traffic. Started off noticing that IPv6 wasn't working consistently. Connected a laptop direct (Wired) and can see all broadcast traffic. Connected via wireless (UAP AP AC Pro) - no broadcast traffic received.

 

Able to reproduce with "ping -b 192.168.x.255 -I interface" whist running wireshark on both the wired source and the [wireless|wired] receiver.  All brodcasts received when receiver connected via ethernet/wired, none received on wireless. This is NOT a guest SSID. I do have a guest SSID configured, however it is not this one.

 

Unifi config - as vanilla as I can get whilst not causing a firestorm by breaking my family service contract ;-)   :

 

  • UniFi AP-AC-Pro - running this release,
  • 6 SSIDs, one guest, others are IOT/trusted/dmz/ with schedule controlled
  • Wired backhaul
  • No "advanced features"
  • Auth: WPA personal
  • NOT a guest SSID
  • Rekey interval 3600 seconds (toying with reducing.)
  • "Block LAN to WLAN Multicast and Broadcast Data" not enabled (A test with this enabled and router / broadcast source MAC listed had same result)
  • No fast roaming
  • No vlan (for this SSID)
  • Not a hidden ssid
  • No UAPSD for all SSIDs
  • No wlan schedule for this test SSID
  • Multicast enhancement enabled & disabled - both same result.
  • "High performace devices " not enabled for all
  • DTIM @ 3 seconds for both
  • No data rate controls enabled.
  • No MAC filter

Verified broadcast is working by:

  • Wired network - to same switch - works fine using wireshark on sender&receiver.
  • Wireshark - verified MAC destination is FF:FF:FF:FF:FF:FF (yep, it's really a broadcast frame)

Verified ping is working using unicast ping. Echo request and response working fine. Unicast=ok-cool.

 

Happy to provide any more info on request.

 

Dave

 

--

 

Regular Member
Posts: 343
Registered: ‎10-23-2016
Kudos: 93
Solutions: 2

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@chaicka do you have wireless up link enabled? I have it disabled, I have not tested with it enabled yet, I'll do that shortly, Its possible that if wireless up link is enabled that the ap correctly resets the Ethernet port so it can get 1gb after link loss.

Regular Member
Posts: 343
Registered: ‎10-23-2016
Kudos: 93
Solutions: 2

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@UBNT-jeff I did some testing in several builds. In my setup I am only able to get the 100FDX issue on my AC-M on builds 4.0.29 and 4.0.30. If I load 4.0.28 and below I am unable to reproduce the issue. With  .29 or .30 I can reproduce it every time I reboot my us8 that is powering the ap.

 

Let me know if you want pull logs or get in my ap.

 

 

Senior Member
Posts: 2,738
Registered: ‎04-21-2015
Kudos: 404
Solutions: 108

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@davetick  Two clients connected to the same AP,  can they ping each other? 

Thanks,
Myky
CWNA
--------------------------------------------------------------------------------------------------------------------------------------------------
Don`t blame the device as it`s always doing what you have asked it to do, this is not always the same as what you want.
New Member
Posts: 10
Registered: ‎03-24-2018
Kudos: 9

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@myky. - just tried and yes. Verified I can ping between two wireless clients on the same AP, channel and SSID.

 

Confused as doing this proves ARP is working, which uses broadcast?? 

 

Thanks!

 

Dave

 

 

---

Senior Member
Posts: 2,738
Registered: ‎04-21-2015
Kudos: 404
Solutions: 108

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

@davetick  Yes that is correct.

 

I have tested with nanoHD between two wireless clients and could see broadcast packets while pinging .255 IP address:

 

br.JPG

Thanks,
Myky
CWNA
--------------------------------------------------------------------------------------------------------------------------------------------------
Don`t blame the device as it`s always doing what you have asked it to do, this is not always the same as what you want.
New Member
Posts: 22
Registered: ‎02-13-2019
Kudos: 6
Solutions: 2

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@chaicka wrote:

@wavesound wrote:
There are a lot of comments in the Beta forum about DHCP failing to renew when clients roam between APs and clients end up with a 169.x.x.x address. Since most of my devices are Apple devices, I assumed that they were to blame but the issue seems more widespread.

While there are posts on this, I just want to share that there are also non-posted instances where this does not happen at all. In short, the real cause of it does not seem to be a single factor.

 

I have tens of deployments and none are experiencing this for those under our maintenance, and no feedback for those not under our maintenance so far. One difference I can think of is use of USG and perhaps a set of features enabled on UniFi platform (be it on USW or UAP). Reason being ~95% of our deployments do not use USG (a long topic to share on why). They are either on ISP's ONR or EdgeRouter. Perhaps the simplicity setup of all these deployments helped avoid facing this 'DHCP-related' issue.


Most of the DHCP-related issues that people are posting seem to be related to Windows Server DHCP, hence why you aren't seeing issues.

In my experience it also seems to be more related to 5GHz as turning the 5GHz radio off seems to solve my issues.

 

To me this also appears to link in to the prevalence of reports of Apple products having DHCP issues, in that maybe they bandsteer more aggressively towards 5GHz. That part is pure speculation though.

New Member
Posts: 12
Registered: ‎05-06-2016

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

Using 4.0.30 for us has brought guest network issues. Guests can connect but never receive a login page or redirect when using external portal server. There is no 302 redirect generated by the WAP.

 

Downgrading to 4.0.21 solves the problem immediately.

Senior Member
Posts: 3,333
Registered: ‎05-19-2013
Kudos: 1451
Solutions: 33

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@FiCastle wrote:

@chaicka wrote:
@mrjmc99

.... often do not have decent networking knowledge and tends to strip the CAT6 of its outer skin for extra length than really necessary + untwisting the pairs for extra length than really necessary to crimp or punch down....

I would of course agree the correct cabling is of great importance. How ever. A reboot solves the problem. So there must be a different signal state on the according ports before and after the reboot. Or the Firmware is buggy or its maturity does not allow to effectively analyse the signal quality comming along with the cable and take the right decisions. I would recommend to put some more analysis into this issue to further narrow down the cause.

 

Same with DHCP. Some releases ago it was working properly. Now it doesn't. So a change must have make things worse in the past. 

 

 


Agrees and hence why I mentioned the issue is rather random. I shared the only difference for one site which experienced this issue but I do not believe that being the cause. In short, just sharing how random this issue really is and does not seem to have a definite known cause yet.

New Member
Posts: 12
Registered: ‎02-03-2018
Kudos: 1

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate

[ Edited ]

This release caused total chaos on my network. Total unavailbility with me trying to power cycle switches to get some sort of stability. Eventually was able to see cloud key for a brief moment and was able to downgrade the switches, which reinstated stability. I don't know whatis going on with this release, but here is what I saw in the syslog after the upgrade. It's almost as though the system was brought to its knees writing enormous amounts of logs to disk/syslog forwarding.

 

I have one USG, six (6) AP-AC-PROs, one US-16-150W (core), one US-8-60W (downlink from core), and a gen1 cloud key connected to the US-8-60W.

 

Thousands of these entries

  • br0: received packet on vwire6 with own address as source address
  • br0: received packet on vwire6 with own address as source address
  • br0: received packet on vwire6 with own address as source address
  • br0: received packet on vwire6 with own address as source address
  • br0: received packet on vwire6 with own address as source address
  • br0: received packet on vwire6 with own address as source address
  • kernel: [ 104.085171] net_ratelimit: 791 callbacks suppressed

Then, thousands of this log entry

[wifi1] FWLOG: [273902] VDEV_MGR_DEBID_DEFINITION_START ( 0x3, 0x40, 0x1, 0x6 )

 

Then, thousands of this entry

kernel: [ 137.208522] ieee80211_assoc_state_mlme_wait_event: waiting for mlme cancel to complete

 

Then, the worst was *thousands* of these log entries thrown, per second

kernel: [ 6372.352224] wmi_unified_cmd_send : Cookie alloc Failed for cmd_id : 9024

Emerging Member
Posts: 90
Registered: ‎04-09-2016
Kudos: 25
Solutions: 3

Re: [FIRMWARE] 4.0.30.10217 for UAP/USW has been released | Stable Candidate


@chaicka wrote:

@wavesound wrote:
There are a lot of comments in the Beta forum about DHCP failing to renew when clients roam between APs and clients end up with a 169.x.x.x address. Since most of my devices are Apple devices, I assumed that they were to blame but the issue seems more widespread.

While there are posts on this, I just want to share that there are also non-posted instances where this does not happen at all. In short, the real cause of it does not seem to be a single factor.

 

I have tens of deployments and none are experiencing this for those under our maintenance, and no feedback for those not under our maintenance so far. One difference I can think of is use of USG and perhaps a set of features enabled on UniFi platform (be it on USW or UAP). Reason being ~95% of our deployments do not use USG (a long topic to share on why). They are either on ISP's ONR or EdgeRouter. Perhaps the simplicity setup of all these deployments helped avoid facing this 'DHCP-related' issue.


@chaicka 

 

Others have reported that you need to use VLANs with your SSIDs for the issue to appear. I'm using a USG as well as Ubiquiti switches which is also different from your deployment. Users in the beta forum are also reporting that the issue goes away if you revert back to 3.9.x.

Reply