The only failure I'm seeing with the new beta firmware for the RBK50 is that my HP printer which is connecting wirelessly at 2.4G will lose it's connection daily. A static IP address seemed to do nothing ... very similar to the earlier posts re: Rainmachine. Only thing that would reset the wifi to the printer was to power cycle it. Perhaps just a limitation in the beta firmware that will get corrected as this was always stable in the past. The beta firmware did stop all of the crazy drops I was seeing recently, even with the prior "safe" auto-update firmware level ... this beta is definitely better in that respect ... harkens back to the good ole days.
What is the best procedure to set up a system w/ wired backhaul? I can't seem to get the system to fully recognize the sats with wired backhaul. To even get close I need to turn off daisy chain, sync with the sats unpluged, and then once the system is stable on the wireless side plug everything in...eventually it will start reporting wired backhaul, but even jumping through hoops like this the GUI never reports stable connections to the sats. Is there an optimal procedure that repeatably gets this to a stable, wired system?
I really can't understand how this wouldn't be tested even for a beta - did they really not factory reset, turn on the RBR, plug in ethernet, turn on RBS and sync? I'm not trying anythng remotely complicated here - so it's shocking to me that it doesn't just work...
My experience after upgrading to 2.1.3.4 has been great. All devices show up correctly and ethernet backhaul working.
My only observation is that one device, Lenovo Yoga book (android) which is my most used tablet at home still dropped connection (seemingly after sleeping) whilst backhaul was wireless. Now with ethernet backhaul, it hasn't dropped at all.
I had 2 crashes yesterday and today with new beta firmware 😞 (yes hard reset) for a week it would just have random lag but now it full on crashes
I removed my equipment with 10G nics and anything thats outdated and IOT I could think of *bascially down to just 2 laptops and a desktop
and still it crashed
(pretty sure If I just left it plugged in with nothing connected to it would crash itself in a week based on its software performance)
I have no issues with wireless connection/strength -- it is the main orbi that has dns issues then lags then crashes it dosen't matter what or how its connected
Anyone having issues with smart devices and Alexa? Alexa only seems to work half the time on my switches and says they are not responding when not working. Only started doing this when using the beta firmware.
Model: RBK50| Orbi AC3000 High-Performance Tri-Band WiFi System
@@jeffholiday wrote: Anyone having issues with smart devices and Alexa? Alexa only seems to work half the time on my switches and says they are not responding when not working. Only started doing this when using the beta firmware.
1-Gen1 Echo, 2-Taps, 2-Gen1 Dots, 6-Gen2 Dots all working without issue with an RBK53 system running V2.1.3.4.
@@jeffholiday wrote: Anyone having issues with smart devices and Alexa? Alexa only seems to work half the time on my switches and says they are not responding when not working. Only started doing this when using the beta firmware.
1-Gen1 Echo, 2-Taps, 2-Gen1 Dots, 6-Gen2 Dots all working without issue with an RBK53 system running V2.1.3.4.
I have 1 Gen 1 Echo, 1 Gen 1 Dot, 2 Gen 2 Dots, 1 Echo Spot.... All behaving perfectly. RBK53 V2.1.3.4
This has been the most stable firmware I've seen from Orbi, although the problems I had been experiencing with past firmware were much much less severe than others reported.
Sharing this for the techies here. While I have not had any perceived issues with the latest firmware (.34) on my RBK53 (but currently only using 1 of the 2 satellites that came with it) I did notice that DHCP requests seem to be a little odd. Here's an extract from my log once I remove all the DOS Attack stuff. Look at the .16 IP for example... It's a LIFX bulb and had multiple DHCP requests etc.... I would expect a device to get DHCP and then hold it until renewal:
[DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 07:55:26 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 06:46:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:24 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:46:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:43:43 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:41:18 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:39:51 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:36:41 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:05:20 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:04:16 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:57:30 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:51:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:58 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:53 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:20 [WLAN access rejected: incorrect security] from MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:39:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:38:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:24:22 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:23:35 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:21:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:20:29
Sharing this for the techies here. While I have not had any perceived issues with the latest firmware (.34) on my RBK53 (but currently only using 1 of the 2 satellites that came with it) I did notice that DHCP requests seem to be a little odd. Here's an extract from my log once I remove all the DOS Attack stuff. Look at the .16 IP for example... It's a LIFX bulb and had multiple DHCP requests etc.... I would expect a device to get DHCP and then hold it until renewal:
[DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 07:55:26 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 06:46:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:24 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:46:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:43:43 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:41:18 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:39:51 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:36:41 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:05:20 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:04:16 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:57:30 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:51:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:58 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:53 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:20 [WLAN access rejected: incorrect security] from MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:39:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:38:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:24:22 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:23:35 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:21:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:20:29
Looks like the rainmachine log I posted earlier. And just a little bit ago someone commented he had similar issues on a 2.4GHz device. Seems to be a common issue with this firmware.
Model: RBK50| Orbi AC3000 High-Performance Tri-Band WiFi System
I've been running the 2.1.3.4 Beta on my RBR50 router & (2) RBS50 satellites for a week now, and it's working great. I did do a paperclip reset on the satellites after upgrading from 2.1.2.18, but I have not factory reset the router.
The only negative change I've experienced with this FW is the satellite in a detached garage wouldn't connect to the router anymore (wasn't a great connection to start with). However, I purchased a Netgear Powerline 2000 kit, and Ethernet Backhaul is working flawlessly and much faster than the previous wireless connection.
The 2.1.3.4 Beta did fix:
Regularly dropped Verizon WiFi calling during calls (iPhone 8 Plus)
Complaints of broken audio on receiving end while on Verizon WiFi calling
"Not connected to Internet" issue on iPad Air 2 (while being connected to WiFi)
Belkin Wemo light controller being intermittently inaccessable by Alexa
Model: RBK53| Orbi Router + 2 Satellites Orbi WiFi System
@@jeffholiday wrote: Anyone having issues with smart devices and Alexa? Alexa only seems to work half the time on my switches and says they are not responding when not working. Only started doing this when using the beta firmware.
1-Gen1 Echo, 2-Taps, 2-Gen1 Dots, 6-Gen2 Dots all working without issue with an RBK53 system running V2.1.3.4.
I have 1 Gen 1 Echo, 1 Gen 1 Dot, 2 Gen 2 Dots, 1 Echo Spot.... All behaving perfectly. RBK53 V2.1.3.4
This has been the most stable firmware I've seen from Orbi, although the problems I had been experiencing with past firmware were much much less severe than others reported.
Similar issue with a particular device on my system:
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:57:50
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:57:16
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:56:45
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:56:12
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:54:18
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:53:12
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:52:16
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:51:47
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:51:09
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:50:42
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:50:05
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:49:15
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:48:18
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:47:33
This is a La Crosse wireless weather station with a WiFi chipset made by Espressif Inc..
The only anomaly I notice about this is that it loads a hostname of "espressif_32d8ee" which RFC1123 defines as an invalid character. ( https://en.wikipedia.org/wiki/Hostname )
Sharing this for the techies here. While I have not had any perceived issues with the latest firmware (.34) on my RBK53 (but currently only using 1 of the 2 satellites that came with it) I did notice that DHCP requests seem to be a little odd. Here's an extract from my log once I remove all the DOS Attack stuff. Look at the .16 IP for example... It's a LIFX bulb and had multiple DHCP requests etc.... I would expect a device to get DHCP and then hold it until renewal:
[DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 07:55:26 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 06:46:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:49:24 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:46:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:43:43 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:41:18 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:39:51 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 04:36:41 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:05:20 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 03:04:16 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:57:30 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:51:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:58 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:50:53 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:20 [WLAN access rejected: incorrect security] from MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:41:12 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:39:29 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Monday, April 02, 2018 00:38:08 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:24:22 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:23:35 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:21:42 [DHCP IP: 192.168.1.16] to MAC address d0:73:d5:**:**:**, Sunday, April 01, 2018 23:20:29
Looks like the rainmachine log I posted earlier. And just a little bit ago someone commented he had similar issues on a 2.4GHz device. Seems to be a common issue with this firmware.
Similar issue with a particular device on my system:
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:57:50
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:57:16
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:56:45
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:56:12
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:54:18
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:53:12
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:52:16
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:51:47
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:51:09
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:50:42
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:50:05
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:49:15
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:48:18
[DHCP IP: 192.168.68.103] to MAC address 60:01:94:32:d8:ee, Monday, April 02, 2018 07:47:33
This is a La Crosse wireless weather station with a WiFi chipset made by Espressif Inc..
The only anomaly I notice about this is that it loads a hostname of "espressif_32d8ee" which RFC1123 defines as an invalid character. ( https://en.wikipedia.org/wiki/Hostname )
I understood that fix for issue making Orbi nearly unusable was found in the meantime.
Currently I am spending ~1-2 hours / day trying to get Orbi to stable state (using ethernet backhaul - Wifi uplink not possible).
This is terrible experience considering the price of the product.
When I tried to open support ticket - for Orbi it never shows button to continue and I am looking at endless wheel rotating trying to find Orbi records is knowledgebase. When I tried for my Netgear X4S it works just fine (so it is on purpose?).
My setup is Netgear DL200 in bridge mode -> behind Nighthawk X4S with Wifi OFF -> behind is Netgear switch GS108 -> behind is RBR40 and 2x RBS40 (all AP mode).
*Problems experienced are:
*Disconnection of Apple devices from WiFi
*Suden unavailability of Wifi to any device
*No Internet access
*First or second satellite start flooding network with packets -> network down
When everything runs (and I am lucky) I see zero satellites reported to RBR40 (shows 0 in iPhone app and in WebUI at the same time)
I spent quite a lot of money on Netgear equipment (for home use) and now with latest 500$ purchase I got worst experience.
When the new version of firmware containing the fix is going to be released?
(since I can not contact support using my account I am writing here)
I updated to the newest firmware and it worked for a few days error free. I had an issue where I lost internet yesterday, and reset both the router and the satellite. This worked for a few hours. Now it appears as if anything attached to the satellite is losing internet. If I reset the satellite, it works for a while, then same symptoms. I have unplugged the satellite and currently don't have any issues. I'm going to leave the satellite unplugged and see how things are for the rest of the day.
This is beyond frustrating. I have been trying to deal with this since I bought the Orbi in December. There seems to be no recourse here....I can't keep these devicies much longer if this isn't fixed/addressed.
If someone from netgear wants to gather data, let me know. I have a wide array of devices (kindles, alexa, android, iPhones). I'm more than willing to help.
