As cited here, I think there are likely issues unique to Terminal-IDE users because Terminal-IDE is, effectively, an "accessable-linux-on-your-non-rooted-Android" environment. And, therefore, it likely has unique environmental issues. So thank you for not immediately telling me to go to ServerFault or SuperUser...

After installing Terminal-IDE, I read all the help and set about taking advantage of the SSH tools - I really want to get logged in from another system so I have a full keyboard and can treat the phone just like any other networked system. However, I got stopped in my tracks pretty quickly.

I have several routing issues, but I'll put them all here in thinking they may well be related and one place is better than several for finding answers.

I'm using WiFi to get to/from the phone and, using my possibly lame Netgear WN802T WiFi unit (that doesn't have a DHCP server and requires another system to do that). The phone (and other devices) links up, gets an IP address, and surfs the internet from there just fine. I told the DHCP server to match up the MAC address and give a fixed IP - this way I avoid the "single IP for all interfaces when "fixed IP" is chosen" problems identified elsewhere on this site. I have confirmed that IP is indeed given to the phone.

So, I set up the sshd service as found in the official Help PDF. It runs. But no inbound connections succeed; they always end with "Connection timed out" (notably NOT "no route to host" - which is what I get when I ask for a non-existent IP). That tells me it MAY be actually getting to the port on the phone but nobody's answering! This leads to to immediate questions:

Is there a way to log inbound attempts?

Is there a "firewall" of some kind?

When I connect out-bound, it ONLY connects either on the wilds of the internet, OR on the default gateway the DHCP server told it about. It won't connect to ANY "non-routing IPs", even though other devices on the same WiFi will (so clearly the WiFi is routing to the local subnet just fine).

Do I have to create a route specifically pointing to the internal router (the netgear box)? Or;

tell the real outbound router how to route internally as well as externally?

Thanks for any insights.

EDIT TO SHARE MORE DATA

As I have continued to work the problem, and after many hours of frustration, I hooked up a USB cable to the phone and used "internet passthrough" to connect to a lap-top which itself is connected via the same wifi. Now I have more data.

I have confirmed the following:

connection via the laptop to the rest of the network is stable

connection to the phone from the laptop succeed in getting through authentication and, after discovering and fixing a minor typo in the sshd script, it works fine.

connection from the phone, through the cable to the laptop then has full access to the local internal network via IP address.

So, this strongly implicates that there are some issues with the phone's end of the WiFi and NOT with the WiFi itself, however, there's not quite enough data to say that since I haven't got sshd running on the laptop to know it is accepting connections through the net... Interestingly, it is not rejecting connection attempts out of hand - they take a long time to drop! (It's a Windows 7 laptop and, frankly, I don't really know how to tell it to open up specific ports - or how to forward to the phone!)

Note also that the only system that can connect to the phone via the wired connection is the laptop that the phone is wired to; so far I have been unable to find a way to get to the phone through the laptop.

1 Answer
1

A bit frustrated, I kept trying and then noticed something that I suppose should not have surprise me: I set one computer screen to 'pinging' the Android device, with ZERO reply for a long time, and forgot about it. Then, I later noticed the pings were getting through and there were zillions of them scrolling past.

From this, and a bit more investigation, I found that the stability of a WiFi connection on my Android device isn't very stable, especially as compared with my laptop.

In short, "be patient, ping the heck out of it while moving the device to find a good signal path, and it should eventually work."