Guys, have you read my other posts? There is already dropbear ssh daemon & the necessary packing scripts. :)
Printable View
Guys, have you read my other posts? There is already dropbear ssh daemon & the necessary packing scripts. :)
Just as a quick question, why didn't you use 0.41 version of Dropbear ?Quote:
Originally posted by Oleg
Guys, have you read my other posts? There is already dropbear ssh daemon & the necessary packing scripts. :)
Thanks for the heads up on the ssh addition. As to the packing scripts, your original will only unpack the factory firmware, I wanted to be able to unpack yours and modify it without rebuilding busybox, etc., which is why I wrote one that uses the TRX header instead of dd and "magic" numbers. The packing stuff was for my convenience, so I threw it in. There are some changes I want to make for myself - writing the tools helps me to understand the environment rather than just following a cookbook approach.Quote:
Originally posted by Oleg
Guys, have you read my other posts? There is already dropbear ssh daemon & the necessary packing scripts. :)
Working on these mass-produced routers is a great way to brush up on embedded programming skills, which is one reason for my interest in the Asus and Linksys units. It occurs to me that the Asus, with its parallel port, would be a great controller unit for any number of applications.
I haven't looked at your latest with SSH yet (I'm at work...). In your post you mention compiling busybox with uclibc. How much space did that free up? Did you recompile both busybox binaries? Allso, do you have any idea why Asus used 2 different busybox binaries?
Thanks for your help.
:) Ok, I've downloaded dropbear-0.39 some time ago. And I've not rechecked the dropbear site until today. Anyway, I think the firmware could be safely rebuild with 0.41.Quote:
Originally posted by zomk3
Just as a quick question, why didn't you use 0.41 version of Dropbear ?
Ok, your unpack tool could be usefull. :) As for pack - have not seen this yet. If you've used my Makefile stuff, please retain the GPL license and mention the original copyright. :) Also there is a good idea to make the GPLed version of trx tool.
I'm also has something like this - the untrx tool, to break the trx on to the parts and simple script which call untrx & uncramfs (available on the internet, and also patched just because of the stupid error). Ok, I've never release this to public.
As for busyboxes - starting with my 1.6.5.3-2 firmwares there is only one busybox binary. The only reason why ASUS have included two binaries was as seems the fact that second busybox was used for insmod only. They probably has the problems with insmod (and everybody have it with stock busybox), which is segfaults on the brcm modules. If you review my patch you will notice the required patch for insmod. May be Asus guys was lazy enough to recompile busybox or whatever.
As for libc/uclibc stuff. I've tried to compiling dropbear and busybox against the glibc dynamically to reduce the size of the resultant firmware, added needed resolver libraries, but it was 8k larger than the maximim allowed size. So, I decided not to use glibc resolver and parts that depends on it. I've relinked the glibc without the busyboxes and I've freed up around 250 k in the original firmware and this was large enough to include uclibc (relinked also).
Regards, Oleg.
Oleg, since with your newest firmware some binaries are linked to libc and others are linked to ulibc, does this mean you give up RAM (because both shared libs are loaded) to save flash memory?
(That's not a criticism, I'm just trying to understand the tradeoffs.)
Also, do you know whether any of the code on the flash memory "executes in place", or is it all loaded into RAM? My guess is that the kernel on MTD1 is "execute in place" but that user-space programs, being CRAMFS on MTD2, have to run in RAM.
Finally, do you think it's possible to use USB flash disk as swap space?
Thanks.
Don't worry about that: Linux kernel smart enough to not copy r/o pages, but I don't know how it's exactly working with cramfs compressed images, hopefully they're also just pinned to the buffer cache, and freed than more memory needed. As for kernel itself - it's opposite. The kernel (except the init parts) consumes RAM and can't be swapped or ran from flash or whatever. The same applies to kernel modules.
As for USB swap - I think this is possible, but I've not tried this yet. Either way you need to recompile usb stuff - ASUS uses 2.4.5 modules with 2.4.20 kernel. And this is unacceptable...
Guys, in my opinion the only thing which stops the "real" custom firmware is the lpr stuff. I've tried to recompile the lprng (Asus uses it as seems) with minimal options, but it's still too big.
Volunteers needed to dig onto lpr printing. :)
and what about 'http' printing? don't know how it works, but my Laserjet2200DTN uses itQuote:
Originally posted by Oleg
Don't worry about that: Linux kernel smart enough to not copy r/o pages, but I don't know how it's exactly working with cramfs compressed images, hopefully they're also just pinned to the buffer cache, and freed than more memory needed. As for kernel itself - it's opposite. The kernel (except the init parts) consumes RAM and can't be swapped or ran from flash or whatever. The same applies to kernel modules.
As for USB swap - I think this is possible, but I've not tried this yet. Either way you need to recompile usb stuff - ASUS uses 2.4.5 modules with 2.4.20 kernel. And this is unacceptable...
Guys, in my opinion the only thing which stops the "real" custom firmware is the lpr stuff. I've tried to recompile the lprng (Asus uses it as seems) with minimal options, but it's still too big.
Volunteers needed to dig onto lpr printing. :)
i only have to enter http://192.168.0.100 as http printer and install the driver at my XP machines and it works.
if this is standard possible in linux, than it's maybe better than LPR
Oleg,
I have compiled dropbear and am running it as a daemon from the USB drive. However, I can't scp files to or from the Asus. Does scp work with your firmware? Is there a path issue, perhaps - my dropbear and scp are in /mnt/usbfs/bin, your scp is on /usr/bin (I think).
Any help appreciated.
PS When I scp to/from the Asus I either get "no such file or directory" or "lost connection".
Thanks again.
I got a similar problem when i tried scp. It looked for an "ssh" binary in /usr/bin but there is none. So i will try to redo olegs 1.6.5.3-3 with a symlink for this, and post the results. But as i am out of office i can do that earliest this weekend.Quote:
Originally posted by RCR
Oleg,
I have compiled dropbear and am running it as a daemon from the USB drive. However, I can't scp files to or from the Asus. Does scp work with your firmware? Is there a path issue, perhaps - my dropbear and scp are in /mnt/usbfs/bin, your scp is on /usr/bin (I think).
Any help appreciated.
PS When I scp to/from the Asus I either get "no such file or directory" or "lost connection".
Thanks again.
Guys, scp works in one direction only, the initiator should be pc. You can't execute scp on the router, because there is no ssh. So, scp works in client mode only. Also dropbear has scp path hardcoded - /usr/bin/scp.
So, you can perform the following from your PCs:
pc-box# scp some_file admin@my.router:/tmp
pc-box# scp admin@my.router:/tmp/bootCmd.log .
But you can't do this from the router because it's relies on ssh
# scp pc-box:/tmp/some_file /tmp
# scp /tmp/bootCmd.log pc-box:/tmp/some_file /tmp
I don't think this is correct. I think the client (on the PC, not router) tells the server (dropbear on the route) what commad to execute. If you run your client with debug, you'll see the scp command sent, but without a full path (something like "scp -v -t filename"). I can find no hardcoded path (grep for "scp") in the dropbear sources. When you log in to the router via ssh, /bin is in your shell's path. Likewise, I asssume when the client logs in and tries to run scp.Quote:
Originally posted by Oleg
Guys, scp works in one direction only, the initiator should be pc. You can't execute scp on the router, because there is no ssh. So, scp works in client mode only. Also dropbear has scp path hardcoded - /usr/bin/scp.
You can see this by doing this on the client (PC) side:
ssh admin@192.168.1.1 type scp
Compre to:
ssh admin@192.168.1.1 type sh
The first will say "file not found" (the same error when scp fails for me), the second says "sh is /usr/bin/ssh".
So...
Since my scheme is to not put scp in the firmware but rather to keep it in the USB flash drive, how can I setup the default path? I assume this is a busybox thing - I need the equivalent of ".bashrc" or ".login".
Any ideas?
Client in my post is not whom runs scp interactively, but whom is running scp with -t switch. And this dropbear daemon, which is run on router. The scp works as follows: when you type scp on the host, scp itself establishes the connection to the remote host and execute "scp -t" remotely, which is just mimics the rcp protocol.
Yes, scp path is not hardcoded - this is was my mistake in the previous post, but ssh path is hardcoded inside the scp. Either way, in my firmware scp is on the PATH and it works ok.
As for your particular setup - yes, it can't find scp, you need to add it to PATH. THe simplest way to do this - is to use the /etc/profile, as I wrote before.
Also note that, if you want to use an alternate shell (not /bin/sh), for example "/mnt/ramfs/bin/ash", in the shell field of the /etc/passwd file, you have to add that shell to /etc/shells, which will then look like this:
/bin/sh
/etc/sh
Otherwise dropbear will refuse to let you log in.
Oleg - do you know if port forwarding work with dropbear?
Have not checked this yet, but staring with dropbear-0.41 everything should work fine.
Antiloop, were can I find these tools?Quote:
Originally posted by RCR
Based on Oleg's work, I've written some tools to help unpack and repack the trx files. These will work with any trx file, even the modified ones since they unpack based on info found in the trx header. This makes it easy to, for example, unpack Oleg's custom firmware, add or modify something, and repack it without having to apply his patches to the original firmware.
If anyone is interested, I can provide them to Antiloop so that others can download them.
Now to fiddle with the firewall and add an SSH deamon...
i'm interested in such tools too if available...i need to extract the ov51x and videodev modules from Oleg's firmware
Thank you
What are the hard limits for firmware on WL-500gx? With hard limits I mean filesystem size and trx size?
I have enabled wide character support in wl500g-1.9.2.7-7c.tar.bz2 uClibc config file and got the system following sizes:and trx ofCode:Little endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments
Filesystem size 2694.88 Kbytes (2.63 Mbytes)
22.94% of uncompressed filesystem size (11746.99 Kbytes)
Inode table size 2922 bytes (2.85 Kbytes)
26.35% of uncompressed inode table size (11089 bytes)
Directory table size 3710 bytes (3.62 Kbytes)
49.59% of uncompressed directory table size (7481 bytes)
Number of duplicate files found 3
Number of inodes 498
Number of files 293
Number of fragments 41
Number of symbolic links 158
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 47
Number of uids 1
root (0)
Number of gids 0
When I compare this to original distribution which have:Quote:
-rw-r--r-- 1 leon staff 3465216 2006-03-09 10:20 mipsel-uclibc/WL500gx-1.9.2.7-7c.trx
This means that wchar support brings me as little as 4kB of additional flash/filesystem size! Is it OK to try flashing this firmware with wchar enabled?Code:Filesystem size 2690.57 Kbytes (2.63 Mbytes)
22.95% of uncompressed filesystem size (11721.74 Kbytes)
Inode table size 2928 bytes (2.86 Kbytes)
26.41% of uncompressed inode table size (11085 bytes)
Directory table size 3706 bytes (3.62 Kbytes)
49.54% of uncompressed directory table size (7481 bytes)
Number of duplicate files found 3
Number of inodes 498
Number of files 293
Number of fragments 41
Number of symbolic links 158
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 47
Number of uids 1
root (0)
Number of gids 0
-rw-r--r-- 1 leon staff 3461120 2006-03-09 10:49 mipsel-uclibc/WL500gx-1.9.2.7-7c.trx
I have succesfuly tested wchar support and I hope that this little change will be included in the upcoming Oleg releases. Any way i am releasing it as is together with source code and prebuilt firmwares at ->>> custom/wl500g-1.9.2.7-7cw/
Note that this release is marked as cw sufix meaning wchar (Unicode support) in uClibc.
This little change could enable many non working packages from Optware to start building! (unrar, glib, giFTcurs, swi-prolog, gambit-c, ... to many to mention)
Oleo, is samba included in this firmware?
Yes. This is Oleg firmware with wchar enabled.