Ah, given that both sides are loopback, TCP/IP doesn't really even enter into it in a meaningful way. I think the problem pretty much has to be with your client.
I began suspecting that once you mentioned that closed connections stayed open until you killed the process. A RST on one should trigger a close on the other side. I've had good luck with openSSH, and though I've not used it heavily, I've heard good things from others, so I think it's a solid choice. But google around, there are others. Another possibility is to use OpenVPN. This will let your clients talk directly to the target server or servers, rather than to a local forwarded port. This is a lot more flexible, if that's a good thing. If you want to lock down and limit access, you're better off with port following. On Feb 3, 10:55 pm, mericksonj <mericks...@gmail.com> wrote: > The lack of an application-level timeout does explain why software > will generally hang. > > The error message that I've seen the most is as follows: > java.net.SocketTimeoutException: The operation timed out > > Now, in my tests with a PC, the sockets are generated and torn down > dynamically with the client always connecting with its random port to > the same passive port on the server. > > The android device will not tear the connection down however after the > exception. The session will stay up indefinitely as established on > both ends until I kill the port forwarding process. > > There does also appear to be situations where I can get a directory > "list" received from the server to show up on the client device > (subsequent cwd commands work, but list will fail), but it seems to be > intermittent and very erratic. Which leads me to take more notice of > the buffer messages rather than a specific point in the code that > breaks down. > > As for NAT or Firewall issues, all client communications are looped.. > meaning that with the TCP tunneling in place, all FTP packets are sent > to 127.0.0.1 where it is picked up by SSH for crypto and encaps into > another IP packet. Once at the SSH server, the outer packet is > stripped, contents are decrypted and sent to the FTP server. The FTP > server (same box as the SSH server) thinks it came from 127.0.0.1 and > uses that same IP for its replies. I guess that's just the long way > of saying that each device thinks it's talking to itself, so there's > no NAT or firewall confusion. At least not until I move the FTP > service off my SSH server, but even then IP masquerading in the > proftpd_conf will fix the NAT issue. > > I really think a TCP dump would help the issue.. at least I could see > how big the FTP packets are, if they're being fragmented, and when/ > where they're being sent. I just found the tcpdump on the emulator, > how can I filter out the non-interesting packets? > > I would like to try similar port forwarding tests using adb or other > tools, is there a recommended tutorial on how to use the port > forwarding there? will it be able to simulate what I'm doing with > SSH? > > Also maybe trying a different SSH client would help, is there anyone > besides connectbot that accepts RSA keys and allows TCP port > forwarding? > > -- > Regarding the security discussion, I think in my setup I'm pretty safe > since all FTP packets are looped within client/server platforms as > described above, but you do make a case for FTPS w/out encryption that > could maybe alteast mask the username and password within the system > or in case I ever do move the FTP server off the SSH box, then again, > it is at least on a trusted network once the SSH server decrypts it. > > Again, Thanks! > --James -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
