mirror of
http://galexander.org/git/simplesshd.git
synced 2024-12-24 15:08:07 +00:00
1707 lines
76 KiB
Plaintext
1707 lines
76 KiB
Plaintext
BUILD INSTRUCTIONS:
|
|
|
|
|
|
To build this without my private keys, you'll need to replace my
|
|
ant.properties symlink with an empty file. You'll have to build a
|
|
"debug" apk instead of a "release" one. Android will not let you install
|
|
a debug apk on top of a release one, so you have to remove stock
|
|
SimpleSSHD first before installing the debug build.
|
|
|
|
Then follow the steps in the "doit" script (you will need to change the
|
|
last line to indicate how you install the app on your phone or emulator).
|
|
|
|
The mv steps in "doit" are very important, because ant will only package
|
|
the necessary binaries if they have a .so extension (even though they are
|
|
stand alone executables).
|
|
|
|
|
|
|
|
DEVELOPMENT JOURNAL:
|
|
|
|
|
|
December 6, 2014.
|
|
|
|
The idea is to make a proper ssh implementation for Android. Important
|
|
features:
|
|
|
|
* it should run happily without root (on a non-root port)
|
|
|
|
* it should be a regular android app requiring no special permissions,
|
|
and not requiring any 'magic' executable files
|
|
|
|
* should not rely on busybox
|
|
|
|
* preferably support sftp
|
|
|
|
* open source
|
|
|
|
The existing apps are either expensive, don't work, need root, or too
|
|
complicated, or a mix of all of the above. And none of them are open
|
|
source.
|
|
|
|
I figure I'll start with dropbear, which I will run through JNI instead
|
|
of putting it in its own binary (because making such a binary executable
|
|
is a bit of a hack).
|
|
|
|
So that's the plan........
|
|
|
|
|
|
December 14, 2014.
|
|
|
|
I got dropbear to compile under the Android NDK, so now it's time to work
|
|
on the Android side of it.
|
|
|
|
I need:
|
|
* a Service that can be started, stopped, and queried for whether it's
|
|
running or not
|
|
* a Thread to implement the Service's work (by calling into dropbear's
|
|
main()), which can also be stopped.
|
|
* a config UI with at least these choices:
|
|
- bool: start on boot (def: false)
|
|
- number: port number (def: 2222)
|
|
- string: path to authorized_keys file (def: /sdcard/ssh)
|
|
- string: name of default shell (def: /system/bin/sh -l)
|
|
- string: default path for HOME (def: /sdcard/ssh)
|
|
- button: start or (if it's running) stop
|
|
|
|
|
|
December 15, 2014.
|
|
|
|
Getting to the fun part. Process management...
|
|
|
|
To start sshd, it seems like I can startService(). Then in the Service's
|
|
onStartCommand(), call startForeground() so it won't be killed (return
|
|
START_STICKY too?).
|
|
|
|
The question is if dropbear's main() should run under a separate Thread,
|
|
or a separate Process. The trouble with a Thread is that it might be
|
|
hard to kill. The trouble with a process is that there is no way to
|
|
report back status (such as a failure to start sshd).
|
|
|
|
Connectbot starts a new process for its shell -- it really doesn't have a
|
|
choice because the shell binary isn't linked with Connectbot, and exec()
|
|
in a thread stinks. To stop it, it just closes stdin/stdout!!! So
|
|
zombies can (and do) linger.
|
|
|
|
I suppose dropbear could be in its own process if it had something like
|
|
stdin/stdout to communicate failure? Or it could just write error
|
|
messages to (i.e.) /sdcard/ssh/log. To stop the service, it would just
|
|
use kill().
|
|
|
|
I am curious how the main waiting-for-connections loop looks, but even if
|
|
it uses select(), I'm not sure how I would honor Thread.interrupt() or
|
|
whatever. It's not guaranteed to interrupt select(), and I'm not keen on
|
|
adding an arbitrary timeout/polling feature to it.
|
|
|
|
|
|
December 20, 2014.
|
|
|
|
So, I added a builtin scp endpoint. It was pretty straight forward,
|
|
except dropbear defaults to vfork(), which blocks the parent until the
|
|
child runs execve()!!
|
|
|
|
Anyways, I noticed that scp doesn't quote its arguments to the remote
|
|
scp. That means you can't conveniently copy a remote file with a space in
|
|
its name (it becomes two files). But the upside is that this is where
|
|
wildcards are handled -- by the shell!
|
|
|
|
So I need to either run it as a separate executable launched through the
|
|
shell, or make my own implementation of wildcards.
|
|
|
|
It is easy, using a $(BUILD_EXECUTABLE) script, to get ndk to build an
|
|
executable. But it is only packaged up if it is named "gdbserver" (and
|
|
debug apk), or "libfoo.so". The good news is that libfoo.so can be
|
|
executed in /data/data/org.galexander.sshd/lib/libfoo.so, so that is a
|
|
viable option.
|
|
|
|
Doing the expansion myself is not necessarily hard either, though. I
|
|
need a library function called glob(), which is apparently not part of
|
|
bionic. But I have the idea some cut and paste would resolve that with
|
|
very little extra work on my part.
|
|
|
|
|
|
December 21, 2014.
|
|
|
|
Well, bionic libc *does* provide fnmatch(), and even scandir() (a
|
|
shortcut for readdir). In the best case, though, that still leaves me
|
|
with a bit of a path parsing conundrum (I have to tell scandir which
|
|
directory to operate on). And also a bit of an escape character
|
|
conundrum -- \* and "*" should not act like wildcards.
|
|
|
|
Those are not insurmountable but I think I've talked myself out of it.
|
|
So then the question is, do I figure out how to ship an executable, or
|
|
do I do some hack like open a pipe to "/system/bin/sh echo filespec" and
|
|
use the shell solely for expansion?
|
|
|
|
I'm developing the idea that it's actually pretty easy to ship an
|
|
executable, I just need to find some -pre-package step where I can do
|
|
"mv scp libscp.so" and then it will ship. ndk-build will not let me make
|
|
a target with a "." in it directly.
|
|
|
|
...
|
|
|
|
Now scp, sftp-server, and rsync work as separate executables... rsync
|
|
does fail at -z because it needs it's own custom zlib...The stock
|
|
"external" one seems to lack the "old-style compress" method. There is
|
|
another commandline option for the new (deflate?) technique, but I think
|
|
the normal -z ought to work too. But that is literally the last feature!
|
|
Then just release details.
|
|
|
|
|
|
December 29, 2014.
|
|
|
|
First problem report from a user. Lollipop (Android 5.0) requires "PIE"
|
|
executables -- position independent code. I think that is a modern
|
|
equivalent to -fpic that Android is now requiring so that it can
|
|
randomize addresses to try to obscure stack smashing attacks that rely on
|
|
fixed addresses. It is epicly lame.
|
|
|
|
Anyways, the big fuck-you from Google is that Ice Cream Sandwich (Android
|
|
4.1) and earlier require fixed-position code. So one binary will not
|
|
generally work on both.
|
|
|
|
Here is a good summary:
|
|
https://code.google.com/p/android-developer-preview/issues/detail?id=888
|
|
|
|
There is something called "run_pie" which you can wrap your executables
|
|
in that lets older Android run PIE executables. It would require a
|
|
relatively small change to the exec() call to prepend it with "run_pie".
|
|
That seems like a hack.
|
|
|
|
The suggested remedy is to build two different apks! Yuck!
|
|
|
|
Anyways, it is only executables (not libraries -- they are position
|
|
independent already) that are affected. And apparently static
|
|
executables don't care one way or the other.
|
|
|
|
So that is my remedy -- static executables for the moment. I tested them
|
|
and it is only a little bit bigger -- 904kB of binaries instead of 668kB.
|
|
|
|
|
|
January 18, 2015.
|
|
|
|
Markus Ethen suggested it display the current IP address so you know
|
|
where to ssh to, in case it isn't convenient to use static dhcp or to
|
|
remember the address. That seems to be easier said than done. You can
|
|
use WifiManager, but that won't give your IP address unless you're on
|
|
wifi. That is probably "good enough", but it is certainly not ideal.
|
|
There is also java.net.NetworkInterface, which seems to return a random
|
|
ipv6 address.
|
|
|
|
Ah-hah! It is fe80::macaddr, which is a bogus "local-connection only"
|
|
ipv6 address, like 192.168, but automatically-generated without dhcp.
|
|
So if I skip that, it finds the proper ipv4 address!
|
|
|
|
Pfew! I was thinking I'd have to directly use /proc/net/dev and
|
|
SIOCGIFCONF, just like ifconfig does, but it works fine with
|
|
java.net.NetworkInterface.
|
|
|
|
|
|
June 20, 2015.
|
|
|
|
At some points, rsync is only write()ing, and assumes that the other end
|
|
will receive it all. The other end does a little bit of write()ing of
|
|
its own, and then is happy to read() all it wants. So this written stuff
|
|
may sit in a buffer somewhere indefinitely. If that happens, an
|
|
infelicity in the design of SuperSU causes everything to wedge.
|
|
|
|
Of course, this is only if you set the shell to /system/xbin/su as a way
|
|
of having root access for rsync.
|
|
|
|
Anyways, I made a new program, "buffersu", which is just a
|
|
stdin/stdout-buffering wrapper for rsync that is guaranteed to always
|
|
perform any read() that is possible at any time, no matter how many
|
|
write()s are outstanding. That seems to do the trick.
|
|
|
|
|
|
June 21, 2016.
|
|
|
|
Chris Moore reports that rsync and sftp do not like files larger than 2GB.
|
|
|
|
rsync was easy - it just needed an additional #define in rsync/config.h
|
|
to enable its builtin support for using stat64/lseek64/off64_t/etc.
|
|
|
|
Now that I'm investigating sftp, I find this surprising fact about bionic
|
|
(though the glibc man page for stat(2) tried to tell me this) - stat64
|
|
and stat are the same thing! But off64_t and lseek64 are significant.
|
|
That should make converting sftp pretty convenient. Especially since
|
|
sftp already uses "u_int64_t" instead of off_t.
|
|
|
|
p.s. Chris Moore gave me this command to test sftp, which turned out to
|
|
be useful:
|
|
|
|
curl -v --pubkey .ssh/id_rsa.pub -r 2147482624-2147484672 -k sftp://mushroom:2222/sdcard/ssh/buh -o buh-new
|
|
|
|
As for scp, it's not as clear what needs to be done. It doesn't use
|
|
lseek. But it does use off_t a bit, including on an index in a for loop
|
|
that is compared against st_size (which is 64-bit). So I'll just change
|
|
all of the off_t to off64_t and hope for the best.
|
|
|
|
sftp and rsync work! Not gonna bother testing scp on big files...
|
|
|
|
|
|
October 1, 2016.
|
|
|
|
Jared Stafford told me startForeground() improves responsiveness on
|
|
Nougat. There had been a comment suggesting startForeground(), but I
|
|
never got around to trying it because it has worked "well enough". With
|
|
Nougat, though, there is a definite tendency for SimpleSSHD to be
|
|
non-responsive. I'm not sure exactly what its cause is, but the symptom
|
|
I notice most frequently is that the first ssh connection after a while
|
|
will be delayed "a long time" - on the order of 10-30 seconds, or maybe
|
|
indefinitely sometimes. Oddly, a second connection can sometimes get
|
|
through undelayed, even before the first connection does. It is as if
|
|
the fork() of process for the new connection is where the delay is, not
|
|
in the listen() call.
|
|
|
|
That's not overall too surprising, Nougat is a lot harsher about
|
|
background processes as part of a Google push to reduce power consumption
|
|
on idle devices.
|
|
|
|
Another concern is related to a change back in July - sometimes the
|
|
system will kill the sshd process for no good reason (maybe because they
|
|
removed it from the recent apps list). The remedy I settled on was to
|
|
monitor for the sshd process dying from within the regular
|
|
Android-managed process, and restart it. I guess I didn't write down
|
|
where in the documentation I found it, but Android seems expressly
|
|
antagonistic to non-system-managed processes. If they ever get more
|
|
hard-assed about that, this whole idea goes out the window.
|
|
|
|
Anyways, I implemented startForeground(), and I am unhappy that it
|
|
requires a Notification. At API 7 (Android 2.1) those are really
|
|
primitive. For example, the PRIORITY_MIN behavior which will sometimes
|
|
hide the notification is added in API 16 (Android 4.1). So, I've got it
|
|
with this stupid old-style notification, and it really doesn't look good,
|
|
and it is always present. That is not awesome.
|
|
|
|
On the other hand, it's easy to block the notifications, and a few people
|
|
have expressed an interest in a notification.
|
|
|
|
It doesn't seem worth it to me to upgrade to a newer API just for the
|
|
better notifications... On the other hand, Google Play shows that I have
|
|
862 users:
|
|
Android 7+ : 3.13%
|
|
Android 6+ : 37.47%
|
|
Android 5+ : 67.86%
|
|
Android 4.1+: 96.62%
|
|
Android 4.0+: 98.01%
|
|
|
|
The oldest reported version is Android 2.3.
|
|
|
|
So, there are a few people on very old versions, but actually SimpleSSHD
|
|
is used on newer devices than the average app, which is the reverse of my
|
|
typical trend. So a few people would be negatively impacted, but not a
|
|
very large number. I could switch to multi-APK mode so that legacy users
|
|
are just stuck with an unsupported back-version, which is probably what
|
|
they truly want anyways..
|
|
|
|
Anyways, I'm gonna use it with startForeground() and the notifications
|
|
disabled for a while, and if I find it to be an improvement then I'll
|
|
just make it so clicking on the notification goes to the app, update the
|
|
doc, and then publish it.
|
|
|
|
...
|
|
|
|
Looking up doze mode details for improving a different app, I stumbled
|
|
across this:
|
|
|
|
https://www.bignerdranch.com/blog/diving-into-doze-mode-for-developers/
|
|
|
|
One last case which is not mentioned in the Android documentation is
|
|
an app using a foreground service. Any process using a foreground
|
|
service is exempt from Doze Mode effects, which is key for
|
|
long-running applications that you may want to run even if the user
|
|
has put their phone down for a long period of time -- like a music app,
|
|
for example.
|
|
|
|
There is, however, a bug in Android Marshmallow which requires a
|
|
foreground service to be in a separate process from all other activity
|
|
code, documented here. It is planned to be fixed in Nougat.
|
|
|
|
Not exactly confidence-inspiring. And I haven't come across a
|
|
description of how exactly doze mode screws up SimpleSSHD, either.
|
|
|
|
It might be worthwhile to do the work to find out where things actually
|
|
get wedged, it might even be a flaw in Dropbear that makes it so
|
|
unreliable with Nougat.
|
|
|
|
|
|
October 16, 2016.
|
|
|
|
I've been using a foreground service for a while, and it has not caused
|
|
me any troubles. The thing I have been most anxious about is that it
|
|
might disable doze mode entirely...but there has not been any noteworthy
|
|
overnight drain.
|
|
|
|
So, in case someone does have problems with it, I am making it an option
|
|
that defaults to enabled.
|
|
|
|
Looking through email, I haven't seen any, but I have the idea several
|
|
users have asked for a notification icon in the past. And now that that
|
|
is finally implemented, I am curious about other things people have
|
|
requested that I have not been keen on. And Jan Ondrej's requests come
|
|
to mind:
|
|
|
|
o) setting to start the service automatically when the application is
|
|
launched
|
|
o) QUIT button that stops the service and the activity at once
|
|
o) not allow wifi to power down when the activity is open
|
|
|
|
I'm really not crazy about integrating any kind of wakelock. And having
|
|
two buttons still seems silly to me. But with the notification there,
|
|
the idea that someone will micromanage whether the service is running or
|
|
not does not seem so far fetched.
|
|
|
|
So I'll go ahead and add "Start on Open" setting.
|
|
|
|
...
|
|
|
|
Looking at reviews on Google Play Store, I finally found a couple reviews
|
|
in the last couple months who would have enjoyed password login. I'm
|
|
still pretty opposed to it because it seems like the usage model would be
|
|
to enable a default password, login with it to transfer an
|
|
authorized_keys file, and then disable the default password. That is
|
|
fine, and would even be kind of convenient (I might use it), but it seems
|
|
more often than not the default password would be left enabled
|
|
indefinitely, which is not awesome. And I can't imagine more than 1% of
|
|
users ever typing a strong password into their phones.
|
|
|
|
But I've thought of a compromise. What if, if there is no
|
|
authorized_keys file, it accepts passwordless logins but with some sort
|
|
of obnoxious alert dialog sort of thing to interrupt the user? That way,
|
|
you would be able to login once to copy the authorized keys file, and the
|
|
nuissance alert would be no big deal. Then once the authorized keys
|
|
exists, no further action is necessary.
|
|
|
|
It's a pity there is no convenient way to interact between the Android
|
|
GUI thread and the sshd thread.
|
|
|
|
Ah-hah! I've got the least effort idea in my head! Under situations
|
|
that I'm not sure what they should be, it should generate a random
|
|
password and display it on the phone's screen. Probably it should
|
|
generate it iff there is no authorized_keys file at all. Since that
|
|
detection happens for each client connection, then probably all of this
|
|
logic should go in dropbear itself, and the display should come through
|
|
dropbear.err.
|
|
|
|
Then we might even want a UI way to delete authorized_keys, perhaps even
|
|
as a replacement for the current awkward UI.
|
|
|
|
|
|
November 19, 2016.
|
|
|
|
I got a user request to update for security. I looked at dropbear and
|
|
didn't see any relevant security issues, so I'm gonna hold off for a
|
|
while, but it should be on my radar.
|
|
|
|
I also got a user request for writing to external SD card. He gave
|
|
this link:
|
|
|
|
http://stackoverflow.com/questions/33162152/storage-permission-error-in-marshmallow
|
|
|
|
It gives me a really strong deja vu, I think I tried that a few months
|
|
ago when a nearly identical request came in, and it didn't work. I wish
|
|
I had kept notes for that experiment!
|
|
|
|
I think there are two separate issues. I think Android 6+ push you to
|
|
use requestPermission() to explicitly enable the WRITE_EXTERNAL_STORAGE
|
|
permission, but if targetSdkVersion is low enough then you are
|
|
grandfathered in, so we don't care. The second issue is that Android 5+
|
|
require use of a special API to access a removable SD card (which is
|
|
different from /sdcard, which is typically internal storage protected by
|
|
WRITE_EXTERNAL_STORAGE on new phones?). That second issue is what is
|
|
biting people.
|
|
|
|
I don't know any way around that. If Google doesn't back down, then I
|
|
guess the only plausible way around it would be something like an
|
|
LD_PRELOAD that intercepts open/lseek/read/write/close to external SD,
|
|
and replaces them with connection to a local daemon process that is
|
|
running in a typical Android context and is able to use the awful API.
|
|
|
|
Seems like a lot of work and complication. I might go through with it if
|
|
I happened to use external SD myself, but I'm of the personal opinion
|
|
that removable storage is obsolete now that even relatively cheap phones
|
|
like the base Moto G4 come with 16GB... 640kB ought to be enough for
|
|
anybody.
|
|
|
|
I told the most recent guy to try SuperSU. I don't have any idea if that
|
|
will really work, to be honest.
|
|
|
|
|
|
October 28, 2017.
|
|
|
|
At the beginning of October, a user notified me that rsync doesn't work
|
|
on Android 8.0 (Oreo, API 26). In the past week, Google has upgraded my
|
|
Nexus 5x to Oreo and I can confirm it.
|
|
|
|
It seems that SE Linux or something causes certain system calls to
|
|
perform the equivalent of:
|
|
|
|
fprintf(stderr, "Bad system call\n");
|
|
exit(-1);
|
|
|
|
It should return ENOSYS instead, but someone at Google is not cool enough
|
|
to be working with Unix.
|
|
|
|
The first one I discovered like this is sigprocmask(), which we can
|
|
probably do without. The next one is chmod(), which is somewhat more
|
|
useful.
|
|
|
|
The troubling thing is that I can find a file where the commandline chmod
|
|
works, but the same chmod() doesn't work in rsync.
|
|
|
|
I figured maybe my NDK was just too old ("r10d"), but I think I can't
|
|
conveniently upgrade it because Google only distributes the NDK for Linux
|
|
x86-64 now. I was using SDK 7, so I tried SDK 11, 17, 19, and got the
|
|
same result. The NDK I have also has a directory for SDK 21, but it has
|
|
typos in the header files, or they aren't compatible with its version of
|
|
gcc. But anyways, if SDK 19 doesn't work then maybe it's more than just
|
|
linking against a bad version of Bionic.
|
|
|
|
Well, I think I've got it - fchmod() works, but chmod() does not.
|
|
*shrug*
|
|
|
|
|
|
March 4, 2018.
|
|
|
|
Looked in the google play console for crashes, and I find a few. 10
|
|
people have run into UnsatisfiedLinkError, and they seem to all be using
|
|
x86. According to
|
|
|
|
https://stackoverflow.com/questions/32598756/android-ndkhow-to-exclude-x86-device-in-google-player
|
|
|
|
It's not plausible to fix this problem by blacklisting x86 devices!
|
|
Google sucks! And the justification is that there is an ARM emulation
|
|
layer, but obviously it doesn't work and why should I have to debug it??
|
|
|
|
Anyways, someday may want to try making a jni/Application.mk and setting
|
|
APP_ABI in there to support x86 too? Do I really think that will work
|
|
for scp/rsync/etc? Guh.
|
|
|
|
And this bug has only one report... The startActivity() call to open the
|
|
documentation is getting a android.content.ActivityNotFoundException. I
|
|
guess it must mean there is no browser installed or something? I seem to
|
|
be using the normal way to visit an http programatically.. Only one
|
|
report, so I guess I just don't care.
|
|
|
|
|
|
March 24, 2018.
|
|
|
|
Win Bent emailed me to let me know his x86_64 Asus ZenPad is able to run
|
|
SimpleSSHD but is unable to run rsync. So, the ARM-on-x86 emulation
|
|
layer is catching up and now works sometimes, but isn't compatible with
|
|
the hack for scp/sftp/rsync. Win was kind enough to test a build that
|
|
supports just armeabi and x86, and reported it works. So I don't need to
|
|
build support for both x86 and x86_64, apparently. Nice to have a
|
|
concrete answer to the question!
|
|
|
|
|
|
|
|
May 16, 2018.
|
|
|
|
Roland Jaeger let me know busybox's "su" doesn't appreciate being called
|
|
with "-" prefix to argv[0] for a login shell, it can't find the "-su"
|
|
applet. su wants "-" to come in argv[>=1] instead to indicate a login
|
|
shell.
|
|
|
|
I guess it's kind of a hack but I just don't see it causing much
|
|
trouble... If the string "su" is found in the shell's name, it runs
|
|
"su -" instead of "-su". *shrug*. Roland tested it and reports it works
|
|
for him.
|
|
|
|
He also notes that the default /system/bin/sh distributed with his device
|
|
doesn't run .profile, instead it runs whatever is in $ENV. Apparently
|
|
mksh is "the Android shell", and indeed that is what's on my Nexus 5x.
|
|
mksh is supposed to run /etc/mkshrc (well, /system/etc/mkshrc on Android,
|
|
I guess), and then $ENV. But on my device, it loads .profile too. So I
|
|
guess there is some diversity of configurations. *shrug*
|
|
|
|
NB - bash supports the same idea but it calls the variable $BASH_ENV, or
|
|
$ENV if --posix is set. *shrug* And whatever shell comes with
|
|
SimpleBusyBox (ash?) loads .profile by default.
|
|
|
|
Anyways, it seems the obvious way forward is to make a setting for the
|
|
environment...just one name=value per line.
|
|
|
|
...
|
|
|
|
Noticed a couple crashes in the Play store console. One is a repeat of
|
|
this Note 7 that gives ActivityNotFoundException when viewing
|
|
documentation. I decided to catch the exception and display a dialog
|
|
asking the user to contact me, because I'm curious.
|
|
|
|
The other crash is a NullPointerException due to a bug in older Android
|
|
(a 2013 Nexus 7). It isn't my fault and I don't care.
|
|
https://issuetracker.google.com/issues/36972466
|
|
|
|
There is also an ANR, I think it's my very first! Here's the message:
|
|
Input dispatching timed out (Waiting to send non-key event because the
|
|
touched window has not finished processing certain input events that
|
|
were delivered to it over 500.0ms ago. Wait queue length: 25. Wait
|
|
queue head age: 34478.4ms.)
|
|
I can't tell if it's saying it blocked for 500ms or for 34s, but either
|
|
one seems problematic.
|
|
|
|
It's 4 identical-looking failures on one day, so it might be a fluke.
|
|
It's on x86_64, though I don't think that's the problem...
|
|
|
|
There are a ton of threads so it will be a bit of a trick to try to describe:
|
|
main - waiting in epoll_wait() under a bunch of framework
|
|
MessageQueue/Looper stuff.
|
|
Thread-23 - sleeping in UpdaterThread.run() line 26
|
|
Thread-15 - SimpleSSHDService.run()'s call to native waitpid()
|
|
and just a ton of misc threads that don't seem interesting to me
|
|
|
|
So, it seems like the main thread is specifically waiting for something
|
|
to do, I have no idea why it's not responding to user input. I don't
|
|
think the blocked UpdaterThread or SimpleSSHDService thread, because
|
|
those are specifically in other threads because they are designed to
|
|
block. I'm thinking it's a fluke of some sort, maybe a DoS sort of
|
|
scenario on this one device.
|
|
|
|
Anyways, the other thing I found out at the Play store is I got warned
|
|
because I'm supposed to "target a recent SDK", which means API level 26
|
|
(Android 8.0 Oreo). I think this is dumb but apparently it only means
|
|
I have to update android:targetSdkVersion to 26. I can leave
|
|
minSdkVersion at 7, and target=android-7. I hope.
|
|
|
|
I imagine a bit of UI will move around but it should just be a matter of
|
|
shaking it out and then testing it on an older device.
|
|
|
|
Oh, I just remembered the important new Androidism - permissions. In
|
|
particular, I think it is now more complicated than just
|
|
WRITE_EXTERNAL_STORAGE. Ugh?
|
|
|
|
Using my Nexus 5x (Android 8.1), updating to a new one with
|
|
targetSdkVersion 26, everything seems to just work. But the
|
|
blue-on-white for the IP display becomes blue-on-black and it is almost
|
|
unreadable. And also, it is kind of ugly. I think if I can switch it to
|
|
a dark theme or something that will work itself out.
|
|
|
|
But then I uninstalled the app and installed it from scratch with
|
|
targetSdkVersion 26, and that does not work at all. On startup it shows
|
|
the next "null" on every line where it's supposed to show the log. And
|
|
once the service is started, the log is still null, and anything
|
|
attempting to connect says:
|
|
Connection closed by 192.168.1.23
|
|
|
|
So my guess is that it's now more complicated than just
|
|
WRITE_EXTERNAL_STORAGE. Ugh!
|
|
|
|
...
|
|
|
|
A little info from
|
|
|
|
https://medium.com/google-developers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
|
|
|
|
which told me I can put the compile target much ahead of the min target
|
|
and supposedly I'll get warned if I use new features. Anyways, maybe I
|
|
can gate the new permissions model behind a simple if? I'm not sure if
|
|
it will be enough to explicitly ask for the permission, or if the
|
|
permission is accessed differently.
|
|
|
|
It also suggests I look at the "Platform Highlights" in the API Level
|
|
table at:
|
|
|
|
https://developer.android.com/guide/topics/manifest/uses-sdk-element
|
|
|
|
That's quite a few to check out to go from SDK 11 (Honeycomb) to SDK 26
|
|
(Oreo). But I'll probably learn something...
|
|
|
|
Have to use checkSelfPermission() and requestPermission() to get
|
|
"dangerous" permissions (WRITE_EXTERNAL_STORAGE). Luckily, INTERNET and
|
|
RECEIVE_BOOT_COMPLETED are "normal" permissions and just need to be in
|
|
the AndroidManifest.xml, I guess. And I don't need to worry about
|
|
READ_EXTERNAL_STORAGE, so long as I explicitly request
|
|
WRITE_EXTERNAL_STORAGE.
|
|
|
|
|
|
May 19, 2018.
|
|
|
|
Michael Mess wrote to let me know that he can't use authorized_keys file
|
|
because the /sdcard/ssh/authorized_keys file is group-readwritable. I
|
|
know regular OpenSSH on a PC does complain if the authorized_keys file is
|
|
world-writable, so this made sense to me. He says it is a security flaw,
|
|
but really, it is not, because any app that can run code and write to
|
|
/sdcard/ssh already has all of the permissions that SimpleSSHD has
|
|
(except network, but whatever) -- it isn't escalation, just a horizontal
|
|
spreading.
|
|
|
|
He suggested moving the SSH config into app-private, which is something
|
|
I've been toying with anyways.
|
|
|
|
So after some internal debate, I decided to do two changes:
|
|
|
|
* add "Copy app-private path" to the options menu, which brings up a
|
|
dialog showing the app-private path, with an option "Copy" to put it
|
|
in the clipboard.
|
|
* make the default for new installs for "home" and "path" be the
|
|
app-private dir
|
|
|
|
I look forward to seeing if anyone complains about it.
|
|
|
|
|
|
May 20, 2018.
|
|
|
|
I tried updating the build target to a newer version than minSdkVersion,
|
|
and I got a warning, and I looked at the official google documentation,
|
|
and you can't build with anything newer than the minSdkVersion. I mean,
|
|
I knew that, so, what I'm saying is, I feel stupid for reading that
|
|
medium.com link.
|
|
|
|
|
|
June 8, 2018.
|
|
|
|
Request from Joan Marce i Igual for --iconv. That requires iconv.h,
|
|
which isn't part of Bionic. GNU libiconv will do it, but it doesn't look
|
|
particularly easy to build, and it isn't small. Someone on github has
|
|
uploaded their tree for building iconv on Android, which might save me a
|
|
bunch of effort:
|
|
|
|
https://github.com/ironsteel/iconv-android.git
|
|
|
|
Unfortunately it doesn't have much history to it, so I don't know if
|
|
it'll be worth anything or not but it should give me a sense of the build
|
|
task without forcing me to decipher autoconf.
|
|
|
|
|
|
May 25, 2019.
|
|
|
|
To update to the new SDK (26 required now, 28 required starting in
|
|
August), I have to switch to gradle and all that garbage. Every time I
|
|
update anything with the new SDKs, everything breaks, even after I've
|
|
already updated everything to gradle. So basically it is the worst
|
|
possible development environment.
|
|
|
|
Anyways, the NDK now doesn't support anything older than android-16 (JB
|
|
4.1), which is stupid but whatever. Looking on the play store, it looks
|
|
like I have 5 users on these older devices. I hope it simply refuses to
|
|
update for them, and they can continue to use the older version!
|
|
|
|
... I got it to build and install and run, and it "works". The only
|
|
issue that is currently biting me is (on using am to install an apk):
|
|
|
|
InstallStart: Requesting uid 10180 needs to declare permission
|
|
android.permission.REQUEST_INSTALL_PACKAGES
|
|
|
|
Anyways, there's a bunch of stuff remaining to do, and then I will
|
|
release it.
|
|
|
|
|
|
May 26, 2019.
|
|
|
|
I got an AVD (emulated android) running SDK 26 (Oreo 8.0) x86. It uses
|
|
kvm virtualization so it's much faster than the old emulated ARM I used
|
|
to be shackled with.
|
|
|
|
Anyways, right off, it says (in a toast):
|
|
Developer warning for package "org.galexander.sshd"
|
|
Failed to post notification on channel "null"
|
|
See log for more details
|
|
adb logcat says:
|
|
05-26 17:13:49.877 1741 1764 E NotificationService: No Channel found
|
|
for pkg=org.galexander.sshd, channelId=null, id=1, tag=null,
|
|
opPkg=org.galexander.sshd, callingUid=10085, userId=0, incomingUserId=0,
|
|
notificationUid=10085, notification=Notification(channel=null pri=0
|
|
contentView=org.galexander.sshd/0x7f030001 vibrate=null sound=null
|
|
tick defaults=0x0 flags=0x40 color=0x00000000 vis=PRIVATE)
|
|
|
|
This gives a kind of deja vu -- I think from BluntMP3? I'm just adding
|
|
it to the todo list.
|
|
|
|
To access SimpleSSHD, run
|
|
adb forward tcp:2222 tcp:2222
|
|
ssh -p 2222 localhost
|
|
|
|
And it demonstrates that the sdcard access is forbidden. In fact, I can
|
|
toggle it inside the System Settings -> Applications -> SimpleSSHD ->
|
|
permissions -> Storage, and it takes effect more or less immediately.
|
|
|
|
Android development is such a constant stream of astonishing garbage.
|
|
When it requests the permission, which happens just as I would want it
|
|
to, it then pops up a "System UI has stopped" dialog. But look, it isn't
|
|
my fault:
|
|
|
|
https://stackoverflow.com/questions/49261555/system-ui-has-stopped-emulator-when-requesting-permissions
|
|
|
|
For real. There's a bug in the emulator you fix by "increasing the DPI."
|
|
I had tried some older 854x480 sort of emulated device because I didn't
|
|
want all those pixels, but I'll just use Pixel 2 (the default, and one
|
|
Google surely tests). It has a different skin where the soft buttons are
|
|
part of the skin, which is I bet what the bug is around.
|
|
|
|
So, the permissions request works now. It just asks once, and no matter
|
|
what the answer is, it never asks again. And if it is grandfathered in
|
|
because the previous version of the app used an older SDK, then it will
|
|
never ask and it'll just have the permission. And, at least on an
|
|
emulated Pixel 2, it can access /sdcard, which is "internal storage."
|
|
It does emulate an "SD card", but it can't access that.
|
|
|
|
...
|
|
|
|
Getting a channel onto the notification was a pain in the ass. All this
|
|
gradle stuff is getting increasingly undocumented. Every time they
|
|
change something so they won't ever have to change anything again, they
|
|
then immediately change everything. This leads to a mass proliferation
|
|
of immediately-obsoleted documents. It even damages resources like
|
|
stackexchange because people take their extraordinarily unique context
|
|
for granted when asking and answering questions. So something that
|
|
worked against gradle 3.3.4 will now be broken against gradle 3.3.5 but
|
|
no one will think to mention what version of gradle, or what version of
|
|
the build scripts gradle runs, or what-have-you.
|
|
|
|
Anyways, the upshot is, the way I got it to work is I opened the project
|
|
in Android Studio, and eventually I used Refactor->Migrate to AndroidX,
|
|
which turned out to have all manner of complications but here we go.
|
|
|
|
Speaking of Android Studio, the AVD Manager (Android Virtual Device, I
|
|
guess) is not accessible under Tools, even though it should be. Instead,
|
|
you have to click on the icon which is a portrait phone with a green
|
|
android head on the lower-right corner of it. Upper-right corner.
|
|
And you have to open a project before it will show you that. Jesus.
|
|
|
|
...
|
|
|
|
Testing with pie, I am able to reproduce the problem with start-on-boot.
|
|
Here's some excerpts from logcat:
|
|
|
|
05-26 21:24:26.251 1837 3408 W ActivityManager: Background start not allowed: service Intent { cmp=org.galexander.sshd/.SimpleSSHDService } to org.galexander.sshd/.SimpleSSHDService from pid=3756 uid=10085 pkg=org.galexander.sshd startFg?=false
|
|
--------- beginning of crash
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: FATAL EXCEPTION: main
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: Process: org.galexander.sshd, PID: 3756
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: java.lang.RuntimeException: Unable to start receiver org.galexander.sshd.BootReceiver: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=org.galexander.sshd/.SimpleSSHDService }: app is in background uid UidRecord{5aff37a u0a85 RCVR idle change:uncached procs:1 seq(0,0,0)}
|
|
...
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: Caused by: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=org.galexander.sshd/.SimpleSSHDService }: app is in background uid UidRecord{5aff37a u0a85 RCVR idle change:uncached procs:1 seq(0,0,0)}
|
|
...
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: at android.content.ContextWrapper.startService(ContextWrapper.java:664)
|
|
05-26 21:24:26.251 3756 3756 E AndroidRuntime: at org.galexander.sshd.BootReceiver.onReceive(BootReceiver.java:11)
|
|
|
|
So it looks like a pretty intentional rule that you can't start a service
|
|
from a boot receiver??
|
|
|
|
And I have the same problem on my Z2 Force (Oreo 8.0) now that I've
|
|
updated the SDK.
|
|
|
|
This guy says it will allow you to startForegroundService(), so that's
|
|
what I'll try...
|
|
|
|
https://stackoverflow.com/questions/49572570/android-start-a-service-on-boot-not-working
|
|
|
|
Which seems to work! So there is a need for some sort of dance in the
|
|
Settings screen to force it to enable foreground services if
|
|
start-on-boot is selected, and then we'll be golden.
|
|
|
|
|
|
June 16, 2019.
|
|
|
|
I finished the dropbear 2019.78 merge and got it all to work again on the
|
|
x86 version 28 (Pie) emulator. It also works on x86 version 26 (Oreo)
|
|
emulator, and on my ARM Oreo phone (Moto Z2 Force). I also tried with an
|
|
emulated ARM version 16 (JB 4.1), and it works, but it generates a lot of
|
|
this spamming the log:
|
|
|
|
Failed lookup: Non-recoverable failure in name resolution.
|
|
|
|
This gives me a kind of deja vu, something to do with library versions. I
|
|
have the idea it's because I built with a newer libc than what is found
|
|
by dynamic linking in older Android. But I cannot link the main dropbear
|
|
thing with -static because it needs to be JNI (which is loaded with
|
|
dlopen()). Apparently.
|
|
|
|
Anyways, I'm not sure there's anything I can do about that other than
|
|
reduce the log noise. I'm not really interested in digging up a magic
|
|
older version of the NDK or anything like that.
|
|
|
|
But I do think the only reason it has -static on the stand-alone
|
|
executables is basically a hack to make them work with the old NDK, so I
|
|
can get rid of that...
|
|
|
|
Testing with emulated x86 Android 21 (KK 5.0)... It seems to work fine.
|
|
It resolve my IP to the string "127.0.0.1", anyways. rsync seems to
|
|
work, and start-on-boot in the background works.
|
|
|
|
Anyways, I made a naive thing to decode an IP address to a numeric
|
|
string, in case getnameinfo() fails. It is working for me in the ARM
|
|
Android 16 now. It generates a reasonable string even though it
|
|
presumably fails to use the library lookup. It starts on boot as a
|
|
background service. And rsync and scp work. Only need to test on my
|
|
Moto X now.
|
|
|
|
...
|
|
|
|
Testing start-on-boot on my Moto Z2 Force, it works, but there is an
|
|
infelicity. If I go into Settings and try to turn off foreground
|
|
service, it won't let me because start-on-boot is selected and I am using
|
|
Oreo. It is supposed to show a toast to let me know this, but the toast
|
|
doesn't appear. That's because I had previously disabled notifications
|
|
so that the foreground service doesn't have a notification.
|
|
|
|
I can make the toast appear by following these steps: re-enable
|
|
notifications (manually in Settings -> Apps & Notifications), then
|
|
re-start the service, then disable the notification (by long-tapping on
|
|
the notification itself). Then toasts work. I think probably it has
|
|
saved the fact that all notifications are disabled, because it only knew
|
|
one class of notification when it was using compatibility with the old
|
|
SDK...but now it knows two classes (a notification and a toast), and it
|
|
records that only one class is disabled. I really have no idea but I
|
|
think it sucks.
|
|
|
|
...
|
|
|
|
Testing with Moto X (ARM, Android 5.1 API 22), and it works. But it has
|
|
this infelicity...when scp or rsync is run:
|
|
|
|
WARNING: linker: /data/app/org.galexander.sshd-2/lib/arm/libscp.so: unused DT entry: type 0x6ffffffe arg 0xb64
|
|
WARNING: linker: /data/app/org.galexander.sshd-2/lib/arm/libscp.so: unused DT entry: type 0x6fffffff arg 0x2
|
|
|
|
These are DT types that are present in the .so which are not supported by
|
|
the kernel. It may be because the kernel is CyanogenMod? The types are
|
|
DT_VERNEED and DT_VERNEEDNUM. They refer to a section .gnu.version_r,
|
|
which I guess holds two 32-byte entries which are unintelligible to me.
|
|
|
|
Supposedly I can use an "ELF cleaner" to strip out these DT_VERNEED
|
|
things. But there's some ambiguity as to whether they're necessary or
|
|
useful. I think I'm gonna leave that be.
|
|
|
|
More productively, I found that it won't startForegroundService() because
|
|
that was added at Oreo!
|
|
|
|
I can't seem to get start-on-boot to work, but from some of the crap in
|
|
logcat, I have the idea CyanogenMod might not be good at broadcasting the
|
|
boot event.
|
|
|
|
Now for the interesting test...I uninstalled SimpleSSHD on the Moto X
|
|
(API 22), and am reinstalling it new. So it won't have grandfathered
|
|
permissions. It works fine! No surprises. It still doesn't start on
|
|
boot *shrug*.
|
|
|
|
Now to try the same uninstall test with Moto Z2 Force (API 26). It works
|
|
fine, and on the first start-up it does ask for permission to access
|
|
files (/sdcard). To my surprise, it saved my Settings and my
|
|
/data/user/0/org.galexander.sshd/files. That's actually kind of bad,
|
|
because the host key would be saved, and there aren't really many
|
|
settings to re-enter in the upside case. Apparently this is new behavior
|
|
since I added targetSdkVersion>=23, so users haven't had their data
|
|
backed up yet and I can change this setting with allowBackup="false" in
|
|
the manifest...
|
|
|
|
allowBackup="false" took immediate effect and had no surprises...
|
|
|
|
|
|
August 4, 2019.
|
|
|
|
I finally got a dump from a user (Hammad), and it's quite distressing.
|
|
The stack trace is roughly:
|
|
backtrace()
|
|
sigsegv_handler()
|
|
/system/bin/app_process64+0x2a90
|
|
__kernel_rt_sigreturn()
|
|
A5xContext::HwAddNop(unsigned int *, unsigned int)
|
|
EsxCmdMgr::IssuePendingIB1s(EsxFlushReason, int, int)
|
|
EsxCmdMgr::Flush(EsxFlushReason)
|
|
EsxContext::Destroy()
|
|
EglContext::DestroyEsxContext()
|
|
EglDisplay::MarkContextListForDestroy()
|
|
EglDisplay::Terminate(int)
|
|
EglDisplayList::Destroy()
|
|
EglDisplay::DestroyStaticListsMutexesAndTlsKeys()
|
|
EsxEntryDestruct()
|
|
/system/vendor/lib64/egl/libGLESv2_adreno.so+0x12780
|
|
[... cut off at 16 ...]
|
|
|
|
So many questions! I think app_process64 must be the actual C main() of
|
|
a process, responsible for branching into all the android system
|
|
libraries? I imagine it's involved because it's somehow intercepted the
|
|
SIGSEGV and re-dispatched it to my handler? I don't see any way we could
|
|
have branched into libGLESv2_adreno from userland, so the SIGSEGV must
|
|
come from the UI thread, I guess? Maybe this SIGSEGV is actually the
|
|
sort of thing we'd get if we tried to call UI code from the non-UI
|
|
thread??
|
|
|
|
It looks like GLES is busy cleaning itself up, and it crashes. Why's it
|
|
crash? Why's it trying to clean itself up?
|
|
|
|
Hammad says there is no problem using sshd...I thought he meant that the
|
|
re-start logic is working for him but his dropbear.err has multiple dumps
|
|
in it! The SIGSEGVs are apparently not killing the daemon.
|
|
|
|
There are no timestamps on the dumps, but it looks like they're
|
|
associated with activity anyways. Each dump happens between "Disconnect
|
|
received" and "sigchld". Some of them have "server select out"
|
|
interleaved into the dump, which I think is the result of Hammad running:
|
|
while true; do ssh phone 'exit'; done
|
|
That is, it appears he starts a new connection the very instant the old
|
|
connection ends. So the new connection comes into the server process
|
|
while the child process is in the act of dying.
|
|
|
|
The thing is, I don't see how it could possibly be getting signals from
|
|
the Java side of things, because it fork()s before setting up the signal
|
|
handling. It's not just running in a different thread, it should be a
|
|
totally separate process. I can test this but I don't think I'm wrong
|
|
about that.
|
|
|
|
So I guess just about the only thing that's really possible is that
|
|
there's an atexit() which survives the fork() because it isn't followed
|
|
up with an execve(). It's not caused by ARM, or even necessarily by
|
|
Android 9...the reason it doesn't show up in the emulator is that the
|
|
libGLES that registers the atexit() is vendor-supplied for specific
|
|
hardware ("Adreno").
|
|
|
|
So I need to figure out how to bypass the atexit() somehow, perhaps by
|
|
calling _exit() directly?
|
|
|
|
|
|
August 12, 2019.
|
|
|
|
Kumaran Santhanam suggests START and STOP broadcast intents, which seems
|
|
A number 1 to me!
|
|
|
|
And a few people have written back to say the atexit bypass worked for
|
|
their SIGSEGV - pfew!
|
|
|
|
|
|
September 21, 2019.
|
|
|
|
First, some user reports.
|
|
|
|
Kumaran says the START/STOP broadcast intents work wwith Tasker on
|
|
Android 7 but not on Android 9. He also reports it works from the shell
|
|
(am broadcast --user 0 -a org.galexander.sshd.START org.galexander.ssh)
|
|
so I'm not sure what the difference is, and I'm not super inclined to
|
|
install Tasker to find out. I wonder if there is some sort of implicit
|
|
distinction between sending a broadcast intent and sending a service
|
|
intent that is negotiated differently at Android 9?
|
|
|
|
Roman reports that it "works" on his Onyx Boox i68ML (eink, I think), but
|
|
it doesn't refresh the log display so he can never see the
|
|
one-time-password. I think I just need to find a way to manually trigger
|
|
a refresh of the eInk but I haven't found anything like that yet...just a
|
|
bunch of people reporting that other apps (KOReader, CoolReader) stopped
|
|
working on onyx boox at some point. I do remember being somewhat
|
|
surprised that the log view worked at all, so maybe there is something
|
|
missing from my use of TextView and we just have been getting lucky...
|
|
|
|
But while I was looking for a way to get the android emulator to emulate
|
|
eink (no dice), I stumbled onto the Android TV emulation! I haven't
|
|
received one of these requests recently but they used to be a common
|
|
occurrence, and I suspect people would really appreciate if SimpleSSHD
|
|
was just available regularly through the app store on TV.
|
|
|
|
With the emulator, I was able to sideload the app with adb, and then
|
|
enable it under Settings -> Security & Permissions and then launch it
|
|
with Settings -> Apps -> SimpleSSHD -> open. Then it works, except
|
|
there's no three-dots menu button, so no way to get to Settings.
|
|
|
|
Anyways, there's a whole laundry list of things to do to get into the app
|
|
store and to get shown in the regular launcher.
|
|
|
|
...
|
|
|
|
Luckily, even though the list of requirements is long, it is largely
|
|
irrelevant or redundant, so I'm just about there.
|
|
|
|
...
|
|
|
|
On Android, they suggest you make a URL Intent and send it to the system
|
|
browser. But on Android TV, you make a WebView, I guess there is no
|
|
stock Chrome. It's easy enough. The disconcerting part is I can't test
|
|
it on my emulated phone or real phone because WebView.loadUrl() just
|
|
defaults to sending to the system Chrome. That's fine, though,
|
|
apparently it's a known thing you can work around, but I really don't
|
|
need to work around it, assuming Android properly defaults to WebView
|
|
instead if Chrome isn't available. *shrug*
|
|
|
|
So I'm tagging the new version.
|
|
|
|
...
|
|
|
|
When I went to upload version 23, I found that there was a crash reported
|
|
on version 22 with Android 9, two users, a Galaxy S9+ and a OnePlus5T.
|
|
The crash looks like:
|
|
|
|
java.lang.RuntimeException:
|
|
at android.app.ActivityThread.performResumeActivity (ActivityThread.java:3992)
|
|
at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:4024)
|
|
at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:51)
|
|
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:145)
|
|
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:70)
|
|
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1926)
|
|
at android.os.Handler.dispatchMessage (Handler.java:106)
|
|
at android.os.Looper.loop (Looper.java:214)
|
|
at android.app.ActivityThread.main (ActivityThread.java:6990)
|
|
at java.lang.reflect.Method.invoke (Native Method)
|
|
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
|
|
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1445)
|
|
Caused by: java.lang.IllegalStateException:
|
|
at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1666)
|
|
at android.app.ContextImpl.startService (ContextImpl.java:1611)
|
|
at android.content.ContextWrapper.startService (ContextWrapper.java:677)
|
|
at org.galexander.sshd.SimpleSSHD.onResume (SimpleSSHD.java:62)
|
|
at android.app.Instrumentation.callActivityOnResume (Instrumentation.java:1412)
|
|
at android.app.Activity.performResume (Activity.java:7611)
|
|
at android.app.ActivityThread.performResumeActivity (ActivityThread.java:3984)
|
|
|
|
It's the startService() call for Start On Open. So I tested that on my
|
|
phone (Android 8), and on the emulator with Android 9 and 10, and I
|
|
couldn't get it to happen. Either it's upset that it isn't
|
|
startForegroundService(), or maybe it somehow starts the service even
|
|
after it's already been started and complains about that? It seems like
|
|
it must be intermittent or harmless, because one user has triggered it 6
|
|
times on different days over the week.
|
|
|
|
There's also a crash with version 19 on Android 9, and it only shows as
|
|
far as:
|
|
android.app.ActivityThread.performLaunchActivity
|
|
Which seems to me to maybe be the same spot? Anyways, it didn't recur,
|
|
and I'm not gonna be doing new updates to version 19 anyways, so,
|
|
whatever.
|
|
|
|
|
|
September 22, 2019.
|
|
|
|
The crash on startService() in onResume() has already been verified to
|
|
occur also at version 23, so I have to track that down. I found this,
|
|
which is likely to be the underlying problem:
|
|
|
|
https://stackoverflow.com/questions/52013545/android-9-0-not-allowed-to-start-service-app-is-in-background-after-onresume
|
|
|
|
It looks like the user opens the app with start-on-open, it works, and
|
|
then they let the phone fall asleep with SimpleSSHD on top, and some sort
|
|
of shuffle kills the service, and then they wake the phone up, and then
|
|
it tries to resume SimpleSSHD, which tries to re-start the service, which
|
|
fails because the phone hasn't finished waking up yet so even the top
|
|
activity isn't active yet, even though it's already in
|
|
SimpleSSHD.onResume(). Apparently acknowledged as a bug in Android 9.
|
|
|
|
I tried to synthesize this sequence on the emulator with x86 pie, and I
|
|
had no luck. I was able to get the service to die (by broadcasting STOP)
|
|
while the emulator was "asleep", but then it woke up it didn't cause any
|
|
trouble. I suspect it takes a few coincidences to reliably trigger.
|
|
|
|
Anyways, so what I'm doing is I'm having the startService() calls in
|
|
SimpleSSHD go through the SimpleSSHDService.do_startService() wrapper, so
|
|
that they become startForegroundService() calls as appropriate. This may
|
|
solve the problem on its own, if the user happens to have selected
|
|
foreground. But then I can also make this common path smarter...
|
|
|
|
On another note, I stumbled onto something that says Android 9 limits
|
|
implicit broadcasts (no explicit destination), and considers a broadcast
|
|
to be implicit even if it does have an explicit destination if there is
|
|
an "action string." !!! Not sure if that's something I can play with,
|
|
but putting it on the list.
|
|
|
|
|
|
October 7, 2019.
|
|
|
|
Tom Davidson was having some problems with port proxy. I guess he just
|
|
wants client-side -L and -D to work, which they do work, so far as I
|
|
know. But I tested, and -R does not work! My phone seems to have some
|
|
sort of firewall, it hangs instead of saying connection denied. So maybe
|
|
-R isn't bypassing the firewall. Another possibility is that dropbear
|
|
simply doesn't support -R, but I kind of thought it did?
|
|
|
|
|
|
January 10, 2020.
|
|
|
|
I was here to add Fionn Behrens' request for dark mode support,
|
|
especially for the Notification. And I found, it's already on the list.
|
|
There's a lot on the list.
|
|
|
|
|
|
January 29, 2020.
|
|
|
|
There's a cluster of reviews indicating problems with WinSCP:
|
|
|
|
Wojtek El Jan 9, 2020 at 8:52 AM
|
|
1 star
|
|
Worked great until latest update. Keeps loosing contection when
|
|
uploading file using sftp in WinSCP. Please do something about it then
|
|
I`ll change my rate. Android 5.1
|
|
|
|
Sounds like the new receive window size breaks WinSCP??
|
|
|
|
|
|
March 20, 2020.
|
|
|
|
I happened to install wine today, so I decided to try WinSCP. The newest
|
|
version of WinSCP (5.17.2) doesn't work, it gets an "Invalid access to
|
|
memory" error when connecting. Don't know why, maybe it's wine or maybe
|
|
it's WinSCP. Version 5.16.7 (slightly older) gets the same error.
|
|
Version 4.0.4 is way too old, and can't connect (doesn't know any modern
|
|
ciphers). Version 5.9.3 is just right, I guess. It "works". But then,
|
|
using SFTP to upload a file around 1MB, it reproduces the reported error.
|
|
WinSCP reports "Server sent command status 11". It has a log facility,
|
|
but it shows precious little information. It seems to send about 512kB
|
|
and then it says:
|
|
|
|
. 2020-03-20 20:35:08.191 There are 197377 bytes remaining in the send buffer, need to send at least another 164609 bytes
|
|
. 2020-03-20 20:35:08.191 Looking for network events
|
|
. 2020-03-20 20:35:08.191 Detected network event
|
|
. 2020-03-20 20:35:08.191 Enumerating network events for socket 536
|
|
. 2020-03-20 20:35:08.191 Enumerated 1 network events making 1 cumulative events for socket 536
|
|
. 2020-03-20 20:35:08.191 Handling network read event on socket 536 with error 0
|
|
. 2020-03-20 20:35:08.191 Server sent command exit status 11
|
|
. 2020-03-20 20:35:08.192 Selecting events 0 for socket 536
|
|
. 2020-03-20 20:35:08.192 Disconnected: All channels closed
|
|
. 2020-03-20 20:35:08.192 Connection was lost, asking what to do.
|
|
. 2020-03-20 20:35:08.192 Asking user:
|
|
. 2020-03-20 20:35:08.192 Connection has been unexpectedly closed. Server sent command exit status 11. ()
|
|
|
|
Not sure there's any information there. The SimpleSSHD log shows just a
|
|
normal "Exited normally". Does that mean sftp did an "exit(11)" ? Was
|
|
there a SIGSEGV? Did WinSCP just eat itself for no reason? I have not
|
|
been very impressed with WinSCP (and there is already a user report that
|
|
switching to FileZilla is the right remedy all around), but I would like
|
|
to investigate before throwing in the towel.
|
|
|
|
The file is created on the target with length 65536.
|
|
|
|
Anyways, first thing to do is dick around with the setting that probably
|
|
caused the problem. This is the change:
|
|
|
|
#define DEFAULT_RECV_WINDOW 524288
|
|
#define RECV_MAX_PAYLOAD_LEN (524288+16384)
|
|
|
|
The previous values were apparently
|
|
|
|
#define DEFAULT_RECV_WINDOW 24576
|
|
#define RECV_MAX_PAYLOAD_LEN 32768
|
|
|
|
Combinations DEFAULT_RECV_WINDOW / RECV_MAX_PAYLOAD_LEN.
|
|
512 kB / 512+128 kB broken
|
|
24 kB / 512+128 kB broken
|
|
24 kB / 32 kB fixed
|
|
512 kB / 32 kB fixed
|
|
512-32 kB / 512 kB broken
|
|
512-32 kB / 32 kB fixed
|
|
512-32 kB / 64 kB fixed
|
|
512-32 kB / 128 kB fixed
|
|
512-32 kB / 256 kB fixed
|
|
512-32 kB / 384 kB broken
|
|
|
|
It seems that WinSCP doesn't like RECV_MAX_PAYLOAD_LEN larger than 256kB.
|
|
|
|
Domagoj, who first pointed this out to me, sent this link:
|
|
|
|
https://lab.nexedi.com/nexedi/slapos/commit/605e564b8f3008cdb48dbc6e82c956029469ff02
|
|
|
|
There they say that the -W option allows a major improvement in speed,
|
|
but in order to be compatible with OpenSSH the RECV_MAX_PAYLOAD_LEN must
|
|
also be increased. I only made RECV_MAX_PAYLOAD_LEN "somewhat" bigger
|
|
than DEFAULT_RECV_WINDOW because that was how it was before...
|
|
|
|
So I guess I need to stop poking around in the dark, and find out these
|
|
things really do.
|
|
|
|
DEFAULT_RECV_WINDOW becomes opts.recv_window, which newchannel() uses to
|
|
pick the size of writebuf, and to set chan->recvwindow.
|
|
|
|
RECV_MAX_PAYLOAD_LEN-9 becomes RECV_MAX_CHANNEL_DATA_LEN, then goes into
|
|
chan->recvmaxpacket.
|
|
|
|
Both values are sent across by send_msg_channel_open_init()
|
|
(SSH_MSG_CHANNEL_OPEN), and also by send_msg_channel_open_confirmation()
|
|
(SSH_MSG_CHANNEL_OPEN_CONFIRMATION).
|
|
|
|
It looks like chan->recvwindow is decremented as things come into the
|
|
buffer, and incremented as they leave it. recvmaxpacket doesn't seem to
|
|
do anything other than get sent across.
|
|
|
|
RFC4254 SSH Connection Protocol defines these SSH_MSG_CHANNEL_OPEN
|
|
packets. DEFAULT_RECV_WINDOW is called 'initial window size' and
|
|
"specifies how many bytes of channel data can be sent without adjusting
|
|
the window". RECV_MAX_PAYLOAD_LEN is called 'maximum packet size' and
|
|
"specifies the maximum size of an individual data packet that can be sent
|
|
to the sender."
|
|
|
|
So, really, I think that there is no reason for RECV_MAX_PAYLOAD_LEN to
|
|
be bigger than DEFAULT_RECV_WINDOW. I think DEFAULT_RECV_WINDOW was just
|
|
unreasonably small in the Dropbear defaults, and RECV_MAX_PAYLOAD_LEN
|
|
happened to be the smallest that was permitted by compatibility.
|
|
|
|
A bigger DEFAULT_RECV_WINDOW would allow greater saturation of the pipe
|
|
without worrying about the latency of ACKs. A bigger
|
|
RECV_MAX_PAYLOAD_LEN just saves the overhead of having more packet
|
|
headers, I think. So I think in principle, DEFAULT_RECV_WINDOW will have
|
|
the bigger effect on effective bandwidth, so long as RECV_MAX_PAYLOAD_LEN
|
|
is at least "decently large."
|
|
|
|
So now I'm trying combinations to see performance and compatibility
|
|
OpenSSH (sending a 16.4MB file across ssh 'cat > /dev/null', wall time):
|
|
|
|
512-32 kB / 384 kB works 3.1s 3.4s 3.1s
|
|
512 kB / 32 kB works 2.4s 2.1s 2.0s
|
|
1024 kB / 32 kB works 2.2s 2.0s 2.2s
|
|
24 kB / 32 kB works 10.4s 10.3s 8.9s
|
|
512 kB / 256 kB works 2.3s 2.3s 2.1s
|
|
512 kB / 128 kB works 2.9s 2.1s 2.1s
|
|
512 kB / 512 kB works 2.4s 2.1s 2.2s
|
|
256 kB / 256 kB works 3.4s 4.5s 2.4s 4.7s 2.0s 2.1s
|
|
128 kB / 128 kB works 2.5s 2.3s 2.3s
|
|
64 kB / 64 kB works 3.8s 3.1s 3.2s
|
|
32 kB / 256 kB works 8.9s 9.1s 8.0s
|
|
64 kB / 256 kB works 3.9s 5.6s 3.1s
|
|
512 kB / 128 kB(again) works 2.3s 1.9s 2.0s
|
|
|
|
Obviously a lot of variation from noise on the wireless network, though I
|
|
think the larger receive window actually helps erase some of that
|
|
variability because it doesn't have to wait for the ACK whether the ACK
|
|
is delayed by congestion or not.
|
|
|
|
So, rather frustratingly, I've (somewhat) reproduced the performance
|
|
motivation for changing DEFAULT_RECV_WINDOW, but I haven't found the
|
|
compatibility motivation for changing RECV_MAX_PAYLOAD_LEN. So I'm still
|
|
stabbing in the dark. I suspect that the compatibility problem was
|
|
actually a since-fixed bug in OpenSSH, since ideally it should honor the
|
|
packet length limit regardless of the window size? Or! The report is
|
|
actually that a packet of length 32777 was sent... That's 32768+9, maybe
|
|
the -9 in the definition of RECV_MAX_CHANNEL_DATA_LEN is relatively
|
|
modern in Dropbear?? I bet that's it! It was a phantom all along that
|
|
was forcing RECV_MAX_PAYLOAD_LEN to grow.
|
|
|
|
Anyways, it looks like DEFAULT_RECV_WINDOW really just needs to be bigger
|
|
than 128kB, and RECV_MAX_PAYLOAD_LEN hardly matters at all. So I'm going
|
|
with 512kB / 128kB. And I confirm, that does work with WinSCP.
|
|
|
|
|
|
December 28, 2020.
|
|
|
|
Dropbear 2020.79 finally adds support for ed25519, which is a frequent
|
|
comment I've received from users because some openssh configuration
|
|
generates these keys by default I guess? Anyways, I'm finally updating
|
|
it to 2020.81.
|
|
|
|
The update went about as you would expect and seems to be successful. I
|
|
just onnected to my phone using an ed25519 user key for authentication --
|
|
it works!
|
|
|
|
So that's about time for a new release. People have apparently been
|
|
waiting since March for the WinSCP fix, though I stopped getting emails
|
|
about it and that's why I haven't bothered with it.
|
|
|
|
The only thing pending is updating to the SDK needed for the play store.
|
|
Supposedly they require 29 today and will require 30 in aug 2021. I
|
|
happen to have already used 30 for TunerTime, so I know I've got the SDK
|
|
version 30 installed all the way, so that's what I'm gonna aim for I
|
|
guess.
|
|
|
|
It's currently at 28, so that's not a huge step...
|
|
|
|
Looking at the list of things to expect when updating to SDK 30, the only
|
|
one that looks relevant is "scoped storage enforcement", which is just
|
|
the /sdcard nightmare that we've known all along is getting worse.
|
|
|
|
|
|
January 17, 2021.
|
|
|
|
I have had a little luck today... I tested a little with
|
|
requestLegacyExternalStorage and API 29, on an emulated Android 11, and
|
|
it seems to work. Users will likely need to use the new "Enable /sdcard"
|
|
menu option.
|
|
|
|
Also, it turns out to be trivial to honor the MY_PACKAGE_REPLACED
|
|
(package upgrade) intent using the same receiver as BOOT_COMPLETED, which
|
|
is going to be great for people going forward.
|
|
|
|
...
|
|
|
|
I have been banging on the problem people have reported with
|
|
"Non-matching signing type." with older versions of OpenSSH. I've been
|
|
told it's the OpenSSH 7.2p2 that ships stock with Ubuntu 16.04 and Mint
|
|
18.3. Rich D did the legwork and found it is probably
|
|
https://svn.dd-wrt.com/ticket/7179
|
|
|
|
There is a new check for expect_sigtype != sigtype in dropbear 2020.81.
|
|
The fix the dd-wrt guys came up with is simply to disable that check if
|
|
expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA256. I don't like simply
|
|
disabling the check, because I don't know what the role of the check is.
|
|
I don't want to be a blind fool.
|
|
|
|
It sounds like there's one protocol string "ssh-rsa" that can also be
|
|
used to represent "rsa-sha2-256". I did not bother to trace through how
|
|
that string gets converted into these numeric values. But at the bottom
|
|
of http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030200.html
|
|
it says the actual signature is DROPBEAR_SIGNATURE_RSA_SHA1. This makes
|
|
sense from grepping around the dropbear source:
|
|
|
|
{"rsa-sha2-256", DROPBEAR_SIGNATURE_RSA_SHA256, NULL, 1, NULL},
|
|
{"ssh-rsa", DROPBEAR_SIGNATURE_RSA_SHA1, NULL, 1, NULL},
|
|
DROPBEAR_SIGNATURE_RSA_SHA1 = 100, /* ssh-rsa signature (sha1) */
|
|
DROPBEAR_SIGNATURE_RSA_SHA256 = 101, /* rsa-sha2-256 signature. has a ssh-rsa key */
|
|
|
|
So confusion between those two sounds likely to me.
|
|
|
|
...
|
|
|
|
Triaged the crashes again. crash.20200109 is the only one that bothers
|
|
me. It will probably continue at a low incidence until I figure out
|
|
what's causing it.
|
|
|
|
...
|
|
|
|
Oh and! There is one more interesting problem, reported by Brad R and
|
|
Andreas S. Maybe it's different problems?? The thing in common is that
|
|
they aren't seeing anything displayed from the dropbear.err file, and
|
|
then they aren't able to connect. But Brad R says he used netstat and it
|
|
really is listening on the port, and he sent me a ssh -vvv report that
|
|
seems to show the server dropping connection after the client has
|
|
received an SSH2_MSG_KEXINIT, while waiting for a response to
|
|
SSH_MSG_KEXDH_INIT. So I guess the server must be running?
|
|
|
|
Andreas S concluded that the server isn't running, due to the lack of
|
|
displayed dropbear.err output. That made sense to me at first, but now I
|
|
think maybe his server is also running, just not working??
|
|
|
|
So one possible explanation for both of them is that they have put their
|
|
dropbear directory under /sdcard, and the external storage charley
|
|
foxtrot has made them unable to access their server's host key at the
|
|
same time as making them unable to diagnose the problem (unable to read
|
|
dropbear.err). I haven't yet asked either of them if they have
|
|
configured it to use /sdcard.
|
|
|
|
But I'm worried there's something more fundamental going on. We'll see
|
|
if they report any progress with version 27 that I just released.
|
|
|
|
|
|
January 18, 2021.
|
|
|
|
Andreas S and Brad R wrote back to say their problem is fixed. I suspect
|
|
their dropbear.err was somehow hidden by the external storage problem.
|
|
|
|
|
|
May 13, 2022.
|
|
|
|
Just got an astonishing email from an anonymizer service. Hopefully they
|
|
don't mind me pasting the contents here, because I don't have time to
|
|
look into it at the moment. They suggest a resolution for
|
|
crash.20220424:
|
|
|
|
Hello,
|
|
|
|
I see recent git change for your simplesshd app for
|
|
RemoteServiceException. I worked on fixing that in my own app before
|
|
and some devices have the issue, some don't. Its with the foreground
|
|
notification use that people have been using and is something Google
|
|
hasn't fixed.
|
|
|
|
You can work around it by using WorkManager and Worker. You don't need
|
|
to use the foreground stuff that way. I switched over my own apps that
|
|
way successfully and no more problems from that situation.
|
|
|
|
You can lookup "RemoteServiceException workmanager" and a stack
|
|
overflow page suggests this which is the only way I found to solve it.
|
|
|
|
I see you will also need to include the Android 11+ storage usage of
|
|
asking the user to select a folder for access using new
|
|
Intent(Intent.ACTION_OPEN_DOCUMENT_TREE), getting repeat URI use of
|
|
the path & files from DocumentFile via
|
|
DocumentFile.fromTreeUri(context, uri) for reading and writing to go
|
|
with it for all the public storage use.
|
|
|
|
Hope that helps.
|
|
|
|
I'm just sending from a temporary email address. Don't reply as I
|
|
won't get it. I'm not interested in back and forth :-)
|
|
|
|
I have faith that's a useful breadcrumb for RemoteServiceException. I'm
|
|
not sure what the ACTION_OPEN_DOCUMENT_TREE part has to do with...I've
|
|
looked into that before and was unable to figure out a way to use that to
|
|
directly access the filesystem in a sensible fashion but maybe there is a
|
|
way to get a real unix path access from it, or maybe it has improved
|
|
somewhat since the last time I looked at it. I probably won't be able to
|
|
make sense of that part until I am stuck with a phone that limits me and
|
|
I need to actually work through it. Maybe when I set up an Android 12
|
|
emulator I will see what's up.
|
|
|
|
|
|
August 2, 2022.
|
|
|
|
Got a new phone, with Android 11. SimpleSSHD seems to be a lot more
|
|
thoroughly unscheduled if it is in the background...I have to bring it to
|
|
the foreground manually to accept a connection, and if it's not a bulk
|
|
rsync then I need to stay in the foreground to even continue the existing
|
|
connection.
|
|
|
|
But just looking through Settings -> Addition settings -> Developer
|
|
options, I noticed "Suspend execution for cached apps". I disabled it,
|
|
and now sshd is responsive all the time. So that's something worth
|
|
sharing with the user. But also, it might not even be necessary for the
|
|
user to do it:
|
|
|
|
As a workaround, if an app has a process that needs to perform
|
|
activities while cached, change the process status to non-cached (such
|
|
as Bound ForeGround Service (BFGS) or foreground) before the process
|
|
needs to do any work to allow the app to remain active.
|
|
|
|
I don't know what that means, but it seems like an indication that there
|
|
is perhaps some new / advanced "foreground service" mode.
|
|
|
|
|
|
August 22, 2022.
|
|
|
|
It's freezing it again today. Here is it freezing it while it's executing
|
|
$ while true; do date; sleep 1; date
|
|
|
|
08-02 22:17:17.534 1926 4196 I OplusHansManager : freeze uid: 10278
|
|
org.galexander.sshd pids: [6026, 5953, 5952, 5948, 5946, 3666, 3665,
|
|
3614, 3568] scene: LcdOn
|
|
08-02 22:17:19.540 8813 23721 D IHansComunication: HANS
|
|
sendMessageToKernel: threadId = 540790373568, netLinkSetup = 1, type =
|
|
FROZEN_TRANS, targetUid = 10278, pkgCmd = PKG_CMD_MAX
|
|
08-02 22:19:27.124 1926 4197 I OplusHansManager : unfreeze uid: 10278
|
|
org.galexander.sshd pids: [6026, 5953, 5952, 5948, 5946, 3666, 3665,
|
|
3614, 3568] reason: AsyncBinder scene: LcdOn
|
|
08-02 22:19:27.125 1926 4196 I OplusHansManager : uid=10278,
|
|
pkg=org.galexander.sshd, transition from Frozen to Middle,
|
|
reason=AsyncBinder
|
|
08-02 22:19:27.128 1926 4197 I OplusHansManager : unfreeze uid: 10320
|
|
org.galexander.soft84 pids: [31948] reason: AsyncBinder scene: LcdOn
|
|
08-02 22:19:27.129 1926 4196 I OplusHansManager : uid=10320,
|
|
pkg=org.galexander.soft84, transition from Frozen to Middle,
|
|
reason=AsyncBinder
|
|
08-02 22:19:27.130 1926 4197 I OplusHansManager : unfreeze uid: 10317
|
|
org.galexander.bluntmp3 pids: [22587] reason: AsyncBinder scene: LcdOn
|
|
08-02 22:19:27.131 1926 4196 I OplusHansManager : uid=10317,
|
|
pkg=org.galexander.bluntmp3, transition from Frozen to Middle,
|
|
reason=AsyncBinder
|
|
08-02 22:19:37.147 1926 4196 I OplusHansManager : freeze uid: 10278
|
|
org.galexander.sshd pids: [6195, 5953, 5952, 5948, 5946, 3666, 3665,
|
|
3614, 3568] scene: LcdOn
|
|
08-02 22:19:37.157 1926 4196 I OplusHansManager : freeze uid: 10320
|
|
org.galexander.soft84 pids: [31948] scene: LcdOn
|
|
08-02 22:19:37.163 1926 4196 I OplusHansManager : freeze uid: 10317
|
|
org.galexander.bluntmp3 pids: [22587] scene: LcdOn
|
|
08-02 22:19:39.155 8813 23721 D IHansComunication: HANS
|
|
sendMessageToKernel: threadId = 540790373568, netLinkSetup = 1, type =
|
|
FROZEN_TRANS, targetUid = 10278, pkgCmd = PKG_CMD_MAX
|
|
08-02 22:19:39.161 8813 8835 D IHansComunication: HANS
|
|
sendMessageToKernel: threadId = 540790373568, netLinkSetup = 1, type =
|
|
FROZEN_TRANS, targetUid = 10320, pkgCmd = PKG_CMD_MAX
|
|
08-02 22:19:39.165 8813 8835 D IHansComunication: HANS
|
|
sendMessageToKernel: threadId = 540790373568, netLinkSetup = 1, type =
|
|
FROZEN_TRANS, targetUid = 10317, pkgCmd = PKG_CMD_MAX
|
|
|
|
So it decides to freeze it after a while, and then unfreezes it
|
|
"reason=AsyncBinder" every now and then for about 10 seconds at a time.
|
|
|
|
The two processes involved:
|
|
system 1926 841 13580368 523424 0 0 S system_server
|
|
system 8813 1 2182528 1084 0 0 S hans
|
|
|
|
I'm trying to see if system_server, at least, might be part of their open
|
|
source package. It doesn't look like it. I started downloading their
|
|
repo but it's almost entirely AOSP, and the parts they provide (at least
|
|
/usr/src/oneplus/android_system_core/) don't seem to be very useful.
|
|
|
|
I made a copy of its /system in ~/mole/system, and it looks like the
|
|
following .jar files in framework/ all reference Hans something:
|
|
ext.jar
|
|
framework.jar
|
|
oplus-framework.jar
|
|
oplus-internal-services.jar
|
|
oplus-services.jar
|
|
service-jobscheduler.jar
|
|
services.jar
|
|
|
|
So that's a lead for now.
|
|
|
|
|
|
August 6, 2022.
|
|
|
|
I noticed that for the past couple days, write access to /sdcard has gone
|
|
away! I felt like I was being gaslit, because I was sure it had worked.
|
|
Turns out, I had accidentally disabled write access in SimpleSSHD while I
|
|
was working on NGN! Oh! The human capacity for error. So I am still
|
|
able to write into /sdcard on a decently modern phone and that is a huge
|
|
reassurance about the possible future of SimpleSSHD on Android!
|
|
|
|
Anyways, when I restored write access, I re-installed the app and got to
|
|
see something which might substitute for start-on-boot failing:
|
|
|
|
08-06 17:45:17.415 4694 4694 I NotificationBackend: onReceive package
|
|
intent= Intent { act=android.intent.action.PACKAGE_REPLACED
|
|
dat=package:org.galexander.sshd flg=0x4000010 (has extras) }
|
|
...
|
|
08-06 17:45:17.834 1878 2105 W BroadcastQueue: Background execution not
|
|
allowed: receiving Intent { act=android.intent.action.PACKAGE_ADDED
|
|
dat=package:org.galexander.sshd flg=0x4000010 (has extras) } to
|
|
com.google.android.packageinstaller/com.android.packageinstaller.Packa
|
|
ge InstalledReceiver
|
|
...
|
|
08-06 17:45:17.880 1878 2105 W BroadcastQueue: Background execution not
|
|
allowed: receiving Intent { act=android.intent.action.PACKAGE_REPLACED
|
|
dat=package:org.galexander.sshd flg=0x4000010 (has extras) } to
|
|
com.google.android.gms/.gass.chimera.PackageChangeBroadcastReceiver
|
|
|
|
It's probably not interesting but I was surprised to see that each of the
|
|
BroadcastQueue errors repeated 5x in the log, as if it was expected to
|
|
succeed.
|
|
|
|
I was expecting the problem to be that the broadcast receiver was
|
|
triggering but wasn't allowed to spawn a foreground service or something
|
|
like that, but it looks like the receiver is rejected much earlier.
|
|
stackoverflow confirms that people are getting the same problem with
|
|
BOOT_COMPLETED, and that it doesn't call BroadcastReceiver.onReceive() at
|
|
all!
|
|
|
|
There's a suggestion that it needs to register the receivers using
|
|
context.registerReceiver(new BroadcastReceiver(...), new IntentFilter(...))
|
|
That seems crazy.
|
|
|
|
It is apparently this:
|
|
|
|
https://developer.android.com/about/versions/oreo/background#broadcasts
|
|
|
|
Which I thought I already dealt with in order to receive BOOT_RECEIVER in
|
|
the first place (since I've already been using it under Oreo, version
|
|
26), but really I think what I'm running into is just that it's no longer
|
|
"grandfathered in" if you declare minSdkVersion 17.
|
|
|
|
Anyways, the google doc supports the hack of registering the receivers in
|
|
code instead of using AndroidManifest, which is just crazy.
|
|
|
|
OTOH, MY_PACKAGE_REPLACED is specifically supposed to be allowed in the
|
|
new regime (it is not "implicit" because it has an explicit target)! And
|
|
there's no reference to MY_PACKAGE_REPLACED in the logcat.
|
|
ACTION_MY_PACKAGE_REPLACED has been part of android.content.intent since
|
|
API 12.
|
|
|
|
Maybe it's upset seeing both MY_PACKAGE_REPLACE and BOOT_COMPLETED in the
|
|
same broadcast receiver in the XML??
|
|
|
|
|
|
August 25, 2022.
|
|
|
|
Reimer Prochnow sent a patch to use the new Android 11 permissions! They
|
|
are disappointed that it does not seem to allow more access than before,
|
|
but it will nonetheless probably be necessary when I update to the new
|
|
sdk.
|
|
|
|
Leaving it in reimer_prochnow-manage_extensions.patch until then.
|
|
|
|
|
|
September 4, 2022.
|
|
|
|
I want to resolve the two big problems for me since Android 11.
|
|
|
|
The resource starvation is bad. It is about 50/50 on completing my
|
|
morning rsync, and unfortunately it's streaky so I will go weeks without
|
|
a successful backup, I guess. And interactively, it seems to get about
|
|
2s of execution out of every 5 minutes, even if the phone is extremely
|
|
active in another app. It is definitely freezing it, not merely failing
|
|
to keep the CPU hot. The only way I can think to make progress on this
|
|
is to look in the Android framework and try to figure out what the actual
|
|
heuristic is for freezing. Or trial and error with dumb things like wake
|
|
locks and so on. But that's not what they're for! Ugh.
|
|
|
|
Oh, I found https://dontkillmyapp.com/oneplus, which led me to some
|
|
stabbing around in the UI. I found and enabled hidden app settings for
|
|
"auto launch" (which might solve start-on-boot), and "never optimize
|
|
battery", and in the task switcher long-pressed on SimpleSSHD then
|
|
"lock". And that seems to have done it! It only starves for resources
|
|
if the phone is asleep! Well, maybe. I will have to wait and see.
|
|
|
|
I can't tell how it's really working, but after about 30 seconds of
|
|
while true; do date; sleep 1; date
|
|
it stops, but then it immediately resumes the moment I hit enter on my
|
|
terminal! I'm having a hard time imagining the heuristic it uses to
|
|
detect that event.
|
|
|
|
Anyways, too bad that's a OnePlus-specific hack that won't help anyone else.
|
|
But I should probably add dontkillmyapp.com to the doc, I guess.
|
|
|
|
|
|
The other problem is the inability to trigger an intent from the shell,
|
|
which is single-handedly responsible for me needing a cable just to
|
|
upgrade my own apps. "am" used to allow this, but it now says (on
|
|
stderr):
|
|
|
|
java.lang.SecurityException: Permission Denial:
|
|
package=com.android.shell does not belong to uid=10278
|
|
|
|
I googled that and found confirmation of the problem, but no reported
|
|
work-around. It doesn't matter what I put as --user: none, --user 0,
|
|
--user 278, --user 10278, all the same result. --user -1 gives a
|
|
different error "Error: Can't start service with user 'all'". I did find
|
|
a report that "am start-foreground-service" still works but I'm shrugging
|
|
at it. It has been becoming harder to launch "am" over the years and if
|
|
this isn't when the camel broke, then I think I'd rather not know.
|
|
|
|
FWIW, the --user 0 one works under 'adb shell'. Of course.
|
|
|
|
I want to take the first timid step towards the future nuclear option. I
|
|
want to make a way for my unix environment to communicate with the java
|
|
side of SimpleSSHD, so that it can launder requests as if they are coming
|
|
from Java.
|
|
|
|
It seems like something on the order of a named pipe, AF_UNIX socket, or
|
|
a TCP/IP socket is indicated. The TCP/IP socket could be plausibly
|
|
secure by providing an authentication string in a $SIMPLESSHD_TOKEN env
|
|
var that would authenticate it?
|
|
|
|
|
|
And a third problem! I keep losing the ability to write to /sdcard.
|
|
The upshot is, this time I got it back simply by doing
|
|
"... -> Enable /sdcard" again. Why does it lose that? In settings ->
|
|
apps -> SimpleSSHD -> Permissions it says "Allowed Storage All Files",
|
|
but it also says, at the bottom, in small print:
|
|
|
|
To protect your data, if the app is unused for a few months, the
|
|
following permissions will be removed: Storage
|
|
|
|
Well it hasn't been a few months but it does very much seem like someone
|
|
is removing or degrading the storage permission on some sort of schedule.
|
|
Sigh.
|
|
|
|
|
|
September 5, 2022.
|
|
|
|
The OnePlus 'auto-launch' setting seems to have fixed both start-on-boot
|
|
and start-after-apk-upgrade! Hooray!
|
|
|
|
|
|
XXX - Hammad asks for 'quick settings tile' to turn it on and off
|
|
XXX - Andinus asks for 'Stop' to kill existing connections
|
|
XXX - Nazar asks for holding a screen wake lock, i guess we could do it just while the app is open
|
|
|
|
XXX - each time it starts, mkdir apiXX (if not present), fill in apiXX/ss_api (if not present), ln -sf apiXX api (overwriting if different), fork a thread in java that listens on 127.0.0.1:port, set $SS_TOKEN, $SS_PORTNO
|
|
XXX - make api for start http intent
|
|
XXX - make api for start apk install intent?
|
|
|
|
XXX - try MANAGE_EXTERNAL_STORAGE permission -> ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION intent action, will that help??
|
|
|
|
XXX - should probably add dontkillmyapp.com to the doc
|
|
XXX - why is it 100% starved of foreground service cpu time, unless it happens to have been running when i switched away from the app
|
|
XXX - why won't it start on boot?
|
|
|
|
|
|
XXX - message about can't do background service on oreo should say oreo or later
|
|
|
|
XXX - for Jose Miguel, script to run when user clicks 'start' or even when IP changes? to like use curl to notify about a dynamic IP..
|
|
|
|
XXX - update rsync version for Michael H
|
|
|
|
XXX - --remove-source-files rsync deleting doesn't work? is unlink() failing or is it trying something else first that fails?
|
|
|
|
XXX - see if i can reproduce android 11 problem with executing files in app-private
|
|
XXX - see if /data/user_de/0/org.galexander.sshd bypasses it on the emulator??
|
|
XXX - try busybox on android TV again, try putting the binary in "native libs" and sharing it from there
|
|
XXX - use linker hack instead of execve? supposedly you can "/lib/ld-linux.so.2 /bin/echo"
|
|
|
|
XXX - crash.20200109
|
|
XXX - on android 6 (duckling moto g2), the notification is white-on-white?
|
|
XXX - test Settings and Notifications colors in Pie (or Quiche?) "dark mode" for Alexander Chobot, and for Fionn Behrens (https://developer.android.com/guide/topics/ui/look-and-feel/darktheme)
|
|
XXX - if the unlink(authorized_keys) fails, or if the open() fails for permission reasons, generate a Toast for the user. (confirmed that restorecon -F authorized_keys works)
|
|
XXX - why doesn't "ssh -R 2223:192.168.1.254:80 mouse" work?
|
|
|
|
XXX - when i am forced to upgrade to SDK 30, request MANAGE_EXTERNAL_STORAGE permission
|
|
XXX - Vitalii suggests giving an error message for unrecognized key types (ed25519) that are encountered in authorized_keys, so the user doesn't have to stab in the dark
|
|
XXX - ability to dynamically request <uses-permission-sdk-23 android:name="android.permission.SEND_SMS" /> (and if that's dynamic, could we make the install app permission also dynamic??)
|
|
|
|
XXX - figure out how to force a screen refresh on eink devices (onyx boox) when the password is displayed (Roman)
|
|
XXX - Tasker on Android 9 can't trigger the new START/STOP intents? (Kumaran)
|
|
|
|
--- new release
|
|
|
|
XXX - libiconv? HAVE_ICONV_H etc
|