Can't SSH Into Kindle Touch

[twobob]

Mine required a binary patch. as may others in the future. solution found. thanks for the report though!

[ixtab]

Originally Posted by twobob

Mine required a binary patch. as may others in the future. solution found. thanks for the report though!

@twobob: Since the binary patch that you are mentioning is for the diags partition anyway, it would have been much easier to just flash a "known working" diags partition with SSH... or - even easier - the update package.

Just sayin'

[knc1]

@ixtab: But that course would not have turned up the reason.

[twobob]

Originally Posted by ixtab

@twobob: Since the binary patch that you are mentioning is for the diags partition anyway, it would have been much easier to just flash a "known working" diags partition with SSH... or - even easier - the update package.

Just sayin'

err... I used that. Twice IIRC. it's on the thread. Got wiped both times. (that was the second)

I documented it. a few times.

Once you startup the DIAGS it wipes the /blah/local.

[ixtab]

Originally Posted by twobob

err... I used that. Twice IIRC. it's on the thread. Got wiped both times.

I documented it.

Nope. Absolutely impossible. I just checked it again with the file that I linked to - the system_diags file inside the partition image doesn't even contain the string ("rm -rf /usr/local/*") that you have patched:

$ strings /mnt/opt/factory/system_diags |grep local
localtime
/usr/local/bin/dropbearmulti
mkdir -p /usr/local/sbin
/usr/local/sbin/dropbearkey
/usr/local/sbin/dropbear
rm -f /var/local/system/low_batt

[twobob]

Originally Posted by ixtab

Nope. Absolutely impossible. I just checked it again with the file that I linked to - the system_diags file inside the partition image doesn't even contain the string ("rm -rf /usr/local/*") that you have patched:

$ strings /mnt/opt/factory/system_diags |grep local
localtime
/usr/local/bin/dropbearmulti
mkdir -p /usr/local/sbin
/usr/local/sbin/dropbearkey
/usr/local/sbin/dropbear
rm -f /var/local/system/low_batt

That may be so. And obviously IS given that evidence.

but on my device that is what happens. Over and over. Don't make me break it again to prove it ;( I didn't just create that rogue bin on my own. and I did install your files at least twice. I noted the fancy progress text

(err, and those diags sshd upstart entries were yours, No?)

So impossible, No, odd, yes.

something somewhere must be doing something unexpected. That's as specific as I am going to get. but it's real. B011 device.

[ixtab]

Originally Posted by knc1

@ixtab: But that course would not have turned up the reason.

I can only speculate here, but the reason seems much simpler: people get their device into USB mode (while running in main), but forget to unplug and re-plug the cable so that the host would actually recognize it as a new device and set up the network interface.

(Yes, this keeps happening to me, too.)

[ixtab]

Originally Posted by twobob

That may be so. And obviously IS given that evidence.

but on my device that is what happens. Over and over. Don't make me break it again to prove it ;( I didn't just create that rogue bin on my own. and I did install your files at least twice. I noted the fancy progress text

(err, and those diags sshd upstart entries were yours, No?)

So impossible, No, odd, yes.

something somewhere must be doing something unexpected. That's as specific as I am going to get. but it's real. B011 device.

OK, then so be it

Can you try to *manually* overwrite the diags partition using the commands (and the file) from the update.bin, and check if it keeps happening afterwards? (or... even better: compare the md5sums of the diags partition "before" and "after") ?

I have always been suspicious of whether the update.bin *really* worked the way that it should (it goes through just a bit too fast for my personal taste, so *maybe* it's actually not doing what it should do.) - then again, it always worked correctly on my device, and geekmaster confirmed that it worked smoothly on "demo K5 devices"...

[twobob]

Originally Posted by ixtab

OK, then so be it

Can you try to *manually* overwrite the diags partition using the commands (and the file) from the update.bin, and check if it keeps happening afterwards? (or... even better: compare the md5sums of the diags partition "before" and "after") ?

I have always been suspicious of whether the update.bin *really* worked the way that it should (it goes through just a bit too fast for my personal taste, so *maybe* it's actually not doing what it should do.) - then again, it always worked correctly on my device, and geekmaster confirmed that it worked smoothly on "demo K5 devices"...

I'll give that a go tomorrow then. see what happens, could be something specific to the slightly updated firmware. I dunno.

the challenges we face

[knc1]

Originally Posted by twobob

I'll give that a go tomorrow then. see what happens, could be something specific to the slightly updated firmware. I dunno.

the challenges we face

There may well be an "Early User Space" initramfs that is being run before switching to the eMMC based root file system.
**AND** the things executed in that EUS may be different on 2bob's system.

I have not (yet) taken apart his initial 32Mbyte eMMC area to confirm the above but we have seen 'left overs' in the ps aux listing.

[ixtab]

Originally Posted by ixtab

OK, then so be it

Can you try to *manually* overwrite the diags partition using the commands (and the file) from the update.bin, and check if it keeps happening afterwards? (or... even better: compare the md5sums of the diags partition "before" and "after") ?

I have always been suspicious of whether the update.bin *really* worked the way that it should (it goes through just a bit too fast for my personal taste, so *maybe* it's actually not doing what it should do.) - then again, it always worked correctly on my device, and geekmaster confirmed that it worked smoothly on "demo K5 devices"...

OK, so I just had a conversation via PM with someone who had the exact same problem (SSH not working after using update.bin) Turns out that extracting it, and manually executing the run.ffs works exactly as it should.

Now... why on earth does it not work from the update.bin? The dd command gets executed (and yes, I have verified that it changes at least something on the diags partition, by creating a test file in diags, running the update.bin [which doesn't contain that file], and verifying that the file was gone afterwards), and runs for about 5 seconds (only).

So, first question is: how can that be? It seems like it is killed by something. I'm not too familiar with these "policy" things, but could it be that something like a ulimit/something similar is set, which would kill a process after some time? And... if so, my understanding is that the diags partition should actually be a complete mess, with a broken FS. But it seems to be just fine, even with an "aborted" dd. WTF is going on here?

EDIT: just for completeness, and to make things even stranger: while the dd runs through too fast (5 secs, where it should really take something like 10 or 20), which makes me think that it gets aborted, it still returns a 0 exit code.

[NiLuJe]

@ixtab: Well, after a quick look at the package, it at least unearthed a stupid bug in KindleTool, but I'm not sure it's actually harmful since everything runs as root... (When creating a tarball, directories end up with broken permission: they're not searchable).

Will continue looking into it...

EDIT: Not sure what's the $PWD during the update process when the install script is in a subdirectory, and since it's using relative paths, I'm not quite sure it's actually finding the kernel & partition dumps... (Try repacking it with -C ?) [I'm still confused, like you, as to why that wouldn't completely wreck the FS, though. But I'm not familiar with dd, and even less with busybox's implementation, so, there may be some *nix magic at work here ^^]

[ixtab]

Originally Posted by NiLuJe

@ixtab: Well, after a quick look at the package, it at least unearthed a stupid bug in KindleTool, but I'm not sure it's actually harmful since everything runs as root... (When creating a tarball, directories end up with broken permission: they're not searchable).

Will continue looking into it...

EDIT: Not sure what's the $PWD during the update process when the install script is in a subdirectory, and since it's using relative paths, I'm not quite sure it's actually finding the kernel & partition dumps... (Try repacking it with -C ?) [I'm still confused, like you, as to why that wouldn't completely wreck the FS, though. But I'm not familiar with dd, and even less with busybox's implementation, so, there may be some *nix magic at work here ^^]

Yeah, I might try the "-C" switch. Actually, I think I'll try the kamikaze method and zero out the diags partition, then run the update.bin and see what happens

[twobob]

Originally Posted by askak

Hi,
I had a hard time connecting ssh, my error was something similar, time out connection fail port 20, I can't recall exactly now, but I searched the forum and lot of peaple had it. I also remember reading what geekmaster recomends you.
Well it may sound idiotic, but I finally made it, unplugin and pluging again the usb cable of the kindle to the pc. Really.

actually that doesn't sound so daft. just saying