Re: Orbi Showing Wireless Devices as Wired in Attached Devices List
Hi,
I just closed out my support case with Netgear on this issue. It took 4 months (opened in August, finally closed in January) and I spent much of that time being passed back and forth between support associates. But in the end, Netgear finally admitted to me the following about this particular issue.
From Support:
"I have confirmed with our engineers that the satellite has a limitation with reporting connected devices while its in ethernet backhaul as the router identifies that the wired backhaul connection of the satellite rather than the actual connection of the device to the satellite which are engineers a indicated that it is a limitation in the design of the system.
I apologize for the inconvenience. Let me know if you have questions or concerns."
I then asked:
"Is it unfixable and therefore a product flaw that just needs to be lived with?"
And was told:
"As I have confirmed that this is a limitation as per our engineers. We were only informed of this upon consultation with our engineers and I sincerely apologize if it took awhile to get answers for you."
(Note: This answer from Engineering took 4 months to get to.)
So in short, the way the Orbi system is designed, it is impossible for them to report properly whether a device is Wired or Wireless if any of the satellites are using Ethernet Backhaul.
In my investigation into how the Orbi works (which under the covers appears to use technology provided by Fing to do device discovery), here is what I summarized based on a discussion with technical support at Netgear:
"After noting that all of the devices incorrectly labeled as Wired were coming from the RBS40V, you suggested that we remove the Ethernet backhaul from that specific satellite to see if it would correct the problem. I did this, and checked the Attached Devices list. I found that the RBS40V no longer reported any Wired devices at all. I also found that the RBR50 Attached Devices list was now 100% correct, and no longer incorrectly listed any wireless devices as Wired. You also mentioned that the Orbi's use Fing's software to do device collection. Perhaps the way the Fing utility is being run on the RBS40V is causing it to collect Wired devices instead of only reporting back the Wireless ones. Again, thank you for the call and helping to do some additional troubleshooting on this. I hope the above notes are helpful."
I also provided a potential software solution that could likely fix the problem:
"Each device (RBR50, RBS50, RBS40V) collects a list of devices it "sees". Each device knows which clients are connected wirelessly to it, and each device can see ARP requests for devices not connected to it and it detects those devices as "Wired". So, every device is both reporting "Wireless" devices accurately, and reporting "Wired" devices sometimes accurately, and sometimes inaccurately.
The right way to fix this would be for the RBR50 to have logic that preferred reporting Wireless if it gets conflicting information. For example: RBS40V reports a device as 2.4G, RBR50 reports same device as Wired. The RBR50 should "prefer" the Wireless reporting, since that is more accurate than the Wired reporting, and therefore should display the device as 2.4G. Right now, it appears to be a "random" determination as to whether the RBR50 will pick the Wired or Wireless designation for a device that is reported by multiple Orbi devices.
Further, Satellites (like the RBS40V and RBS50) can report Wired devices they see to the RBR50, but they should never list those as "locally connected". There's no way to determine if a wired device is connected to one Orbi device or another, so the default should be to always say that Wired devices are solely connected to the primary router (i.e. RBR50)
If the above logic was put into place, I believe this problem would be resolved."
Given that a user would expect to see Wired and Wireless devices reported accurately, and there is a potential software solution to fixing this issue, I believe this absolutely is classified as a bug.
Netgear has chosen to not fix this issue, and that is of course their perrogative. Not all bugs are of equal priority, and this one being purely cosmetic perhaps does not rise to the level of importance to justify investment in it being fixed. And it could also be that the fix for this would be more invasive than is warranted for an existing deployed system. But, I did suggest to Netgear support that perhaps they could implement what I described above in future generations of Orbi systems if that was indeed a concern.
In the end, the answer I got indicated that it is a limitation of the system. But in a sense, any bug can be waved away as a limitation of the system. A bug is a bug, even if the software vendor chooses not to fix it. I am content with the response I got from Netgear, because they acknowledged this was an issue (by claiming it was a limitation of the design) and eventually letting me know that they would not address it. (I only wish that it didn't require countless hours of my time and literally 4 months to get there...)
On the other hand, this is a bug, and I would hope that in future generations of Orbi software that they fix it, and I believe that the mechanism I suggested above could do that.
If the software was Open Source, I likely could fix this myself... But I could only go so far in trying to fix the issue given that much of the Orbi software are composed of binary blobs without accompanying source code.
