OpenWrt Forum Archive

Topic: interface-wrt 0.7 available for beta (adds ipkg interface)

The content of this topic has been archived on 7 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.

i agree with you that there are certain standard packages that it may make sense to include by default.  i would include dropbear and also pppoe among these.

as for your second question, i recommend putting everything, including scripts, in packages/wifidog.  it will make upgrades to interface-wrt less likely to break what you have done.

I builded a package for Wifidog in the packages directory. When I want to submit my configuration, index.sh can not easily handle the data.

My first try was that : I set subsection=wifidog_set in the form, the file will be out of the wifidog in /www/openwrt/packages/wifidog_set and all will work as expected.  But this is not really usefull for single dir package files add-on.

So I did some modification to index.sh : I added read STDIN in the file and modified this code :

[...]
if [ "$section" = "packages" ] && [ -d $pkg_dir/$subsection ]; then
        if [ "$(post_var submit)" = "Apply+Changes" ]; then
                . "$section/$subsection/submit"
        else
                . "$section/$subsection/index"
        fi
else
        . "$section/$subsection"
fi
[...]

and added the name field for the submit button to my script of wifidog :

<input type="submit" value="Apply Changes" class="submit" name="submit" />

With this code if the submit button is defined by Apply Changes, the submit file is sourced instead of the index file.

What do you think of my modifications ?

And I want to know why you are not reading STDIN in index.sh and remove all read STDIN of the beginning of all submit files ? I did not read all the script and I want to know if I am not breaking some code or going in futur design trouble.

Many scripts did no data input validation. What is the best, javascript validation before submitting data or shell validation before doing any modifications ?

Also, If some people ask for small documentation I can write something. It's easy to understand how all things work, but it will provide rapid overview and standard code creation and validation.

I take a look of the needs of Ile Sans Fil and I will had support for :
- httpd : done, need some minor changes before releasing code
- ez-ipupdate (package) : In progress
- rdate : In progress
- Wifidog (package) : Basic config done and tested
- pppoe : To do
- Maybe some basic support for openvpn (package)

Thanks

couldn't you handle it as a get variable passed through from index.sh

in other words call your form this way:

index.sh?section=packages&subsection=wifidog&apply_changes=y

than have your index page have the logic you suggest.

that way the main index.sh page will simply pass the apply_change=y variable through to your custom page and you can use it as you like.

in other words, index.sh will always source  packages/subsection/index, but then packages/subsection/index can source whatever it wants.

i would do it this way so as to avoid having to tailor the index.sh page to the needs of various packages.  the packages/subsection/index page is where customization should happen in my view, not index.sh

thoughts?

couldn't you handle it as a get variable passed through from index.sh

in other words call your form this way:

index.sh?section=packages&subsection=wifidog&apply_changes=y

than have your index page have the logic you suggest.

that way the main index.sh page will simply pass the apply_change=y variable through to your custom page and you can use it as you like.

I can do it that way, the final result will be the same.

in other words, index.sh will always source  packages/subsection/index, but then packages/subsection/index can source whatever it wants.

Without modification in index.sh, how can I use an other file than index by using index.sh ? I thought seperating the presentation code and submission code file simplifie the work for new package add-on.

i would do it this way so as to avoid having to tailor the index.sh page to the needs of various packages.  the packages/subsection/index page is where customization should happen in my view, not index.sh

thoughts?

I understand your point. I'm looking for a way to have a presentation code file and a submission code file easily handle by the web interface. And all the files must go in /www/openwrt/packages/myNewPackage. With this code modification, I think the package add-on had a better support. It's a one time small code add.

But I could put at the begin of my index file validation for apply_change=y and source my submit file instead of the remaining code. But, all new packages might work differently from others. I am looking for a standard for all packages.

You are the Boss  wink   It's why I'am asking you questions  smile

Without modification in index.sh, how can I use an other file than index by using index.sh ? I thought seperating the presentation code and submission code file simplifie the work for new package add-on.

i agree, but my idea is that the index file is neither.  index would, in your situation, merely contain logic that switches between presentation and submission, i.e., index contains no content itself.  in anything other than the simplest situation my idea was index would contain something like this (not real code):

switch some_get_var

case "status" - source "status"
case "form" - source "form
case "submit" - source "submit"
etc...

all your actual content would be neatly kept in other files, which index sourced as needed.

You are the Boss  wink   It's why I'am asking you questions  smile

ha. i hope i'm an open-minded boss, then.

i really wish i had more time to work on this stuff.  i appreciate the work you're doing; it's what makes open source great.

in the version 0.71 there is a bug in the file /www/openwrt/management/dhcp

the second line in the file should be

dhcp_status=`[ $(grep -c '^dhcp-range' /etc/dnsmasq.conf) = "1" ] && echo "on" || echo "off"`

there was a ) just after "on"

in the version 0.71 there is a bug in the file /www/openwrt/management/dhcp

the second line in the file should be

dhcp_status=`[ $(grep -c '^dhcp-range' /etc/dnsmasq.conf) = "1" ] && echo "on" || echo "off"`

there was a ) just after "on"

thanks, although, actually i think the fix is to add the opening paren, i.e.,

dhcp_status=`([ $(grep -c '^dhcp-range' /etc/dnsmasq.conf) = "1" ] && echo "on") || echo "off"`

in the version 0.71 there is a bug in the file /www/openwrt/management/dhcp

the second line in the file should be

dhcp_status=`[ $(grep -c '^dhcp-range' /etc/dnsmasq.conf) = "1" ] && echo "on" || echo "off"`

there was a ) just after "on"

thanks, although, actually i think the fix is to add the opening paren, i.e.,

dhcp_status=`([ $(grep -c '^dhcp-range' /etc/dnsmasq.conf) = "1" ] && echo "on") || echo "off"`

it works for me without the extra ()

is it possible to get the source and packaging information i could not find it on the download url

also one minor change in the file /www/openwrt/wireless/security

change the line  of the case statement in the beginning from

        "on" )

to

        "on"|"restricted" )

this should take care of previously configured stuff with stock linksys firmware

is it possible to get the source and packaging information i could not find it on the download url

also one minor change in the file /www/openwrt/wireless/security

change the line  of the case statement in the beginning from

        "on" )

to

        "on"|"restricted" )

this should take care of previously configured stuff with stock linksys firmware

well, there's no source, because it's just a bunch of scripts and html pages, so nothing's compiled -- what you see is what you get.

as for packaging info, basically the same thing.  if you just untar the .pkg file you'll see everything i used to make the package.

feel free to ask me if there's something you don't get, though.

interesting about the parens issue.  you're right, i guess i didn't totally get the order of operators, but it turns out
[ 'x' = 'y' ] && echo true || echo false
will print false.

thanks for the tip on stock firmware.

i really appreciate these suggestions/bug reports.

some other bugfixes and cleanup for displaying status of the wan ip when there is no ip

diffs are done agains 0.71

see attached file

some other bugfixes and cleanup for displaying status of the wan ip when there is no ip

diffs are done agains 0.71

see attached file

very much appreciated, i will try to review and incorporate this weekend.

another patch against 0.71 this time it's all enhancements to the services screens.

This patch makes it possible to just drop in just 5 small scripts per service telnet / dns / syslog are part of the base package and an example is included for dropbear

to use the new structure just drop in 5 scripts in the scripts directory

dropbear_status
dropbear_setup
dropbear_enable
dropbear_disable
dropbear_apply

you can remove these from the base package and maybe package them up in something like interface-dropbear

This setup makes it much easier to add new services as there are no changes to the base setup.

Have fun with it and let me know what you think about it.

hey, nice work.
i found a few small bugs in 0.72 and fixed them. (they mainly refer to my asus hardware wink )

but i take this code and rewrite it for my own purposes: (maybe i re-invent the wheel, as i often do)

i wanted a webinterface close to the original (i wonder why i use openwrt *g)
my aim is to build a single image with all stuff i want on the router + webinterface to configure it properly

now it works as expected (a few things are missing) and i'm happy with it

to support the great work of all the developers here i will provide the code/files for testing or merging with recent versions if anyone is intrested...

cyberwulf wrote:

i wanted a webinterface close to the original (i wonder why i use openwrt *g)

...close to the original asus fw webinterface or linksys fw webinterface?

i'm currently developing a new interface which is really close to the linksys webinterface (the code behind the interface is not yet built). you can have a look at it here
my interface is fully validated xhtml 1.1 strict and css 2.0 and looks really good in firefox/mozilla, IE and Opera.
I couldn't test it in other browsers, but it should look almost the same in more exotic browsers like safari, camino and konqueror.

(Last edited by thefRont on 3 Aug 2005, 12:22)

Maybe it's irrelevant to most people, but my internet provider requires a hostname for giving me a lease.

I posted a hostname fix for my wl500g, but on my wrt54g (v4 fixed snapshot by ndb) it worked out of the box.

So I added a couple of lines to set the hostname in v0.72.
/www/openwrt/network/wan between line 23 & 24:

<label for="hostname">Hostname</label>
<div class="input_wrap">
<input type="text" name="hostname" id="hostname" value="$(get_wrt_value wan_hostname)" size="15" maxlength="15" />.
</div>
<br />

/www/openwrt/network/wan_set between line 7 & 8:

set_wrt_value "wan_hostname" $(post_var "hostname")

The discussion might have continued from here.