I was having similar issues, and similarities to previous embedded board work with RNDIS suggested this was possibly Windows 10 foolishness at work (with respect to its “intelligent” labeling of networks as “Private” vs “Public” based on…who knows; some heuristics)
Anyways, here is what I did to stabilize things: (NOTE: this is specifically for WINDOWS 10)
- follow the instructions from NVIDIA’s various getting started guides to get the board up in “headless mode” via the USB cable (ethernet-over-usb) connection.
- In Windows 10’s settings, go to the “Network & Internet settings” screens (there are a few ways to get here, so i’ll leave this as a generic description)
- select “Change adapter properties”, which should bring up a file-explorer -like window of different NIC adapters you have (physical and virtual).
- Find one that describes itself as “Remote NDIS compatible…” or somesuch thing. If none say this, disconnect all hardwired ethernet cables/adapters running to your machine, and pick the last “Ethernet” icon in that window that is still active…double click this to bring up a status dialog
- in that status dialog, select the button “Properties”, and the dialog will change.
- Unselect TCP/IPv6 in that list (* may not be necessary but I did it anyways to eliminate variables)
- Select TCP/IPv4 and click the Properties button…another dialog will come up
- for the address properties, put
192.168.55.55 as the address
255.255.255.0 as the netmask
192.168.55.1 as the gateway
(you can leave the DNS settings untouched)
click apply/ok…all the way back out.
At this point, Win10 may reenumerate the network , give it a new name (e.g. Network 2) and ask if you want your PC to be discoverable. Say YES. (near as i can tell, this marks it as a “Private network” in its weird terminology.
Regardless of whether it asks or not, go ahead and unplug the USB cable and replug it, for good measure.
ANOTHER IMPORTANT NOTE:
On one machine, there was a lot of latency and page loading errors even with these steps. The problem seems to be that the “primary” network adapter (the WiFi connecting it to the internet) was set up to be on the 192.168.x.y network with a netmask of 255.255.0.0…which makes it overlap with the Nano’s 192.168.55.x network. Ordinarily, this would be resolved with routing table metrics values, but…again…Windows! (big shrug).
Hope this helps.