i spent quite a while banging my head trying to understand why a luci
graph was not working, the XHR.poll() was failing on a given, specific URL.
turns out, it failed when the url ended like "whatever_adhoc"
luci XHR appends a '?_=0.15089513623292194', resulting in a url like
after a quick chat with jow, i found out it was uBlock getting in the
way; chromium with adBlockPlus gave the same problem.
i have both with defaults settings, namely, just use Easylist
see it for yourselves:
includes the expression
the "?" is not a regexp, it's a literal "?", but as i said XHR.poll
appends a '?' to the end of the url, completing the blocked expression
so this breaks, for example, luci Realtime Traffic graphs for the
interface "wlan0_adhoc", amongst others.
My suggestion for this bizarre coincidence of events, is simply to
change our lime separator to "-" instead of "_"
which, by the way, is more "in line" with upstream
automatic names for several wifi-ifaces are like wlan0, wlan0-1, wlan0-2
so it's better if we use wlan0-adhoc, wlan0-ap, etc
and for the vlanSeparator (which is currently '-') just use '_',
so complete interface name will be wlan0-adhoc_167 and such
(exactly the opposite of the current name, but at least to me it makes
more sense, and as a bonus this will not end up in a blocked url)
I noticed that the subdomain dev.libre-mesh.org runs with a self-signed
certificate, which is annoying because casual people browsing (and
security paranoid) won't accept to add an exception in order to read
more and will leave...
A free browser-accepted certificate can be obtained from StartSSL 
(for that specific domain, wildcards and extended verification certs are
not for free of course, but we there is no need for them).
This is Roger, from Barcelona, one of the maintainers of qMp . I
would like to ask you a couple of questions regarding VLANs in LiMe and
its compatibility with qMp.
In qMp we use 802.1q to create VLANs for BMX6 (e.g. eth0.12). This is
quite a mess for devices with a switch, because they typically block
traffic created on top of the switch's own VLANs (e.g. eth0.1.12).
Therefore, we are going to switch to 802.1ad in wired devices, the same
as in LiMe, from the next major release on. This will break backwards
compatibility with previous versions of qMp, but I believe it's a good
I wonder how LiMe manages VLANs in wireless devices. Do you also use
802.1ad there, or 802.1q? In order not to completely break backwards
compatibility, our idea is to keep using 802.1q on wireless devices.
What do you think it would be the best approach to allow LiMe/qMp
I have experienced problem changing 5GHz channel on our routers, do you think
it may be related to this ?
If so shoulb we enable by default that option at least on lime-build or lime-
---------- Forwarded Message ----------
Subject: Re: [OpenWrt-Devel] [patch] mac80211: Force Atheros drivers to
respect the user's regdomain settings by default
Date: Friday, April 03, 2015, 12:53:00 PM
From: bkil <bk.il.hU+ibLa_qUzy(a)gmail.com>
To: Jiri Pirko <jiri(a)resnulli.us>
CC: openwrt-devel <openwrt-devel(a)lists.openwrt.org>
Unfortunately, your patch will never be merged because most developers
are from the USA:
There's no use in resending or even debating it.
On Fri, Apr 3, 2015 at 12:09 PM, Jiri Pirko <jiri(a)resnulli.us> wrote:
> User's regdomain should know the correct setting. So change default for
> ath drivers to respect those.
> Signed-off-by: Jiri Pirko <jiri(a)resnulli.us>
> package/kernel/mac80211/Makefile | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/package/kernel/mac80211/Makefile
> index 11c8bcf..ab79330 100644
> --- a/package/kernel/mac80211/Makefile
> +++ b/package/kernel/mac80211/Makefile
> @@ -503,6 +503,7 @@ define KernelPackage/ath/config
> if PACKAGE_kmod-ath
> config ATH_USER_REGD
> bool "Force Atheros drivers to respect the user's regdomain
> + default y
> Atheros' idea of regulatory handling is that the EEPROM of
the card defines
> the regulatory limits and the user is only allowed to
restrict the settings
> openwrt-devel mailing list
openwrt-devel mailing list