This makes it more possible to build scons based applications
for openwrt.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31618 3c298f89-4303-0410-b956-a3cf2f4a3e73
Passes the document-root to the Lua handler by placing it in uhttpd.docroot.
It could alternatively be placed in env.DOCUMENT_ROOT which would more closely
resemble the CGI protocol; but would mean that it is not available at the time
when the handler-chunk is loaded but rather not until the handler is called,
without any code savings.
Signed-off-by: David Favro <openwrt@meta-dynamic.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31571 3c298f89-4303-0410-b956-a3cf2f4a3e73
My apologies, the 2nd of those patches had a syntax error -- that's what
I get for making a last-minute edit, even to the comments, without
testing! :-p
Here is the corrected patch.
-- David
From d259cff104d2084455476b82e92a3a27524f4263 Mon Sep 17 00:00:00 2001
From: David Favro <openwrt@meta-dynamic.com>
Date: Fri, 27 Apr 2012 14:17:52 -0400
Subject: [PATCH] uhttpd URL-codec enhancements.
* uh_urlencode() and uh_urldecode() now return an error condition for
buffer-overflow and malformed-encoding rather than normal return with corrupt
or truncated data. As HTTP request processing is currently implemented, this
causes a 404 HTTP status returned to the client, while 400 is more
appropriate.
* Exposed urlencode() to Lua.
* Lua's uhttpd.urlencode() and .urldecode() now raise an error condition for
buffer-overflow and malformed-encoding rather than normal return with
incorrect data.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31570 3c298f89-4303-0410-b956-a3cf2f4a3e73
* Fixed output-buffer-overflow bug in uh_urlencode() and uh_urldecode() [tested
input-buffer index against output-buffer length]. In reality, this would not
typically cause an overflow on decode, where the output string would be
expected to be shorter than the input string; and uh_urlencode() seems to have
been unreferenced in the source.
* Fixed bug: uh_urlencode() and uh_urldecode() both read one extra byte from the
input-string. While this could manifest in C code, the result was most
egregious when called from Lua, where it caused an extra null byte to be
embedded at the end of the output string.
* uh_urlencode() cleanup: removed redundant bitwise-and.
Signed-off-by: David Favro <openwrt@meta-dynamic.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31569 3c298f89-4303-0410-b956-a3cf2f4a3e73
[juhosg: export xt_layer7.h for all kernel versions]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31566 3c298f89-4303-0410-b956-a3cf2f4a3e73
The existing code is fairly broken. It assumes you're using Legacy IP, and
it assumes that the server is reachable via your default route. Via the
first default route in the 'route -n' output, in fact, regardless of metric.
Fix all those problems by using 'ip route get' to really find the *current*
route to the server, and install a host-specific route to match.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31565 3c298f89-4303-0410-b956-a3cf2f4a3e73
Fixed: GPIO typos and confirmed GPIO_BUTTON_RESET
Fixed: Lan & Wan reversed: swaped "eth0.2" with "eth0.1" by
removing a line(default is correct), and reversed the
Lan/wan layout LLLLW to WLLLL.
Added: image/Makefile now builds -factory.bin files. I am
unsure of the accepted way to change the makefile but
the name of the image needs to be 'linkn Kernel Image'
in order to be accepted by the OEM firmware.
Known issue: eth0 (internal switch i think has mac address:
00:11:22:33:44:55 but i think it should be same as
the lan).
Known issue: Pressing the reset button has no noticable effect,
i would expect the router to boot failsafe if being
pressed on boot, reboot if short press and reset all
to default if long press.
[juhosg: remove mtdlayout_W306R and use mtdlayout_4M instead]
Signed-off-by: David Pearce <david_18051985@hotmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31557 3c298f89-4303-0410-b956-a3cf2f4a3e73