Jump to content

Asterion

Members
  • Posts

    19
  • Joined

  • Last visited

Posts posted by Asterion

  1. On 6/27/2017 at 6:28 PM, tkaiser said:

    @Asterionwould be great if you could mark the thread as solved and edit initial post with a simple one liner at the top so other people coming accross 'Authentication token manipulation' issues via Google get immediately that they also most probably just run in obscure SD card problems.

    Yep, and unsolved again.  Looks like the problems are "haunting" the Echer burnt image as well.

  2. 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?

  3. 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.

  4. 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.

  5. 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?

  6. 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.

  7. 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.

  8. 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 !

  9. 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. 

  10. 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

     

     

    no connection.png

     

    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. 

     

  11. On 6/26/2017 at 0:37 AM, Igor said:

     

    Remind yourself that you are (ab)using free technical support, which is pure good will and cost of people that were trying the best to help you, even everything is already written in documentation. You should only read, accept and act but no ... 

     

    We told you again here what the problem is and you insist that we are wrong. There are thousands of users which does not have this problem, which means problem, from our perspective, does not exists. We are discussion over the phantom problem and this is: pure waste of time. Case closed.

    Take your chill pill.  There was no abuse.  I did point out a fact though.  Emasculating was it?

     

    And just a point on argument, if no one was having sporadic problems due to FS corruption then there was no need for Etcher.

  12. On 6/25/2017 at 11:19 PM, martinayotte said:

    If your SDCard is mounted as Read-Only because of some corruptions, then new password just entered is not save, therefore SDCard is unusable.

    You have to re-write the SDCard with Etcher tool ...

     

    Cheers, that speaks to the heart of the question.  Comes with explanation to help understanding.

  13. Go figure, I haven't had much luck with my Orange Pi Zero after it appeared that attaching the expansion board fragged the motherboard somewhat (see my journey at).

     

    The confounding factor was that multiple SD image burns, using WIN32DiskImager, prior to expansion board insertion on the Orange Pi Zero, were fine for about a week of experiments.  Immediately expansion board was inserted it all went downhill - literally.  

     

    Thus, without any other evidence it appeared a hardware frag.

     

    Problems like this not seen previously on my microPython, ODROID-W, ODROID-C1, RaspingBreathberry Doodle Pi, BeagleBone Black, BeagleBoard XM - all using WIN32DiskImager.  

     

    Indeed, parallella distro was burnt to one of the SD from the Orange Pi experiments, using WIN32DiskImager, and no problem there.

     

    Orange Pi Zero SD card was finally re-burnt, as suggested on forum, using Etcher.  

     

    I note no warning on download page about why Etcher should be used (it is a "can" implying optional).  There is some explanation in the docs but, as tech authoring standards are not being used, it wasn't wrapped as NOTE or WARNING so is lost on page buried in website.

     

    If, like me, you go to the archive to get the debian server, and you haven't come across etcher (and the mention of it is at bottom of the parent Orange Pi Zero page so is easily missed), and you have gotten by with WIN32DiskImager for yonks, you will also be burnt.
     

    I can't corroborate claims of FS corruption as I wasn't using 3-pin serial - thus missing out on early login messages.

     

    Otherwise, seems to be running again, for now, with same distro as before/during problems (but using Etcher instead of WIN32DiskImager).

     

    Thanks to all those that helped me understand the problem.

     

    RETRACTION!

     

    I ran the system for two days, checking in occasionally by browsing into see node-red and emqttd running.  This morning I could not connect.  I checked and IP address had disappeared which was a problem seen on the WIN32DiskImager burnt version of the distro.  The problem cleared after 3 reboots (that is 2 reboots came up no IP set and then third with IP set).  I had done nothing but reboot (so no fiddling of config in between).  The piece de resistance was that I hung the device by opening up nmtui and going to the connection window.  That was a problem I was plagued with on the WIN32DiskImager burn version of distro and can now confirm it occurs on Etcher burnt distro.

     

    The quirk with the nmtui that noticed was that, with the fresh Etcher burnt SD card, I used nmtui and the window was blue colour.  Now that the system has degraded the nmtui window opens white on black background with connection highlighted in yellow.  Exactly the same behaviour on WIN32DI burnt SD card.  So, the quirk seems that system is hanging in mid draw of nmtui connection window.

     

    So, the behaviour seems characterised as a slow degrading of system over time that persists between reboots.  The IP dropout likely will flit in and out now, and then become permanent, as it did with WIN32DI burnt SD card.

     

    I am going back to my device fragged (somehow) by expansion board.

     

    I have two more OPiZ coming so I will try same process to built SD card, using Etcher, to see if there is a difference with board that haven't had expansion board inserted (originally I have a working device that would not boot once expansion board was inserted).

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines