-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
Most of the failures on this platform produce no error message, so this is mostly a list of symptoms and what actually causes them.
The descriptor opens as a page of text instead of installing.
The server is sending the wrong MIME type. It must be
text/vnd.sun.j2me.app-descriptor. See Installing.
The install fails with no explanation.
MIDlet-Jar-Size in the descriptor does not match the jar's actual length.
Usually the two came from different builds, often through a cache serving an
old descriptor beside a new jar. Serve both no-store.
The browser will not load the page at all. The hostname redirects HTTP to HTTPS. The device cannot complete a modern TLS handshake — TLS 1.0 at best, and a trust store from 2011. Use a hostname that does not redirect.
907 Invalid JAR — missing stack map.
The jar was not preverified. See Building from source.
The device says it is already installed. The version in the descriptor must be higher than the installed one. Equal is refused, and the message does not mention versions.
"no transport reached host:port". Nothing answered on any of the three connection modes berryssh tries. Check Wi-Fi is up, and that you are on a network that can see that address — a handset on mobile data cannot see your LAN.
"THE HOST KEY FOR ... HAS CHANGED". Either the server was rebuilt, or something is intercepting the connection. There is deliberately no way past this. If you know the server was rebuilt, delete the saved connection and create it again.
Authentication fails with a key that works from a laptop.
Three possibilities. The key is not Ed25519 — RSA is not supported, because it
needs BigInteger and CLDC has none. The key has a passphrase — also not
supported. Or the public half is not in the server's authorized_keys.
It connects, authenticates, then nothing appears. Usually a terminal size problem on an unusual screen. Try a different Terminal size in the connection editor.
"this is not an authenticating bridge". You set a Bridge key but the far side is a plain WebSocket-to-TCP proxy that pipes immediately and never asks a question. Either clear the bridge key, or point at a bridge that wants one.
"the bridge refused the key".
The key does not match the psk in the bridge's config. Note that it is
compared exactly — a trailing space from a paste counts.
"the bridge would not open X: no such target".
That name is not in the bridge's targets. Open the Bridge target field
again to re-fetch the list; it may have changed on the server.
"Could not ask the bridge".
The bridge could not be reached at all. Check with curl as shown in
Reaching remote servers — 101 means it is alive.
The field falls back to a text box so you can still type a name you know.
The session drops after about a minute of idleness.
An nginx in front with a default proxy_read_timeout. Set it to something
long: proxy_read_timeout 86400s;.
It works from the LAN but not from outside.
The reverse proxy is not passing the WebSocket upgrade. Caddy does this
automatically; nginx needs proxy_set_header Upgrade and Connection "upgrade" explicitly.
Some keys do nothing, others produce the wrong character. Known and open — issue #11. The mapping needs raw key codes measured on real hardware. The Keys item in the session menu shows the code for whatever you press; those measurements are what the issue is waiting for.
Open an issue. Useful to
include: the handset model and OS version, what the status line said, and
whether the same connection works from ssh on a desktop.