home 
wiki
wiki
MinitarHacking
- Code Organization
- ROM size and building the image
- Embedded ramdisk
- Bootloader
- Memory map
- Building the embedded ramdisk
- Console login
- Flash Variables
- Builtin tftp
- What is on this box?
- Things that are prebuilt
- Web pages
- What to add to this unit?
- Software Modifications
Code Organization
The source code released seems to be either "cleaned" or it is from an early stage in the development of the device. I suspect it has been cleaned, there are some obvious things that should be there such as Makefiles in the Linux and AP directories as well as some packages and files that you would expect to be there to make a working image.
The release has three parts:
- AP - application code running on the AP
- LINUX - kernal code
- boot - seperate archive containing the boot loader
As well as the code there is the build environment. This is a third archive that has instructions to load it into /usr/local ( yeah right - not this little black duck).
Looking through the build stuff it seems a bit of a mess. They have zipped up the entire /usr/local from the build machine. Some interesting things in there - looks like the thought about using eCos at some stage as there is a directory fo it there. eCos is an Redhat offering for embedded systems.
ROM size and building the image
So, initally I though there was a limit on the image being 1MB when compressed (well a little smaller, 1MB less the 0x0000-0x10000 (64 KB) that is reserved for the boot code). I found when making an image that some of the files were zero size, turns out that the embedded filesystem that is built in the AP code tree needs to be big enough to fit it all in.
The ROM image is a bit under 1MB when packed for flashing. As the Flash on my unit is 2MB, it is probably safe to make a biger image and load it on. I suspect that the initial units had a 1Mbyte flash and so they are trying to keep the image within that size.
Need to build a test for the size of the image to make sure we allocate enough blocks
Embedded ramdisk
The kernel has an embedded ramdisk that contains all the application code. When the kernel is built the ramdisk is packed into the kernel and is uncompressed and copied to ram as the kernel loads.
Usually a ramdisk like this is used for getting the system up and initializing the disk subsystem etc. Once the normal filesystem is loaded then the root is mounted at the appropriate place. In this case, this is the only file system that is created and loaded.
The script that builds it and loads in the applications (mkimg) calls appimg with an option -b that is labeled block-size, it is -b number of blocks to make the image filesystem. appimg seems to be some sort of munged binary that calls mk2fs then runs through the app_script loading the files into the newly created and mounted filesystem (mounted over /mnt). After the filesystem is created t is unmounted and zipped
You can change the size of the ramdisk by changing the number of blocks. There is an upper limit of 4000 Blocks due to mkimg using the ramfs device to make the filesystem. a better way is to use the loopback device and you are not limited to this size.
If you are building a ramdisk make sure you mount it and check it is not full before trying to use it as the mkimg binary won't complain if the device is full, you end up with a lot of zero length files.
Bootloader
The bootloader (well if they are really using the one made from the source) is in the btcode directory. The boot code is built first in the boot dir than a file boot.img is dumped into the btcode directory. running make in btcode finishes building the bootloader.
The assembly code in Start.S is the first thing executed. Does a bit of houskeeping then copies the boot code to RAM
after that it jumps to the boot code
la k0, 0x80000000 --> set the address to jump to
jr k0 --> jump to the start of the boot code
nopThe boot image is tftp'd to the device and left in RAM, then you use the FLW command to write it to ROM. FLW <dst> <src> <size> the dst is 000000 the src will be 80500000 and the size what is reported by the tftp
Notice the unusual copy semantics here
The <dst> is the offset from the base of the ROM, not an absolute address.
Memory map
ROM base is at 0x2bf0000 (or is it 0x00ff0000)
Found 1 x 2M Byte MXIC MX29LV160AB at 0xbe000000
There is 2MB ROM 0x000000 -> 0x200000
+-----------------------------+ | 2| 0| 0| 0| 0| 0| Digit counting for hex challenged |0000|0000|0000|0000|0000|0000| | |1M |64K |4K |256 |16 | +-----------------------------+
in the boot loader code there is some mention of partitions in the rom - This is in the first 64K of space 0x00000 to 0x010000.
ROM is partitioned into 4 chunks:
from for 0x000000 -> 0x004000 ( 16K ) 0x004000 -> 0x002000 ( 8K ) + 8K unalloc 0x008000 -> 0x008000 ( 32K ) 0x010000 -> 0x010000 ( 64K )
This partition map ( as documented in the source) is wrong. The bootloader is a little under 24 KB and is followed by the HS (Hardware Settings), DS (Default Settings), CS (Current Settings) to make up the first 64KB.
It's something like this:
from for 0x000000 -> 0x006000 ( 24K ) Bootloader 0x006000 -> 0x000400 ( 1K ) HS Hardware settings 0x006400 -> 0x001C00 ( 7K ) DS Default settings 0x008000 -> 0x008000 ( 32K ) CS Current settings 0x010000 -> 0x010000 ( 64K ) Web pages (depricated in most firmware) 0x020000 -> Space for CSYS image(s)
The map is a little cramped, My custom bootloader is bigger than 24K now so I chain to it from the default bootloader rather than overwrite it. Ideally the the partition should be enlarged to 32K and the HS, DS and CS partitions "slipped" a bit.
It's supposed to be DANGEROUS to flash from address 0x000000 - boot loader space here.
The firmware image is supposed to be flashed from 0x020000, so it is after the four partitions mentioned in the map above.
It looks like the tftp that is included in the release is modified so when it is launched from the web admin page it performs the transfer, a validation then flashes the image. It expects a full image (WEBS and CSYS) and so would flash from 0x10000. This tftp is different to the one launched by the board boot code, the boot tftp will upload an image to 0x80500000 in RAM and not do anything else with it. It will also download an image in response to a get but only if a previous upload has been performed (do a put of a filename of a certain size and then do a get filename and it knows the last uploaded size, so will retrieve what is in RAM from 80500000 for the size number of bytes: - you may be able to extract ROM contents by writing a dummy file of the appropriate size, doing a FLR 80500000 00000 <size> then the tftp get)
RAM base is at 0x80000000
80000000--- boot loader ? On startup it is copied to here then the code jumps to here
80100000---
80200000---
80500000--- current system upload load point. The image that is uploaded will have a CSYS header that contains the load memory address. When the image has been written to FLASH the boot code looks for the CSYS headder in a number of locations then reads the image load address (in my case it was 80350000) and the size of the image.
from the boot messages:
Memory: 4836k/8192k available (1320k kernal code, 3356k reserved, 1696k data, 44k init, 0k highmem)
Building the embedded ramdisk
The ramdisk is built using mke2fs. There is a binary that is provided in the
SDK for building it but it is kind of restrictive.
dd if=/dev/zero of=/dev/ram bs=1k count=$block_count mke2fs /dev/ram $block_count mount -t ext2 /dev/ram /mnt sh $script_file umount /dev/ram dd if=/dev/ram bs=1k count=$block_count of=$temp_file rename $temp_file, $image_file gzip -9v -f $image_file rename "$image_file.gz", $target_file
A perl script to do the same is at the
Sourceforge ForumBuilding the filesystem encounters problems when trying to run mke2fs with more than 4096 blocks. It complains about the size of the underlying device name="console_login">
Console login
The console login was cracked on earlier versions:
2.32 user: super passwd: lance@edimax.com.tw
When the system boots busybox starts, normally there is direct access to the console, and the login screen did not seem to be part of the busybox application?
It comes from a binary /bin/setup.
Ok so how is it invoked? Also how is the "real" system setup called from when the kernel finished loading?
Busybox init.c shows that normally init runs the runlevels as defined in /etc/init.d but in the case where there is not an init.d that it runs some default settings and starts a shell on the system console. The hack is that in /etc/profile (should be .profile? rather than a normal "shell" configuration the /etc/init.sh script is called.
profile runs init.sh starts the webserver and then runs setup. As it is a script then it should be possible to either patch the firmware to comment out the setup call or patch the image once it has been loaded but before we jump to it.
Setup dosn't seem to use the FLASH variables for super login, the password stored in FLASH in the DS and CS sections didn't work. SO the setup binary is a prime candidate for disassembling to work out where it gets it's password from. I suspect that after the last one was cracked so easily they have stopped putting it in clear text, though even if they use someting simple like crypt, then crypt needs to be on the box.
A dump of the file flash.inc shows DS and CS settings for both the super and admin users. Unfortunately the password there ( user: super passwd: APR@xuniL ) did not work for the login but it did give me a clue to how it was being done.
Flash Variables
When running 2.32 on a Unit that came installed with 2.39 I was looking at a script called create_flash.sh. This script pulls out the data stored in the HS DS and CS segments of the Flash memory and puts them in a file /etc/flash.inc. Thsi file is not present in the firmware, it is created on the fly as the system boots.
# cat flash.inc
HW_BOARD_ID=3 HW_NIC0_ADDR=0050fcd7089d HW_NIC1_ADDR=000000000000 HW_WLAN_ADDR=0050fcd7089d HW_REG_DOMAIN=3 HW_RF_TYPE=3 HW_TX_POWER=1,1,1,0,0,0,0,0,0,0,0,0,0,0 HW_ANT_DIVERSITY=0 HW_TX_ANT=0 HW_CS_THRESHOLD=11 HW_CCA_MODE=1 HW_PHY_TYPE=0 HW_WLAN_LED_TYPE=0 DEF_DHCP_CLIENT_START='192.168.2.100' DEF_DHCP_CLIENT_END='192.168.2.200' DEF_RSER_ENABLED=0 DEF_RSER_CLT_TBL_NUM=0 DEF_RSER_USR_TBL_NUM=0 DEF_ELAN_MAC_ADDR=000000000000 DEF_WLAN_MAC_ADDR=000000000000 DEF_SSID='default' DEF_CHANNEL=11 DEF_WEP=0 DEF_WEP64_KEY1=0000000000 DEF_WEP64_KEY2=0000000000 DEF_WEP64_KEY3=0000000000 DEF_WEP64_KEY4=0000000000 DEF_WEP128_KEY1=00000000000000000000000000 DEF_WEP128_KEY2=00000000000000000000000000 DEF_WEP128_KEY3=00000000000000000000000000 DEF_WEP128_KEY4=00000000000000000000000000 DEF_WEP_DEFAULT_KEY=0 DEF_WEP_KEY_TYPE=1 DEF_FRAG_THRESHOLD=2346 DEF_SUPPORTED_RATES=15 DEF_BEACON_INTERVAL=100 DEF_PREAMBLE_TYPE=0 DEF_BASIC_RATES=3 DEF_RTS_THRESHOLD=2347 DEF_AUTH_TYPE=2 DEF_HIDDEN_SSID=0 DEF_WLAN_DISABLED=0 DEF_INACTIVITY_TIME=30000 DEF_RATE_ADAPTIVE_ENABLED=1 DEF_DTIM_PERIOD=127 DEF_WLAN_MODE=255 DEF_NETWORK_TYPE=255 DEF_IAPP_DISABLED=0 DEF_AP_MODE=0 DEF_AP_MODE_TEMP=0 DEF_SECURITY_MODE=0 DEF_CLIENT_IP_DISABLED=0 DEF_WL_LINKMAC1=000000000000 DEF_WL_LINKMAC2=000000000000 DEF_WL_LINKMAC3=000000000000 DEF_WL_LINKMAC4=000000000000 DEF_WL_LINKMAC5=000000000000 DEF_WL_LINKMAC6=000000000000 DEF_WLAN_ENCRYPT=255 DEF_WLAN_ENABLE_SUPP_NONWPA=3 DEF_WLAN_SUPP_NONWPA=0 DEF_WLAN_WPA_AUTH=0 DEF_WLAN_WPA_CIPHER_SUITE=0 DEF_WLAN_WPA_PSK='' DEF_WLAN_WPA_GROUP_REKEY_TIME=0 DEF_MAC_AUTH_ENABLED=0 DEF_RS_IP='0.1.81.128' DEF_RS_PORT=0 DEF_RS_PASSWORD='' DEF_RS_MAXRETRY=0 DEF_RS_INTERVAL_TIME=60 DEF_ACCOUNT_RS_ENABLED=0 DEF_ACCOUNT_RS_IP='0.0.0.0' DEF_ACCOUNT_RS_PORT=0 DEF_ACCOUNT_RS_PASSWORD='' DEF_ACCOUNT_RS_UPDATE_ENABLED=0 DEF_ACCOUNT_RS_UPDATE_DELAY=0 DEF_ACCOUNT_RS_MAXRETRY=0 DEF_ACCOUNT_RS_INTERVAL_TIME=768 DEF_WLAN_ENABLE_1X=0 DEF_WLAN_PSK_FORMAT=0 DEF_ALIAS_NAME='Wireless AP' DEF_IP_ADDR='192.168.2.1' DEF_DHCPGATEWAYIP_ADDR='0.0.0.0' DEF_DHCPNAMESERVER_ADDR='0.0.0.0' DEF_DOMAIN_NAME='' DEF_LAN_LEASE_TIME=84082693 DEF_SUBNET_MASK='255.255.255.0' DEF_DEFAULT_GATEWAY='0.0.0.0' DEF_DHCP=0 DEF_STP_ENABLED=0 DEF_WLAN_MACAC_NUM=0 DEF_WLAN_MACAC_ENABLED=0 DEF_SUPER_NAME='super' DEF_SUPER_PASSWORD='APR@xuniL' DEF_USER_NAME='admin' DEF_USER_PASSWORD='1234' DHCP_CLIENT_START='192.168.2.100' DHCP_CLIENT_END='192.168.2.200' RSER_ENABLED=0 RSER_CLT_TBL_NUM=0 RSER_USR_TBL_NUM=0 ELAN_MAC_ADDR=000000000000 WLAN_MAC_ADDR=000000000000 SSID='HYA-L1' CHANNEL=1 WEP=0 WEP64_KEY1=0000000000 WEP64_KEY2=0000000000 WEP64_KEY3=0000000000 WEP64_KEY4=0000000000 WEP128_KEY1=00000000000000000000000000 WEP128_KEY2=00000000000000000000000000 WEP128_KEY3=00000000000000000000000000 WEP128_KEY4=00000000000000000000000000 WEP_DEFAULT_KEY=0 WEP_KEY_TYPE=1 FRAG_THRESHOLD=2346 SUPPORTED_RATES=15 BEACON_INTERVAL=100 PREAMBLE_TYPE=0 BASIC_RATES=3 RTS_THRESHOLD=2347 AUTH_TYPE=2 HIDDEN_SSID=0 WLAN_DISABLED=0 INACTIVITY_TIME=30000 RATE_ADAPTIVE_ENABLED=1 DTIM_PERIOD=127 WLAN_MODE=255 NETWORK_TYPE=255 IAPP_DISABLED=0 AP_MODE=0 AP_MODE_TEMP=0 SECURITY_MODE=0 CLIENT_IP_DISABLED=0 WL_LINKMAC1=000000000000 WL_LINKMAC2=000000000000 WL_LINKMAC3=000000000000 WL_LINKMAC4=000000000000 WL_LINKMAC5=000000000000 WL_LINKMAC6=000000000000 WLAN_ENCRYPT=255 WLAN_ENABLE_SUPP_NONWPA=3 WLAN_SUPP_NONWPA=0 WLAN_WPA_AUTH=0 WLAN_WPA_CIPHER_SUITE=0 WLAN_WPA_PSK='' WLAN_WPA_GROUP_REKEY_TIME=0 MAC_AUTH_ENABLED=0 RS_IP='0.1.81.128' RS_PORT=0 RS_PASSWORD='' RS_MAXRETRY=0 RS_INTERVAL_TIME=60 ACCOUNT_RS_ENABLED=0 ACCOUNT_RS_IP='0.0.0.0' ACCOUNT_RS_PORT=0 ACCOUNT_RS_PASSWORD='' ACCOUNT_RS_UPDATE_ENABLED=0 ACCOUNT_RS_UPDATE_DELAY=0 ACCOUNT_RS_MAXRETRY=0 ACCOUNT_RS_INTERVAL_TIME=768 WLAN_ENABLE_1X=0 WLAN_PSK_FORMAT=0 ALIAS_NAME='' IP_ADDR='192.168.2.1' DHCPGATEWAYIP_ADDR='0.0.0.0' DHCPNAMESERVER_ADDR='0.0.0.0' DOMAIN_NAME='' LAN_LEASE_TIME=84082693 SUBNET_MASK='255.255.255.0' DEFAULT_GATEWAY='0.0.0.0' DHCP=0 STP_ENABLED=0 WLAN_MACAC_NUM=0 WLAN_MACAC_ENABLED=0 SUPER_NAME='super' SUPER_PASSWORD='APR@xuniL' USER_NAME='admin' USER_PASSWORD='1234'
Builtin tftp
The builtin tftp that is invoked from the web interface loads, verifies?, flashes and reboots. No source is provided for this binary.
This is not so useful as we would really like to do two things here:
- load and execute (not flash) - may not be possible due to space constraints
- load an arbitary binary - if you have a console who cares?
What is on this box?
Looks like the earlier firmware had a bunch of stuff for both an AP and a Gateway (Router). This was changed somewhere along the way and the 2.49 firmware is stripped right down. The following is what I have cobbled together from the 2.32 firmware + some other packages.
| brctl | Bridge utility. This manges and controls bridging tables for joining the wireless and ethernet interfaces together as one LAN |
| pppd | ppp daemon, Hmm, why is this here? |
| pppoed | ppp over ethernet daemon, even curiouser. Tis can be used to connect to a DSL modem or tunnel through to somewhere else |
| dhcpc | DHCP client, so we can get an address from ?? |
| webs | tiny webserver for the admin pages |
| iptables | interface to netfilter tables. Needs to have support in the kernel |
| iwpriv | Wir eless tools |
| flash | Flash seems to be a utility that allows the get and set of parameters; no source to this - extracted from the firmware. The typical use is in scripts where it is run like: eval `flash get WLAN_MODE` This sets an environment variable $WLAN_MODE that is used after the get |
Things that are prebuilt
Uh, these are things that I extracted from the firmware. No source is available for
any of them.
auth ??
disc_server
flash Very important. This is the binary that is used to write stuff to flash - oh and also to read. Assuming it is something like the flash that is included in the boot code (but driven from the command line rather than linked in). There are examples of it's useage in the scripts in the firmware.
iapp ??
iwcontrol ??
pptp Client for the proprietary Microsoft Point-to-point Tunneling Protocol PPTP (Allows connection to a PPTP based VPN -- or a cable or DSL service)
setup Custom login binary that is executed from /etc/profile as the system comes up. Presents a login screen using non-standard methods.
upnpd Universal plug and play daemon. Supposed to help things like MSN Messenger work from behind a firewall
Web pages
The web pages used to be in an external archive that was loaded into flash at an address 64K before the CSYS image. Somewhere arround 2.39 this changed. In 2.49 the web pages are in the ramdisk image in /web
Two things of interest with the web interface, firstly how are the settings and ROM values extracted for the web server to display?
- In the asp pages there is the use fo a function "getInfo" that seems to return the parameters needed. Where is this command, is it a bit of Java script that is not included with the source? Is it some other function - I suspect that the flash values are retrieved from the flash dump in /etc
- Secondly how are changes applied back to the system?
The GoAhead webserver has a special type of CGI procesing. It accepts a POST command with the target of /goform/pagename. This is for an embedded function that proceses the POST data. A function is added to the configuration using the websFormDefine function and a jump table is built of the embedded forms. Each ASP page in the webs configuration uses this mechanism to pass variables (configuration changes) to the embedded functions in the webserver.
The webs binary in the 2.39 image is 238272 bytes
The webs built in the 1.6-SDK tree is 225196 bytes
partial dump of the 2.49 webs binary. Note: these are just the strings form the bss section of the binary, the code that implements these functions is elsewhere. The binary is stripped maing it a bit difficult to reverse engineer the functionality of the forms.
00002a30 66 6f 72 6d 57 6c 61 6e 53 65 74 75 70 00 77 65 |formWlanSetup.we| 00002a40 62 73 46 6f 72 6d 44 65 66 69 6e 65 00 66 6f 72 |bsFormDefine.for| 00002a50 6d 57 6c 61 6e 54 65 6d 70 00 66 6f 72 6d 57 65 |mWlanTemp.formWe| 00002a60 70 00 66 6f 72 6d 57 64 73 57 65 70 00 66 6f 72 |p.formWdsWep.for| 00002a70 6d 54 63 70 69 70 53 65 74 75 70 00 67 65 74 49 |mTcpipSetup.getI| 00002a80 6e 66 6f 00 77 65 62 73 41 73 70 44 65 66 69 6e |nfo.websAspDefin| 00002a90 65 00 67 65 74 49 6e 64 65 78 00 77 6c 41 63 4c |e.getIndex.wlAcL| 00002aa0 69 73 74 00 66 6f 72 6d 50 61 73 73 77 6f 72 64 |ist.formPassword| 00002ab0 53 65 74 75 70 00 66 6f 72 6d 55 70 6c 6f 61 64 |Setup.formUpload| 00002ac0 00 66 6f 72 6d 57 6c 41 63 00 66 6f 72 6d 41 64 |.formWlAc.formAd| 00002ad0 76 61 6e 63 65 53 65 74 75 70 00 66 6f 72 6d 53 |vanceSetup.formS| 00002ae0 65 63 4c 6f 67 00 66 6f 72 6d 53 79 73 4c 6f 67 |ecLog.formSysLog| 00002af0 00 66 6f 72 6d 44 65 62 75 67 00 66 6f 72 6d 53 |.formDebug.formS| 00002b00 61 76 65 43 6f 6e 66 69 67 00 66 6f 72 6d 57 6c |aveConfig.formWl| 00002b10 53 69 74 65 53 75 72 76 65 79 00 77 6c 53 69 74 |SiteSurvey.wlSit| 00002b20 65 53 75 72 76 65 79 54 62 6c 00 66 6f 72 6d 57 |eSurveyTbl.formW| 00002b30 6c 45 6e 63 72 79 70 74 00 66 6f 72 6d 52 61 64 |lEncrypt.formRad| 00002b40 69 75 73 00 52 61 64 69 75 73 43 6c 74 4c 69 73 |ius.RadiusCltLis| 00002b50 74 00 52 61 64 69 75 73 55 73 72 4c 69 73 74 00 |t.RadiusUsrList.| 00002b60 66 6f 72 6d 52 65 62 6f 6f 74 00 66 6f 72 6d 41 |formReboot.formA| 00002b70 63 63 65 70 74 00 66 6f 72 6d 4c 69 63 65 6e 63 |ccept.formLicenc| 00002b80 65 00 77 69 72 65 6c 65 73 73 43 6c 69 65 6e 74 |e.wirelessClient| 00002b90 4c 69 73 74 00 66 6f 72 6d 57 69 72 65 6c 65 73 |List.formWireles| 00002ba0 73 54 62 6c 00 66 6f 72 6d 53 74 61 74 73 00 69 |sTbl.formStats.i| 00002bd0 49 70 61 64 64 72 00 77 65 62 73 53 65 74 48 6f |Ipaddr.websSetHo|
Forms called from 2.49 web pages
| formSaveConfig | contool.asp |
| formWep | encryption.asp encryption1.asp encryption2.asp wlwdk.asp wlwep.asp wlwsk.asp |
| formReboot | reset.asp |
| formTcpipSetup | sysutility.asp |
| formUpload | upgrade.asp |
| formWlEncrypt | wl1x.asp wlars.asp wlencrypt.asp wlpsk.asp wlsec.asp |
| formAdvanceSetup | wla.asp wlaipc.asp |
| formWlanSetup | wlbasic.asp |
| formWirelessTbl | wlstatbl.asp |
| formWlSiteSurvey | wlsurvey.asp |
| formWdsWep | wlwdswep.asp |
What to add to this unit?
Well apart from just being able to build and modify the firmware, what I was looking for is to add a few features that make it a bit more useable and useful.
Useable
Means allowing someone that doesn't want to mod the hardware to upload custom firmware. This may be a two step process. Use the web interface to load a firmware version that allows access to the box (telnet of ssh).Need to investigate how the web pages interact with the device. Interested in how settings are changed, change is affected and how the firmware upload is done
From there a new bootloader could be installed that provides the boot wait functionality that would allow recovery after a problem.
Useful
In a community wireless environment there are two possible uses of this box, one as a public AP and the second as a backlink to a higher order node. In addition it might be fun to use it as a WLAN only Gateway device - turn the LAN port into a WAN port - all the software is therebut not configured correctly.- Public AP
- Needs NoCatSplash for access control / logging
- Route (not bridge) between WLAN and LAN
- Backlink
- Configure as a client of the higher order node (wireless radio in client mode)
- Route (not bridge) between WLAN and LAN
- Gateway
- Use ethernet port for WAN access (no local LAN only WLAN)
- Add second ethernet controller and line driver for WLAN,LAN and WAN use
Software Modifications
These are software modifications I have been working on.
Boot_wait
The serial port modification is a giant pain in the arse. Modification to the boot loader to provide the same type of boot_wait functionality as we have on the LINKSYS would be a good start.- changed eth_tftpd.c to support "know" filenames. This will allow automatic action when a tftp is done using well known file names. Two names are supported: dna_test.img dna_flash.img
- If a file named fw_test.img is uploaded it is written to RAM and execution jumps to the start of the file. (needs to not have the CSYS header)
- If a file named fw_flash.img is uploaded it is written to flash at the address 0x020000. This will be the system firmware upon reboot. The aim of being able to do this is to let someone without a serial console update the firmware during the boot wait period (especially useful once you have accidently bricked your AP).
- Only a well formed CSYS image should ever be flashed this way (i.e. not stripped header).
- changed main.c to run the tftpd during the user_interrupt wait function. Now this function will start the tftpd server and go into it's timer loop waiting for a keyboard interrupt. If there is no interrupt and a tftp has commenced it falls into the monitor. There is potentially a problem here if the transfer is not a known image - it will write it to RAM then stay in the monitor forever. (reboot will be Ok though).
To do this we need to re-flash the boot loader - For now build the functionality we want, use the existing loader to copy it to RAM then jump to it. See if we can get it to work then flash it.
For mass use the approach would be to distribute a firmware that has the boot loaded image and a little utility.
Use the web download to put it on the machine then ssh in and run the utility. This would then load the new boot loader.
Need to understand what get's flashed from the web interface (seems to take the image including the web pages probably loads to 0x10000.
Route not Bridge
The bridging rules are set up in a script that calls brutils. This can be easily changed to remove the bridge between the WLAN and the LAN interface. The script has code for a WAN interface (not physicaly on this unit) that is a good template of what is wanted here. Need to the set the WLAN and LAN addresses seperatelySystem access
You can turn on the telnet daemon in busybox, useful for the initial exploration. Not sure if the password protection on the serial port is in the busybox code or a wrapper.Once I have had a look around then dropbear looks like the way to go. Using the code from the LINKSYS I have been able to build it in the tree - need to make a script to do the setup. (crib the linksys rc code). The start script first creates the server key (if it is not present) the runs it.
?????? need to understand how the flash utility works - assume it allows storing values in flash but how big and how much space is available and how much is used - probably one of those partitions in the boot sector of the flash.
Monitoring
Snort for intrusion detection.Traffic management
Frottle, as the other nodes are likely to be using this.Routing
Bird or Quagga for all routing.Reality Check
After another month or so of playing with this thing, I have realized that *MB of RAM is very tight. You loose almost 2MB for the kernel, a further 3-4MB with the ramdisk and each application that is loaded chews however much it needs. I could run bird (OSPF daemon) but nothing else. So the reality check is that while a hypothetical device could have configurations for the three uses described above the reality is that with some reletively minor modifications this device can be used for a cheap and cheerful backlink but it's not really worth spending time trying to use it for a captive portal or an Internet gateway.One thing that could change this is the addition of a second RAM chip. It was suggested to me that you could take a chip of a PC133 SDRAM (the RAM chip is a standard SDRAM 54 pin TSOP2 package). Adding a second chip 64MBit gives you another 8MB RAM or replacing the existing chip with a 128MBit and adding a second takes you up to the max 32MB supported by the processor.
Using CRAMFS or a tiny bootdisk & NFS are also ways of getting back a bit of RAM .
I'll post up the modified boot loader, I'm adding DHCP client support to it so you can have the device boot from a TFTP server and a minimal ramdisk to use it as a backlink radio
Version 3 (old) modified Mon, 26 Jul 2021 12:49:28 +0000 by capatana
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]