Ethernet Config dropped randomly [UNSOLVED]

[Asterion]

So, back again. 

 

I keep seeing the ethernet connection dropped.

 

When logging in by USB the login reports IP <blank> (see picture).

 

I saw this previously (see full set of traumas here https://organicmonkeymotion.wordpress.com/category/orange-pi/).

 

Happens now on freshly burnt image using Etcher.

 

Ran for two days.

 

The problem also manifested using an image burnt with WIN32DiskImager so we can discount any FS corruption assumptions - the Etcher burn reported no errors.

 

Call it "Phantom Ethernet" in honour of Screaming Jeeby - that is the board is haunted wooooooooooooooooooooooooooooooooooo!

 

Note when I discovered the problem I also tried logging in by USB.  Would not connect.

 

I had to pull power.  When board came back up still no ethernet but I can get in by USB.

 

As USB is different route to 3-pin serial I am assuming that is telling?

 

I will dust off 3-pin serial.

 

It might actually be two problems, a crash plus the problem with the connection config disappearing (not enough info yet).

 

I will start poking through logs but if anyone has a hint if you have seen this before that would be grand.

 

Cheers,

A

 

 

 

root@house:~# journalctl -full -b -u NetworkManager
-- Logs begin at Thu 2017-06-29 09:17:03 CEST. --
Jun 29 09:17:12 house NetworkManager[435]: <info> (wlan0) supports 2 scan SSIDs
Jun 29 09:17:12 house NetworkManager[435]: <info> (eth0): link disconnected (deferring action for 4 seconds)
Jun 29 09:17:13 house NetworkManager[435]: <info> (wlan0): supplicant interface state: disconnected -> inactive
Jun 29 09:17:14 house NetworkManager[435]: <warn> Could not send ARP for local address 192.168.0.100: Failed to execute child process "/usr/bin/arping" (No such file or directory)
Jun 29 09:17:17 house NetworkManager[435]: <info> startup complete
Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): link disconnected (calling deferred action)
Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): device state change: activated -> unavailable (reason 'carrier-changed') [100 20 40]
Jun 29 09:17:17 house NetworkManager[435]: <info> (eth0): deactivating device (reason 'carrier-changed') [40]
Jun 29 09:17:17 house NetworkManager[435]: <info> NetworkManager state is now CONNECTED_LOCAL
Jun 29 09:17:17 house NetworkManager[435]: <info> NetworkManager state is now DISCONNECTED

 

So, has worked fine.  Now fails?  Whereis of arping turns up naught!

 

So here is the kicker, reboot a few times (doing nothing else touching nothing else) and IP comes up. 

 

[kutysam]

it would be good if you have some logs..
dmesg

[Asterion]

9 hours ago, kutysam said:

it would be good if you have some logs..
dmesg

Yep, did mention I would look into logs.  I work for a living so when I get to my next hobby break I will tear into the logs.  

 

The question though was had you seen this before?  The more pertinent question is whether network manager would drop a connection like this for some reason. 

[zador.blood.stained]

4 hours ago, Asterion said:

The question though was had you seen this before?  The more pertinent question is whether network manager would drop a connection like this for some reason. 

yes, I saw the arping issue in logs and newer images include arping by default. On older images "iputils-arping" package can be installed manually.

[Asterion]

Bingo!

 

I have locked up my OPiZ using nmtui again.  That is, the same behaviour using the Etcher burnt CD.

 

So, I am seeing an malaise that degrades the distro over time when it is run for a couple of days BUT it appears not to clear on reboot. 

[Asterion]

Just now, zador.blood.stained said:

yes, I saw the arping issue in logs and newer images include arping by default. On older images "iputils-arping" package can be installed manually.

But that isn't the problem at all as I have now seen the system boot fine (without doing anything else) and arping is still not there !

[tkaiser]

19 minutes ago, Asterion said:

arping is still not there !

 

That's why @zador.blood.stainedsuggested installing 'iputils-arping' package. Since you mentioned 'nmtui': In case you configure wlan0 and eth0 to connect to the same AP/router/network all sorts of weird stuff will happen (depending on AP/router too so somewhat unpredictable). Anyway without logs this is somewhat useless (if you've only serial console providing dmesg output and contents of /var/log/armhwinfo.log via pastebin.com would ge great).

 

And then another frustrating read (SD cards that work fine on Windows, can be burned with Etcher, pass counterfeit card tests but simply don't work on the dev board of choice): 

 

[Asterion]

Just now, tkaiser said:

 

That's why @zador.blood.stainedsuggested installing 'iputils-arping' package. Since you mentioned 'nmtui': In case you configure wlan0 and eth0 to connect to the same AP/router/network all sorts of weird stuff will happen (depending on AP/router too so somewhat unpredictable). Anyway without logs this is somewhat useless (if you've only serial console providing dmesg output and contents of /var/log/armhwinfo.log via pastebin.com would ge great).

 

And then another frustrating read (SD cards that work fine on Windows, can be burned with Etcher, pass counterfeit card tests but simply don't work on the dev board of choice): 

 

Ah! So, armbian doesn't come with arping installed but calls it during startup.  I see.

 

Is arping supposed to be there? is it part of the problem or is it just an interesting side discussion?  It turns out arping is missing whether the system boots up with IP set or not for example.  

 

Happy to install it if it will "fix" something.

 

But, ah ha!  Okay, I will look at the wlan0 setting setup and thanks for the hint as to which of the myriad logs would be best to take a peek at - that always is a help.

 

I am being slammed at work so I will get to this again on the weekend.

[Asterion]

13 minutes ago, tkaiser said:

 

That's why @zador.blood.stainedsuggested installing 'iputils-arping' package. Since you mentioned 'nmtui': In case you configure wlan0 and eth0 to connect to the same AP/router/network all sorts of weird stuff will happen (depending on AP/router too so somewhat unpredictable). Anyway without logs this is somewhat useless (if you've only serial console providing dmesg output and contents of /var/log/armhwinfo.log via pastebin.com would ge great).

 

And then another frustrating read (SD cards that work fine on Windows, can be burned with Etcher, pass counterfeit card tests but simply don't work on the dev board of choice): 

 

Yep, but my reading of the package is SanDisk Ultra microSDHC UHS-1 so I am not convinced I have a SD card quality problem.

[Asterion]

48 minutes ago, zador.blood.stained said:

yes, I saw the arping issue in logs and newer images include arping by default. On older images "iputils-arping" package can be installed manually.

Older than what? 5.25?

[zador.blood.stained]

2 minutes ago, Asterion said:

Older than what? 5.25?

Older than 5.30 stable, or build date older than May 6th for other images.

 

6 minutes ago, Asterion said:

Yep, but my reading of the package is SanDisk Ultra microSDHC UHS-1 so I am not convinced I have a SD card quality problem.

@tkaiser @Igor And this is a good example for the "Improve support over Forum" thread that tells us that we need to update/improve documentation first before implementing any changes on the forum.

 

@Asterion I have 2 (I'm pretty sure genuine) Samsung Evo 16GB laying in front of me that survived for less than a year since I bought them. "Card quality problem" can be caused by aging, and label on the card influences only probability of failure happening sooner than later.

[tkaiser]

15 minutes ago, Asterion said:

So, armbian doesn't come with arping installed but calls it during startup.  I see.

 

 

Armbian is a build system that can create either Debian or Ubuntu based OS images. Most probably with one Network Manager update this requirement has been introduced (but obviously the upstream networkmanager package missed to declare this dependency), @zador.blood.stainedtook notice and fixed the issue on May 6th so current Armbian images are not affected (5.31 is current version). You already know how to fix this in your installation.

 

Whether this will 'cure' anything or not nobody knows. Logs needed and appropriate descriptions. In case you suffer from a dying SD card everything we're doing here is a waste of time of course  An easy test would be to use any of the OS images here instead: http://www.orangepi.org/downloadresources/

 

[Asterion]

8 hours ago, tkaiser said:

In case you configure wlan0 and eth0 to connect to the same AP/router/network all sorts of weird stuff will happen (depending on AP/router too so somewhat unpredictable).

 

 

 

Sorry, I am confused here with your use of language.  

 

I hadn't set up wlan0 so it shouldn't start.  

 

The way you have stated the sentence it reads I get "weird stuff happen" IF wlan0 and eth0 are connected to same AP/router/network, yes?

 

So that is you are telling me not to have eth0 and wlan0 running at same time?

[Asterion]

7 hours ago, zador.blood.stained said:

Older than 5.30 stable, or build date older than May 6th for other images.

 

@tkaiser @Igor And this is a good example for the "Improve support over Forum" thread that tells us that we need to update/improve documentation first before implementing any changes on the forum.

 

@Asterion I have 2 (I'm pretty sure genuine) Samsung Evo 16GB laying in front of me that survived for less than a year since I bought them. "Card quality problem" can be caused by aging, and label on the card influences only probability of failure happening sooner than later.

All cards used in experiment are freshly bought so this is first use.

[Asterion]

8 hours ago, tkaiser said:

 

Since you mentioned 'nmtui':

 

Yep, and it may have be a red-herring.  What I just discovered was that I had the log you asked me to look at opened in nano via my TerraTerm session over the USB connection.  That stopped mid scroll.

 

Used a cgwin console to ssh into the device to find nmtui and nano works fine via my ssh session but the session over usb is fragged.   

 

So, it looks almost like another problem were session over USB is getting "broken" - repeatedly using nmtui and randomly in other instances.  Note I have setup static IP on my PC as well so its end isn't "floating".

 

OR there is some common mechanism that frags eth0 and usb connections???  Something sitting higher in oversight?

 

Yeah, yeah.  Get 3-pin serial going, I hear ya.

[Asterion]

8 hours ago, zador.blood.stained said:

yes, I saw the arping issue in logs and newer images include arping by default. On older images "iputils-arping" package can be installed manually.

Okay, so we have an a statement that the claim is arping should be in 5.25 as "older", you have pointed out, is older than 5.25 yes.

 

That is I should not have seen the arping "missing" in a freshly burnt 5.25 distro?

[zador.blood.stained]

9 hours ago, Asterion said:

Okay, so we have an a statement that the claim is arping should be in 5.25 as "older", you have pointed out, is older than 5.25 yes.

Please read my message again. On images older than 5.30 iputils-arping should be installed manually if it is needed, it was not installed by default in those images.