This error is popping up from the desktop that runs Ubuntu ONLY to service the Nano and TX2 (TX2 not converted yet.) It must have something to do with the way the SDKManager sets up the artificial USB “network” to the Nano, but danged if I can figure out how to turn it off.
The error is generated by the fiber modem and will not allow the desktop to “log on to the internet.” Meaning I can’t even run apt update. I can ping from the desktop but can’t run anything useful that has to connect to the internet, including the nano utilities. The ONLY reason I put ubuntu on a desktop is to service the nano, due to the restrictions imposed by nVidia.
There is --no-- secondary router on my household 'net as I only use switches. Further, the 8-way switch that is on the ubuntu desktop ALSO has a monitor, the Nano, a Debian desktop, and sometimes an RPi or two on it and none of them generate this ‘router behind router’ error.
Please advise on how to clear away this problem so I can use the ubuntu desktop as nVidia intends.
Thanks.
it will not allow a browser, apt, or any other program to access any other part of the internet, and when I try, my local fiber router throws a “router behind router” error, even though there are no other routers on my home 'net.
fiber router → local 8-port switch → 4-7 devices behind that local switch. The Nano is running Ubuntu without problems, and none of the other devices have any problem EXCEPT the desktop running Ubuntu to service the Nano.
Disconnecting the USB cable from the Ubuntu desktop from the Nano solved the “router behind router” problem but only temporarily. Killing the software “internet connection” on the Ubuntu host (that feeds that USB to the Nano) does not make the problem go away.
Bottom line, I cannot use the Ubuntu desktop, whose ONLY purpose in life is to service the Nano, to do it’s job in serving the Nano.
Thanks for explanation. I got it. This error is new to us.
Could you paste the full error or screenshot when you failed to access the other part of internet?
No, that machine cannot connect to the Internet. :)
First, at the top of a browser page, it says, “you’re not connected to the Internet.” Well, duh. But that’s only in the local browser. And the local real physical router between me and the world on the fiber connection from AT&T gives the error “router behind router” and gives me 2 options to correct or make the Ubuntu desktop a fixed address to the world. Both options have been explored ad infinitum and yield terrible results. (That local Ubuntu desktop can NOT be in the mode where it’s open wide to the Internet; security is nonexistent in that mode.)
And has nothing to do with the Ubuntu desktop appearing to be a router by itself, and it is not one. Except in software as setup by the SDKManager or one of the steps to it getting there.
On any system involved, please show the output of the commands “ifconfig” and “route”. It may be that you have two routers using the same route with the same metric, or some other subtle setting.
The problem is AT&T. This is a known issue if you google the error. The solution is to switch ISPs to one that doesn’t F with your traffic. They are counting hops and cutting off nested nat traffic (a router behind a router). You could try a VPN on your destop, and that might get you around it, but really your ISP should not be doing this.
Alternatively a router that is not the ISP provided one might fix it, if your isp’s router/modem combo supports bridge mode. It all depends on where the error is being generated. If it’s at the ISP side, there isn’t much you can do. I would just switch providers if I were you and the alternative is somehow not worse. Even if a new router solves the problem you’re paying a BS rental fee for their hardware which is defective in your case.
mdegans, thanks but that doesn’t make sense if you envision the home 'net system as laid out in detail above. There is only ONE physical router in the entire house and that is the one that is the fiber modem. There are 3-8 computers on at any one time and never had a problem like this until the “pseudo router” created by SDKManager. Again, the ubuntu desktop AND the Nano are BOTH BEHIND THE SAME SWITCH, along with a Debian desktop and usually 1-3 RPi’s and sometimes the TX2. The error is caused by something in the pseudo setup that SDKManager uses to act like an ethernet connection through the USB port on the Nano.
And I have investigated the “router behind router” issue at LENGTH over the web.
Well. If you Google the issue it does seem to be mostly AT&T related. You’re not wrong that your ISP shouldn’t be detecting your Ubuntu desktop as a router, but it is. It’s possibly because at one time it did route traffic and your router remembers that. You could try disabling IPv4 & ipv6 forwarding in /etc/sysctl.conf (instructions should be in the comments)… But that will disable your nano’s connection through the desktop as well. That may trick the router into working again if you also change the MAC address. Resetting the router might also make it forget.
In any case the problem is related to something your ISP shouldn’t be doing in the first place. Anything else is a workaround to that F up. This should happen if you try to use a virtual machine in with nested nat as well, so even if you do resolve it here, you’re likely to run into the same error in the future.
BTW, you don’t have to install the nano’s software through SDK Manager. Once you flash it, you can plug it into Ethernet and, when promoted by SDK Manager, give it the nano’s eth0 ip address rather than the USB interface at …55.1
Alternatively, nearly everything can now be installed via the online apt repositories set up by default in JetPack 4.3. You can install DeepStream, for example, by doing a “sudo apt install deepstream-4.0”
If you Google, there are instructions out there on how to list every package in an apt repository. That will give you a full list. Then you can use SDK Manager just to flash, or not at all if you’re booting off SD cards.
And you ran SDK Manager once, which, if your router is as bad as I suspect, might be enough. Change /etc/sysctl.conf and your MAC address and you will know for sure.
If you set one of your Pis up to route traffic (eg. a pi hole) it would probably block it as well. Can’t rule it out unless you try.
There is one possibility to consider: During flash your PC can be set up to act as DHCP server and router to the 192.168.55.1 IP address (meaning that if your USB virtual ethernet is being bridged by the PC rather than the Nano going straight to actual ethernet, then this might cause your PC to act as a router).
I still suggest posting the output of “ifconfig” and “route” from both Nano (if at a stage where you can do this), and the PC. You might be able to adjust the metric of an interface, or to simply remove a conflicting route (assumes you can use purely the wired ethernet).
So far as using the wired ethernet only, you’d simply disconnect the micro-B USB cable once the Nano can boot and tell JetPack/SDK Manager to use the wired ethernet address. Any kind of bridging on the PC would no longer exist unless you specifically set the wired ethernet address or Nano MAC to be bridged through the PC (very unlikely).
I would have to agree though that any ISP which does not allow additional routers behind their router is broken. I don’t know if this is the case here.
I think it’s a case of AT&T or the router manufacturer trying to be too helpful. Normally nested nat is not something you want to do because it will break things like upnp and port fowarding in general.
A customer might bring their own router and plug it’s wan port into the AT&T router combo’s lan port. That will work for web browsing, for example, but will break things like bittorrent, some gaming apps/consoles… anything that needs a forwarded port.
The customer, not being aware of how to access AT&T’s router and set it into bridge mode, then calls support and complains. This costs money. Instead, AT&T Has their router detect if there is nested nat (and there is) and offer to “strip away” the outer connection by putting it into bridge mode.
Unfortunately, this would have the side effect of breaking nested nat when you actually need it (for a vm, or for cases like this). In any case, disabling ip forwarding in /etc/sysctl.conf and rotating the MAC address should resolve the issue… or connecting to an external VPN from the Ubuntu desktop should also do it.
I think I’ve cured it. It was a compound problem. First, (and apparently the cause) was the software ISP downlink setup to the Nano through the PC via the USB cable. Clever but I hope we get away from that completely. So I removed all that from the desktop PC. But it was still occurring. Dug deep into the gizzard of that AT&T supplied (Motorola?) fiber modem. Changed several things there, too. Then changed them all back. :( Finally, powered off that modem and then powered it back up. Problem gone -so far- and it’s been about a few days now without returning. This entire process took WEEKS!
Be advised.
I sure hope we can now go straight from SD Card download and boot without 15 extra partitions and other weirdness, then go straight to normal Linux boots and package updates. Especially since I’m now booting off the SD card straight to root on USB drive. Sure wish the all the Jetson firmwares would support boot from USB/network/PCIe as well as SD card, with option saved in “BIOS.”
Probably the power cycle was all it needed to forget your PC ever forwarded anything. A full reset would have done it. Changing the Mac address would also have done it. Sorry it took so long to resolve, but be aware the issue will likely reoccur if you use SDK Manager to install software on the Nano again (or if you run a VM behind NAT).
The reason for the multiple partitions is because of how the device boots. Pi has 2 partitions. Android devices generally have many. It’s common to have a separate /boot, /home, etc, or to have /tmp be a ramdisk. There are often security and performance benefits. If you read the Linux for Tegra documentation, the details for each partition are laid out.
I do agree, however, that without SDK Manager your problem would never have happened. I am glad Nvidia is moving in the direction of making it less necessary with JetPack 4.3. The use of online apt repos is personally very welcome.