JetPack 2.3.1: flood RTNETLINK answers: Network is unreachable

Hi Dears,

Sometimes I have to work without Eth connected.
In this case a serial console is full of

RTNETLINK answers: Network is unreachable

Please advise, how to suppress it.

Thank you,

It looks like a message where no default route is reachable. Just a guess, but try adding a default route to the local loopback interface (no doubt that if this works it is probably still the wrong way to do it):

sudo route add default gw

Thank you a lot! It works. You saved my life :)

Is it possible to include this into netcfg default behavior?

I have insufficient knowledge on Ubuntu to say for certain, but here’s “food for thought”…

Many of the problems people have with networking failure on Ubuntu and other Linux systems capable of WiFi when other networking is simultaneously available is how the software chooses which interface to use. If you have only wired, then there are not any real choices…if available, enable it, if not available, don’t. There are also mobile devices which have only WiFi…pick the best end point available.

The complication starts when you have both wired and WiFi, and WiFi might change. Suddenly you need rules about what to do…if both WiFi and wired are available, which do you use? Probably you want to use wired if available and skip WiFi because of quality issues. Then again, perhaps wired is goes only to a private net (e.g., printers or remote storage) and WiFi is used for public internet; in this case you end up having two routes…one for private, one for public. Rules for this suddenly need customization. Software for managing those rules started appearing after multiple networks (and networks which are temporary) became common (we got WiFi). One of the solutions to this is NetworkManager.

What you’re asking for, if done correctly, probably requires adding rules to NetworkManager. I don’t know how to do that (NetworkManager frustrates me…and even if you do understand NetworkManager, you might need to make the adjustments via systemd configuration…yet another learning curve). If you want to do things correctly, then it seems like you’ll need to survive the learning curve for NetworkManager expertise. NetworkManager is hotplug for networking interfaces.

You could easily add this to other places, e.g., rc.local. The problem is that you are not always going to want this config. I’m not sure that events changing networking availability would then update correctly if you’ve manually entered a default route. If you add something to rc.local, then you may need to manually run something like “sudo systemctl restart networking.service” each time you actually have network access. You might have just substituted having to enter a default route each time to instead having to bring up networking manually…the inverse of your current situation.

You might instead figure out what commands are required and just package them in two scripts for manual use: “” and “”.

Thank you again.

Some years ago I had an experience to build our own Linux, it was more clear for me.
Modern startup schemes and script sets looks incredible…

In case of release features you are right, it is a big trouble how to do it right.
We actually need both, WiFi and Wired connection and should provide user with a possibility to choose which interface is main.

Now I’m talking about just a debugging environment for my job, to debug mostly electronics, FPGA and related drivers that we are developing…

Anyway, it seems strange to have a flood in dmesg just in case of a network absence.
I mean, this situation maybe normal for a final device.