OPi Lite does not close SSH session upon reboot/poweroff


zgoda_j
 Share

0

Recommended Posts

I have couple H3 and A20 devices and all run fine except one - Opi Lite, running latest Arbian (5.26) with built in wifi connected does not close SSH session upon reboot/poweroff. The session eventually times out on client but sometimes I have to kill it manually. There are no modifications to PAM nor systemd-logind configurations and the configuration is exactly the same as on other devices. I'm wondering what may cause this misbehaviour, and how can I fix this?

 

(This topic was created yesterday before db failure/site update and I can't find it now on restored site, I guess it has been lost)

Link to post
Share on other sites

Donate and support the project!

2 hours ago, zgoda_j said:

I'm wondering what may cause this misbehaviour,

Probably wireless connection is killed before SSH server

 

2 hours ago, zgoda_j said:

how can I fix this?

On Ubuntu Xenial it's possible to mark interfaces in /etc/network/interfaces with "no-auto-down" (assuming wireless connection is configured there), no idea if there is anything similar with NM. Also forced modules unloading by armhwinfo may need to be disabled...

Link to post
Share on other sites

Disabling forced module unloading in /etc/init.d/armhwinfo (commented out the whole line) and no change. Then uncommented the line and added systemctl stop ssh just before this line and still ssh session is not closed properly.

 

Perhaps this is related to GPIO power being cut too early?

Link to post
Share on other sites

Maybe others simply don't notice it. My SSH sessions (initiated from OS X) always time out if something happened like losing connection for whatever reasons. Anyway without information it's a bit hard to even think about helping you (which kernel version is used, do you have other H3 devices with same 8189FTV module and so on)...

Link to post
Share on other sites

This is the only device with 8189FTV I have. I have other boards with built in wifi but they have other chip and are not H3 based. This is:

$ uname -a
Linux opi3 3.4.113-sun8i #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017 armv7l GNU/Linux
$ cat /etc/armbian-release 
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepilite
BOARD_NAME="Orange Pi Lite"
VERSION=5.25
LINUXFAMILY=sun8i
BRANCH=default
ARCH=arm
IMAGE_TYPE=stable

Armbianmonitor log -> http://sprunge.us/KTMD

 

Normally pam-systemd closes all user sessions upon power off, including SSH sessions. This looks differently, on client I see SSH session hanging, after issuing eg. sudo reboot board reboots but the session on client remains in half-dead state:

17813 pts/7    S+     0:00          |   |   \_ ssh -vvv jarek@192.168.0.23

Which means it's still waiting for some event. Eventually I get packet_write_wait and session times out on client, so I suppose pam does not have chance to close user session.

 

EDIT:

Sometimes session on client does not time out and I have to kill it manually, IDK why:

$ sudo poweroff
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)

debug1: Killed by signal 15.

 

Link to post
Share on other sites

Thanks for the information provided. But without serial console connected and maximum verbosity (see https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toogle-verbose-boot please) I doubt we get the culprit what's going wrong. And to be honest at least I wouldn't look into unless the fix is very trivial.

 

In the meantime situation with H3/H2+ boards got really absurd (most devs use solely mainline kernel while we tell users they shouldn't due to everything being WiP and not supported :) )

Link to post
Share on other sites

1 hour ago, tkaiser said:

In the meantime situation with H3/H2+ boards got really absurd (most devs use solely mainline kernel while we tell users they shouldn't due to everything being WiP and not supported :) )

We don't tell users they shouldn't use mainline, it's just that users shouldn't bombard us with questions and private messages about things that don't work at all, don't work as intended or not enabled by default. People complain about OPi Zero and OPi PC2 (close enough to H3), but the former is about to reach mainline in u-boot 2017.03 (~1 week from now) and kernel 4.11 (~2 months from now), and the latter is still WIP, 8th version of the support patches was posted yesterday and it may be not the final one yet.

 

Regarding wireless drivers (8189es, 8189fs, XRadio) - they were poked just enough to make them work and it's not clear if anybody is interested in mainlining or just improving them, so unless they require some trivial fixes, they will probably stay as is for now.

Link to post
Share on other sites

OK, tried to follow procedure. Verbosity is already at max:

$ cat /boot/armbianEnv.txt | grep verbosity
verbosity=7

So next step - check storage integrity:

$ armbianmonitor -c /
mktemp: failed to create directory via template '//cardtest.XXXXXX': Permission denied
/usr/bin/armbianmonitor: line 731: /.starttime: Permission denied
$ sudo armbianmonitor -c /
Checking disks is not permitted as root or through sudo. Exiting

Erm...

Link to post
Share on other sites

On 7.3.2017 at 4:03 PM, zgoda_j said:

mktemp: failed to create directory via template '//cardtest.XXXXXX': Permission denied

 

Thanks, fixed: https://github.com/igorpecovnik/lib.docs/commit/d2e4196c5273e947fb5f47e360c49f5e74b0a346

 

Not really helpful, I know... But same behaviour with most recent Raspbian on Raspberries when using SSH over Wi-Fi: SSH sessions aren't terminated normally but time out (doing some Wi-Fi tests today with RPi 3 and maybe tomorrow on RPi Zero too)

 

Edit: Even less helpful but that's my OPi Lite running with legacy kernel and SSH session over Wi-Fi:

root@orangepilite:~# shutdown -h now
Connection to 192.168.83.98 closed by remote host.
Connection to 192.168.83.98 closed.

Details here: 

 

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

0