OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Dropbear Keeps Regenerating Machine Key
agraef
post Dec 28 2006, 06:18 AM
Post #1





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



First, kudos to the OZ team for this release, it really works great for me except for the "altboot hangs on boot from loopfile" bug and the following minor issue.

I have Oz 3.5.4.1 on a C-1000 installed, altbooted from an SD card (direct install). Network via WLAN works great, but I have troubles with dropbear which regenerates the machine rsa key on every reboot. Of course that means that on my desktop I have to remove the key from .ssh/known_hosts every time I have to reboot the Z. This happens with both Opie and GPE. I don't have this problem with OZ installed in the flash, though.

I took a look at /etc/init.d/dropbear and noticed that on SD I have a dropbear_rsa_host_key file in *both* /etc/dropbear and /var/lib/dropbear. The relevant lines in /etc/init.d/dropbear are:

CODE
readonly_rootfs=0
for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }' </proc/mounts`; do
 case $flag in
  ro)
    readonly_rootfs=1
   ;;
 esac
done

if [ $readonly_rootfs = "1" ]; then
 mkdir -p /var/lib/dropbear
 DROPBEAR_RSAKEY_DEFAULT="/var/lib/dropbear/dropbear_rsa_host_key"
 DROPBEAR_DSSKEY_DEFAULT="/var/lib/dropbear/dropbear_dss_host_key"
else
 DROPBEAR_RSAKEY_DEFAULT="/etc/dropbear/dropbear_rsa_host_key"
 DROPBEAR_DSSKEY_DEFAULT="/etc/dropbear/dropbear_dss_host_key"
fi


So it seems that when booting from SD the startup script is invoked while the rootfs is still mounted readonly, in which case the script generates a new key in /var/lib/dropbear even though there is already one in /etc/dropbear.

Just commenting out the lines which check the rootfs (so that readonly_rootfs is always 0) works around this, but of course this will only work if you're sure that there's already a keyfile. It seems that to really solve that issue the logic in the script which tests for an existing keyfile needs an overhaul, but before I do that I wanted to ask whether anyone else has already noticed this and maybe found a proper fix. (I couldn't find anything in OE bugzilla, so I can also submit a bug report if necessary.)
Go to the top of the page
 
+Quote Post
Da_Blitz
post Dec 28 2006, 06:23 PM
Post #2





Group: Members
Posts: 1,565
Joined: 7-April 05
From: Sydney, Australia
Member No.: 6,806



if [ $readonly_rootfs = "1" ]

seems to be the offender, check it. the problem may not be that your root FS is RO when you can open a terminal but that it might be RO during boot, which most linux distros do (that way they can do a fsck if need be

working out if its RO during boot at the wrong time might be hard, or you may be right and the detection code needs an overhaul
Go to the top of the page
 
+Quote Post
agraef
post Dec 28 2006, 06:44 PM
Post #3





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



QUOTE(Da_Blitz @ Dec 29 2006, 04:23 AM)
if [ $readonly_rootfs = "1" ]

seems to be the offender, check it. the problem may not be that your root FS is RO when you can open a terminal but that it might be RO during boot, which most linux distros do
*


Yes, that's my analysis as well. But, as this problem only surfaces when booting from SD (rather than flash) there must be some difference in the boot sequence when altboot boots from SD. Maybe that is the real issue?

Of course I could just get rid of the $readonly_rootfs test (that's essentially what I do if I comment out the code which checks for the rootfs, a few lines above), but that's not a foolproof solution. If the rootfs is mounted read-only and no keyfile exists yet (maybe first boot after a fresh installation), there is no other option than to write the newly created keyfile into ram. The situation where the current script goes wrong is when the rootfs is r/o (during boot), but a keyfile already exists in /etc/dropbear. Then that file should be used, but the current script errorneously chooses to create a new keyfile under /var/lib. You can clearly see that in the few lines of the script I quoted above.

Oh well, I guess I'll just post a fixed script here tomorrow and leave it up to the OE guys to decide what to do about this... smile.gif
Go to the top of the page
 
+Quote Post
agraef
post Dec 29 2006, 04:32 AM
Post #4





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



Ok, I figured this one out. In fact the rootfs *is* mounted rw when the dropbear init script runs, but I found that after booting from SD with altboot, / is actually mounted *thrice*. Here are the relevant lines from the output of "cat /proc/mounts":

CODE
rootfs / rootfs rw 0 0
/dev/mmcblk0p1 / ext2 rw,nogrpid 0 0
/dev/mtdblock2 / jffs2 ro,noatime 0 0


Is that normal?? Anyway, if you take a look at the awk command which parses that output in the init.d/dropbear script:

CODE
awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }' </proc/mounts


you'll notice that it collects the options from the *last* "/" mount it finds, which is wrong. The solution is to munge the awk command so that it picks up the *first* mount instead:

CODE
awk '{ if ($2 == "/") { split($4,FLAGS,","); for (f in FLAGS) print FLAGS[f]; nextfile } }' </proc/mounts


Works now. smile.gif Patch to the init.d/dropbear script attached. Let me know whether it's useful to file a bug report on that; I'm still not sure whether it's not actually an altboot bug that "/" appears thrice in the mount table.

EDIT: Hmm, attachments still don't work? So here's the patch as a code section:

CODE
--- dropbear.orig    2006-12-28 13:10:55.000000000 +0000
+++ dropbear    2006-12-29 12:11:33.000000000 +0000
@@ -20,7 +20,7 @@
test ! -h /var/service/dropbear || exit 0

readonly_rootfs=0
-for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }' </proc/mounts`; do
+for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,","); for (f in FLAGS) print FLAGS[f]; nextfile } }' </proc/mounts`; do
  case $flag in
   ro)
     readonly_rootfs=1
Go to the top of the page
 
+Quote Post
koen
post Dec 29 2006, 04:35 AM
Post #5





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



QUOTE(agraef @ Dec 29 2006, 12:32 PM)
I'm still not sure whether it's not actually an altboot bug that "/" appears thrice in the mount table.
*


Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.
Go to the top of the page
 
+Quote Post
agraef
post Dec 29 2006, 05:31 AM
Post #6





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



QUOTE(koen @ Dec 29 2006, 02:35 PM)
Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.
*


Why oh why? Maybe I'm just talking to myself here because I'm not sure yet what the bug actually is, so that I can file a decent bug report? So that someone who knows this system better than me (like you for instance) can say "Scratch that, the script is ok, it's a bug in altboot, file a report under that title instead". Also, like it or not, this is not just some random forum here, it gets visited by many Z users and developers alike, so it's a good place for such discussions IMHO.

I know that at times as a developer who has so many things to do, it's not easy to stay calm and well-tempered when users make silly remarks or ask silly questions. But remember that some of us "lusers" may also be experienced developers, albeit in other areas of expertise.

Ok, with that off my chest, I'll file a bug report now. smile.gif If anyone else has an idea whether this is really an issue with init.d/dropbear or whether there's actually a problem with altboot, please let me know.

Cheers,
Albert
Go to the top of the page
 
+Quote Post
koen
post Dec 29 2006, 05:41 AM
Post #7





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



QUOTE(agraef @ Dec 29 2006, 01:31 PM)
QUOTE(koen @ Dec 29 2006, 02:35 PM)
Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.
*


Why oh why? Maybe I'm just talking to myself here because I'm not sure yet what the bug actually is, so that I can file a decent bug report? So that someone who knows this system better than me (like you for instance) can say "Scratch that, the script is ok, it's a bug in altboot, file a report under that title instead". Also, like it or not, this is not just some random forum here, it gets visited by many Z users and developers alike, so it's a good place for such discussions IMHO.
*



But not visited by 95% of the OE developers, so this forum is not a good place for such discussions.
Go to the top of the page
 
+Quote Post
agraef
post Dec 29 2006, 06:11 AM
Post #8





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



QUOTE(koen @ Dec 29 2006, 03:41 PM)
But not visited by 95% of the OE developers, so this forum is not a good place for such discussions.
*


I can't verify this number, it might be true. But you post regularly here, Mickey, Hrw, CoreDump, ... I'd say that's already a sizable fraction of the OE/OZ core developers. wink.gif
Go to the top of the page
 
+Quote Post
agraef
post Dec 29 2006, 06:36 AM
Post #9





Group: Members
Posts: 54
Joined: 28-August 05
Member No.: 7,962



Ok, I've reported this issue in the OE bugtracker (#1723).
Go to the top of the page
 
+Quote Post
Hrw
post Dec 29 2006, 09:33 AM
Post #10





Group: Members
Posts: 1,376
Joined: 11-January 04
From: Poznań, Poland
Member No.: 1,413



QUOTE(agraef @ Dec 29 2006, 04:11 PM)
I can't verify this number, it might be true. But you post regularly here, Mickey, Hrw, CoreDump, ... I'd say that's already a sizable fraction of the OE/OZ core developers.  wink.gif
*


I tend to ignore forum bugreports as many times they are written like 'it does not work' or 'it works when I edit file' but came without solutions.

In OE we have bugdays when we work on fixing bugs instead of adding new stuff.

So if someone want to get some fixed he need to report it. Forum posts, Mailing list posts, private posts are not correct way. You can write about bug in forum but devels will rather do not follow this way.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd October 2014 - 01:40 AM