Getting past the initial network setup can be very difficult in a corporate setting.
Our primary sanctioned WiFi network requires password AND username to connect. There is no option in the onboard Reach for this style of login.
The secondary WiFi network which requires only password to access blocks scanning across the router/switch so getting the unit’s IP address is a laborious process of trying one address after the other until the Reach answers.
Or the third option of temporarily setting up an unsanctioned WiFi for the setup period and hope no one down in corporate IT get’s wind of it and brings down repercussions.
There really should be a method of passing network setup and credentials to the unit over a wired connection.
It doesn’t take much of a scan over the forum topics to show there’s a great deal of trouble and confusion over this step in general let alone restricted environments like ours. In my opinion a wired connect option would go a long way to resolving these as well.
The secondary WiFi network which requires only password to access blocks scanning across the router/switch
This was wrong. Scanning is not being blocked. Something else failed. Everything else still stands though: it’s too hard to connect to the device in a corporate environment.
It appears Windows supported Ethernet over USB in several versions up to Win7 but dropped it in Win10. The prototcol is known as RNDIS “a Microsoft proprietary protocol … provides a virtual Ethernet link … A partial RNDIS specification is available from Microsoft” (ref)
From my reading, Windows delivers the DLLs even in Win10. What’s missing is an INF file which tells Windows the USB hardware ID the Reach devices report and to use the RNDIS protocol for them.
Microsoft describes the INF templates for RNDIS. I’ve taken a crack at modifying them to match the Reach USB hardware ID I see on my machine but have not had success so far.
One of the challenges is Windows 10 refuses to install the INF-file because of it is not signed file. There’s a recipe to disable signing which I don’t particularly want to do.
A kindle hacker has both the INF writing and the signed cert part sorted out and posted detailed step by step recipe. “The solution is to provide a driver that will specifically handle USB\PID_0525&VID_A4A2. It is just a dummy driver that will tell the OS our “Linux USB Gadget” should be handled as a remote NDIS device. Windows has been shipping with the RNDIS driver bundled in for quite some time now, so it’s basically a matter of a simple declaration.” (ref)
There is a USB/IP project on GitHub which “aims to support both a USB/IP server and a client on Windows platform”. This might be the most profitable route to pursue. The code base goes back to 2009 and most recent commit was a few days ago.
These breadcrumbs are probably for others to pursue. Two of us have spent many hours over several days trying to get these brand new units up and running. There’s serious talk of just returning them to the vendor as they don’t seem to be the right tool for our organization. The hardware build quality of the units is excellent, we’re very impressed, but not being able to talk to them in context of our corporate infrastructure is a hard sell to management. I’m the only linux adept in the shop and I can’t make myself the only link.
That is an excellent amount of research, but if the end game is to do software updates over USB, then there are more hurdles than RNDIS. If you get RNDIS working you will be able to access ReachView and all that entails, but that is where it (probably) ends.
Massaging the network gateway over to the USB interface and coaching the software updater to use the USB interface to poll for updates is a whole other thing that isn’t easy AFAIK.
For software updating of Reach devices in your corporate environment, the way through is to get Wi-Fi working. If your corporation can’t provide a Wi-Fi network that works with simple devices (like devices without screens), then just grab a corporate phone (or your own phone) and enable the hotspot and update them that way. Or go to a small cafe that has a consumer router and have a coffee and do the update there. For that matter, just take them home for the night, update them and bring them back in the morning.
I guess if corporate Wi-Fi is a difficult thing to work with, then you have to ask, “What does the corporate Wi-Fi network offer that I actually need anyway?”
I guess if corporate Wi-Fi is a difficult thing to work with, then you have to ask, “What does the corporate Wi-Fi network offer that I actually need anyway?”
Unfortunately that will get reversed to “if the device can’t work with our security enhanced network then it doesn’t offer what we need”. My personal opinion matters little. Central IT would prefer we didn’t have wifi at all. It took them years to yield to the industry trends, just rolling it out 11 months ago.
Not being able to connect direct to the device with a wired connection (or bluetooth) and use that channel for initial setup is a major hurdle. I expected to be able to connect to these units from a laptop or workstation and then use the workstation to update device firmware, software, etc. and utiliize that machine’s internet access for whatever resources are needed. It’s a pattern we’ve been using decades. This is the first time we haven’t been able to do that, so it was a surprise.
Anyway, we finally did manage to get both our units through the initial setup and can finally get to the real business of doing field tests. There’s apprehension about future updates consuming similar time and effort but for now I’ve kicked that can down the road.
Yes, I understand, and I can identify with that attitude if I put my network admin hat on. And I suppose they would prefer that you opened a support request with them for any kind of software/firmware upgrade; hand over the units to them; and wait in their priority queue for a few weeks while they find time to do it. In the end, they just set up their own sanctioned, unrestricted Wi-Fi network to do the upgrade anyway.
But enough muttering about IT curmudgeons (coming from a wannabe IT curmudgeon ).
I agree there. It would be nice if the units had default support for ‘over the wire’ setup/upgrade.
I’m glad you got through the setup hurdle and can get to work.
BTW: The firmware flashing process is done with the USB cable from your laptop/desktop computer (see firmware flashing in the docs). It is just that it requires an Internet connection on the next boot up to check for updates before you can continue (so then you are back in the same boat as when you received them new).
haha! Here’s to the budding IT curmudgeon: . Thankfully our IT doesn’t want to administer the non-computer devices, but the workflow description you gave perfectly fits the rest of our ‘support’.
Emlid uses a wired option for firmware but not software!? Sigh. I’m sure they have they’re reasons but right now I’m not liking them. I’ve contacted Emlid directly and we’re stepping through that process.
Thank you for taking the time to read and respond @bide, much appreciated.
).
. Thankfully our IT doesn’t want to administer the non-computer devices, but the workflow description you gave perfectly fits the rest of our ‘support’.
cheers.