Building the custom firmware

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. :)

Quote:

---

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. :)

---

and what about 'http' printing? don't know how it works, but my Laserjet2200DTN uses it

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.

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.

---

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.

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

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.

---

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.

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.

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...

---

Antiloop, were can I find these tools?

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:

Code:

---

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

---

and trx of

Quote:

---

-rw-r--r-- 1 leon staff 3465216 2006-03-09 10:20 mipsel-uclibc/WL500gx-1.9.2.7-7c.trx

---

When I compare this to original distribution which have:

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

---

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?

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?