been busy so this week's update adds very little.

as always, use at your own risk. i'd love to hear bugs, feature requests, etc. here's what's new:

+syslog configuration

still TODO:

+add something to the "commands" page
+package managment
+cleanup web code
+move away from php (or lwhp)

as far as prioritys go; i'll probably start working on a conversion (probably to ash).  i'm going to let the package managment functionality alone for now, mostly because the conversion project sounds more fun.

repository is at http://davidoffdotnet.net/openwrt/ipkg

Nice.

- maybe a choice to reboot or not for simple changes?
- web interface version displayed on initial/all pages?
- modules for addon packages?
- syslogd: local and remote logging?

I was thinking about sending some patches to you but I don't want to spend too much time on it if you will be switching over to ash soon.  Do you have a ballpark idea of when that would happen?

I noticed that mbm would like a different interface, would you be against moving to something a bit more CSS oriented if you were provided patches?

is syslogd not working?  it should be -- it's under management->services.  the other suggestions are good.

i plan to start on the ash conversion next.  at the same time i will make the conversion to css as well, and possibly a little javascript.  i hope to release the ash conversion in the next couple weeks, but i've been kept busy with other things.  i hope some time will free up.

Sorry.  Meant to explain that having the ability to remote log and locally log (with optional log rotate time) would be cool.

Okay, I have a couple of module ideas already but will wait until you have some prelim stuff before finalizing.

ok, here's a snag.  does ash support arrays?  i can't get it to work, if it does.  any clever workarounds?

just a quick update for those interested. . .

i'm still working on this, but i haven't been able to make a weekly update.  the reason is that the next update will be more significant, yet i've had less time to work on this project recently.  the result is delay.

the two things i'm working on are:

1. css formatting -- the current version's html looks like its from the 1990's.  someone never updated their html skills, but i'm rectifying that.

2. conversion to ash -- i'm using ash as the scripting language.  the debate on the subject has been interesting, i've chosen ash because (a) it works, and (b) it's already installed.  it's true you lose some flexibility, but on the whole i think its worth it for as simple a project as a web interface.

realistically, i probably won't make another release until next week at the earliest.

is an IPTables Interface planned, I'd like to start tackling this.

Fozz

there's a rudimentary interface, it only allows forwarding and opening ports.

if you want to add to it, it might be worth waiting till i finish the ash conversion.

I'm not too keen on the PHP thing either.

Foz

I'm new around here, and I don't have any hardware to test with yet (though I'm getting a WRT54GS soon), but I've been looking at the idea of using Lua as a lightweight web scripting language. It's quite small (my untested MIPS binaries of it are about 250k), but still quite powerful.

I don't have anything to show off yet, but I've been working on support code (CGI query/form parsing etc.) and a simple templating system. Once I get some hardware and get OpenWRT on it, I'll put something useful together and throw the packages up somewhere.

I've also been working on porting Python over to OpenWRT (which doesn't seem to be any too easy, since python includes a lot of thing that the WRT probably doesn't need, like Tk and infinite-precision integers).  I'd be very interested to see where you get with Lua, which I also looked at briefy.  I've also been considering pike and various small schemes (schemata?) for their utility in the OpenWRT.  This is not so much because I think they'd be super-useful as because scripting languages are fun.

I have this vague plan to do a reimplementation of python specifically for embedded systems, which would be tons of fun but which I probably don't realistically have time for.

I must say, though, that using sh as a web development language seems like it's just asking for trouble from a security angle.  I suppose if the program is very rigorous about escaping input and so forth it should be doable, but the idea of running a root shell where the user can enter in `rm -rf /` as their username (or what have you) gives me the heebie-jeebies.  (I haven't really looked at BusyBox ash in particular, either, maybe it's more robust than I think.)

Lua was dead simple to get going, since it only depends on the standard C library (and optionally libdl for loading modules at runtime). If anyone's interested, I've uploaded my untested build here:

http://gir.eclinic.com.au/~lsd/openwrt/

The tarball puts the lua interpreter and luac compiiler in to /usr/bin, and the liblua and liblualib libraries in to /usr/lib. The sort.lua script is just an example I pulled from the Lua tarball to test with. One again, this is an untested build (I don't have any hardware to test it on yet), but I'd love to hear from anyone willing to give it a go and report success or failure.

i've hit a problem with ash, and I'm not sure there's much to do about it. the problem is . . . it's slow. it seems to take between 3-5 secs to parse each page.  slow enough to be pretty annoying.

maybe i'm doing something wrong.

other than that, though, the conversion from php to ash is pretty easy.  but the "that" might be a deal breaker.

here's hoping i find some optimizations. . .

Post it or send it my way; I'll take a crack at optimizing it.

Anyways, not as if the page needs to be extremely fast; you really don't need to reconfigure that often.

i'm a moron.  someone remind me to run top before complaining about performance issues.   i had some half-assed shell script stuck in a loop in the background.  someone buy me a clue . . .

that being said, i'm still going to post some of the code.  any suggestions on optimizations, or other things are most welcome.

this is very beta.  it's not a package.  it's not even close to workable or complete.  it is, in fact, nothing more than two web pages (the network->status and network->local pages).  only download it if you want to look at my ash code or css.

if you do download, dump it all in /www/cgi-bin and it should run.

as for the css, i know the "content" div widths are a little off in some browsers.  i'll fix it.

Hi Sam,

How is the conversion to Ash going for the interface?  I'd like to have a crack at designing an interface that can do network bridge and vlan control.  I'm very new to this, but if I'm hoping if I can get the web side of it designed it might inspire some people to help me with the back-end stuff.

I'm fiddling with the Javascript that comes with the default WRT54G and have noticed that the code has got "UNPUBLISHED PROPRIETARY SOURCE CODE of CyberTAN Inc." written all over it.  I take it we can't use this code as a base?  How do we get around this?

The conversion is going nicely.  The only problem has been time.  I just got back from vacation after an incredibly busy month.  I hope to get some time this weekend to possibly get the conversion in a state to release.

fwiw, the ash conversion is basically done.  a few more little things to fix.

i'll release it for testing, suggestions, etc. once cvs and snapshots are updated to a version of busybox that has the patch for the http post limitation.

http://www.busybox.net/lists/busybox/20 … 12410.html

of course, people can update the buildroot themselves, but i'm going to delay my release to avoid unecessary bug reports.

Great!  I look forward to it.

I'm going to have a crack at doing a web interface for Shorewall which I've recently gotten to work under OpenWRT.  It's slow but seems to be the only way of handling a firewall for 3 or more interfaces without melting your brain.   Having Shorewall in place will make it easier to add and delete VLANs and bridges dynamically from the web interface whilst maintaining a method of controlling the firewall.

The problem I see with existing web interfaces is that by using naked iptables commands to control the firewall they are locked into a certain number of interfaces in the box.  It would seem that having a web interface that lets you add and remove VLAN, bridge, WDS and VPN network interfaces would cause a nightmare when it came to writing an accompanying iptables firewall web interface.

I believe Shorewall solves this nightmare for us.  It'd be pretty easy for a web interface to add and remove entries from the Shorewall config files and to execute Shorewall.

Because Shorewall takes a long time to execute on the WRT54G (over a minute at the moment), I'm thinking that using 'iptables-save' and 'iptables-restore' would speed things up.  Run 'iptables-save' after Shorewall executes and then run 'iptables-restore' on boot instead of Shorewall or a hand-written firewall script.

You would only need to execute Shorewall if you wanted to change the firewall behaviour.  I believe this would be acceptable to all users except those who need to constanlty tweak their firewall.

EDIT: I just found out that recent versions of Shorewall have iptables-save/restore funtionality built-in.  So I'll experiment with that...

how many flash space is needed for shorewall ?

After stripping almost all of the comments out of the config files and scripts I've gotten Shorewall v2.0.8 down to about 208k.  Still a fairly hefty package, sure.  It's written entirely in shell script so that probably contributes to it's size, but it does make it easy to 'port'.   I believe the functionality it provides makes it worth the room it occupies on the flash.

UPDATE: on my debian box iptables-save is 51752 bytes and iptables-restore is 51788 bytes.  So I guess shorewall does open a can of worms with the other apps it needs to fully function.  I still think it's worth it.