Bekijk de volledige versie : Building the custom firmware
Info on how I've build the firmware.
First read the http://www.seattlewireless.net/index.cgi/LinksysWrt54g it contains the info about one of the Broadcom based Linksys router. Most of the things applies to wl-500g. But wl-500g is the best one. :)
For building the firmware you will need the linux box. I'm using RH8 for the purpose. Second, you will need the tools availbale from the linksys site. See the seattlewireless for the details. I've used WRT54G 1.42.3 supplies sources.
I've sent the 1.6.5.4.tar.gz file to the forum@chupa.nl. Hope Antiloop will post it.
The first thing you will need to do is to install broadcom tools. The next one is to extract files from the Asus 1.6.5.3 firmware. The simplest way for this is using the extract script I've supplied:
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.vmlinuz skip=28 ibs=1 count=705256
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.cramfs skip=705284 ibs=1
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.trailer skip=3769092 ibs=1
This will produce 3 files, containing compressed linux kenel, rootfs & asus firmware trailer.
The next thing you will need to to is to extract rootfs from the 1.6.5.3.cramfs file. You may want tou use uncramfs available on the net, or just mount this file using something like this
mount -o loop 1.6.5.3.cramfs /mnt/cramfs
and then just copy the files to the build dir.
The next thing is customizing the firmware. I've examined it and found 2 busybox executables - /bin/busybox & /sbin/busybox. The second are just used by insmod, so I've decided to alter it. I've used used busybox-1.0pre5 (www.busybox.net) for the purpose, but have patched, to make insmod & passwd --stdin working (the patch named 1.6.5.3-busybox.diff, it's also contains the config I've used). You will need to make the busybox, and install it over the extracted rootfs using
make PREFIX=/path/to/roofs install
The next thing to do is the altering of the init scripts of the wl500g. The patch is named 1.6.5.3-patch.diff.
Finally you will need to pack the firmware using the trx tool from broadcom. I've supplied the pack script for the purpose:
mkcramfs cramfs pack.cramfs
cat pack.cramfs 1.6.5.3.trailer > pack-trailer.cramfs
./trx -o pack.trx 1.6.5.3.vmlinuz pack-trailer.cramfs
At this point you've got the pack.trx file which can be uploaded to wl500g. For other details see http://wl500g.info/showthread.php?s=&threadid=65
Regards,
Oleg.
Oleg, would it be hard for you to make an update for WL-500b as well please? Unfortunately I don't have any Linux box at the moment so I can't make it myself. I think it could be interesting for some other WL-500b users too. Anyway, thanks a lot for this detailed HOW-TO - very nice work! :)
Ok, I've done it and sent to Antiloop. But it's untested.
The firmwares are looks identical. All binaries except the upnp are the same, the only difference is g to b change and the nvram settings. So, probably it's possible to load the wl500g firmware to the wl500b using the Firmware restoration tool. All except g band should work. :)
Regards,
Oleg.
I thought there should not be a big difference between B and G version but I did not compare files.
What I would like to manage in future (as soon as I install and configure a Linux box) is the OV-511 webcam driver update. Although the WL-500b web configurator is indicating the OV-511 driver version is 2.10, it seems there's just 1.61 driver version in fact. I hope the webcam driver update could help to get my Creative Labs WebCam III camera working properly in security monitor mode. I think I could use the drivers from this site: http://alpha.dyndns.org/ov511/download.html
I think everything is possible. :) You will need the kernel sources to build the modules - use the ones from linksys site (WRT54 kernel looks ok, btw it contains number of things related to Linksys hardware, while the WAP54 & WRT55 are more like Broadcom reference design). BTW I've successufully compiled number of modules for the existing kernel using the WRT54 1.42.3 sources.
Antiloop
30-12-2003, 22:38
Originally posted by Technik
Oleg, would it be hard for you to make an update for WL-500b as well please? Unfortunately I don't have any Linux box at the moment so I can't make it myself. I think it could be interesting for some other WL-500b users too. Anyway, thanks a lot for this detailed HOW-TO - very nice work! :)
here you go: http://files.wl500g.info/asus/wl500b/firmware/customized/wg01060503_WL500b_en_patch1.trx
Antiloop
30-12-2003, 22:39
the patch file from Oleg:
http://files.wl500g.info/asus/wl500g/firmware/patched/1.6.5.3.patch.tgz
Thanks a lot, Antiloop, I got it. :)
Happy New Year to everybody! ;)
Oleg, I successfully updated my WL-500b with your patched firmware. The router seems to be working fine but the telnetd does not start automatically. When I run it manually, the daemon is running then but Telnet logon is not possible still - the reason seems to be that passwd and group files are not initialized during the router boot. I did not test to create some BootCmd record yet. Could you please tell me what should I check and what to do to make the telnetd working properly? :confused:
Originally posted by Oleg
Info on how I've build the firmware.
First read the http://www.seattlewireless.net/index.cgi/LinksysWrt54g it contains the info about one of the Broadcom based Linksys router. Most of the things applies to wl-500g. But wl-500g is the best one. :)
For building the firmware you will need the linux box. I'm using RH8 for the purpose. Second, you will need the tools availbale from the linksys site. See the seattlewireless for the details. I've used WRT54G 1.42.3 supplies sources.
I've sent the 1.6.5.4.tar.gz file to the forum@chupa.nl. Hope Antiloop will post it.
The first thing you will need to do is to install broadcom tools. The next one is to extract files from the Asus 1.6.5.3 firmware. The simplest way for this is using the extract script I've supplied:
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.vmlinuz skip=28 ibs=1 count=705256
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.cramfs skip=705284 ibs=1
dd if=wg01060503_WL500g_en.trx of=1.6.5.3.trailer skip=3769092 ibs=1
This will produce 3 files, containing compressed linux kenel, rootfs & asus firmware trailer.
The next thing you will need to to is to extract rootfs from the 1.6.5.3.cramfs file. You may want tou use uncramfs available on the net, or just mount this file using something like this
mount -o loop 1.6.5.3.cramfs /mnt/cramfs
and then just copy the files to the build dir.
The next thing is customizing the firmware. I've examined it and found 2 busybox executables - /bin/busybox & /sbin/busybox. The second are just used by insmod, so I've decided to alter it. I've used used busybox-1.0pre5 (www.busybox.net) for the purpose, but have patched, to make insmod & passwd --stdin working (the patch named 1.6.5.3-busybox.diff, it's also contains the config I've used). You will need to make the busybox, and install it over the extracted rootfs using
make PREFIX=/path/to/roofs install
The next thing to do is the altering of the init scripts of the wl500g. The patch is named 1.6.5.3-patch.diff.
Finally you will need to pack the firmware using the trx tool from broadcom. I've supplied the pack script for the purpose:
mkcramfs cramfs pack.cramfs
cat pack.cramfs 1.6.5.3.trailer > pack-trailer.cramfs
./trx -o pack.trx 1.6.5.3.vmlinuz pack-trailer.cramfs
At this point you've got the pack.trx file which can be uploaded to wl500g. For other details see http://wl500g.info/showthread.php?s=&threadid=65
Regards,
Oleg.
Hi,
i examined the kernel config of the linksys sources and discovered, that the don't enable the usb support by default. Also the prt port ist not enabled.
Did you create you own kernel config ? If yes, can you post it here ?
Rgds
Michael
Originally posted by Technik
Oleg, I successfully updated my WL-500b with your patched firmware. The router seems to be working fine but the telnetd does not start automatically. When I run it manually, the daemon is running then but Telnet logon is not possible still - the reason seems to be that passwd and group files are not initialized during the router boot. I did not test to create some BootCmd record yet. Could you please tell me what should I check and what to do to make the telnetd working properly? :confused:
Ok, I've figured out the problem with wl500b firmware - I've not set the x bit on the rc.nvram & rc.telnetd scripts. I will do this and resend the firmware to Antiloop. Sorry for that.
Originally posted by zomk3
Hi,
i examined the kernel config of the linksys sources and discovered, that the don't enable the usb support by default. Also the prt port ist not enabled.
Did you create you own kernel config ? If yes, can you post it here ?
Rgds
Michael
Michael, I've not rebuild kernel, I've used the kernel & the modules supplied by ASUS. WRT54G kernel & modules can't be used directly - they have different ethernet interfaces, led drivers and possibly more. The closest kernel should be from the wap54 & wrt55. Asus also has the modules, which we can't recompile using the Linksys sources - the things related to parallel port (parport_splink), splink_led (it's pretty simple). And the main problem is the debugging of the newely build kernel.
BTW, I'm was able to build some modules to use with existing kernel using the wrt54g config (I've added the ext2, loop, nfs and the friends). I'm was able to mount nfs share.
Originally posted by Oleg
Ok, I've figured out the problem with wl500b firmware - I've not set the x bit on the rc.nvram & rc.telnetd scripts. I will do this and resend the firmware to Antiloop. Sorry for that.
No problem, Oleg, thanks a lot for the update in advance! :)
ok, have posted the updated firmware to Antiloop. The file with this new firmware for wl500b is 3796992 bytes in size (4096 bytes larger than the previous).
Antiloop
07-01-2004, 00:11
http://files.wl500g.info/asus/wl500b/firmware/customized/wg01060503_WL500b_en_patch1a.trx
uploaded now
Oleg, could you please explain how have you found those magic numbers that you use as arguments for 'dd'?
When I do a
hexdump -C wg01060503_WL500g_en.trx | grep Compressed
I get
000ac310 00 00 00 00 43 6f 6d 70 72 65 73 73 65 64 20 52 |....Compressed R|
000ac330 3e af a7 ef 43 6f 6d 70 72 65 73 73 65 64 00 00 |>¯§īCompressed..|
But AC310 is 705296, so where does your 705256 comes from?
And how did you found the length of the header (28) and trailer (3324)?
And to build busybox did you have to set up a cross-compiler?
Congratulations for your work.
Oleg, Antiloop, thanks a lot for the WL-500b patch update! Now it works fine. :)
Antiloop
08-01-2004, 09:25
Originally posted by Technik
Oleg, Antiloop, thanks a lot for the WL-500b patch update! Now it works fine. :)
all credits should go to Oleg, not me
Originally posted by joao
Oleg, could you please explain how have you found those magic numbers that you use as arguments for 'dd'?
When I do a
hexdump -C wg01060503_WL500g_en.trx | grep Compressed
I get
000ac310 00 00 00 00 43 6f 6d 70 72 65 73 73 65 64 20 52 |....Compressed R|
000ac330 3e af a7 ef 43 6f 6d 70 72 65 73 73 65 64 00 00 |>¯§īCompressed..|
But AC310 is 705296, so where does your 705256 comes from?
And how did you found the length of the header (28) and trailer (3324)?
And to build busybox did you have to set up a cross-compiler?
Congratulations for your work.
Yes, you will need to setup the crosscompiler. The simplest way to get it - is just to download the wrt54g sources from the linksys site.
Regarding the starting offsets - they are all encoded in the trx header (it's 28 bytes in size as you mention), and defined as follows (btw, old trx header have offsets set to zero, so the right offsets was 0x1c & 0xc0000):
typedef struct {
uint32 magic; /* "HDR0" */
uint32 len; /* Length of file including header */
uint32 crc32; /* 32-bit CRC from flag_version to end of file */
uint32 flag_version; /* 0:15 flags, 16:31 version */
uint32 offsets[3]; /* Offsets of partitions from start of header */
} TRXHDR, *PTRXHDR;
705256 - is the real offset to cramfs image, 0xac310 just an offset inside the cramfs header (consult linux kernel sources) for detail.
As for trailer length - it's just a guess. To find it I've packed the rootfs using the mkcramfs and when found the difference (possibly trailer length depends on the size of kernel, to align the entire trx size to 4k boundary, cause the cramfs 4k aligned by it's self). Also, please note - old asus firmwares has 64 bytes trailer...
Originally posted by Antiloop
all credits should go to Oleg, not me
I know but you posted a link to updated file. ;)
BTW I think Oleg could take a control of WL-500b/g updates over ASUS yet! :)
Originally posted by Oleg
Michael, I've not rebuild kernel, I've used the kernel & the modules supplied by ASUS. WRT54G kernel & modules can't be used directly - they have different ethernet interfaces, led drivers and possibly more. The closest kernel should be from the wap54 & wrt55. Asus also has the modules, which we can't recompile using the Linksys sources - the things related to parallel port (parport_splink), splink_led (it's pretty simple). And the main problem is the debugging of the newely build kernel.
BTW, I'm was able to build some modules to use with existing kernel using the wrt54g config (I've added the ext2, loop, nfs and the friends). I'm was able to mount nfs share.
I just looked in some of the kernel sources and some kernel boot outputs of the Linksys and the Asus Router.
The usb port is supported by the linksys modified kernel and they use the usb-ohci module for it..
The Ethernet ports are part of the broadcom chip, so they are also supported by the linksys sources.
Also broadcom only provides the binary kernel modules which should be ok. We can use those binary modules also in custom firmwares.
What is different is that Asus uses a other switch chip than linksys but this doesn't care, its outside of the linux stuff.
The Prt port is an Attansic at7601F, which they claim as IBM PC Compatible Printer Port (see http://www.attansic.com.tw/english/products/pdf/at7601f.pdf ).
So it should run with the standard parport module.
One of the things we need to find out to be able to compile the kernel correct is what modules are enabled in the ASUS kernel, Antiloop has posted this already. There we will get the messages which drivers were loaded. I will take a more detailed look myself, but my delivered WL500 was broken and i had to send it back.
I hope my replacement will be delivered soon.
As i said already Antiloop has posted the dmesg of the asus router in the openwrt thread, so we can see the the most of the modules the router uses.
What do you guys think of setting up a own Project on sourceforge ? We could use the provided cvs for storage of files and having a bugtracking aso. ?
We could also join Kaloz project in adopting the openwrt to the WL500.
I agree with you regarding the debug problem. But how do you debug a broken linux kernel on your pc ? Are you a real kernel hacker, i must admit that i can not do this. I can just try the things i compiled in and use them. If an error occures i just can upload a old working kernel.
Antiloop
09-01-2004, 11:02
Originally posted by zomk3
What do you guys think of setting up a own Project on sourceforge ? We could use the provided cvs for storage of files and having a bugtracking aso. ?
We could also join Kaloz project in adopting the openwrt to the WL500.
I agree with you regarding the debug problem. But how do you debug a broken linux kernel on your pc ? Are you a real kernel hacker, i must admit that i can not do this. I can just try the things i compiled in and use them. If an error occures i just can upload a old working kernel.
if in need of space chupa.nl has enough for now,
if you want to share bigger files send them through email to forum@chupa.nl, and i'll upload them at the site
i'm planning to create a upload page soon, so it can be uploaded to the site directly.
Originally posted by Antiloop
if in need of space chupa.nl has enough for now,
if you want to share bigger files send them through email to forum@chupa.nl, and i'll upload them at the site
i'm planning to create a upload page soon, so it can be uploaded to the site directly.
I am not talking of binary files, i was thinking of the sources. cvs is a very usable tool for this. But if you'd like to set up a cvs or similar system ond chupa.nl that would be great. But think of maintenance and all the administrative stuff.
Originally posted by zomk3
The Ethernet ports are part of the broadcom chip, so they are also supported by the linksys sources.
....
So it should run with the standard parport module.
Once again, linksys (cybertan) wrt54g use different approach for the eth interfaces: they're using one physical ethernet port for both lan & wan and then drive two different connectors using the vlan tagging & built it switch chip. wl500g and all other similar things from dell, trendnet, buffalo and linksys wrt55 uses 2 physical enternet ports (this is reference design). BTW, there is not a big deal for compiling the kernel, which properly support ethernet ports (one of the linksys packages has original sources from broadcom with no vlan tagging dano by cybertan). But do you really need this new kernel right now? If you need additional features - compile these as modules.
As for parport - there are two modules loaded - parport & parport_splink, which uses parport. Don't know what parport_splink doing...
This is suffucient to start digging, but do we really need jffs on the flash? It's more resonable to use external USB disk for the purpose, saving the flash... WRT54G does not have usb port, so they decided to make the jffs partion.
As for debuging - I think it's possible to code the loader which will run just from the telnet shell and will boot the new kernel from the usb disk or so. No need to flash the firmware until it's fully debugged.
Just a thought: as an output solution - just use the parallel printer port for the console output :D, and it's also possible to use the parallel port as i/o port right in the windows (just how null modem does).
Since we now have both ftp to upload files and telnet to control the router, why not install a full development environment on the USB disk ?
We have to install gcc and then use the wl-500g to compile its new binaries, and gdb to debug them.
First, it will avoid cross-compilers...
Second, we shall share the same environment.
Another wish will be to install traffic control (tc) or iproute2 on the wl-500g in order to add QoS functionality.
Originally posted by Oleg
As for debuging - I think it's possible to code the loader which will run just from the telnet shell and will boot the new kernel from the usb disk or so. No need to flash the firmware until it's fully debugged.
Just a thought: as an output solution - just use the parallel printer port for the console output :D, and it's also possible to use the parallel port as i/o port right in the windows (just how null modem does).
Just as an idea. Isn't there a diagonistic port on the side of the board ? I think i have seen something like this on the pictures.
But then we would need to open the device and loose the guarantee. A parallel port diagnostic wouldn't be too bad. The usb disk as storage is a very good idea. Independant of the size its easier to replace it after too many writes to the flash.
Originally posted by Ark+
Since we now have both ftp to upload files and telnet to control the router, why not install a full development environment on the USB disk ?
We have to install gcc and then use the wl-500g to compile its new binaries, and gdb to debug them.
First, it will avoid cross-compilers...
Second, we shall share the same environment.
Another wish will be to install traffic control (tc) or iproute2 on the wl-500g in order to add QoS functionality.
Do you think its a good idea to compile something like the kernel on a 125Mhz Box with only 16M RAM?
Regarding the Environment i already mentioned to use something like sourceforge, so everybody can use cvs to share their sources. More important a diff/merge functionality is provided in many clients.
If we use the memory stick to store our extra software on it, we can easily compile it on linux and upload it. Very important is to use the same guidlines (e.g for directories, config files...)
Do you think its a good idea to compile something like the kernel on a 125Mhz Box with only 16M RAM?
Compiling a kernel on the wl-500g might cause overheating :)
And there is also the Broadcom binary modules issue. Aren't they compiled for that specific kernel version (2.4.5)? Is there a way to make them work with a higher kernel version? What do you think Oleg?
Originally posted by joao
And there is also the Broadcom binary modules issue. Aren't they compiled for that specific kernel version (2.4.5)? Is there a way to make them work with a higher kernel version? What do you think Oleg?
Asus firmware uses the 2.4.20 kernel with broadcom modules compiled for 2.4.20. There are also some modules compiled for 2.4.5 by Asus itself - so they are using a mix. :) They are to lazy to recompile everything. As for using with newer kernels - seems any kernel from the 2.4.x (x >= 20) can be used safely (we just need to make a patch from against the stock 2.4.20) and also we can recompile most of the parts (except the wireless stuff, which can be safely taken as is from linksys sources). As for wireless, can't recall exactly, broadcom uses open source compatibilty layer for their drivers (they are layed out as a set of compiled .o files) and links it to the final module.
As for connecting to the diagnostic port - yes it's possible, but there are no info on the port itself. Possibly it's JTAG, but who knows...
i4shop.net
18-01-2004, 18:04
There is an internal connector on the WL-500 board. You
can find a picture on this page.
http://www.i4shop.net/cz/iObchod/WebInfo.asp?idprod=wl500
the image itself:
http://www.i4shop.net/cz/iObchod/Img/WL-500/wl500e.jpg
Originally posted by zomk3
Just as an idea. Isn't there a diagonistic port on the side of the board ?
If I unpack and repack the factory firmware using the instructions on this forum, the new packed file is not identical to the original, even though I didn't modify anything in the build directory. Is this normal, or am I doing something wrong?
Thanks.
Yes, there is a small difference in the cramfs headers. Some of the fields are unique for every pack operation (they are choosen randomly by mkcramfs). Also, be sure you've added ASUS trailer to the cramfs.
Regards,
Oleg.
Thanks, Oleg, I won't be concerned about the small difference in size and content. How did you arrive at the offsets you use in the dd commands in your extract scripts? [Never mind - I see that was answered above.]
Based on your work, I decided to get the WL-500g instead of a Linksys unit, since it looks like I can easily add functions by putting stuff on a USB "drive" and making limited changes to Busybox and/or init scripts, etc. instead of having to rebuild the whole firmware package, as the Linksys hackers have done.
In looking at the scripts, I don't see an inittab, or an /etc/nit.d/rcS file as mentioned in the busybox docs (http://www.busybox.net/downloads/BusyBox.html). Could anyone explain the boot process and how the scripts in /init get run an in what order?
Thanks.
Originally posted by RCR
Thanks, Oleg, I won't be concerned about the small difference in size and content. How did you arrive at the offsets you use in the dd commands in your extract scripts? [Never mind - I see that was answered above.]
Based on your work, I decided to get the WL-500g instead of a Linksys unit, since it looks like I can easily add functions by putting stuff on a USB "drive" and making limited changes to Busybox and/or init scripts, etc. instead of having to rebuild the whole firmware package, as the Linksys hackers have done.
In looking at the scripts, I don't see an inittab, or an /etc/nit.d/rcS file as mentioned in the busybox docs (http://www.busybox.net/downloads/BusyBox.html). Could anyone explain the boot process and how the scripts in /init get run an in what order?
Thanks.
The offsets are coming from the trx header (see the corresponding file in the linksys sources). As for WRT54G - it's seems it's pretty easy to do the hardware "hacking" to add USB support to the WRT54G and other broadcom based devices.
As for Busybox - ASUS has changed the busybox. They're launching the /init/boot
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...
A good job, RCR, thanks. I am sure it will be interesting for some people. Does it run in Windows or under Linux? If the length of zipped file is under 200 KB, perhaps you can attach it here (in HOW TO TALK section). :)
Antiloop
29-02-2004, 13:45
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...
send them! :)
to forum@chupa.nl
tx
I just emailed them. Here's the text of the README file:
This is a set of tools to unpack and repack firmware files for the Asus WL-500g
wireless router. The tools should run on any Linux system. The license for the
programs is at the end of this file.
See the scripts, source, and make file for setup and usage instructions. You
will need to download the Linksys source. For example, get wrt54gv2.2.02.2.tgz
from http://www.linksys.com/support/gpl.asp.
The procedure is as follows:
wlextract old-firmware-file.trx
uncram
[Modify the root file system in the ./build directory.]
mktrx
Afterward, you can use the WL-500g's web interface to upload the new firmware
file ("firmware.trx")
The trx file consists of 2 segments: the kernel and cramfs image with appended
Asus trailer.
The uncram program uses the sudo command to allow non-root users to mount the
cramfs file system.
The root file system directory ("build") will be owned by root. Modified and
additional files should be owned by root and be in the root group.
After loading modified firmware with router's upgrade web page (wait for
transfer to complete), connections may not be allowed. Power off and on the
router to recover.
If you load bad firmware (power LED blinking, unable to connect) power off,
hold down reset button, and turn power back on. Then use the Asus
"Firmware Restoration" tool to reload good firmware.
Thanks to Oleg at the www.chupa.nl forums for discovering the structure of the
firmware files and documenting them on the forums. Thanks too to the Antiloop
at www.chupa.nl for providing the forums for exchange of WL-500g technical
info.
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 am currently examining some of the custom firmwares for the linksys router. Especially regarding the Dropbear ssh deamon.
I think till end of this week i can proviade a modified firmware based on olegs with dropbear.
Guys, have you read my other posts? There is already dropbear ssh daemon & the necessary packing scripts. :)
Originally posted by Oleg
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 ?
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.
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.
Originally posted by zomk3
Just as a quick question, why didn't you use 0.41 version of Dropbear ?
:) 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.
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. :)
Antiloop
03-03-2004, 19:08
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.
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
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.
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?
KillerOPS
18-05-2005, 15:08
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:
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
-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:
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/ (http://www.wlan-sat.com/potrebni_material/wlan_firmare/Asus/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)
alien433
23-03-2006, 11:58
Oleo, is samba included in this firmware?
Yes. This is Oleg firmware with wchar enabled.