I've noticed that there is nothing in my /tmp/luci-modulecache
directory. Digging into it it looks like because both the expected uid
and mode of the files doesn't match, so for security reasons they're
long being loaded or saved by ccache.lua (from the luci-lib-core
package). I'm not sure how far back this has been broken but I it
appears to have been quite some time, possibly years?
I've included a patch which updates the checks to use the right newer
function name / structure name. It decreases page load times by about
10-15% on my bcm2708 (raspberrypi). I can create a ticket if you'd
prefer. The patch is against the luci-0.11 branch but should apply to
trunk as well.
Signed-off-by: Bryan Mayland <bmayland@leoninedev.com>
The nixio library can mistakenly build without shadow password support due to the
compile-time test failing.
Because the test for HAS_SHADOW in the nixio Makefile uses the default CC flags,
the test may attempt to cross-compile with different VFP abi than libc does and
will therefore not link. Passing CCFLAGS on the command line builds the test
correctly and will enable HAS_SHADOW if available.
The validity of authentication tokens was determined by the
mtime of respective authentication tokens on filesystem
stored in $sessionpath.
Talking about hardware without RTC or without a prior
connection to a time server, date/time usually around 1970 -
so is the mtime of the authentication token file in
$sessionpath.
When now configuring an internet connection via LuCI, the
system might fetch the current date/time (e.g. via ntp)
which invalidates the token, returns "403 Forbidden" and
kicks the user out of the interface.
This patch changes the authentication system to use time values
based on the uptime of the machine - rather than values based upon
gettimeofday() and {a|m}time values - and save them inside the token.
That way can always determine the difference between login
(last interaction respectively) and the current time, in-
dependant of the system clock jumping backwards/forwards.
Warning: This patch removes the clean() function and respective calls.
This means, invalid tokens will NOT be determined and removed from
filesystem automatically anymore.
Before, every HTTP-call caused a scan for invalid tokens,
which is quite expensive. Instead consider using a cron job
deleting all stalled files periodically.
Contributed by T-Labs, Deutsche Telekom Innovation Laboratories
Signed-off-by: Mirko Vogt <mirko@openwrt.org>
Hi,
The attached patch fixes the JSON generation when dealing with NaN (not
a number), this makes the JSON parsing in the web browser succeed
(before it would get a "nan" which is not a valid JS value)
Chris
The Chrome web browser revalidates every resource if no explicit Cache-Control or Expires HTTP/1.1 header is sent. This makes the page loads appear to take a long time on pages with a few external resources, adding 300-500ms
per item. This includes the XHR json responses that set page images, like wireless signal indicators and the like-- the images are revalidated on every XHR response. As an example, the Network -> Interfaces page generates 16
requests to the lucid http server:
Main HTML
cascade.css
xhr.js
tabbg.png
cbi.js
loading.gif
ethernet_disabled.png
reload.png
reset.gif
edit.gif
remove.gif
add.gif
bridge.png
vlan.png
wifi.png
iface_status
Of those, 14 should be pulled from cache but they are all valdiated. The lucid server returns the correct 304 (Not Modified) responses but it delays the apparent page load time because of the backlog it creates at the http
server.
I would suggest setting explicit cache control on all files returned by the lucid http directory dispatcher. The "Expires" header is reportedly more widely supported, however this relies on the clock on the OpenWrt? system
being accurate, which may not be the case. The "Cache-Control: max-age=" allows the server to set a timeout in seconds. I've included a patch that sets revalidate interval to 1 year, which is the value recommended by google.
Reference: http://code.google.com/speed/page-speed/docs/caching.html
Note this could create an issue if there are luci application which are generating files which change that are being served by the lucid http DirectoryPublisher?. I'm not sure if there is anyone doing that. If needed, this can
probably be created as an option to the DirectoryPublisher? config stanza for each vhost.
Finally, this only affects the Google Chrome browser, as both IE9 and Firefox seem to have their own revalidation interval in the absence of explicit cache control which may be based on the last modified time of the resource.
Even in Chrome, this change doesn't take effect until the item is re-served with a 200 HTTP response so Chrome's cache should be cleared after this patch is applied. The patch can be extended to include cache control on 304
responses, but I'd not worry about cluttering the code with it because the problem will solve itself once chrome redownloads the resource.
The commit adds a recursive parser for datatype expressions which allows nesting of validators,
this allows for complex expressions like "list(or(range(0,65535),'infinite'))" to allow a list of
values which are either integers between 0 and 65535 or the literal string "inifinite".
That change also deprecates combined datatypes like "ipaddr" ["or(ip4addr,ip6addr)"] or
"host" ["or(hostname,ip4addr,ip6addr)"]
For SimpleSection, use the section name (always "1") instead of the
section type in the CBI-like string used to identify the upload. This
allows upload fields to be placed in SimpleSections. The fix changes a
minimal number of lines, but does introduce some unnecessary confusion,
it may or may not be better than a more thorough/invasive fix.
Set the enctype for the form element in the simpleform view to be
multipart/form-data because the default
application/x-www-form-urlencoded does not support input files.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
In #274, I stated abstract namespace and autobound abstract namespace datagram UNIX domain sockets work perfectly with nixio. However, I may have jumped the gun on that conclusion. Turns out they work perfectly for only one
concurrent connection.
The problem is that when binding to an abstract address socket, which begins with a NULL byte, nixio strncpy's the name into the sockaddr_un structure, which effectively copies nothing. It then binds to an address of 180 NULLs,
which is completely legal, but obviously you run into problems when a second client tries to bind to the same address.
The rules are as follows ( http://linux.die.net/man/7/unix) for the names:
* If the name is blank, bind() should pass that the addrlen of sizeof(sa_family_t) and Linux will autobind a name that begins with null and is followed by 5 digits.
* If the first character of the name is non-null, the name is a pathname and is null-terminated. addrlen should be sizeof(sockaddr_un), but the length can also be the pathname len + sizeof(sa_family_t) as the value will be
null-terminated by the kernel unix socket driver
* If the first character is null, the address is abstract and the value should not be null-terminated and addrlen is pathname + sizeof(sa_family_t)
The attached patch fixes bind/connect/sendto by shortening the addrlen passed to be pathname len + sizeof(sa_family_t), which generates the correct socket names for all 3 cases above.
It also fixes the address returned by recvfrom, which currently returns a blank string for any abstract address socket (as they begin with a null).
From: Gabor Juhos <juhosg@openwrt.org>
Date: Mon, 5 Dec 2011 14:36:34 +0100
Subject: [PATCH] libs/sys: read model name from /tmp/sysinfo/model if present
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
As I've brought up on the mailing list thread "High latency caused by full tree creation", there is a large amount of delay per LuCI request which is spent building the node tree in createtree(). Most nodes created aren't
needed for the view presented to the user and only serve to consume memory and CPU time during a page load.
My idea is to provide an easy mechanism for index()ers to determine which needs to be created and what isn't. Due to the constraints of the standard LuCI web interface, this optimization needs to establish a few rules:
* The page requested must have its node created
* All parents of the page being requested must be created, so the children inherit the track
* All the top-level nodes "Status", "System", "Services", "Network" (and others added by extensions) must be created in order to have their top-level tabs in the UI
* All peers of second-level nodes need to be created as well for the same reason, to display their links on the subindexes
To make this easy to implement in each controller, the attached patch adds an "inreq" field to each created node to indicate if it lies on the request path. To satisfy the "top level node" requirement, we always
add the top level node, then check its inreq property if the top-level node is not "in request", then the controller can exit index() early.
When creating the node tree, every node stores a copy of its full path table. e.g. for node("admin.network.wireless"), node.path = { "admin", "network", "wireless" }
This value is not used anywhere, and likely may be from before the addition of the treecache lookup table? In any instance, I've searched high and low and see nothing ever referencing any node's path via the path member. It
eats a good chunk of memory though and as such I believe it should be removed.
I've tested every page in the admin-full module after removing it and all seem to function properly.
