Re: [OpenWrt-Devel] proto 'none' overwriting tun interfaces
> On Oct 13, 2015, at 4:50 AM, Roman Yeryomin wrote: > > On 13 October 2015 at 03:16, wrote: >> Hi all, >> >> I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and >> now a WD MyNet N750) for a number of years. I just recently encountered a >> problem with the OpenVPN tun interfaces are showing up without IP addresses >> after a reboot. I have the following in my /etc/config/network: >> >> config interface 'vpn_udp' >>option ifname 'tun0' >>option proto 'none' >> >> config interface 'vpn_tcp' >>option ifname 'tun1' >>option proto 'none' >> > > Why do you use proto=none? > Isn't it supposed to be used to actually disable/deconfigure that interface? I use proto=none because I don't want OpenWRT doing anything to the tun interfaces, which had been working for several years. There's a separate "enabled" option that can be used to toggle interfaces on/off. > > Regards, > Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: add an --address entry for each host
Hi Julián,
This functionality already (mostly) exists. My patch, which switched something
to use host-record instead, did not remove the existing functionality.
Specifically there's this configuration structure:
config 'domain'
option 'name' 'typhoon'
option 'ip' '192.168.1.140'
This is parsed with the following function in the current dnsmasq.init:
dhcp_domain_add() {
local cfg="$1"
local ip name names record
config_get names "$cfg" name "$2"
[ -n "$names" ] || return 0
config_get ip "$cfg" ip "$3"
[ -n "$ip" ] || return 0
for name in $names; do
record="${record:+$record/}$name"
done
xappend "--address=/$record/$ip"
}
Which ultimately adds, per the last line there:
--address=/typhoon/192.168.1.140
…to /tmp/etc/dnsmasq.conf.
Your patch seems to be nearly identical except you are adding the domain to the
end. I'm not sure I see the need to have a nearly identical function to append
the domain to the end. Wouldn't it be easier to define it as such:
config 'domain'
option 'name' 'typhoon.domain.name'
option 'ip' '192.168.1.140'
That would accomplish the same thing using existing functionality.
Regarding the wildcards, are you really looking to resolve, in keeping with the
above example:
*.typhoon.domain.name --> 192.168.1.140
So, essentially, everything possible, that ends in typhoon.domain.name to
192.168.1.140? Keep in mind that using --address does not get you the proper
reverse DNS records, only A records are created.
Adam
On Jul 16, 2013, at 4:47 PM, Julián Landerreche wrote:
> The goal of this change is to allow the dynamic creation
> of an "--address" option for each host in the local network.
>
> This opens up the possibility of fitting a common request among users
> (particularly web-developers). That request is:to resolve DNS
> request for wildcard subdomains for local domains.[2][3]
> This plays nice with serving virtual hosts from different machines
> on LAN, allowing to easily test on different devices . [3]
>
> [1] dnsmasq: use host-record instead of address
> https://dev.openwrt.org/changeset/36943
>
> [2] dnsmasq + wildcard + address
> https://www.google.com/search?q=dnsmasq+wildcard+address
>
> [3] Feature request: dynamically add an "address=/hostname/ip" line
> for each hostname (on generated /tmp/etc/dnsmasq.conf)
> https://dev.openwrt.org/ticket/12722
>
> Signed-off-by: Julián Landerreche
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 19
> +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 630c07d..8c43e48 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -408,6 +408,24 @@ dhcp_domain_add() {
> xappend "--address=/$record/$ip"
> }
>
> +dhcp_address_add() {
> + local cfg="$1"
> + local ip name names record
> +
> + config_get names "$cfg" name "$2"
> + [ -n "$names" ] || return 0
> +
> + config_get ip "$cfg" ip "$3"
> + [ -n "$ip" ] || return 0
> +
> + for name in $names; do
> + fqdn="$name${DOMAIN:+.$DOMAIN}"
> + record="${record:+$record/}$name/$fqdn"
> + done
> +
> + xappend "--address=/$record/$ip"
> +}
> +
> dhcp_srv_add() {
> local cfg="$1"
>
> @@ -512,6 +530,7 @@ start() {
> config_foreach dhcp_subscrid_add subscrid
> config_foreach dhcp_domain_add domain
> config_foreach dhcp_hostrecord_add hostrecord
> + config_foreach dhcp_address_add host
>
> # add own hostname
> [ $ADD_LOCAL_HOSTNAME -eq 1 ] && [ -n "$lanaddr" ] && {
> --
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] dnsmasq: use host-record instead of address
All,
Any thoughts and/or feedback on this?
Thanks,
Adam
On 6/5/2013 12:44 AM, Adam Gensler wrote:
Hi all,
TL;DR - using "--address" for individual host A records is broken, use
"--host-record" instead.
The following patch changes dnsmasq.init to build individual host records using "--host-record"
instead of "--address". Using "--address" in this context is incorrect. For example, the
current init script will create the following two entries in /var/etc/dnsmasq.conf:
address=/OpenWrt.lan/192.168.1.1
ptr-record=1.1.168.192.in-addr.arpa,OpenWrt.lan
At first glance this has the desired effect, "OpenWrt.lan" resolves to 192.168.1.1. However, what
it really says is "for anything that ends with "OpenWrt.lan," that I don't have a record for,
return 192.168.1.1". For example:
fakeaddress.OpenWrt.lan would return 192.168.1.1.
adsfasdfsdfsd.OpenWrt.lan would return 192.168.1.1.
That's wrong and it causes problems when using a real domain name, such as domain.com. Often it's
desirable to have "domain.com" resolve to an address so users can hit the http service at
http://domain.com. By using the existing "config domain" option, you would configure this
as follows:
config domain
option name 'domain.com'
option ip '192.168.1.100'
This would create these config items:
address=/domain.com/192.168.1.100
ptr-record=100.1.168.192.in-addr.arpa,domain.com
Now, as a result, anything that doesn't have its own, preexisting record, will
also resolve to 192.168.1.100. That's no good because things like Windows do
proxy requests by default for wpad.domain.com and instead of getting back an
NXDOMAIN, it gets 192.168.1.100 and goes hunting for a pac file that doesn't
exist.
The solution for this is to use "--host-record". This is actually a lot easier
to configure because dnsmasq will create the PTR records automatically, so there's no
need to manual calculate it like is done today. This means that IPv6 addresses can be
supported as well. The attached patch makes this adjustment and accomplishes the
following:
1. By default, the router's hostname is now added to the configuration using
"--host-record" instead of "--address". If there's a domain configured, the
default host-record entry looks like this:
host-record=OpenWrt.lan,OpenWrt,192.168.1.1
With this, now both "OpenWrt.lan" and "OpenWrt" will both resolve to 192.168.1.1. In the
reverse, 192.168.1.1 will resolve to only "OpenWrt.lan".
2. It introduces a new configuration structure to define additional host
records. For example:
config hostrecord
list name 'mail.domain.com'
list name 'www.domain.com'
list name 'domain.com'
list ip '192.168.1.100'
It uses lists here because dnsmasq can accept multiple hostnames and IP
addresses in a single host-record. This generates the following config:
host-record=mail.domain.com,www.domain.com,domain.com,192.168.1.100
All of those hostnames will resolve to 192.168.1.100 in the forward direction.
192.168.1.100 will resolve to "mail.domain.com" in the reverse.
3. It restructures "dhcp_domain_add()" to remove the manual PTR record calculation and
configuration. This only supported IPv4 and isn't the proper use of the "--address" option. Now it
will build a proper "--address" config that can support multiple domain names to a single IP
address as per the dnsmasq MAN page.
Note, the domain name is no longer automatically appended to the end of either "config
hostrecord" or "config domain" entries as was previously the case. To define a
specific fqdn, one needs to manually configure it as such. This makes the configuration more
consistent; only what's configured is what is generated for dnsmasq.
Sorry for the long email. I hope it all made sense. If not, please let me know.
Thanks,
Adam
Signed-off-by: Adam Gensler
---
Index: network/services/dnsmasq/files/dnsmasq.init
===
--- network/services/dnsmasq/files/dnsmasq.init (revision 36849)
+++ network/services/dnsmasq/files/dnsmasq.init (working copy)
@@ -393,7 +393,7 @@
dhcp_domain_add() {
local cfg="$1"
- local ip name names
+ local ip name names record
config_get names "$cfg" name "$2"
[ -n "$names" ] || return 0
@@ -401,22 +401,15 @@
config_get ip "$cfg" ip "$3"
[ -n "$ip" ] || return 0
- local oIFS="$IFS"; IFS="."; set -- $ip; IFS="$oIFS"
- local raddr="${4:+$4.$3.$2.$1.in-addr.arpa}"
-
for name in $names; do
-
[OpenWrt-Devel] [PATCH] [package] dnsmasq: use host-record instead of address
Hi all,
TL;DR - using "--address" for individual host A records is broken, use
"--host-record" instead.
The following patch changes dnsmasq.init to build individual host records using
"--host-record" instead of "--address". Using "--address" in this context is
incorrect. For example, the current init script will create the following two
entries in /var/etc/dnsmasq.conf:
address=/OpenWrt.lan/192.168.1.1
ptr-record=1.1.168.192.in-addr.arpa,OpenWrt.lan
At first glance this has the desired effect, "OpenWrt.lan" resolves to
192.168.1.1. However, what it really says is "for anything that ends with
"OpenWrt.lan," that I don't have a record for, return 192.168.1.1". For example:
fakeaddress.OpenWrt.lan would return 192.168.1.1.
adsfasdfsdfsd.OpenWrt.lan would return 192.168.1.1.
That's wrong and it causes problems when using a real domain name, such as
domain.com. Often it's desirable to have "domain.com" resolve to an address so
users can hit the http service at http://domain.com. By using the existing
"config domain" option, you would configure this as follows:
config domain
option name 'domain.com'
option ip '192.168.1.100'
This would create these config items:
address=/domain.com/192.168.1.100
ptr-record=100.1.168.192.in-addr.arpa,domain.com
Now, as a result, anything that doesn't have its own, preexisting record, will
also resolve to 192.168.1.100. That's no good because things like Windows do
proxy requests by default for wpad.domain.com and instead of getting back an
NXDOMAIN, it gets 192.168.1.100 and goes hunting for a pac file that doesn't
exist.
The solution for this is to use "--host-record". This is actually a lot easier
to configure because dnsmasq will create the PTR records automatically, so
there's no need to manual calculate it like is done today. This means that IPv6
addresses can be supported as well. The attached patch makes this adjustment
and accomplishes the following:
1. By default, the router's hostname is now added to the configuration using
"--host-record" instead of "--address". If there's a domain configured, the
default host-record entry looks like this:
host-record=OpenWrt.lan,OpenWrt,192.168.1.1
With this, now both "OpenWrt.lan" and "OpenWrt" will both resolve to
192.168.1.1. In the reverse, 192.168.1.1 will resolve to only "OpenWrt.lan".
2. It introduces a new configuration structure to define additional host
records. For example:
config hostrecord
list name 'mail.domain.com'
list name 'www.domain.com'
list name 'domain.com'
list ip '192.168.1.100'
It uses lists here because dnsmasq can accept multiple hostnames and IP
addresses in a single host-record. This generates the following config:
host-record=mail.domain.com,www.domain.com,domain.com,192.168.1.100
All of those hostnames will resolve to 192.168.1.100 in the forward direction.
192.168.1.100 will resolve to "mail.domain.com" in the reverse.
3. It restructures "dhcp_domain_add()" to remove the manual PTR record
calculation and configuration. This only supported IPv4 and isn't the proper
use of the "--address" option. Now it will build a proper "--address" config
that can support multiple domain names to a single IP address as per the
dnsmasq MAN page.
Note, the domain name is no longer automatically appended to the end of either
"config hostrecord" or "config domain" entries as was previously the case. To
define a specific fqdn, one needs to manually configure it as such. This makes
the configuration more consistent; only what's configured is what is generated
for dnsmasq.
Sorry for the long email. I hope it all made sense. If not, please let me know.
Thanks,
Adam
Signed-off-by: Adam Gensler
---
Index: network/services/dnsmasq/files/dnsmasq.init
===
--- network/services/dnsmasq/files/dnsmasq.init (revision 36849)
+++ network/services/dnsmasq/files/dnsmasq.init (working copy)
@@ -393,7 +393,7 @@
dhcp_domain_add() {
local cfg="$1"
- local ip name names
+ local ip name names record
config_get names "$cfg" name "$2"
[ -n "$names" ] || return 0
@@ -401,22 +401,15 @@
config_get ip "$cfg" ip "$3"
[ -n "$ip" ] || return 0
- local oIFS="$IFS"; IFS="."; set -- $ip; IFS="$oIFS"
- local raddr="${4:+$4.$3.$2.$1.in-addr.arpa}"
-
for name in $names; do
- local fqdn="$name"
+ if [ -z "$record" ]; then
+
Re: [OpenWrt-Devel] [PATCH] bump openvpn to 2.3.2
Ah, that explains it. Thanks for the clarification. Here's the updated patch.
Again I've compile tested both the -openssl and -polarssl packages and runtime
tested the -openssl one. I haven't tested the easy-rsa packages though.
Signed-off-by: Adam Gensler
---
Index: network/services/openvpn/patches/100-polarssl_update.patch
===
--- network/services/openvpn/patches/100-polarssl_update.patch (revision 36814)
+++ network/services/openvpn/patches/100-polarssl_update.patch (working copy)
@@ -1,60 +0,0 @@
a/src/openvpn/crypto_polarssl.h
-+++ b/src/openvpn/crypto_polarssl.h
-@@ -60,7 +60,7 @@ typedef md_context_t hmac_ctx_t;
- #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
-
- /** Cipher is in CFB mode */
--#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
-+#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
-
- /** Cipher should encrypt */
- #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
a/src/openvpn/ssl_polarssl.c
-+++ b/src/openvpn/ssl_polarssl.c
-@@ -65,23 +65,6 @@ tls_clear_error()
- {
- }
-
--static int default_ciphersuites[] =
--{
--SSL_EDH_RSA_AES_256_SHA,
--SSL_EDH_RSA_CAMELLIA_256_SHA,
--SSL_EDH_RSA_AES_128_SHA,
--SSL_EDH_RSA_CAMELLIA_128_SHA,
--SSL_EDH_RSA_DES_168_SHA,
--SSL_RSA_AES_256_SHA,
--SSL_RSA_CAMELLIA_256_SHA,
--SSL_RSA_AES_128_SHA,
--SSL_RSA_CAMELLIA_128_SHA,
--SSL_RSA_DES_168_SHA,
--SSL_RSA_RC4_128_SHA,
--SSL_RSA_RC4_128_MD5,
--0
--};
--
- void
- tls_ctx_server_new(struct tls_root_ctx *ctx)
- {
-@@ -515,11 +498,11 @@ void key_state_ssl_init(struct key_state
- ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
-
- ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
-- ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );
-+ ssl_set_session (ks_ssl->ctx, ks_ssl->ssn );
- if (ssl_ctx->allowed_ciphers)
- ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);
- else
-- ssl_set_ciphersuites (ks_ssl->ctx, default_ciphersuites);
-+ ssl_set_ciphersuites (ks_ssl->ctx, ssl_default_ciphersuites);
-
- /* Initialise authentication information */
- if (is_server)
-@@ -828,7 +811,7 @@ print_details (struct key_state_ssl * ks
- ssl_get_version (ks_ssl->ctx),
- ssl_get_ciphersuite(ks_ssl->ctx));
-
-- cert = ks_ssl->ctx->peer_cert;
-+ cert = ssl_get_peer_cert(ks_ssl->ctx);
- if (cert != NULL)
- {
- openvpn_snprintf (s2, sizeof (s2), ", " counter_format " bit RSA",
(counter_type) cert->rsa.len * 8);
Index: network/services/openvpn/Makefile
===
--- network/services/openvpn/Makefile (revision 36814)
+++ network/services/openvpn/Makefile (working copy)
@@ -9,7 +9,7 @@
PKG_NAME:=openvpn
-PKG_VERSION:=2.3.0
+PKG_VERSION:=2.3.2
PKG_RELEASE=1
PKG_SOURCE_URL:=http://swupdate.openvpn.net/community/releases
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bump openvpn to 2.3.1
Hi Gert, I've been keeping an eye on the openvpn project but I haven't seen 2.3.2 drop yet. Can we push forward with 2.3.1? Adam On May 30, 2013, at 5:47 AM, Gert Doering wrote: > Hi, > > On Wed, May 29, 2013 at 11:17:13PM -0400, Adam Gensler wrote: >> The following patch bumps OpenVPN to 2.3.1. Version 2.3.1 adds >> native support for PolarSSL 1.2+, so I dropped the existing >> "100-polarssl_update.patch" from OpenVPN. Compile tested both the >> -polarssl and -openssl versions on ar71xx. Runtime tested the >> -openssl version on a WNDR3800. It's working fine. Interestingly, >> the OpenVPN package Makefile doesn't include an MD5 hash? > > Thanks for that. Just as a side note, OpenVPN upstream is likely to > release 2.3.2 with a few extra bugfixes tomorrow, so you might want to go > right there... > > (As far as OpenWRT goes, the necessary patches for 2.3.1 and 2.3.2 should > be the same) > > gert, > speaking as OpenVPN maintainer > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany g...@greenie.muc.de > fax: +49-89-35655025g...@net.informatik.tu-muenchen.de > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] bump openvpn to 2.3.1
Hi all,
The following patch bumps OpenVPN to 2.3.1. Version 2.3.1 adds native support
for PolarSSL 1.2+, so I dropped the existing "100-polarssl_update.patch" from
OpenVPN. Compile tested both the -polarssl and -openssl versions on ar71xx.
Runtime tested the -openssl version on a WNDR3800. It's working fine.
Interestingly, the OpenVPN package Makefile doesn't include an MD5 hash?
Signed-off-by: Adam Gensler
---
Index: network/services/openvpn/patches/100-polarssl_update.patch
===
--- network/services/openvpn/patches/100-polarssl_update.patch (revision 36763)
+++ network/services/openvpn/patches/100-polarssl_update.patch (working copy)
@@ -1,60 +0,0 @@
a/src/openvpn/crypto_polarssl.h
-+++ b/src/openvpn/crypto_polarssl.h
-@@ -60,7 +60,7 @@ typedef md_context_t hmac_ctx_t;
- #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
-
- /** Cipher is in CFB mode */
--#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
-+#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
-
- /** Cipher should encrypt */
- #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
a/src/openvpn/ssl_polarssl.c
-+++ b/src/openvpn/ssl_polarssl.c
-@@ -65,23 +65,6 @@ tls_clear_error()
- {
- }
-
--static int default_ciphersuites[] =
--{
--SSL_EDH_RSA_AES_256_SHA,
--SSL_EDH_RSA_CAMELLIA_256_SHA,
--SSL_EDH_RSA_AES_128_SHA,
--SSL_EDH_RSA_CAMELLIA_128_SHA,
--SSL_EDH_RSA_DES_168_SHA,
--SSL_RSA_AES_256_SHA,
--SSL_RSA_CAMELLIA_256_SHA,
--SSL_RSA_AES_128_SHA,
--SSL_RSA_CAMELLIA_128_SHA,
--SSL_RSA_DES_168_SHA,
--SSL_RSA_RC4_128_SHA,
--SSL_RSA_RC4_128_MD5,
--0
--};
--
- void
- tls_ctx_server_new(struct tls_root_ctx *ctx)
- {
-@@ -515,11 +498,11 @@ void key_state_ssl_init(struct key_state
- ssl_set_rng (ks_ssl->ctx, ctr_drbg_random, rand_ctx_get());
-
- ALLOC_OBJ_CLEAR (ks_ssl->ssn, ssl_session);
-- ssl_set_session (ks_ssl->ctx, 0, 0, ks_ssl->ssn );
-+ ssl_set_session (ks_ssl->ctx, ks_ssl->ssn );
- if (ssl_ctx->allowed_ciphers)
- ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);
- else
-- ssl_set_ciphersuites (ks_ssl->ctx, default_ciphersuites);
-+ ssl_set_ciphersuites (ks_ssl->ctx, ssl_default_ciphersuites);
-
- /* Initialise authentication information */
- if (is_server)
-@@ -828,7 +811,7 @@ print_details (struct key_state_ssl * ks
- ssl_get_version (ks_ssl->ctx),
- ssl_get_ciphersuite(ks_ssl->ctx));
-
-- cert = ks_ssl->ctx->peer_cert;
-+ cert = ssl_get_peer_cert(ks_ssl->ctx);
- if (cert != NULL)
- {
- openvpn_snprintf (s2, sizeof (s2), ", " counter_format " bit RSA",
(counter_type) cert->rsa.len * 8);
Index: network/services/openvpn/Makefile
===
--- network/services/openvpn/Makefile (revision 36763)
+++ network/services/openvpn/Makefile (working copy)
@@ -9,7 +9,7 @@
PKG_NAME:=openvpn
-PKG_VERSION:=2.3.0
+PKG_VERSION:=2.3.1
PKG_RELEASE=1
PKG_SOURCE_URL:=http://swupdate.openvpn.net/community/releases
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] unbound bump to 1.4.20 and add uci support
Hello, That is a good point, I can adjust the Makefile to not install the example config. I have a question, how did you handle root.key? On my device, a Netgear WNDR3800, the clock is not saved between reboots. If the image is freshly installed and root.key hasn't been populated, unbound sometimes fails to update root.key if the NTP sync has not happened yet. Have you encountered this? Adam On May 14, 2013, at 4:59 AM, Martin Strbačka wrote: > Hello, > > We just made the same thing (patches for uci support) in our company and I > wanted to send our patches. At a first look, it looks almost the same as our > approach. Just one thing - maybe you should remove the unbound.conf.example > file. OpenWRT wants to be very tiny, so there is no place for man pages or > even example configs. And if we have uci support, than the standard conf file > is almost useless, at least from my point of view. > > With regards, > Martin Strbacka > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] unbound bump to 1.4.20 and add uci support
Hi Stepan,
Thanks for the feedback. See my comments inline with [adam]:
On May 14, 2013, at 8:00 AM, Stepan Henek wrote:
> Hello Adam,
>
> we were implementing the same thing as you were (ucifying unbound).
> We put less uci attributes in our config files, so in this way our version is
> more advanced.
[adam] Any chance I could see the version you put together? I struggled with
the best way to handle certain aspects of the config. Perhaps you have done it
a better way?
>
> But there are also some things which you might want to consider:
>
> 1) reload() function is missing in your init script
> I thing that calling stop() and start() functions flushes the cache of the
> server which is something what you don't want when you want just reload the
> configuration (e.g. when you are adding a zone).
> We used something like this:
> reload() {
>
> mkdir -p $(dirname "$CONFIGFILE")
>
> init_unbound
>
> local pidfile
> config_get pidfile server pidfile
>
> if [ -f "$pidfile" ] ; then
> kill -HUP $(cat "$pidfile")
> fi
> }
[adam] I tried this and ran into two problems:
1. I'm running unbound as a non-root user. So in this regard, reloading unbound
fails because the "unbound" user is not privileged to open ports, etc.
2. Using the "-c /path/to/config" option doesn't seem to be compatible with
-HUP signal. When I sent -HUP to unbound it complained that it couldn't find
/etc/unbound/unbound.conf, which is not the config I was using. Again, this may
be because unbound drops privileges.
>
> 2) You are using just a single "include" parameter
> > add_param "$cfg" "include"
> I thing It would be better to include more than a single config path using
> e.g.
> So options such as:
> > config unbound server
> >list include_path "/etc/unbound/zone1.conf"
> >list include_path "/etc/unbound/zone2.conf"
> Are translated to
> > include: "/etc/unbound/zone1.conf"
> > include: "/etc/unbound/zone2.conf"
[adam] I didn't get the impression from the unbound.conf man page that more
than one include statement was allowed. Perhaps that was just an oversight with
how I read it. This is a trivial change.
>
> Our goal is to have ucified unbound in the mainstream, so we could try to
> push it as well.
>
> Cheers,
> Stepan
>
> > Has anyone had a chance to look at this patch? If adjustments are needed
> > please let me know and I'll work on getting them in.
> >
> > Thanks!
> > Adam
> >
> >
> > On May 6, 2013, at 10:44 PM, Adam Gensler
> > wrote:
> >
> > > The following patch does these things:
> > >
> > > 1. bumps unbound to version 1.4.20.
> > >
> > > 2. adds uci support via /etc/config/unbound. The entirety of unbound.conf
> > > has been implemented here.
> > >
> > > 3. removes the existing patch which applied a memory optimized config to
> > > /etc/unbound/unbound.conf. This has been migrated to /etc/config/unbound
> > > as "option lowmem '1'" under "config server". This is the default.
> > > Disabling "lowmem" opens up the relevant parameters for individual
> > > tuning, if desired.
> > >
> > > 4. The other portions of the existing /etc/unbound/unbound.conf have been
> > > migrated to the default /etc/config/unbound, yielding the same operation.
> > >
> > > 5. The old /etc/unbound/unbound.conf has been renamed to
> > > /etc/unbound/unbound.conf.example to avoid confusion.
> > >
> > > This is my first attempt at a uci configuration port. Any feedback and/or
> > > suggestions are greatly appreciated.
> > >
> > > Signed-off-by: Adam Gensler
> > > ---
> > >
> > >
> > > Index: net/unbound/files/unbound.init
> > > ===
> > > --- net/unbound/files/unbound.init(revision 36569)
> > > +++ net/unbound/files/unbound.init(working copy)
> > > @@ -1,14 +1,355 @@
> > > #!/bin/sh /etc/rc.common
> > > -#Copyright (C) 2010 Ondrej Caletka
> > > -START=61
> > > +# Copyright (C) 2007-2013 OpenWrt.org
> > >
> > > -start () {
> > > -unbound
> > > +START=60
> > > +
> > > +SERVICE_USE_PID=1
> > > +
> > > +CONFIGFILE="/var/etc/unbound.conf"
> > > +
> > > +writec
Re: [OpenWrt-Devel] [PATCH] unbound bump to 1.4.20 and add uci support
Has anyone had a chance to look at this patch? If adjustments are needed please
let me know and I'll work on getting them in.
Thanks!
Adam
On May 6, 2013, at 10:44 PM, Adam Gensler wrote:
> The following patch does these things:
>
> 1. bumps unbound to version 1.4.20.
>
> 2. adds uci support via /etc/config/unbound. The entirety of unbound.conf has
> been implemented here.
>
> 3. removes the existing patch which applied a memory optimized config to
> /etc/unbound/unbound.conf. This has been migrated to /etc/config/unbound as
> "option lowmem '1'" under "config server". This is the default. Disabling
> "lowmem" opens up the relevant parameters for individual tuning, if desired.
>
> 4. The other portions of the existing /etc/unbound/unbound.conf have been
> migrated to the default /etc/config/unbound, yielding the same operation.
>
> 5. The old /etc/unbound/unbound.conf has been renamed to
> /etc/unbound/unbound.conf.example to avoid confusion.
>
> This is my first attempt at a uci configuration port. Any feedback and/or
> suggestions are greatly appreciated.
>
> Signed-off-by: Adam Gensler
> ---
>
>
> Index: net/unbound/files/unbound.init
> ===
> --- net/unbound/files/unbound.init(revision 36569)
> +++ net/unbound/files/unbound.init(working copy)
> @@ -1,14 +1,355 @@
> #!/bin/sh /etc/rc.common
> -#Copyright (C) 2010 Ondrej Caletka
> -START=61
> +# Copyright (C) 2007-2013 OpenWrt.org
>
> -start () {
> - unbound
> +START=60
> +
> +SERVICE_USE_PID=1
> +
> +CONFIGFILE="/var/etc/unbound.conf"
> +
> +writeconf() {
> + local opt="$1"
> + local val="$2"
> + local extra="$3"
> +
> + # wrap values with spaces or / in quotes
> + if [ `echo $val | grep -c "[.[:space:]/]"` -gt 0 ]; then
> + val="\"$val\""
> + fi
> +
> + if [ -z "$val" ]; then
> + echo "${opt}: ${val} ${extra}" >> $CONFIGFILE
> + else
> + echo " ${opt}: ${val} ${extra}" >> $CONFIGFILE
> + fi
> }
>
> -stop () {
> - PIDFILE='/var/run/unbound.pid'
> - if [ -f $PIDFILE ] ; then
> - kill $(cat $PIDFILE)
> +add_bool() {
> + local section="$1"
> + local option="$2"
> +
> + if [ -z "$3" ]; then
> + local config="$2"
> + else
> + local config="$3"
> fi
> +
> + config_get value "$section" "$option"
> + [ -z "$value" ] && return 0
> +
> + if [ "$value" -eq 0 ]; then
> + value="no"
> + elif [ "$value" -eq 1 ]; then
> + value="yes"
> + else
> + return 0
> + fi
> +
> + writeconf "$config" "$value"
> }
> +
> +add_param() {
> + local section="$1"
> + local option="$2"
> +
> + if [ -z "$3" ]; then
> + local config="$2"
> + else
> + local config="$3"
> + fi
> +
> + config_get value "$section" "$option"
> + [ -z "$value" ] && return 0
> +
> + writeconf "$config" "$value"
> +}
> +
> +add_server() {
> + local cfg="$1"
> +
> + add_param "$cfg" "include"
> +
> + writeconf "server"
> + add_param "$cfg" "verbosity"
> + add_param "$cfg" "statistics_interval" "statistics-interval"
> + add_bool "$cfg" "statistics_cumulative" "statistics-cumulative"
> + add_bool "$cfg" "extended_statistics" "extended-statistics"
> + add_param "$cfg" "port"
> + config_list_foreach "$cfg" "interface" add_list "interface"
> + add_param "$cfg" "interface_automatic" "interface-automatic"
> + config_list_foreach "$cfg" "outgoing_interface" add_list
> "outgoing-interface"
> + add_param "$cfg" "outgoing_port_permit" "outgoing-port-permit"
> + add_param "$cfg" "outgoing_port_avoid" "outgoing-port-avoid"
> + add_param "$cfg" "edns_buffer_size" "edns-buffer-size"
> +
Re: [OpenWrt-Devel] Booting x86 from SATA drive
Hi Hanno, Last time I checked the x86 target does not include the drivers for SATA ports. The only way I've been able to get it work is by building a custom kernel. 1. make kernel_menuconfig 2. Device Drivers --> Serial ATA and Parallel ATA drivers --> AHCI SATA Support Press "y" on both the "Serial ATA and Parallel ATA drivers" and "AHCI SATA Support" then exit and save and rebuilt the image. Adam On May 13, 2013, at 7:41 AM, Hanno Schupp wrote: > Hi, > > I have a fit-pc2-i http://www.fit-pc.com/web/fit-pc/fit-pc2-i/ with a ADATA > 32GB SSD w/ a SATA interface drive built in. Kamikaze boots fine and from > scratch, but neither backfire nor attitude adjustment. For them the boot > process stops while "waiting for root device /dev/sda2 in both cases. > I assume I need to include some additional modules in my firmware, but am > unsure which ones and at which level: > Can I compile kernel modules kmod* into the image and expect it to work? I > thought that kmod models were stored in rootfs and since the system fails to > boot before it can even find rootfs. If my assumption is correct I have to > compile support directly into the kernel using make kernel_menuconfig > Is that correct? And if so, what do i have to include when configuring make > kernel_menuconfig and/or make menuconfig to get SATA drive to be recognised > as initial and only rootfs? > I consulted the extroot page in wiki, but I understand that approach relies > on an initial rootfs in the device's flash drive to be present, which then > writes its /overlay or / to the external storage; this is not what happens > with this fit-pc2-I, which has no flash drive but but only he SATA drive. > > Any help and pointers on how to build such a x86 image is appreciated. > > Thanks > > Hanno Schupp > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] unbound bump to 1.4.20 and add uci support
The following patch does these things:
1. bumps unbound to version 1.4.20.
2. adds uci support via /etc/config/unbound. The entirety of unbound.conf has
been implemented here.
3. removes the existing patch which applied a memory optimized config to
/etc/unbound/unbound.conf. This has been migrated to /etc/config/unbound as
"option lowmem '1'" under "config server". This is the default. Disabling
"lowmem" opens up the relevant parameters for individual tuning, if desired.
4. The other portions of the existing /etc/unbound/unbound.conf have been
migrated to the default /etc/config/unbound, yielding the same operation.
5. The old /etc/unbound/unbound.conf has been renamed to
/etc/unbound/unbound.conf.example to avoid confusion.
This is my first attempt at a uci configuration port. Any feedback and/or
suggestions are greatly appreciated.
Signed-off-by: Adam Gensler
---
Index: net/unbound/files/unbound.init
===
--- net/unbound/files/unbound.init (revision 36569)
+++ net/unbound/files/unbound.init (working copy)
@@ -1,14 +1,355 @@
#!/bin/sh /etc/rc.common
-#Copyright (C) 2010 Ondrej Caletka
-START=61
+# Copyright (C) 2007-2013 OpenWrt.org
-start () {
- unbound
+START=60
+
+SERVICE_USE_PID=1
+
+CONFIGFILE="/var/etc/unbound.conf"
+
+writeconf() {
+ local opt="$1"
+ local val="$2"
+ local extra="$3"
+
+ # wrap values with spaces or / in quotes
+ if [ `echo $val | grep -c "[.[:space:]/]"` -gt 0 ]; then
+ val="\"$val\""
+ fi
+
+ if [ -z "$val" ]; then
+ echo "${opt}: ${val} ${extra}" >> $CONFIGFILE
+ else
+ echo " ${opt}: ${val} ${extra}" >> $CONFIGFILE
+ fi
}
-stop () {
- PIDFILE='/var/run/unbound.pid'
- if [ -f $PIDFILE ] ; then
- kill $(cat $PIDFILE)
+add_bool() {
+ local section="$1"
+ local option="$2"
+
+ if [ -z "$3" ]; then
+ local config="$2"
+ else
+ local config="$3"
fi
+
+ config_get value "$section" "$option"
+ [ -z "$value" ] && return 0
+
+ if [ "$value" -eq 0 ]; then
+ value="no"
+ elif [ "$value" -eq 1 ]; then
+ value="yes"
+ else
+ return 0
+ fi
+
+ writeconf "$config" "$value"
}
+
+add_param() {
+ local section="$1"
+ local option="$2"
+
+ if [ -z "$3" ]; then
+ local config="$2"
+ else
+ local config="$3"
+ fi
+
+ config_get value "$section" "$option"
+ [ -z "$value" ] && return 0
+
+ writeconf "$config" "$value"
+}
+
+add_server() {
+ local cfg="$1"
+
+ add_param "$cfg" "include"
+
+ writeconf "server"
+ add_param "$cfg" "verbosity"
+ add_param "$cfg" "statistics_interval" "statistics-interval"
+ add_bool "$cfg" "statistics_cumulative" "statistics-cumulative"
+ add_bool "$cfg" "extended_statistics" "extended-statistics"
+ add_param "$cfg" "port"
+ config_list_foreach "$cfg" "interface" add_list "interface"
+ add_param "$cfg" "interface_automatic" "interface-automatic"
+ config_list_foreach "$cfg" "outgoing_interface" add_list
"outgoing-interface"
+ add_param "$cfg" "outgoing_port_permit" "outgoing-port-permit"
+ add_param "$cfg" "outgoing_port_avoid" "outgoing-port-avoid"
+ add_param "$cfg" "edns_buffer_size" "edns-buffer-size"
+ add_param "$cfg" "jostle_timeout" "jostle-timeout"
+ add_param "$cfg" "so_rcvbuf" "so-rcvbuf"
+ add_param "$cfg" "so_sndbuf" "so-sndbuf"
+ add_param "$cfg" "cache_min_ttl" "cache-min-ttl"
+ add_param "$cfg" "cache_max_ttl" "cache-max-ttl"
+ add_param "$cfg" "infra_host_ttl" "infra-host-ttl"
+ add_bool "$cfg" "do_ip4" "do-ip4"
+ add_bool "$cfg" "do_ip6" "do-ip6"
+ add_bool "$cfg" "do_udp&
[OpenWrt-Devel] [PATCH] add uci support for "proxy-dnssec" in dnsmasq
This patch simply adds support for the "--proxy-dnssec" command in dnsmasq into the init file so it can be used with /etc/config/dhcp. Signed-off-by: Adam Gensler --- Index: network/services/dnsmasq/files/dnsmasq.init === --- network/services/dnsmasq/files/dnsmasq.init (revision 36569) +++ network/services/dnsmasq/files/dnsmasq.init (working copy) @@ -96,6 +96,7 @@ append_bool "$cfg" enable_tftp "--enable-tftp" append_bool "$cfg" nonwildcard "--bind-interfaces" append_bool "$cfg" fqdn "--dhcp-fqdn" + append_bool "$cfg" proxydnssec "--proxy-dnssec" append_parm "$cfg" dhcpscript "--dhcp-script" append_parm "$cfg" cachesize "--cache-size" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] fw3 support for ipset?
I noticed the following message when restarting the fw on trunk: Warning: Unable to locate ipset utility, disabling ipset support So, I decided to poke around the fw3 source code on gitweb here: http://nbd.name/gitweb.cgi?p=firewall3.git;a=summary I see there's an ipsets.c and ipsets.h in here. Unfortunately the wiki doesn't have any content on the ipsets support here. I've been using ipsets in firewall.user for a while now, it would be nice to get the same support natively in /etc/config/firewall. Is there an example of how to create and populate an ipset some place using /etc/config/firewall? Once the set is created, can it be referenced in other firewall rules? Thanks! adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Newer AA builds corrupt on WNDR3800
Hi all, I've been building WNDR3800 builds using Attitude Adjustment for a while now. Unfortunately, it seems something has gone awry and I can't build a usable image any more. After flashing, the WNDR3800 reboots but fails to load with the following error (taken from the console via TTL connection). This was from the most current AA svn pull as of today: Verifying Checksum ... OK ### SQUASHFS loading 'image/uImage' to 0x8080 ERROR: LzmaDecode.c, 547 lzma_fs returned unexpected result 0x1 SQUASHFS error: squashfs_readdir: read_block ### SQUASHFS LOAD ERROR<0> for image! Then, it sits in recovery mode. I'm building in Ubuntu 32 bit 10.04.4 server. My build process is as follows: 1. Copy the following into a fresh .config file: # target CONFIG_TARGET_ar71xx=y CONFIG_TARGET_ar71xx_generic=y CONFIG_TARGET_ar71xx_generic_WNDR3700=y CONFIG_TARGET_ROOTFS_JFFS2=n # ddns support CONFIG_PACKAGE_ddns-scripts=y # file system stuff CONFIG_PACKAGE_fdisk=y CONFIG_PACKAGE_e2fsprogs=y CONFIG_PACKAGE_tune2fs=y CONFIG_PACKAGE_block-mount=y CONFIG_PACKAGE_kmod-fs-vfat=y CONFIG_PACKAGE_kmod-nls-base=y CONFIG_PACKAGE_kmod-nls-cp437=y CONFIG_PACKAGE_kmod-nls-iso8859-1=y # firewall support / tools CONFIG_PACKAGE_conntrack-tools=y CONFIG_PACKAGE_iptables-mod-ipopt=y CONFIG_PACKAGE_iptables-mod-nat-extra=y CONFIG_PACKAGE_kmod-ipt-nathelper-extra=y # ipv6 support CONFIG_PACKAGE_kmod-ipv6=y CONFIG_PACKAGE_6in4=y CONFIG_PACKAGE_ip6tables=y CONFIG_PACKAGE_radvd=y # luci CONFIG_PACKAGE_luci-ssl=y CONFIG_PACKAGE_luci-app-ddns=y CONFIG_PACKAGE_luci-app-radvd=y CONFIG_PACKAGE_luci-app-upnp=y CONFIG_PACKAGE_luci-proto-6x4=y # other stuff CONFIG_PACKAGE_ethtool=y CONFIG_PACKAGE_netcat=y CONFIG_PACKAGE_tc=y CONFIG_PACKAGE_tcpdump=y CONFIG_PACKAGE_openvpn=y # upnp support CONFIG_PACKAGE_miniupnpd=y 2. Then I run, "make defconfig" which builds out the rest of the .config file. 3. Then I run "make" which compiles the image. When I'm done, I'm left with these two files: adam@ubuntu:~/openwrt/attitude_adjustment$ ls -l bin/ar71xx/*3800* -rw-r--r-- 1 adam adam 4915333 2012-11-17 22:42 bin/ar71xx/openwrt-ar71xx-generic-wndr3800-squashfs-factory.img -rw-r--r-- 1 adam adam 4915204 2012-11-17 22:42 bin/ar71xx/openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin The image is only 4.9meg so it should fit comfortably inside the 16megs of flash on the WNDR3800. However, after flashing it, I get the above mentioned error message. If I build an image with just the following .config, it works: CONFIG_TARGET_ar71xx=y CONFIG_TARGET_ar71xx_generic=y CONFIG_TARGET_ar71xx_generic_WNDR3700=y CONFIG_TARGET_ROOTFS_JFFS2=n make defconfig make Of course, the image is quite a bit smaller. But I don't think that should be a problem as I tried arokh's image, which is 7+ meg and it boots normally. I've tried this procedure on two completely different build-servers, one Ubuntu 10.04.4 (freshly installed) and another 12.10. I have the same problem on images from both. I don't understand why building in several packages would cause it not to boot. The problem happens with both factory.imgs loaded from tftp and also sysupgrade images loaded from within OpenWRT. Any ideas and/or suggestions would be greatly appreciated. Thanks in advance, Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Understanding LEDs on WNDR3800
Mark, Thanks for the reply, I appreciate the clarification. May I ask how you're turning the WAN LED to green in your setup? What mechanism do you use to do it? I've been unsuccesful thus far but perhaps I'm not trying the proper set of adjustments. More specifically can you share your /etc/config/network and also /etc/config/system? Adam On 10/2/12 10:36 AM, Mark Mentovai wrote: Adam Gensler wrote: I recently acquired a Netgear WNDR3800. To date I've been playing exclusively on an alix 2D13 platform so I have a few new things to learn. In any case, I've been tinkering with the LEDs and I'm having some trouble getting my head around a few things. Specifically: 1. How does one accurately control the WAN LED? /etc/config/network has this: […] Supposedly this controls the orange WAN LED. However, setting "option led 0" does not turn the LED off as indicated. It stops blinking but it doesn't turn off. How do I turn off the orange LED? I don’t know if you can, then. 2. Why is the orange component of the WAN LED configured/controlled via /etc/config/network yet the wan:green LED is controlled via /etc/config/system? Is there some reason I'm not immediately understanding? Is it because the orange LED for WAN isn't listed under /sys/class/leds? This would lead me to believe that this is controlled via some different mechanism than the green LED on the hardware. The original firmware for this router doesn’t use green/amber on the WAN LED to indicate the same thing that it uses green/amber for on the LAN switch port LEDs. For the LAN switch ports, the LED colors indicate link speed. This is easily handled in hardware. For the WAN port, the LED color indicates whether an Internet connection has been established. I don’t recall whether the original firmware was probing some site or whether it was just deciding it had connectivity when it obtained a DHCP lease, but regardless of the mechanism it was using to make this determination, it’s something that’s best handled in software. Accordingly, for the WAN LED, the hardware was left to handle what it does best (turning the LED on for link presence, and blinking it for activity), and software handled the color. (In my own builds, I mimic something close to the original firmware’s meaning for the WAN LED by turning the LED green when a DHCP lease is obtained or renewed, and amber when lost, via a hotplug action launched from /lib/netifd/dhcp.script. For cases where WAN isn’t configured by DHCP, I set the LED color based on the link speed when a link is detected by ifplugd.) 3. Along with #2, why is the green LED pre-configured in /etc/config/system by /etc/uci-defaults/leds on first boot? The preconfiguration doesn't actually do anything. What is this for? Am I missing something? You’re correct, I don’t believe it actually does anything (and I’ve removed it from my own builds). All it’s doing is setting the WAN LED to “not green” (thus amber), but I think that’s the default. Having this in /etc/config/system does provide a template for you to modify if you want to change the behavior of the LED, although given the hardware-software-hybrid nature of that LED, it’s less useful than for LEDs strictly under software control. 4. The wifi adapters, ath9k-phy0 and ath9k-phy1 apparently default to the respective "phy[0|1]tpt" trigger. This also isn't in /etc/config/system. It seems to happen elsewhere, but I haven't found the place that controls this. How is this accomplished? Is this some ath9k driver default? It is. This happens in compat-wireless/drivers/net/wireless/ath/ath9k/init.c. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Understanding LEDs on WNDR3800
Hi all, I recently acquired a Netgear WNDR3800. To date I've been playing exclusively on an alix 2D13 platform so I have a few new things to learn. In any case, I've been tinkering with the LEDs and I'm having some trouble getting my head around a few things. Specifically: 1. How does one accurately control the WAN LED? /etc/config/network has this: config switch_port # Port 5 controls the configuration of the WAN LED and the # section does not correspond to a real switch port. # # To toggle the use of green or orange LEDs for the WAN port, # see the LED setting for wndr3700:green:wan in /etc/config/system. # # See the key above for switch port 1 for the meaning of the # 'led' setting below. option devicertl8366s option port5 option led2 Supposedly this controls the orange WAN LED. However, setting "option led 0" does not turn the LED off as indicated. It stops blinking but it doesn't turn off. How do I turn off the orange LED? 2. Why is the orange component of the WAN LED configured/controlled via /etc/config/network yet the wan:green LED is controlled via /etc/config/system? Is there some reason I'm not immediately understanding? Is it because the orange LED for WAN isn't listed under /sys/class/leds? This would lead me to believe that this is controlled via some different mechanism than the green LED on the hardware. config led 'led_wan' option name 'WAN LED (green)' option sysfs 'wndr3700:green:wan' option default '0' 3. Along with #2, why is the green LED pre-configured in /etc/config/system by /etc/uci-defaults/leds on first boot? The preconfiguration doesn't actually do anything. What is this for? Am I missing something? 4. The wifi adapters, ath9k-phy0 and ath9k-phy1 apparently default to the respective "phy[0|1]tpt" trigger. This also isn't in /etc/config/system. It seems to happen elsewhere, but I haven't found the place that controls this. How is this accomplished? Is this some ath9k driver default? Any input / insight would be most helpful. Thanks in advance, Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Improve generated ext4 images
Is that really a concern these days? Compact flash cards are extremely affordable now. I've had the same 1gig compact flash card in my digital camera for over 6 years. It has taken well more than 20,000 pictures and still works perfectly. Maybe in the past this was something to be concerned with. I don't think such precautions are still required. Resiliency against sudden power outages and/or other file system weirdness should far outweigh preserving a ~$15 flash card. My $0.02. On 8/29/12 1:01 AM, Imre Kaloz wrote: On Tue, 28 Aug 2012 23:05:46 +0200, Michael Heimpold wrote: Currently none of valuable ext4 features are used when ext4 image generation is selected, most notably the journaling function is missing. This patch enables the journaling feature and optimizes the directories in the created filesystem afterwards. NAK. Journaling is disabled on purpose, as it wears out flash based devices faster. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH} fix hard reset of alix/soekris hardware under heavy NIC load
On 8/15/12 9:12 AM, Michael Markstaller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09.08.2012 02:38, Adam Gensler wrote: The following patch corrects a hard reset that occurs on alix and soekris net5501 hardware. Specifically, this is an issue with the via rhine NIC driver. Under periods of extreme load, the via rhine driver can cause a reset of the entire system. When this happens no output is seen on the console, the device simply reboots. This was reported in the following ticket: Consistent crash on Soekris NET5501 https://dev.openwrt.org/ticket/11882 I was able to reproduce the problem locally with numerous alix 2d13 platforms. Under heavy 64 byte frame size load from a Smartbits traffic generator, the alix hardware will hard reset in under 5 minutes. The same hardware, under the same load, on FreeBSD 9.0 does not reset. Getting back to the core (this is also reproducable under Debian back to 2.6.32): Your patch and the changes in kernel 3.5 which they're based on fix the reboot but it's still a heavy DoS against the Box (Alix). Smashing 70 mbit with 64 byte packets against using pktgen makes the loadavg go above 50 and the system unresponsive while "under attack".. Better than reboot but not good.. Any hints where to proceed to fix this? I'm not sure that's entirely fixable. Can you show me any hardware that doesn't go unresponsive if you smash it with a ton of traffic? The alix hardware isn't super fast. I would expect you'd see the same thing on a lot of boards that OpenWRT runs on. best regards Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAroD0ACgkQaWRHV2kMuAK0vQCeNpgg6QSU3zNWS5uHzzw4hpHI ooQAnRs6t92f5NgEonlc4pq+ohduDN8y =e0w8 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH} fix hard reset of alix/soekris hardware under heavy NIC load
I did go way back in trunk to try to find a working version and ended up back on 2.6.39.4 and it crashed there too. So I assume it's in older versions too. On 8/10/12 3:35 PM, Michael Markstaller wrote: On 09.08.2012 02:38, Adam Gensler wrote: The following patch corrects a hard reset that occurs on alix and soekris net5501 hardware. Specifically, this is an issue with the via rhine NIC driver. Under periods of extreme load, the via rhine driver can cause a reset of the entire system. When this happens no output is seen on the console, the device simply reboots. This was reported in the following ticket: Consistent crash on Soekris NET5501 https://dev.openwrt.org/ticket/11882 Sorry for a little OT: Does this -from your experience- also affect older Kernels outside OpenWRT with the via-rhine like 2.6.32/2.6.38 ? Michael P.S.: Thanks, after reading this, I got a really big déjà vu! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH} fix hard reset of alix/soekris hardware under heavy NIC load
This is already in the upstream 3.5 kernel. I just pulled the changes back into OpenWRT's 3.3.8. 3.3.8 is EOL upstream. Once OpenWRT upgrades to 3.5 this patch isn't required anymore. Adam On 8/10/12 4:04 AM, Ferry Huberts wrote: Hi Jo, Are you upstreaming this patch into the linux kernel stable branches? Can you please offer it to Greg? On 09-08-12 11:42, Jo-Philipp Wich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Applied in r33072 - thank you. Next time please ensure that your patch applies with -p1, not -p0. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAjhfYACgkQdputYINPTPPtyQCcCzSzAA1WR1bFQebH7fy8/sL+ uSUAmwWpg0ZOeWBo3iAIGOevufq2nisp =fC/H -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH} fix hard reset of alix/soekris hardware under heavy NIC load
The following patch corrects a hard reset that occurs on alix and
soekris net5501 hardware. Specifically, this is an issue with the via
rhine NIC driver. Under periods of extreme load, the via rhine driver
can cause a reset of the entire system. When this happens no output is
seen on the console, the device simply reboots. This was reported in the
following ticket:
Consistent crash on Soekris NET5501
https://dev.openwrt.org/ticket/11882
I was able to reproduce the problem locally with numerous alix 2d13
platforms. Under heavy 64 byte frame size load from a Smartbits traffic
generator, the alix hardware will hard reset in under 5 minutes. The
same hardware, under the same load, on FreeBSD 9.0 does not reset.
The patch below backports most of the via rhine changes from kernel 3.5.
With OpenWRT trunk being on kernel 3.3.8, it seemed prudent to bring
these changes in to avoid this serious issue.
I've tested this heavily in my test environment and was able to keep the
device stable under load for extended periods of time without any resets.
Also, a nice side effect of this change is that it significantly raises
the performance the platform. Without this patch the alix 2d13 can move
approximately 29,000 packets per second at 64 byte frame sizes. After
this patch the alix can move 52,000 packets per second at 64 byte frame
sizes.
I put this patch under the x86 patches as those are the only platforms
with via rhine hardware that I'm aware of. If it needs to go some place
else please let me know.
Thanks,
Adam
Signed-off-by: Adam Gensler
---
Index: target/linux/x86/patches-3.3/003-via-rhine-crash-fix.patch
===
--- target/linux/x86/patches-3.3/003-via-rhine-crash-fix.patch (revision 0)
+++ target/linux/x86/patches-3.3/003-via-rhine-crash-fix.patch (revision 0)
@@ -0,0 +1,60 @@
+--- a/drivers/net/ethernet/via/via-rhine.c
b/drivers/net/ethernet/via/via-rhine.c
+@@ -689,9 +689,12 @@ static void __devinit rhine_reload_eepro
+ #ifdef CONFIG_NET_POLL_CONTROLLER
+ static void rhine_poll(struct net_device *dev)
+ {
+- disable_irq(dev->irq);
+- rhine_interrupt(dev->irq, (void *)dev);
+- enable_irq(dev->irq);
++ struct rhine_private *rp = netdev_priv(dev);
++ const int irq = rp->pdev->irq;
++
++ disable_irq(irq);
++ rhine_interrupt(irq, dev);
++ enable_irq(irq);
+ }
+ #endif
+
+@@ -929,7 +932,6 @@ static int __devinit rhine_init_one(stru
+ dev = alloc_etherdev(sizeof(struct rhine_private));
+ if (!dev) {
+ rc = -ENOMEM;
+- dev_err(&pdev->dev, "alloc_etherdev failed\n");
+ goto err_out;
+ }
+ SET_NETDEV_DEV(dev, &pdev->dev);
+@@ -973,7 +975,6 @@ static int __devinit rhine_init_one(stru
+ }
+ #endif /* USE_MMIO */
+
+- dev->base_addr = (unsigned long)ioaddr;
+ rp->base = ioaddr;
+
+ /* Get chip registers into a sane state */
+@@ -996,8 +997,6 @@ static int __devinit rhine_init_one(stru
+ if (!phy_id)
+ phy_id = ioread8(ioaddr + 0x6C);
+
+- dev->irq = pdev->irq;
+-
+ spin_lock_init(&rp->lock);
+ mutex_init(&rp->task_lock);
+ INIT_WORK(&rp->reset_task, rhine_reset_task);
+@@ -1158,7 +1157,6 @@ static void alloc_rbufs(struct net_devic
+ rp->rx_skbuff[i] = skb;
+ if (skb == NULL)
+ break;
+- skb->dev = dev; /* Mark as being used by this
device. */
+
+ rp->rx_skbuff_dma[i] =
+ pci_map_single(rp->pdev, skb->data, rp->rx_buf_sz,
+@@ -1943,7 +1941,6 @@ static int rhine_rx(struct net_device *d
+ rp->rx_skbuff[entry] = skb;
+ if (skb == NULL)
+ break; /* Better luck next round. */
+- skb->dev = dev; /* Mark as being used by this
device. */
+ rp->rx_skbuff_dma[entry] =
+ pci_map_single(rp->pdev, skb->data,
+ rp->rx_buf_sz,
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Unable to log in to LuCI 8899
Hm...doesn't seem atime related, as the atime value seems to be derived from luci.sys.uptime. Its unclear why the atime value is nil. Looking in /tmp/luci-sessions shows the files in there. However, the files therein do not contain the atime value. I believe they should but I haven't spent much time with luci to know where to look to submit a patch. I'll keep digging. p.s. luci 8897 works just fine. On 8/7/12 7:41 PM, Adam Gensler wrote: Hi all, I just built a fresh image. I'm unable to log in to luci after authenticating, it states: ***quote** /usr/lib/lua/luci/dispatcher.lua:449: Failed to execute function dispatcher target for entry '/'. The called action terminated with an exception: /usr/lib/lua/luci/dispatcher.lua:449: Failed to execute firstchild dispatcher target for entry '/admin'. The called action terminated with an exception: /usr/lib/lua/luci/sauth.lua:97: attempt to perform arithmetic on field 'atime' (a nil value) stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:449: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:195: in function ***end quote*** Presumably this is because the file system gets mounted, by default, with noatime: ***quote*** root@alix:~# mount rootfs on / type rootfs (rw) /dev/root on /rom type squashfs (ro,relatime) none on /proc type proc (rw,noatime) sysfs on /sys type sysfs (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime) tmpfs on /dev type tmpfs (rw,noatime,size=512k,mode=755) devpts on /dev/pts type devpts (rw,noatime,mode=600) root on /tmp/root type tmpfs (rw,noatime,mode=755) overlayfs:/tmp/root on /tmp/root type overlayfs (ro,noatime,lowerdir=/,upperdir=/tmp/root) debugfs on /sys/kernel/debug type debugfs (rw,relatime) /dev/mtdblock1 on /overlay type jffs2 (rw,noatime) overlayfs:/overlay on / type overlayfs (rw,noatime,lowerdir=/,upperdir=/overlay) }}} ***end quote*** This happened both with ext2 and squashfs on an alix 2d13 using the newest openwrt trunk, r33035, and the newest luci, 8899. Based on the Luci timeline, there was specifically a change made to make the authentication tokens work differently in 8899: http://luci.subsignal.org/trac/changeset/8899 The failure happens both in IE8 on WindowsXP and Safari 6.0 on OSX 10.8. Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Unable to log in to LuCI 8899
Hi all, I just built a fresh image. I'm unable to log in to luci after authenticating, it states: ***quote** /usr/lib/lua/luci/dispatcher.lua:449: Failed to execute function dispatcher target for entry '/'. The called action terminated with an exception: /usr/lib/lua/luci/dispatcher.lua:449: Failed to execute firstchild dispatcher target for entry '/admin'. The called action terminated with an exception: /usr/lib/lua/luci/sauth.lua:97: attempt to perform arithmetic on field 'atime' (a nil value) stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:449: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:195: in function ***end quote*** Presumably this is because the file system gets mounted, by default, with noatime: ***quote*** root@alix:~# mount rootfs on / type rootfs (rw) /dev/root on /rom type squashfs (ro,relatime) none on /proc type proc (rw,noatime) sysfs on /sys type sysfs (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime) tmpfs on /dev type tmpfs (rw,noatime,size=512k,mode=755) devpts on /dev/pts type devpts (rw,noatime,mode=600) root on /tmp/root type tmpfs (rw,noatime,mode=755) overlayfs:/tmp/root on /tmp/root type overlayfs (ro,noatime,lowerdir=/,upperdir=/tmp/root) debugfs on /sys/kernel/debug type debugfs (rw,relatime) /dev/mtdblock1 on /overlay type jffs2 (rw,noatime) overlayfs:/overlay on / type overlayfs (rw,noatime,lowerdir=/,upperdir=/overlay) }}} ***end quote*** This happened both with ext2 and squashfs on an alix 2d13 using the newest openwrt trunk, r33035, and the newest luci, 8899. Based on the Luci timeline, there was specifically a change made to make the authentication tokens work differently in 8899: http://luci.subsignal.org/trac/changeset/8899 The failure happens both in IE8 on WindowsXP and Safari 6.0 on OSX 10.8. Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] fq_codel - has anyone tried it?
I'm not sure that's entirely accurate. QoS has its place. Real-time traffic, for things like VoIP, needs special treatment. For traffic like that, its much preferable to drop packets from other flows before dropping packets from a real-time flow. Also, regardless of bufferbloat, sometimes its necessary to guarantee that a particular traffic stream receives a predetermined amount of bandwidth. I'm not sure other QoS schemes would qualify as "crap" in that respect. It serves a real and important purpose. Adam On 5/27/12 6:18 PM, Michael Markstaller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.05.2012 14:25, Brian J. Murrell wrote: I wonder though, how many people are using QoS as a band-aid for bufferbloat. Anyone using QoS to keep their upstream bandwidth below their supposed available bandwidth ... Think your fully right, I guess not many - or too many to fix things that arent present without.. In this context (async lines) "QoS" (as it was) has been just misunderstood as a placebo-pill against headaches without working on the reason.. (I'm working with for ~10yrs and if I'm asked - all current QoS-mechanisms [without/pre codel etc - havent tested that fully yet] are just simply crap in real life) regards, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/CqDsACgkQaWRHV2kMuAJ2LQCgz2h+gVQInGyfxx/BmL8jrwER SoAAnilEGoR94gMbC/zaugDGoID4U18z =OBpW -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] fq_codel - has anyone tried it?
I've spent the last few hours looking into fq_codel. Currently I'm running a pretty basic hfsc QoS scheme for VoIP and Games. Everything else goes into the Default queue where I have SFQ enabled. From what I can see of fq_codel, it is only meant to replace SFQ, not the other classes I have. In other words, if you need QoS already, fq_codel won't eliminate that need. But, if you aren't running QoS already, fq_codel has some really great potential to keep things running smoothly under load, yes? Am I understanding fq_codel correctly? Thanks, Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Bump dnsmasq to 2.61
All, I've bumped dnsmasq to version 2.61. From my analysis, the 101-ipv6.patch is no longer required. I believe this was simplifying the config/build process to make sure IPv6 support was enabled correctly. The associate file, /src/config.h has been cleaned up in the newest version and it seems to work just fine without this patch. I tested two ways. 1. Without IPv6 enabled in menuconfig, specifically I disabled CONFIG_IPV6. When I did that and ran dnsmasq compiled with that flag disabled, it fired up without IPv6 support: May 26 01:06:22 alix daemon.info dnsmasq[18416]: started, version 2.61 cachesize 150 May 26 01:06:22 alix daemon.info dnsmasq[18416]: compile time options: no-IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack May 26 01:06:22 alix daemon.info dnsmasq-dhcp[18416]: DHCP, IP range 172.28.1.220 -- 172.28.1.249, lease time 8h May 26 01:06:22 alix daemon.info dnsmasq[18416]: using local addresses only for domain lan May 26 01:06:22 alix daemon.info dnsmasq[18416]: reading /tmp/resolv.conf.auto May 26 01:06:22 alix daemon.info dnsmasq[18416]: using nameserver 24.25.5.60#53 May 26 01:06:22 alix daemon.info dnsmasq[18416]: using nameserver 24.25.5.61#53 May 26 01:06:22 alix daemon.info dnsmasq[18416]: using local addresses only for domain lan May 26 01:06:22 alix daemon.info dnsmasq[18416]: read /etc/hosts - 1 addresses 2. Then I cleaned the package, enabled CONFIG_IPV6, recompiled and ran it again, this time it launches with IPv6 support: May 26 01:07:39 alix daemon.info dnsmasq[18860]: started, version 2.61 cachesize 150 May 26 01:07:39 alix daemon.info dnsmasq[18860]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack May 26 01:07:39 alix daemon.info dnsmasq-dhcp[18860]: DHCP, IP range 172.28.1.220 -- 172.28.1.249, lease time 8h May 26 01:07:39 alix daemon.info dnsmasq[18860]: using local addresses only for domain lan May 26 01:07:39 alix daemon.info dnsmasq[18860]: reading /tmp/resolv.conf.auto May 26 01:07:39 alix daemon.info dnsmasq[18860]: using nameserver 24.25.5.60#53 May 26 01:07:39 alix daemon.info dnsmasq[18860]: using nameserver 24.25.5.61#53 May 26 01:07:39 alix daemon.info dnsmasq[18860]: using local addresses only for domain lan May 26 01:07:39 alix daemon.info dnsmasq[18860]: read /etc/hosts - 1 addresses Any input and/or suggestions are welcome. Note, this version of dnsmasq has some DHCPv6 support, however, the dnsmasq.init file has not been updated to support it via UCI. Signed-off-by: Adam Gensler --- Index: package/dnsmasq/patches/101-ipv6.patch === --- package/dnsmasq/patches/101-ipv6.patch (revision 31858) +++ package/dnsmasq/patches/101-ipv6.patch (working copy) @@ -1,13 +0,0 @@ a/src/config.h -+++ b/src/config.h -@@ -263,8 +263,9 @@ NOTES: - /* We assume that systems which don't have IPv6 -headers don't have ntop and pton either */ - --#if defined(INET6_ADDRSTRLEN) && defined(IPV6_V6ONLY) && !defined(NO_IPV6) -+#if defined(INET6_ADDRSTRLEN) && !defined(NO_IPV6) - # define HAVE_IPV6 -+# define IPV6_V6ONLY 26 - # define ADDRSTRLEN INET6_ADDRSTRLEN - # if defined(SOL_IPV6) - #define IPV6_LEVEL SOL_IPV6 Index: package/dnsmasq/Makefile === --- package/dnsmasq/Makefile(revision 31858) +++ package/dnsmasq/Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=dnsmasq -PKG_VERSION:=2.59 -PKG_RELEASE:=4 +PKG_VERSION:=2.61 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq -PKG_MD5SUM:=b5757ef2d7b651748eeebb88af29d7d6 +PKG_MD5SUM:=6ed0a5c2524dfc3a74ef494ee2469f09 PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] move privoxy startup to later in boot process
When using privoxy as a transparent HTTP proxy a race condition occurs where privoxy may attempt to startup and start listening on the LAN interface before the network configuration is completed. As a result privoxy fails to start up because it can't bind to the correct listening address. This patch changes the init.d script to be a little bit later in the boot process. Signed-off-by: Adam Gensler --- Index: packages/net/privoxy/files/privoxy.init === --- packages/net/privoxy/files/privoxy.init (revision 31828) +++ packages/net/privoxy/files/privoxy.init (working copy) @@ -1,8 +1,8 @@ #!/bin/sh /etc/rc.common # Copyright (C) 2006-2011 OpenWrt.org -START=50 -STOP=50 +START=80 +STOP=80 SERVICE_USE_PID=1 Index: packages/net/privoxy/Makefile === --- packages/net/privoxy/Makefile (revision 31828) +++ packages/net/privoxy/Makefile (working copy) @@ -9,7 +9,7 @@ PKG_NAME:=privoxy PKG_VERSION:=3.0.19 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-stable-src.tar.gz PKG_SOURCE_URL:=@SF/ijbswa ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade x86 bounty
There is no overlay filesystem in the pure ext4 images. It mounts like a regular ext4 filesystem would on any other Linux system: root@alix:~# mount rootfs on / type rootfs (rw) /dev/root on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered) none on /proc type proc (rw,noatime) sysfs on /sys type sysfs (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime) tmpfs on /dev type tmpfs (rw,noatime,size=512k,mode=755) devpts on /dev/pts type devpts (rw,noatime,mode=600) debugfs on /sys/kernel/debug type debugfs (rw,relatime) root@alix:~# Overlays are only used on the JFFS2 or squashfs file systems. Both of which can technically be used with this double root partition approach as well, however ext4 makes the most sense on a compact flash card. Adam On 4/21/12 2:52 PM, Philip Prindeville wrote: Sorry for being dense: where is the overlay filesystem during all of this? /dev/sda4? On 4/12/12 8:28 PM, Adam Gensler wrote: I think the layout of the x86 filesystem needs to change in order to support sysupgrade properly. Personally I'm using an alix2 board with the ext4 filesystem (trunk image). I've not had much luck getting reliable sysupgrades when using a pure ext4 filesystem. It works only sporadically. More often than not the file system ends up corrupted. I've been tinkering with the following layout: /dev/sda1 = boot partition, contains two copies of the kernel, vmlinuz and vmlinuz2 /dev/sda2 = root partition, contains ext4 file system /dev/sda3 = second root partition, contains ext4 file system The grub menu.lst would be modified such that vmlinuz would use rootfs /dev/sda2. vmlinuz2 would use root in /dev/sda3. When it is time to upgrade the image, the inactive rootfs partition would be the one upgraded. /dev/sda1 would be mounted, the correct kernel overwritten, and menu.lst updated to default to the new kernel. This would allow the system to remain fully operational during an upgrade, no ramdisk needed. I've got this part working so far, albeit via manual partition creation and upgrades. I'm hacking around in target/linux/x86/image/gen_image_x86.sh and target/linux/x86/image/Makefile to make the extra partition creation automatic, an initial duplicate copy of the rootfs, and the appropriate menu.lst entries. Presumably once this infrastructure is in place it should be possible to mount the upgraded rootfs and extract the sysupgrade backup tarball onto it. That's just a theory though, I haven't gotten that far. Thoughts? Adam On 4/10/12 6:24 PM, Philip Prindeville wrote: Just a reminder that this bounty is still unclaimed. On 2/10/12 3:11 PM, Philip Prindeville wrote: Sysupgrade currently doesn't allow updating software in place without clobbering the existing config (stored on the ext4 overlay filesystem that immediately follows the jffs2 filesystem). I've spoken to various interested parties using x86 hardware, and we'd like to see if anyone is interested in doing bounty work to support sysupgrade on x86. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Generic x86 target still on 2.6.39?
I see that a number of targets were recently bumped up to kernel 3.2.15, including the x86 subtargets like the alix and geos. However, the generic x86 target remains on 2.6.39: adam@openwrt-builder:~/Desktop/openwrt/trunk$ cat target/linux/x86/Makefile # # Copyright (C) 2006-2011 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. # include $(TOPDIR)/rules.mk ARCH:=i386 BOARD:=x86 BOARDNAME:=x86 FEATURES:=squashfs jffs2 ext4 vdi vmdk pcmcia targz SUBTARGETS=generic olpc xen_domu ep80579 net5501 kvm_guest geos alix2 thincan LINUX_VERSION:=2.6.39.4 include $(INCLUDE_DIR)/target.mk $(eval $(call BuildTarget)) $(eval $(call $(if $(CONFIG_TARGET_ROOTFS_ISO),RequireCommand,Ignore),mkisofs, \ Please install mkisofs. \ )) Is there a reason for keeping the generic target so far back on a dead kernel version? Best regards, Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade x86 bounty
Not entirely. If you do sysupgrade -n, even with a squashfs image, the image isn't actually upgraded. The upgrade process skips writing the image file and proceeds with a reboot without having done anything. On 4/13/12 8:03 AM, Kaspar Schleiser wrote: Hey, well, and it only affects those installations that use ext4. Using sqashfs and jffs2 is perfectly possibly on block devices. Sysupgrade works fine with them on x86. Regards Kaspar On 04/13/2012 11:24 AM, David Woodhouse wrote: For a start, this isn't really about "x86", is it? It's about systems which use block-based storage instead of flash? This is for anything which makes the mistake of using CompactFlash or SD instead of letting the OS have real access to the flash. There are x86 systems (like OLPCv1, anything with a DiskOnChip, etc.) with real flash, and there are non-x86 systems which unfortunately use SD. Although perhaps OpenWrt hasn't reached the latter yet. So whatever the solution, it *shouldn't* be specific to the x86 target, surely? On Thu, 2012-04-12 at 22:28 -0400, Adam Gensler wrote: When it is time to upgrade the image, the inactive rootfs partition would be the one upgraded. /dev/sda1 would be mounted, the correct kernel overwritten, and menu.lst updated to default to the new kernel. Sounds like you'd be a lot better off using btrfs snapshots for that. Take a snapshot before upgrade, mount that snapshot and untar the new system image into it. Then reboot mounting that snapshot as root. (Remember, in btrfs snapshots are more like branches; they're writeable and the 'master' is just another snapshot that happens to be the one that gets mounted by default when you don't specify otherwise.) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade x86 bounty
I think the layout of the x86 filesystem needs to change in order to support sysupgrade properly. Personally I'm using an alix2 board with the ext4 filesystem (trunk image). I've not had much luck getting reliable sysupgrades when using a pure ext4 filesystem. It works only sporadically. More often than not the file system ends up corrupted. I've been tinkering with the following layout: /dev/sda1 = boot partition, contains two copies of the kernel, vmlinuz and vmlinuz2 /dev/sda2 = root partition, contains ext4 file system /dev/sda3 = second root partition, contains ext4 file system The grub menu.lst would be modified such that vmlinuz would use rootfs /dev/sda2. vmlinuz2 would use root in /dev/sda3. When it is time to upgrade the image, the inactive rootfs partition would be the one upgraded. /dev/sda1 would be mounted, the correct kernel overwritten, and menu.lst updated to default to the new kernel. This would allow the system to remain fully operational during an upgrade, no ramdisk needed. I've got this part working so far, albeit via manual partition creation and upgrades. I'm hacking around in target/linux/x86/image/gen_image_x86.sh and target/linux/x86/image/Makefile to make the extra partition creation automatic, an initial duplicate copy of the rootfs, and the appropriate menu.lst entries. Presumably once this infrastructure is in place it should be possible to mount the upgraded rootfs and extract the sysupgrade backup tarball onto it. That's just a theory though, I haven't gotten that far. Thoughts? Adam On 4/10/12 6:24 PM, Philip Prindeville wrote: Just a reminder that this bounty is still unclaimed. On 2/10/12 3:11 PM, Philip Prindeville wrote: Sysupgrade currently doesn't allow updating software in place without clobbering the existing config (stored on the ext4 overlay filesystem that immediately follows the jffs2 filesystem). I've spoken to various interested parties using x86 hardware, and we'd like to see if anyone is interested in doing bounty work to support sysupgrade on x86. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] PATCH: Disable console terminal in Grub for alix2 target
The alix2 target has the VGA console for grub enabled by default. This prevents the grub menu from appearing on bootup. It is disabled by default for the other embedded x86 platforms. This patch corrects that behavior for the alix2 target. Signed-off-by: Adam Gensler Index: target/linux/x86/image/Config.in === --- target/linux/x86/image/Config.in(revision 31264) +++ target/linux/x86/image/Config.in(working copy) @@ -23,7 +23,7 @@ config X86_GRUB_CONSOLE bool "Use Console Terminal (in addition to Serial)" depends X86_GRUB_IMAGES - default n if (TARGET_x86_generic_Soekris45xx || TARGET_x86_generic_Soekris48xx || TARGET_x86_net5501 || TARGET_x86_geos) + default n if (TARGET_x86_generic_Soekris45xx || TARGET_x86_generic_Soekris48xx || TARGET_x86_net5501 || TARGET_x86_geos || TARGET_x86_alix2) default y config X86_GRUB_SERIAL ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Went up to kernel version 3.2.5, problem still occurs. Above 3.2.5 requires refreshing the kernel patches. On 2/29/12 11:18 PM, Adam Gensler wrote: For what its worth I spent some time this evening putting together a Fedora Core 16 virtual machine to test with. I pulled a fresh copy of trunk and built the alix2 target and got the same traces on boot up. At this point I'm sure the issue isn't with my build environment but is an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong enough to move closer to resolution. On 2/28/12 7:09 PM, Adam Gensler wrote: Nothing I'm finding online seems to indicate a simple procedure for this. Perhaps I'm not searching for the correct terminology. If you have a sample / example I'd certainly take a look at doing it. On 2/28/12 5:12 PM, Philip Prindeville wrote: As it turns out you only need 2-3 commands... you can almost script it with macros. On 2/28/12 2:17 PM, Adam Gensler wrote: Unfortunately I have zero experience with gdb. It would probably take longer to learn how to use that than to refresh to the kernel patches on 3.2 to support 3.2.7 so I could try that version to see if its already fixed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
For what its worth I spent some time this evening putting together a Fedora Core 16 virtual machine to test with. I pulled a fresh copy of trunk and built the alix2 target and got the same traces on boot up. At this point I'm sure the issue isn't with my build environment but is an issue in trunk. Unfortunately my kernel-debugging-foo isn't strong enough to move closer to resolution. On 2/28/12 7:09 PM, Adam Gensler wrote: Nothing I'm finding online seems to indicate a simple procedure for this. Perhaps I'm not searching for the correct terminology. If you have a sample / example I'd certainly take a look at doing it. On 2/28/12 5:12 PM, Philip Prindeville wrote: As it turns out you only need 2-3 commands... you can almost script it with macros. On 2/28/12 2:17 PM, Adam Gensler wrote: Unfortunately I have zero experience with gdb. It would probably take longer to learn how to use that than to refresh to the kernel patches on 3.2 to support 3.2.7 so I could try that version to see if its already fixed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Nothing I'm finding online seems to indicate a simple procedure for this. Perhaps I'm not searching for the correct terminology. If you have a sample / example I'd certainly take a look at doing it. On 2/28/12 5:12 PM, Philip Prindeville wrote: As it turns out you only need 2-3 commands... you can almost script it with macros. On 2/28/12 2:17 PM, Adam Gensler wrote: Unfortunately I have zero experience with gdb. It would probably take longer to learn how to use that than to refresh to the kernel patches on 3.2 to support 3.2.7 so I could try that version to see if its already fixed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Unfortunately I have zero experience with gdb. It would probably take longer to learn how to use that than to refresh to the kernel patches on 3.2 to support 3.2.7 so I could try that version to see if its already fixed. On 2/28/12 3:08 PM, Philip Prindeville wrote: % cat /proc/modules that will give you the base address of each module... you can then gdb what the load address was of the module on your build host, and as it to print each address... On 2/28/12 12:56 PM, Adam Gensler wrote: I've built a generic x86 image and attempted to get a stack trace by manually mapping the trace addresses to the System.map file. Unfortunately, none of the addresses are in the System.map. I suspect, after having read the following URL, that this is because the call traces are coming from kernel modules, not the kernel itself (hence the reference to insmod in the call trace). http://www.faqs.org/docs/Linux-HOWTO/Kernel-HOWTO.html#systemmap That URL goes on the explain the System.map and why things like modules aren't in it. So...now I'm stuck. On 2/27/12 11:11 PM, Philip Prindeville wrote: You should be able to get a stack trace with gdb and the unstripped kernel, or else just do it by hand with: .tmp_System.map in your build_dir/linux-x86_alix2/linux-3.2.2/ directory. Maybe someone else like Felix or Jo-Philipp can give better suggestions? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
I've built a generic x86 image and attempted to get a stack trace by manually mapping the trace addresses to the System.map file. Unfortunately, none of the addresses are in the System.map. I suspect, after having read the following URL, that this is because the call traces are coming from kernel modules, not the kernel itself (hence the reference to insmod in the call trace). http://www.faqs.org/docs/Linux-HOWTO/Kernel-HOWTO.html#systemmap That URL goes on the explain the System.map and why things like modules aren't in it. So...now I'm stuck. On 2/27/12 11:11 PM, Philip Prindeville wrote: You should be able to get a stack trace with gdb and the unstripped kernel, or else just do it by hand with: .tmp_System.map in your build_dir/linux-x86_alix2/linux-3.2.2/ directory. Maybe someone else like Felix or Jo-Philipp can give better suggestions? -Philip On 2/27/12 5:53 PM, Adam Gensler wrote: By symbolic addresses you mean building it with the symbol table? CONFIG_KERNEL_KALLSYMS=y Doing so corrects the problem, making it impossible to debug. If you mean something else please let me know and I'll be happy to try it. Being stuck on pre-3 revisions in trunk on the x86 alix2 target is not some place I'd like to stay. Thanks, Adam On 2/27/12 1:44 AM, Philip Prindeville wrote: It might also be helpful to get symbolic addresses and not just hex addresses. On 2/25/12 10:48 AM, Adam Gensler wrote: Does anyone else have any thoughts into this? Other suggestions I can try? Seems someone else is seeing the same issue as I've found the following output sitting on pastebin: http://pastebin.com/djNfNa3t These errors match the errors I'm seeing on my system exactly. I've since reverted to trunk@29844 with a patch kicking it up to the 3.0.18 kernel and I don't see these errors. I went ahead and opened a ticket on this for tracking purposes: alix2 - trace messages in dmesg on bootup https://dev.openwrt.org/ticket/11020 Thanks, Adam On 2/22/12 1:02 AM, Adam Gensler wrote: Just build another one, this time with the following: # target CONFIG_TARGET_x86=y CONFIG_TARGET_x86_alix2=y CONFIG_DEVEL=y CONFIG_TOOLCHAINOPTS=y CONFIG_KERNEL_KALLSYMS=y #CONFIG_KERNEL_DEBUG_KERNEL=y #CONFIG_KERNEL_DEBUG_INFO=y Boots fine, no traces showing up. Not sure what that means exactly. Buts it's 100% reproducible on three different alix boards with images from two different build machines. Adam On 2/22/12 12:50 AM, Philip Prindeville wrote: Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ... On 2/21/12 10:34 PM, Adam Gensler wrote: Hi Philip, I suspected that might have been the problem so I did another build real quick, but I removed your extra commands, and the problem returned in that build. So, I ran yet another build, this time, with the following options: # target CONFIG_TARGET_x86=y CONFIG_TARGET_x86_alix2=y CONFIG_DEVEL=y CONFIG_TOOLCHAINOPTS=y #CONFIG_KERNEL_KALLSYMS=y CONFIG_KERNEL_DEBUG_KERNEL=y CONFIG_KERNEL_DEBUG_INFO=y Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems happens when that is disabled. If I turn that back on, "CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear. Adam On 2/22/12 12:30 AM, Philip Prindeville wrote: Actually, that shouldn't have fixed your problem! (Unless Heisenberg's Principle comes into effect.) It was supposed to give us a useful stack trace, however. You might have had a corrupt build. Can you try it on several boxes and see if it's reproducible? -Philip On 2/21/12 10:10 PM, Adam Gensler wrote: Hi Philip, I rebuilt an image with those additional options added. It resolved the call traces I was seeing in dmesg. None of them show up now. I'll admit, I'm not super familiar with the inner-workings of kernel building. Can you provide some insight into why this seems to have resolved the issue? Attached is the dmesg output from the new image, just in case. Thanks, Adam On 2/21/12 10:31 PM, Philip Prindeville wrote: On 2/21/12 8:15 PM, Adam Gensler wrote: Hi all, I have a handful of Alix 2D13 platforms I've been running trunk images on for a while now. I noticed that it was recently kicked up to kernel 3.2.2. When it boots up now there's a number of traces from insmod. Attached is the complete output of the boot sequence. The image was built clean, in a clean pull of trunk, using the default alix2 target. I've seen this on multiple alix boards, on images built on two completely separate build servers so I don't think its related to how I'm building the image. Any suggestions on how to troubleshoot this? Thanks in advance, Adam Please do the following: % mkdir ~/.openwrt % cat>> ~/.openwrt/defconfig CONFIG_DEVEL=y CONFIG_TOOLCHAINOPTS=y CONFIG_KERNEL_KALLSYMS=y CONFIG_KERNEL_DEBUG_KERNEL=y CONFIG_KERNEL_DEBUG_INFO=y
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Good idea, see inline:
On 2/27/12 11:14 PM, Philip Prindeville wrote:
Two questions:
If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what
happens?
[adam] Works fine, 29981 with kernel 2.6.39.4 on the alix2 target boots
without traces in dmesg.
If you build a x86/generic kernel with LINUX_VERSION=3.2.2 what happens?
[adam] Same problem as alix2 target on 3.2.2. Traces in dmesg when
building the generic x86 target using kernel version 3.2.2.
Perhaps this points to a patch issue within the 3.2 patch set?
On 2/27/12 9:01 PM, Adam Gensler wrote:
Confirmed, this issue first appears when the kernel was bumped to 3.2.1
in this change set:
https://dev.openwrt.org/changeset/29981/trunk
29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1
has the previously mentioned traces in dmesg on boot up.
On 2/27/12 7:53 PM, Adam Gensler wrote:
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex
addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off
CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another
build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel
building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from
insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=9
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Confirmed, this issue first appears when the kernel was bumped to 3.2.1
in this change set:
https://dev.openwrt.org/changeset/29981/trunk
29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1
has the previously mentioned traces in dmesg on boot up.
On 2/27/12 7:53 PM, Adam Gensler wrote:
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex
addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off
CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another
build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel
building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from
insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Philip,
Presumably you're running the newest trunk images on your alix boards
and are not seeing this problem? What OS/version are you building with?
I'm using Ubuntu 10.03 LTS as I have been for a while. I wouldn't mind
spinning a VM with whatever distro you're using to give that a try.
Thanks,
Adam
On 2/25/12 10:10 PM, Philip Prindeville wrote:
A couple of other things to try. I build with:
CONFIG_USE_EGLIBC=y
CONFIG_EGLIBC_VERSION_2_13=y
and I use the default gcc.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Just finished building two fresh trunk pulls (which, at the time of this
writing were at r30733). These are clean checkouts from svn that haven't
been mangled in any way. I set the target to x86/alix2. On one I
selected egblic 2.13 and on the other I left it at defaults (uclibc). I
changed nothing else. Both images built fine, then I dd'ed them over to
two separate compact flash cards.
Both images are still dumping all kinds of traces in dmesg on bootup.
On 2/26/12 7:55 AM, Adam Gensler wrote:
I can give that a try, however, I build against the default uclibc
library normally.
On 2/25/12 10:10 PM, Philip Prindeville wrote:
A couple of other things to try. I build with:
CONFIG_USE_EGLIBC=y
CONFIG_EGLIBC_VERSION_2_13=y
and I use the default gcc.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off
CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another
build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel
building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from
insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
I can give that a try, however, I build against the default uclibc
library normally.
On 2/25/12 10:10 PM, Philip Prindeville wrote:
A couple of other things to try. I build with:
CONFIG_USE_EGLIBC=y
CONFIG_EGLIBC_VERSION_2_13=y
and I use the default gcc.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] PATCH: Allow "ss" to build in iproute2
Hi all,
I've been testing "ss" from iproute2 for a number of weeks now across
numerous trunk builds for x86. It's working well and builds without
problems. Digging through the svn tree turns up that this portion of
iproute2 has been disabled for several years now and hasn't been revisited.
There's a related ticket open on it:
https://dev.openwrt.org/ticket/7632
However, I didn't have to do the "fix" suggested therein. I'm providing
my patch here if any other wish to try it out. Here's some sample output
from my alix board:
root@alix:~# ss --help
Usage: ss [ OPTIONS ]
ss [ OPTIONS ] [ FILTER ]
-h, --help this message
-V, --versionoutput version information
-n, --numericdon't resolve service names
-r, --resolve resolve host names
-a, --alldisplay all sockets
-l, --listening display listening sockets
-o, --options show timer information
-e, --extended show detailed socket information
-m, --memoryshow socket memory usage
-p, --processes show process using socket
-i, --info show internal TCP information
-s, --summaryshow socket usage summary
-4, --ipv4 display only IP version 4 sockets
-6, --ipv6 display only IP version 6 sockets
-0, --packet display PACKET sockets
-t, --tcpdisplay only TCP sockets
-u, --udpdisplay only UDP sockets
-d, --dccp display only DCCP sockets
-w, --rawdisplay only RAW sockets
-x, --unix display only Unix domain sockets
-f, --family=FAMILY display sockets of type FAMILY
-A, --query=QUERY
QUERY := {all|inet|tcp|udp|raw|unix|packet|netlink}[,QUERY]
-F, --filter=FILE read filter information from FILE
FILTER := [ state TCP-STATE ] [ EXPRESSION ]
root@alix:~#
root@alix:~# ss -V
ss utility, iproute2-ss2.6.39-1-openwrt
root@alix:~#
Signed-off-by: Adam Gensler
Thanks,
Adam
---
Index: iproute2/Makefile
===
--- iproute2/Makefile (revision 30677)
+++ iproute2/Makefile (working copy)
@@ -9,7 +9,7 @@
PKG_NAME:=iproute2
PKG_VERSION:=2.6.39
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://devresources.linux-foundation.org/dev/iproute2/download/
@@ -47,15 +47,17 @@
TITLE:=General netlink utility frontend
endef
+define Package/ss
+$(call Package/iproute2/Default)
+ TITLE:=Socket Statistics
+endef
+
define Build/Configure
$(SED) "s,-I/usr/include/db3,," $(PKG_BUILD_DIR)/Makefile
$(SED) "s,^KERNEL_INCLUDE.*,KERNEL_INCLUDE=$(LINUX_DIR)/include," \
$(PKG_BUILD_DIR)/Makefile
$(SED) "s,^LIBC_INCLUDE.*,LIBC_INCLUDE=$(STAGING_DIR)/include," \
$(PKG_BUILD_DIR)/Makefile
- # For now disable compiling of the misc directory because it seems to
fail
- rm -rf $(PKG_BUILD_DIR)/misc
- $(SED) "s, misc,," $(PKG_BUILD_DIR)/Makefile
echo "static const char SNAPSHOT[] =
\"$(PKG_VERSION)-$(PKG_RELEASE)-openwrt\";" \
> $(PKG_BUILD_DIR)/include/SNAPSHOT.h
endef
@@ -72,6 +74,7 @@
-I../include -DRESOLVE_HOSTNAMES"
$(MAKE_VARS) $(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) $(MAKE_FLAGS) all
$(MAKE_VARS) $(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR)/tc $(MAKE_FLAGS) tc
+ $(MAKE_VARS) $(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR)/misc $(MAKE_FLAGS)
ss
$(MAKE_VARS) $(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR)/ip $(MAKE_FLAGS) ip
endef
@@ -99,6 +102,12 @@
$(INSTALL_BIN) $(PKG_BUILD_DIR)/genl/genl $(1)/usr/sbin/
endef
+define Package/ss/install
+ $(INSTALL_DIR) $(1)/usr/sbin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/misc/ss $(1)/usr/sbin/
+endef
+
$(eval $(call BuildPackage,ip))
$(eval $(call BuildPackage,tc))
$(eval $(call BuildPackage,genl))
+$(eval $(call BuildPackage,ss))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless Heisenberg's
Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved the
call traces I was seeing in dmesg. None of them show up now. I'll admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk images
on for a while now. I noticed that it was recently kicked up to kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the default
alix2 target. I've seen this on multiple alix boards, on images built on
two completely separate build servers so I don't think its related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>>~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless Heisenberg's
Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved the
call traces I was seeing in dmesg. None of them show up now. I'll admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk images
on for a while now. I noticed that it was recently kicked up to kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the default
alix2 target. I've seen this on multiple alix boards, on images built on
two completely separate build servers so I don't think its related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Hi Philip,
I rebuilt an image with those additional options added. It resolved the
call traces I was seeing in dmesg. None of them show up now. I'll admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk images
on for a while now. I noticed that it was recently kicked up to kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the default
alix2 target. I've seen this on multiple alix boards, on images built on
two completely separate build servers so I don't think its related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory
01F0 Master 848A SanDisk SDCFH-002G
Phys C/H/S 3875/16/63 Log C/H/S 968/64/63
GRUB Loading stage1.5.
GRUB loading, please wait...
Press any key to continue.
Press any key to continue.
[0.00] Linux version 3.2.2 (adam@openwrt-builder) (gcc version 4.6.3
20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Wed Feb 22 00:03:48 EST 2012
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 000a (usable)
[0.00] BIOS-e820: 000f - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 1000 (usable)
[0.00] BIOS-e820: fff0 - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] DMI not present or invalid.
[0.00] last_pfn = 0x1 max_arch_pfn = 0x10
[0.00] init_memory_mapping: -1000
[0.00] 256MB LOWMEM available.
[0.00] mapped low ram: 0 - 1000
[0.00] low ram: 0 - 1000
[0.00] Zone PFN ranges:
[0.00] DMA 0x0010 -> 0x1000
[0.00] Normal 0x1000 -> 0x0001
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0: 0x0010 -> 0x00a0
[0.00] 0: 0x0100 -> 0x0001
[0.00] Using APIC driver default
[0.00] No local APIC present or hardware disabled
[0.00] APIC: disable apic facility
[0.00] APIC: switched to apic NOOP
[0.00] Allocating PCI resources starting at 1000 (gap:
1000:eff0)
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64912
[0.00] Kernel command line: root=/dev/sda2 rootfstype=ext4 rootwait
console=tty0 console=ttyS0,38400n8 noinitrd reboot=bios
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Initializing CPU#0
[0.00] Memory: 256140k/262144k available (2160k kernel code, 5556k
reserved, 746k data, 220k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap : 0xfffa4000 - 0xf000 ( 364 kB)
[0.00] vmalloc : 0xd080 - 0xfffa2000 ( 759 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] .init : 0xc12d7000 - 0xc130e000 ( 220 kB)
[0.00] .data : 0xc121c314 - 0xc12d6c40 ( 746 kB)
[0.00] .text : 0xc100 - 0xc121c314 (2160 kB)
[0.00] Checking if this processor honours the WP bit even in supervisor
mode...Ok.
[0.00] SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1,
Nodes=1
[0.00] NR_IRQS:2304 nr_irqs:256 16
[0.00] console [ttyS0] enabled
[0.00] Fast TSC calibration using PIT
[0.00] Detected 498.052 MHz processor.
[0.030005] Calibrating delay loop (skipped), value calculated using timer
frequency.. 996.10 BogoMIPS (lpj=4980520)
[0.050011] pid_max: default: 32768 minimum: 301
[0.070034] Mount-cache hash table entries: 512
[0.080398] CP
[OpenWrt-Devel] PATCH: secure_mode config options for radvd (updated)
The purpose of this change is to allow users to configure radvd to run
in unprivileged mode. Per the radvd man page:
radvd(8) - Linux man page
http://linux.die.net/man/8/radvd
-u username, --username username
If specified, drops root privileges and changes user ID to username and
group ID to the primary group of username. This is recommended for
security reasons. You might also need to use -p to point to a file in a
username -writable directory (e.g. /var/run/radvd/radvd.pid).
This patch can parse three new fields in /etc/config/radvd, under
"config radvd", specifically:
option secure_mode 1
option username 'nobody'
option group'nogroup'
I think the above is fairly self explanatory. When run with the "-u"
option, radvd spawns two processes, one with root privileges for
interface configuration purposes and another, unprivileged process, for
everything else. With none of these options configured radvd will
operate as it always has.
This patch has been updated to work with the new service wrapper in
trunk and also removes the hotplug patch as its no longer being used by
radvd as per a previous fix.
Signed-off-by: Adam Gensler
---
Index: feeds/packages/ipv6/radvd/files/radvd.init
===
--- feeds/packages/ipv6/radvd/files/radvd.init (revision 29672)
+++ feeds/packages/ipv6/radvd/files/radvd.init (working copy)
@@ -411,6 +411,30 @@
return 0
}
+radvd_start_secure() {
+ local cfg=$1
+ local secure
+
+ validate_varname "$cfg" || return 0
+
+ config_get_bool secure "$cfg" secure_mode 0
+ [ "$secure" -ne 1 ] && return 0
+
+ config_get RADVD_USERNAME "$cfg" username
+ if [ -z "$RADVD_USERNAME" ]; then
+ logger -t "radvd startup" "username required for secure mode, radvd
will run as root"
+ return 1
+ fi
+
+ config_get RADVD_GROUP "$cfg" group
+ if [ -z "$RADVD_GROUP" ] ; then
+ logger -t "radvd startup" "group required for secure mode, radvd
will run as root"
+ return 1
+ fi
+
+ return 0
+}
+
start() {
config_load radvd
@@ -429,7 +453,18 @@
sysctl -w net.ipv6.conf.all.forwarding=1 > /dev/null 2> /dev/null
- service_start /usr/sbin/radvd -C "$RADVD_CONFIG_FILE" -m
stderr_syslog -p /var/run/radvd.pid
+ RADVD_USERNAME=
+ RADVD_GROUP=
+ config_foreach radvd_start_secure radvd
+
+ if [ ! -z "$RADVD_USERNAME" ] && [ ! -z "$RADVD_GROUP" ]; then
+ mkdir -p /var/run/radvd
+ chown $RADVD_USERNAME:$RADVD_GROUP /var/run/radvd
+ service_start /usr/sbin/radvd -u $RADVD_USERNAME -C
"$RADVD_CONFIG_FILE" -m stderr_syslog -p /var/run/radvd/radvd.pid
+ else
+ mkdir -p /var/run/radvd
+ service_start /usr/sbin/radvd -C "$RADVD_CONFIG_FILE" -m
stderr_syslog -p /var/run/radvd/radvd.pid
+ fi
}
stop() {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] PATCH: Bump privoxy to version 3.0.19
This version bumps privoxy from 3.0.17 to 3.0.19. Signed-off-by: Adam Gensler --- Index: feeds/packages/net/privoxy/Makefile === --- feeds/packages/net/privoxy/Makefile (revision 29641) +++ feeds/packages/net/privoxy/Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=privoxy -PKG_VERSION:=3.0.17 +PKG_VERSION:=3.0.19 PKG_RELEASE:=3 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-stable-src.tar.gz PKG_SOURCE_URL:=@SF/ijbswa -PKG_MD5SUM:=9d363d738a3f3d73e774d6dfeafdb15f +PKG_MD5SUM:=57acc79059565cc42eda67982842785d PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)-stable PKG_FIXUP:=autoreconf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Toolchain fails to compile on trunk with glibc 2.7
Hi all, I'm attempting to build a fresh trunk pull using glibc 2.7 instead of uClibc. I'm building on a VM of ubuntu server 10.04LTS. This same server is building many OpenWRT builds using uClibc without issue. It is failing, when compiling glibc, with the following error: make[6]: Entering directory `/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7/nptl' i486-openwrt-linux-gnu-gcc pthread_rwlock_tryrdlock.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fhonour-copts -fmerge-all-constants -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -march=k6-2 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final/nptl -I/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i486 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -nostdinc -isystem /home/buildsrvr/openwrt/trunk-glibc/staging_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/lib/gcc/i486-openwrt-linux-gnu/4.5.4/include -isystem /home/buildsrvr/openwrt/trunk-glibc/staging_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/lib/gcc/i486-openwrt-linux-gnu/4.5.4/include-fixed -isystem /home/buildsrvr/openwrt/trunk-glibc/staging_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libpthread=1-o /home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final/nptl/pthread_rwlock_tryrdlock.o -MD -MP -MF /home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final/nptl/pthread_rwlock_tryrdlock.o.dt -MT /home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final/nptl/pthread_rwlock_tryrdlock.o pthread_rwlock_tryrdlock.c: Assembler messages: pthread_rwlock_tryrdlock.c:52: Error: bad register name `%sil' make[6]: *** [/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final/nptl/pthread_rwlock_tryrdlock.o] Error 1 make[6]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7/nptl' make[5]: *** [nptl/subdir_lib] Error 2 make[5]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc/build_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/glibc-2.7-final' make[3]: *** [/home/buildsrvr/openwrt/trunk-glibc/staging_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/stamp/.glibc_built] Error 2 make[3]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc/toolchain/glibc' make[2]: *** [toolchain/glibc/compile] Error 2 make[2]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc' make[1]: *** [/home/buildsrvr/openwrt/trunk-glibc/staging_dir/toolchain-i386_gcc-4.5-linaro_glibc-2.7/stamp/.toolchain_install] Error 2 make[1]: Leaving directory `/home/buildsrvr/openwrt/trunk-glibc' make: *** [world] Error 2 I hope that pasted correctly. If not, the error specifically is: pthread_rwlock_tryrdlock.c:52: Error: bad register name `%sil' To enable glibc, I enabled Developer Tools, Toolchain Options, Use glibc, and changed the version to 2.7 inside of menuconfig. Then I did a standard "make". I found an old ticket regarding glibc and binutils, https://dev.openwrt.org/ticket/7133 , however, this appears to be failing for a different reason than that one. Any suggestions? Google hasn't turned up much. Best regards, Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] alix2 target in trunk
Hi all, I have a question on the updated alix2 target in trunk. It's great to see the alix platform getting some updates in trunk. However, I noticed the default inclusion of the ath5k and ath9k drivers. Alix boards don't come with wireless built in. While it is true that you can add wireless to it, some people do not, myself included. Most of the rest of the included drivers seem to be foundational alix2 platform pieces. Technically the ath5k and ath9k drivers aren't part of the base platform. The packages (kernel modules I guess), in question are: kmod-cfg80211 kmod-mac80211 kmod-ath kmod-ath5k kmod-ath9k hostapd I think it would be better to not include these by default. Presumably if someone is selecting the alix2 target form menuconfig they are already building them own image and can easily select them manually? If someone downloads a prebuilt image from openwrt.com they could always manually include the ath5k or ath9k drivers as necessary afterwards. Thoughts? Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update ntpd to 4.2.6p4
This simply updated the package to the newest version: Index: Makefile === --- Makefile(revision 28379) +++ Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ntp -PKG_VERSION:=4.2.6p3 +PKG_VERSION:=4.2.6p4 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ -PKG_MD5SUM:=59876a9009b098ff59767ee45a88ebd2 +PKG_MD5SUM:=1447121a07b49361677ffda4f6e29527 It builds and functions fine as far as I can tell. Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] secure_mode config options for radvd [2/2]
All, Here's the second change for this, this time in the radvd.hotplug script. This needed to be tweaked slightly so it only issued a HUP to the unprivileged process. Index: radvd.hotplug === --- radvd.hotplug (revision 28379) +++ radvd.hotplug (working copy) @@ -1,5 +1,5 @@ #!/bin/sh if [ "$ACTION" = ifup ]; then - killall -HUP radvd 2>/dev/null +start-stop-daemon -q -K -s HUP -p /var/run/radvd/radvd.pid fi Again, any input is appreciated. Thanks, Adam On Oct 8, 2011, at 2:17 PM, Adam Gensler wrote: > All, > > This is my first try at a patch and also my first attempt at parsing > /etc/config files in OpenWRT. If I've goofed something up please let me know. > The purpose of this change is to allow users to config radvd to run in > unprivileged mode. Per the radvd man page: > > radvd(8) - Linux man page > http://linux.die.net/man/8/radvd > > -u username, --username username > If specified, drops root privileges and changes user ID to username and group > ID to the primary group of username. This is recommended for security > reasons. You might also need to use -p to point to a file in a username > -writable directory (e.g. /var/run/radvd/radvd.pid). > > This patch can parse three new fields in /etc/config/radvd, under "config > radvd", specifically: > option secure_mode1 > option username 'nobody' > option group 'nogroup' > > I think the above is fairly self explanatory. When run with the "-u" option, > radvd spawns two processes, one with root privileges for interface > configuration purposes and another, unprivileged process, for everything else. > > With none of these options configured radvd will operate as it always has. > > Any suggestions and / or input would be appreciated. As I said, this is my > first crack at working with OpenWRT so there's a possibility I did something > incorrect. > > Thanks in advance, > Adam > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] secure_mode config options for radvd [1/2]
All,
Here's an updated version of the radvd.init patch. There's a slight adjustment
here from the original version.
Index: radvd.init
===
--- radvd.init (revision 28379)
+++ radvd.init (working copy)
@@ -407,6 +407,30 @@
return 0
}
+radvd_start_secure() {
+ local cfg=$1
+ local secure
+
+ validate_varname "$cfg" || return 0
+
+ config_get_bool secure "$cfg" secure_mode 0
+ [ "$secure" -ne 1 ] && return 0
+
+ config_get RADVD_USERNAME "$cfg" username
+ if [ -z "$RADVD_USERNAME" ]; then
+ logger -t "radvd startup" "username required for secure mode,
radvd will run as root"
+ return 1
+ fi
+
+ config_get RADVD_GROUP "$cfg" group
+ if [ -z "$RADVD_GROUP" ] ; then
+ logger -t "radvd startup" "group required for secure mode,
radvd will run as root"
+ return 1
+ fi
+
+ return 0
+}
+
start() {
config_load radvd
@@ -425,7 +449,18 @@
sysctl -w net.ipv6.conf.all.forwarding=1 > /dev/null 2> /dev/null
- radvd -C "$RADVD_CONFIG_FILE" -m stderr_syslog -p /var/run/radvd.pid
+ RADVD_USERNAME=
+ RADVD_GROUP=
+ config_foreach radvd_start_secure radvd
+
+ if [ ! -z "$RADVD_USERNAME" ] && [ ! -z "$RADVD_GROUP" ]; then
+ mkdir -p /var/run/radvd
+ chown $RADVD_USERNAME:$RADVD_GROUP /var/run/radvd
+ radvd -u $RADVD_USERNAME -C "$RADVD_CONFIG_FILE" -m
stderr_syslog -p /var/run/radvd/radvd.pid
+ else
+ mkdir -p /var/run/radvd
+ radvd -C "$RADVD_CONFIG_FILE" -m stderr_syslog -p
/var/run/radvd/radvd.pid
+ fi
}
stop() {
Any thoughts and input are appreciated. I've spent several days testing this
and it seems to work well. It will spawn two processes, as previously mentioned:
root@alix:~# ps | grep radvd
2208 root 564 Sradvd -u nobody -C /var/etc/radvd.conf -m stderr_sysl
2211 nobody 564 Sradvd -u nobody -C /var/etc/radvd.conf -m stderr_sysl
Thanks,
Adam
On Oct 8, 2011, at 2:45 PM, Adam Gensler wrote:
> Hmm, it seems the process is dying when the hotplug script is activated. The
> HUP signal is terminating it when running with "-u". Back the drawing board
> here. Sorry for the premature email.
>
> On Oct 8, 2011, at 2:17 PM, Adam Gensler wrote:
>
>> All,
>>
>> This is my first try at a patch and also my first attempt at parsing
>> /etc/config files in OpenWRT. If I've goofed something up please let me
>> know. The purpose of this change is to allow users to config radvd to run in
>> unprivileged mode. Per the radvd man page:
>>
>> radvd(8) - Linux man page
>> http://linux.die.net/man/8/radvd
>>
>> -u username, --username username
>> If specified, drops root privileges and changes user ID to username and
>> group ID to the primary group of username. This is recommended for security
>> reasons. You might also need to use -p to point to a file in a username
>> -writable directory (e.g. /var/run/radvd/radvd.pid).
>>
>> This patch can parse three new fields in /etc/config/radvd, under "config
>> radvd", specifically:
>> option secure_mode 1
>> option username 'nobody'
>> option group 'nogroup'
>>
>> I think the above is fairly self explanatory. When run with the "-u" option,
>> radvd spawns two processes, one with root privileges for interface
>> configuration purposes and another, unprivileged process, for everything
>> else.
>>
>> With none of these options configured radvd will operate as it always has.
>>
>> Any suggestions and / or input would be appreciated. As I said, this is my
>> first crack at working with OpenWRT so there's a possibility I did something
>> incorrect.
>>
>> Thanks in advance,
>> Adam
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] secure_mode config options for radvd
Hi Philip, Thanks for taking a look. To address your two comments: 1. I use Mail.app on Mac OS X 10.7 for email. I don't believe it has any attachment options that let me adjust that setting. I will investigate or perhaps use Thunderbird for this mailer. 2. About the UPPERCASE variable names. Normally I wouldn't use them as such, however, I did so to keep my additions inline with the rest of radvd.init. In any case, there's still some more work to be done such that unprivileged radvd plays nice with hotplug. I'm investigating further. Thanks, Adam On Oct 8, 2011, at 3:49 PM, Philip Prindeville wrote: > On 10/8/11 11:17 AM, Adam Gensler wrote: >> All, >> >> This is my first try at a patch and also my first attempt at parsing >> /etc/config files in OpenWRT. If I've goofed something up please let me >> know. The purpose of this change is to allow users to config radvd to run in >> unprivileged mode. Per the radvd man page: >> >> radvd(8) - Linux man page >> http://linux.die.net/man/8/radvd >> >> -u username, --username username >> If specified, drops root privileges and changes user ID to username and >> group ID to the primary group of username. This is recommended for security >> reasons. You might also need to use -p to point to a file in a username >> -writable directory (e.g. /var/run/radvd/radvd.pid). >> >> This patch can parse three new fields in /etc/config/radvd, under "config >> radvd", specifically: >> option secure_mode 1 >> option username 'nobody' >> option group 'nogroup' >> >> I think the above is fairly self explanatory. When run with the "-u" option, >> radvd spawns two processes, one with root privileges for interface >> configuration purposes and another, unprivileged process, for everything >> else. >> >> With none of these options configured radvd will operate as it always has. >> >> Any suggestions and / or input would be appreciated. As I said, this is my >> first crack at working with OpenWRT so there's a possibility I did something >> incorrect. >> >> Thanks in advance, >> Adam > > Also, I don't think it's the convention to use UPPERCASE variable names. > > -Philip > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] secure_mode config options for radvd
Hmm, it seems the process is dying when the hotplug script is activated. The HUP signal is terminating it when running with "-u". Back the drawing board here. Sorry for the premature email. On Oct 8, 2011, at 2:17 PM, Adam Gensler wrote: > All, > > This is my first try at a patch and also my first attempt at parsing > /etc/config files in OpenWRT. If I've goofed something up please let me know. > The purpose of this change is to allow users to config radvd to run in > unprivileged mode. Per the radvd man page: > > radvd(8) - Linux man page > http://linux.die.net/man/8/radvd > > -u username, --username username > If specified, drops root privileges and changes user ID to username and group > ID to the primary group of username. This is recommended for security > reasons. You might also need to use -p to point to a file in a username > -writable directory (e.g. /var/run/radvd/radvd.pid). > > This patch can parse three new fields in /etc/config/radvd, under "config > radvd", specifically: > option secure_mode1 > option username 'nobody' > option group 'nogroup' > > I think the above is fairly self explanatory. When run with the "-u" option, > radvd spawns two processes, one with root privileges for interface > configuration purposes and another, unprivileged process, for everything else. > > With none of these options configured radvd will operate as it always has. > > Any suggestions and / or input would be appreciated. As I said, this is my > first crack at working with OpenWRT so there's a possibility I did something > incorrect. > > Thanks in advance, > Adam > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] secure_mode config options for radvd
All, This is my first try at a patch and also my first attempt at parsing /etc/config files in OpenWRT. If I've goofed something up please let me know. The purpose of this change is to allow users to config radvd to run in unprivileged mode. Per the radvd man page: radvd(8) - Linux man page http://linux.die.net/man/8/radvd -u username, --username username If specified, drops root privileges and changes user ID to username and group ID to the primary group of username. This is recommended for security reasons. You might also need to use -p to point to a file in a username -writable directory (e.g. /var/run/radvd/radvd.pid). This patch can parse three new fields in /etc/config/radvd, under "config radvd", specifically: option secure_mode 1 option username 'nobody' option group'nogroup' I think the above is fairly self explanatory. When run with the "-u" option, radvd spawns two processes, one with root privileges for interface configuration purposes and another, unprivileged process, for everything else. With none of these options configured radvd will operate as it always has. Any suggestions and / or input would be appreciated. As I said, this is my first crack at working with OpenWRT so there's a possibility I did something incorrect. Thanks in advance, Adam radvd.init.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
