Hi,

as you know, OpenWrt has always lacked a proper web interface for configuring all those settings. I intend to change that - that's why I've started to work on a new modular web interface that - I hope - will be ready for the next release candidate of OpenWrt 'White Russian' and eventually for our 1.0 release. It is written completely in Shell+AWK and uses Haserl for form processing. It's nowhere near feature complete (but some things like basic wireless settings, firmware upgrade and an ipkg interface do work), that's why I need your help. If you've got some basic skills in HTML, shell and OpenWrt, please have a look at the thing.
I keep an updated snapshot at (dead link removed). If you want to send me patches or have questions about the interface, please talk to me via IRC (nbd in #openwrt on irc.freenode.net) or mail me: openwrt <at> nbd.name

Have fun

- nbd

Update: webif development continues in the X-Wrt project: http://www.x-wrt.org/

Hello,

I started few months ago writing a web interface for our wireless user group in Nantes, the interface is located here : http://sourceforge.net/projects/nwn-firmware. As it is already developped in ash + javascript and haserl, maybe we can merge our work ?

Looks interesting, but I don't think I can use much of your code. Some problems that I noticed:

1) Your code doesn't seem modular at all
2) It relies on JavaScript for form validation etc. That won't work that well in browsers like w3m
3) You have a lot of duplicate code, because the HTML stuff is inseparable from the script code and you haven't added any abstraction.
4) A lot of the stuff uses non-standard nvram variables
5) Most of the stuff is written in pure shell, which is much slower than processing stuff with awk

I tried to address all these issues with my web interface. No category or config page names are hardcoded in the index scripts. The forms are generated completely by an awk script (which abstracts away all the html stuff). And it runs very fast despite having a lot of abstraction code.
I haven't got any internationalization code in there yet, but I intend to do the language translation at compile time so that it doesn't slow down the whole interface.

I think you should have a look at my code and start porting your interface pages to it. It might save you a lot of maintenance effort.

nbd: If you stick this as a module into CVS somewhere I'd be willing to put some effort into it. I'm "experienced" in the field. Would be nice to have commit rights though, so perhaps you have a repo somewhere else to use in the meantime?

(Last edited by TheRoDent on 23 Sep 2005, 08:52)

Thanks a lot nbd for your advice. I will port my web interface to your code because it looks like really pretty and efficient.

Maybe you want a french localized version ?

Hey TheRoDent, RItalMan,

I have now added webif to whiterussian CVS (disabled by default). So you can follow the progress there.
If you have any patches, please send them directly to me.
About the french translation: Sure I'd like that. Maybe after I add language translation support to the build process.
I just want to make it a bit more featureful before starting something like that.
Thanks for your support,

Felix

hi,
would it be possible that the status page is open to everybody/has no password request?
at my old router I used the status page to see if the router was on and had a connection, before browsing. this was neccessary because it liked to crash often, now I would be glad to see the great uptime of the router.
I know that I can access the router with http://user:pw@router/ but I don't like it, that anybody could see the password if he looks in my bookmarks.

lutz

I am working on OpenWrt GUI using nbd's code as a starting point. As soon as I have something semi-working I'll post the code.

My goal is to be able to configure OpenWrt after fresh install without using dreaded command line. Purely by coincidence I posted a small blurb here: http://lazutkin.com/blog/2005/sep/23/openwrt_gui/

My super goal is to be able to configure firewall using WebUI. I want to use this tool: http://easyfwgen.morizot.net/ I already did some research and it looks like it can be ported to JavaScript without major hassle.

I am overloaded with work now, but I am trying to have something worthy of review in 2 weeks.

BTW, what is the release plan for next White Russian and 1.0?

(Last edited by uhop on 24 Sep 2005, 07:19)

I changed it, so that the 'Router Info' and 'About' pages are accessible without authentication.
If you've run the previous version of webif, you need to delete /etc/httpd.conf and run killall -HUP httpd in order to make the change effective.

That doesn't fit into what I'm doing. I want to keep my UI compatible with text mode browsers that don't use JavaScript (like w3m). I do use JavaScript in my UI, but it's not required.

it works for just one time
when I restart firefox I have to type "root" and my pw again. but if I do "rm /etc/httpd.conf && killall -HUP httpd" and then reconnect with firefox, it works, but only the first time I connect to the router with firefox, then I have to do "rm .. && killall .." again.

but don't worry to much about it, when it is too much work and you think it's nearly useless. I'm just the type of person who likes to monitor the CPU, RAM, Traffic, ... of my desktop computer.

// Edit: it seems, that it works as long as I did not have to enter my password in the web interface. the first time after requesting the password, the password is required for the status page, too. but if I just view the status page and restart firefox and view the status page again it works.

(Last edited by Lutz_R on 24 Sep 2005, 20:05)

Thank you.

Text mode browsers? I believe that somebody who keeps text mode browser around will be more comfortable using command line.

Hey,

can anybody tell me the status of the openwrt web UI? I've seen several people announcing such a packet but have no time to evaluate them. What I can offer is this: Throw in a customized version of the Freifunk webadmin with a more OpenWRT screen layout and some changes applied. Will be a spinoff with not to much work required:

- OLSR page (to much firewall stuff in there)
+ WEP/WPA for the Wireless page
+ Some extras for System (e.g. lan_ifname)
% Changed "Update Firmware" approach

Comments?

even though this one isnt done i can say it is the best by far and it should only get better

@Weedy,

which one you are talking about?

@all,

ah - while I'am here, I may spit out another question. I think it's good to have a technique to allow IPK devels to add in an admin page for their packet showing up automatically in the UI. For this a naming convention (e.g. openvpn-with-an-english-webadmin-page.ipk) is required. Also a naming convention for the language used (because the mini-ipk-script on OpenWRT does not handle language deps with version IDs e.g. to have "oh-no-spanisch-ipk-ok-fetch-the-english-one).

LG, Sven-Ola

Ah - sorry. Should read the thread *first*. I'll check...

LG, Sven-Ola

Ah - felix is definitely a good kernel hacker Besides that haserl dep, I prefer to stay stand alone (render stuff statically on a big machine) and do not want to interfere with other peoples projects.

A good time,
Sven-Ola

But there is no reason you can't create a very nice looking and functional UI that also supports text mode browsers or automated http scraping applications. Of course I would probably use ssh in an automated app but there might be valid need for this. The thing I've always liked about OpenWRT is it gives you the basics and lets you customize it to your liking. I almost prefer it to not come with a web UI at all but would surely like to be able to install the one I like (many would choose the really fancy interface but several would also prefer a more basic interface and yet more still would prefer no interface at all). Just a couple of thoughts.

I respect that. I support the idea of several web UIs as installable packages. That's why I want to do it on my own using nbd's code as a starting point.

I know exactly one good reason to justify plain HTML interface --- support for screen reader, which helps blind persons. It is a very good reason.

Personally I would prefer secure SSH to completely unsecured OpenWrt-based web server for simple management tasks. Only complex tasks, which consist of several coordinated changes in different places in correct order, would require some assistance (ash script?). Going with web-based solution makes OpenWrt as secure as your local network. But it is okay in many scenarios.

In my model a user of such web UI is going to be a casual user of OpenWrt, who doesn't have a lot of time to learn all OpenWrt gotchas. I bet that this guy/gal would have access to latest browsers free browsers (IE6, FF, Opera8, Safari 2.0, and so on). In 99.99% of cases s/he would have them installed already. Why not use it to offload OpenWrt?

One example is a firewall configuration. I used a ported package, which generated iptables stuff on the fly from configuration file. It took several minutes to generate it. I decided to generate it outside of OpenWrt and upload the result. It works, but quite cumbersome to do. Clearly it is not what I would recommend to my friends. But if it is done in JavaScript, it can be generated and uploaded within single web application hosted by OpenWrt. Probably I am uncharacteristic user, but firewall is the only place I tweak periodically after initial setup.

Another problem was a code complexity trade-off between client and server code. nbd's code is good but quite complex by necessity --- ash is not designed to do text-processing producing HTML. Some places are just arcane. JavaScript is close to C, which is familiar to almost all developers. JavaScript has regex, which allows massaging text from command line scripts to your liking, like you would do with Perl. I suspect that package writers will prefer JavaScript to awk. I do.

And what is wrong with making web UI pretty? I think it will help popularity of OpenWrt. Interesting fact: ~25% of readers of my blog are coming from openwrt.org main page and from link in this thread. They don't come to read some revelations about OpenWrt internals --- I don't have such things at all. They come just because there is a great interest in web UI. That' s why I am working on it.

There are some problems, which should be addressed in the future:

1) Web UI should be bundled with openwrt to make good first impression for non-hacker users. Which one? It is too early to select now. But clearly such web UI should provide a simple way to switch to other UI. Or be completely uninstalled. One possible solution: different images, which come with different set of pre-installed packages.

2) Web UI will have some core components (e.g., general info on OpenWrt setup with some editing) and additional components, which may come with packages. It would be nice to have package API defined at some point, so it can be reused (if possible) by different web UIs. Obviously a package can use a specialized API to make it super-simple/super-fancy. But we need to have some reasonable common ground.

I would agree with all of your statements except the one stating OpenWRT should be bundled with a web interface. I would actually like to see OpenWRT not even come with a web server. The reason for this is using the squashfs binaries you have no way to remove software. Once it's there it's there. I also like to use Shorewall for my firewall software although it would be nice to have the startup script that is generated on a shorewall restart generated on a machine with more power. It takes over 5 minutes to restart it. I mean it sounds like by bundling all this stuff what you want to end up with here is DD-WRT. Why not just have a script on the OpenWRT that can be run on first login to select and install the base packages you want (something along the lines of Debian). It could then ipkg install them. Then you basically have a highly customized/personalized router almost out of the box.

P.S. I'm not an OpenVPN developer so these are just my inputs as a user and a big fan of OpenWRT.

From what I read there are two or three kinds of people answering here:

* type A: I dont need a web interface, since I can do all changes with ssh.
* type B: A web interface is cool, but it should be using the newest browser, javascript, etc.
* type C: me.

To explain type C:
I can do both. I like to do changes to my configs when i have the time to do them. If i am in a hurry, or just plain lazy, I would like to be able to do simple tasks the easy way, with a web interface. Also for tasks I have never done, for example QoS. It would be great if a web interface just does the changes for me. I can review changes after that and then know how to do it by my self later.

I could do with out a web interace, sure. I would just make a couple of scripts that do the changes for me, basically the backend of the webinterface made standalone. Works fine, and there are probly enuf people out there who do it just that way. Regarding the text-mode browser compatability, I think this is important. I sometimes am at places where I just dont have any UI to work with, just an ssh window at max. I could do changes the ssh-way, sure, but why not do them with the web interface, if they are complex tasks?

The thing is, we want this web interface not only to work for type C people, but also for type B and inbetween people (type A people dont need to install it, or can uninstall it). Therefore, I think the way we are heading right now - having an interface that works with and without the newest browser - is the best way to go.

so how do you test server-side things and get them to the javascript client? If you write a package, anything that depends on server-side tasks (i.e checking for files, etc) relies on shell code. You will need to write it. Or do you want to just make a section with all the output from the (hint: you have to write them too!) shell scripts, and massage that with javascript? Sounds like the wrong thing to do for me, especially since text-mode browsers will just see the shell outputs as they are.

I am sure nbd's code can be taken apart a bit more or be templated a bit more, so that package maintainers just have to use a certain syntax (which may be documented some day) to provide UI for their package. No need to understand awk for that.

I totally agree. There should be a UI to start with. I think nbd's ui should be the standard installed web interface, but I guess thats a question of religion.  The simple way to switch to another is to uninstall one and isntall the other. You dont need different images for that.

I personally love the look of the interface and think it will be a great boon to OpenWRT. It took me a while to decide to give up the Linksys interface. Once I switched to OpenWRT I was very happy, but still wrote a small interface to accomplish some tasks others need to perform on the router.

nbd's XHTML and CSS look very good, but the code to create it looks very complex, almost scary. I wonder how all of the engineering affects performance. Regardless of how it runs under the hood I think it will be a success if it works.

I would prefer two versions of the firmware, one with the interface pre-installed, and one without.

Who is B? I suspect that B is I, because I was the only one in this thread, who said about leveraging modern browsers. As far as I remember I advocated SSH for most tasks and I don't support the idea of "it should be using the newest browser, javascript, etc." --- tools should be adequate to needs.

Every time you code for a web site you are faced with selecting the lowest common denominator as your base ("We don't support NN4!") and providing enhancements for popular browsers ("This is extension for FF!"). I think that targeting text-based browsers makes the lowest common denominator is uncomman and impossibly low.

Sorry, I didn't get this paragraph. What did you mean by that?

In my (far from finished) implementation you still need server-side code. It goes (almost) directly to the browser and processed by JS. In most cases it's a one-liner. No processing is done in OpenWrt besides some greps. Is that what you asked?

I don't recall bashing nbd's code. Just the opposite is true: I am impressed.

I want to clarify my point about awk. I downloaded nbd's code and started to muck around. ash scripts are unsuitable for HTML generation. Any transformation of command line output is a pain. If you can do with grep, and sub, you are fine. If not, you do awk. Basically the only scenario was easy to do: you show command line ouput verbatim, you show static form, you collect parameters from your form, and run a script with this parameters. Sounds familiar? I can do the same workflow with SSH. It would be simpler, more secure, and more flexible. I may need some helper scripts, which will automate some tasks for me. Things are getting more complicated, if you want to validate user's input. Just try to write something realistic. I tried.

It's good to know your opinion. Not being OpenWrt developer I have absolutely no say in this matter. I could propose something. I did.

I hope "to uninstall one and isntall the other" would be possible without command line. Otherwise it defeats the purpose. That's why I proposed "the switch" in #1.

I think it is absolutely counterproductive to have many incompatible versions of web UI. Just imagine writing UI code for 5 different web UIs. That's why I proposed #2.

In my proposals I don't discuss any specifics. I just want to have the door open for alternative implementations. Please keep in mind that at this point my version of web UI is vaporware --- nobody saw it but me. nbd has working version. It is here _now_. So chill your engines. When I have something semi-working (hopefully in ~2 weeks), I would be glad to hear some constructive criticism. But you have to wait.

PS: I re-read previous posts and I think that there is a misunderstanding. Let me tell directly what I thought was implied: I am doing web UI because I want to, I am not forcing it on anybody, I am not trying to convert anybody from their religions, I am not asking for anything, I don't think that I have monopoly on web UI, I am not going to bundle my implementation with anything (it is not my position to do so), I am not saying that you cannot do nice interface without JS. I hope it is clear now. Stop fantasizing.

PPS: No, I am not against Shorewall.

I am a little confused about something. You say you can uninstall one and install another but if it comes on a squashfs it would be in ROM and can not be uninstalled. Is this not correct? That is the only reason I am opposed to including one because it can't be uninstalled thus taking up precious space. Someone might want to use that space for something else. If it could be uninstalled I wouldn't even have piped up in the first place. I know I could build my own without it but it would be nice to have a basic binary. Maybe 2 or 3 different squashfs versions could be created with each release. A "basic" distribution (wouldn't even include web server), a "standard" edition, and a "deluxe" edition with varying degrees of geekiness.

Check out the new Image Builder. It uses package lists to quickly create several images with different feature sets. Should be exactly what you're looking for...