[OpenWrt-Devel] [PATCH] ar71xx: Compex WPE72 network leds, button and partition change for AA.
Sorry, last patch has mistake. This patch add two network leds, which wasn't included before. Change button problem by adding active_low value. Adding compex partition table changes for AA. https://dev.openwrt.org/ticket/14096 https://dev.openwrt.org/ticket/12475 Signed-off-by: Aleksandr Kolesnik ner...@gmail.com wpeFULL.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Introduce 802.11ac support
Since the ath10k driver is getting along nicely, I reckon its time to get proper
802.11ac support to OpenWrt. This patch introduces 802.11ac support to
base-files,
mac80211 and hostapd. Since the changes overall are rather small, I decided to
put everything in a single patch. Let me know if you prefer this to be split up.
The patch introduces a new hwmode 11acna to the uci wireless configuration
file.
It is a bit superfluous, since ac implies n and a, but this was the approach
that
to me seemed to involve least changes. Also, I didn't yet include support for
VHT160 split in two 80 MHz bands, since it requires an additional user supplied
parameter for the channel of the second band. I'm also not sure if ACS support
in
hostapd is required for ac-support, but I included it anyway. Finally, actually
using 80 MHz channels requires a new regulatory database, which comes when
compat-wireless is updated (not included here).
Signed-off-by: Matti Laakso malaa...@elisanet.fi
---
Index: package/base-files/files/sbin/wifi
===
--- package/base-files/files/sbin/wifi (revision 38640)
+++ package/base-files/files/sbin/wifi (working copy)
@@ -62,7 +62,7 @@
wifi_fixup_hwmode() {
local device=$1
local default=$2
- local hwmode hwmode_11n
+ local hwmode hwmode_11n hwmode_11ac
config_get channel $device channel
config_get hwmode $device hwmode
@@ -79,6 +79,12 @@
esac
config_set $device hwmode_11n $hwmode_11n
;;
+ 11ac*)
+ hwmode_11n=a
+ hwmode_11ac=a
+ config_set $device hwmode_11n $hwmode_11n
+ config_set $device hwmode_11ac $hwmode_11ac
+ ;;
*)
hwmode=
if [ ${channel:-0} -gt 0 ]; then
Index: package/kernel/mac80211/files/lib/wifi/mac80211.sh
===
--- package/kernel/mac80211/files/lib/wifi/mac80211.sh (revision 38640)
+++ package/kernel/mac80211/files/lib/wifi/mac80211.sh (working copy)
@@ -41,6 +41,50 @@
done
[ -n $ht_capab ] append base_cfg ht_capab=$ht_capab
$N
}
+ config_get hwmode_11ac $device hwmode_11ac
+ [ -n $hwmode_11ac ] {
+ hwmode=$hwmode_11ac
+ append base_cfg ieee80211ac=1 $N
+ config_get htmode $device htmode
+ config_get vhtmode $device vhtmode
+ config_get vht_capab_list $device vht_capab
+ idx=$channel
+ case $vhtmode in
+ VHT80)
+ case $channel in
+ 36|40|44|48) idx=42;;
+ 52|56|60|64) idx=58;;
+ 100|104|108|112) idx=106;;
+ 116|120|124|128) idx=122;;
+ 132|136|140|144) idx=138;;
+ 149|153|157|161) idx=155;;
+ esac
+ append base_cfg vht_oper_chwidth=1
$N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT160)
+ case $channel in
+ 36|40|44|48|52|56|60|64)
idx=50;;
+
100|104|108|112|116|120|124|128) idx=114;;
+ esac
+ append base_cfg vht_oper_chwidth=2
$N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ *)
+ case $htmode in
+ HT20) ;;
+ HT40+) idx=$((idx+2));;
+ HT40-) idx=$((idx-2));;
+ esac
+ append base_cfg vht_oper_chwidth=0
$N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ esac
+ for cap in $vht_capab_list; do
+ vht_capab=$vht_capab[$cap]
+ done
+ [ -n $vht_capab ] append base_cfg vht_capab=$vht_capab
$N
+ }
}
local country_ie=0
@@
Re: [OpenWrt-Devel] ADSL Drivers
2013/11/6 Ernesto forosylis...@ernet.com.ar: I've read on http://wiki.openwrt.org/inbox/adsl_support that a user named lorema is making progress towards open ADSL drivers. I'd like to contact him to ask information about how to replicate his experiences, but I don't know how to find his email. Where do you find this kind of info? By looking at the linked OpenWrt forum thread [0] I can see that lorema is trying to recompile leaked non-GPL sources. If he success or not has no real meaning for OpenWrt or Linux world, because that will be illegal to push his code to the kernel. I'm not sure if it's even OK to distribute that code (I doubt a bit). The right way to add support for ADSL is to: 1) Find a group that will write the specs. How they do this doesn't matter. They can RE binary or whatever else they manage to. Please remember that as soon as they get involved in that process, they won't be allowed to work on GPL driver anymore. 2) Find a group that will use prepared specs to write a GPL driver. It's called clean room engineering. It was previously used for Broadcom wireless chipsets and resulted in b43 driver. It seems that specs were started, but I guess they are far from being complete: http://bcm63xx.sipsolutions.net/ [0] https://forum.openwrt.org/viewtopic.php?pid=120035#p120035 -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ADSL Drivers
Dear Rafal, Thanks for your answer. I understand your point and agree with you 100%. But what if I wanted to contact lorema anyway? Or any other user of whom I only had username? What should I do? Regards. El 07/11/2013 10:58, Rafał Miłecki escribió: 2013/11/6 Ernesto forosylis...@ernet.com.ar: I've read on http://wiki.openwrt.org/inbox/adsl_support that a user named lorema is making progress towards open ADSL drivers. I'd like to contact him to ask information about how to replicate his experiences, but I don't know how to find his email. Where do you find this kind of info? By looking at the linked OpenWrt forum thread [0] I can see that lorema is trying to recompile leaked non-GPL sources. If he success or not has no real meaning for OpenWrt or Linux world, because that will be illegal to push his code to the kernel. I'm not sure if it's even OK to distribute that code (I doubt a bit). The right way to add support for ADSL is to: 1) Find a group that will write the specs. How they do this doesn't matter. They can RE binary or whatever else they manage to. Please remember that as soon as they get involved in that process, they won't be allowed to work on GPL driver anymore. 2) Find a group that will use prepared specs to write a GPL driver. It's called clean room engineering. It was previously used for Broadcom wireless chipsets and resulted in b43 driver. It seems that specs were started, but I guess they are far from being complete: http://bcm63xx.sipsolutions.net/ [0] https://forum.openwrt.org/viewtopic.php?pid=120035#p120035 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/1]odhcp6c: Extended message validation support and error hardening
The patch adds addtional message validation supports as described in RFC3313
paragraph 15. Additional the patch implements error checks when socket
primitives are called and some other small bugfixes.
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
src/dhcpv6.c | 166 +---
src/odhcp6c.h |4 --
2 files changed, 110 insertions(+), 60 deletions(-)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index 1deb10e..9b03227 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -44,7 +44,8 @@
static bool dhcpv6_response_is_valid(const void *buf, ssize_t len,
- const uint8_t transaction[3], enum dhcpv6_msg type);
+ const uint8_t transaction[3], enum dhcpv6_msg type,
+ const struct in6_addr *daddr);
static int dhcpv6_parse_ia(void *opt, void *end);
@@ -99,18 +100,19 @@ static bool accept_reconfig = false;
static uint8_t reconf_key[16];
-
int init_dhcpv6(const char *ifname, int request_pd, int sol_timeout)
{
request_prefix = request_pd;
dhcpv6_retx[DHCPV6_MSG_SOLICIT].max_timeo = sol_timeout;
sock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, IPPROTO_UDP);
+ if (sock 0)
+ return -1;
// Detect interface
struct ifreq ifr;
strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
- if (ioctl(sock, SIOCGIFINDEX, ifr))
+ if (ioctl(sock, SIOCGIFINDEX, ifr) 0)
return -1;
ifindex = ifr.ifr_ifindex;
@@ -118,10 +120,11 @@ int init_dhcpv6(const char *ifname, int request_pd, int
sol_timeout)
size_t client_id_len;
odhcp6c_get_state(STATE_CLIENT_ID, client_id_len);
if (client_id_len == 0) {
- ioctl(sock, SIOCGIFHWADDR, ifr);
uint8_t duid[14] = {0, DHCPV6_OPT_CLIENTID, 0, 10, 0,
DHCPV6_DUID_LLADDR, 0, 1};
- memcpy(duid[8], ifr.ifr_hwaddr.sa_data, ETHER_ADDR_LEN);
+
+ if (ioctl(sock, SIOCGIFHWADDR, ifr) = 0)
+ memcpy(duid[8], ifr.ifr_hwaddr.sa_data,
ETHER_ADDR_LEN);
uint8_t zero[ETHER_ADDR_LEN] = {0, 0, 0, 0, 0, 0};
struct ifreq ifs[100], *ifp, *ifend;
@@ -134,10 +137,11 @@ int init_dhcpv6(const char *ifname, int request_pd, int
sol_timeout)
// If our interface doesn't have an address...
ifend = ifs + (ifc.ifc_len / sizeof(struct ifreq));
for (ifp = ifc.ifc_req; ifp ifend
- !memcmp(duid[8], zero, 6); ifp++) {
+ !memcmp(duid[8], zero,
ETHER_ADDR_LEN); ifp++) {
memcpy(ifr.ifr_name, ifp-ifr_name,
sizeof(ifr.ifr_name));
- ioctl(sock, SIOCGIFHWADDR, ifr);
+ if (ioctl(sock, SIOCGIFHWADDR, ifr) 0)
+ continue;
memcpy(duid[8], ifr.ifr_hwaddr.sa_data,
ETHER_ADDR_LEN);
}
@@ -153,7 +157,6 @@ int init_dhcpv6(const char *ifname, int request_pd, int
sol_timeout)
htons(DHCPV6_OPT_DNS_SERVERS),
htons(DHCPV6_OPT_DNS_DOMAIN),
htons(DHCPV6_OPT_NTP_SERVER),
- htons(DHCPV6_OPT_SIP_SERVER_A),
htons(DHCPV6_OPT_AFTR_NAME),
htons(DHCPV6_OPT_PD_EXCLUDE),
#ifdef EXT_PREFIX_CLASS
@@ -162,21 +165,31 @@ int init_dhcpv6(const char *ifname, int request_pd, int
sol_timeout)
};
odhcp6c_add_state(STATE_ORO, oro, sizeof(oro));
+ do {
+ // Configure IPv6-options
+ int val = 1;
+ if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, val,
sizeof(val)) 0)
+ break;
+ if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, val,
sizeof(val)) 0)
+ break;
+ if (setsockopt(sock, IPPROTO_IPV6, IPV6_RECVPKTINFO, val,
sizeof(val)) 0)
+ break;
+
+ val = 0;
+ if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, val,
sizeof(val)) 0)
+ break;
+ if (setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, ifname,
strlen(ifname)) 0)
+ break;
- // Configure IPv6-options
- int val = 1;
- setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, val, sizeof(val));
- setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, val, sizeof(val));
- val = 0;
- setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, val, sizeof(val));
- setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, ifname, strlen(ifname));
+ struct sockaddr_in6 client_addr = { .sin6_family = AF_INET6,
+
[OpenWrt-Devel] [PATCH 1/1]odhcp6c: Server unicast option support
The patch implements server unicast option support as
described in RFC3315 paragraphs 18.1 and 22.12; tested
against an ISC DHCPv6 server implementation
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
src/dhcpv6.c | 49 --
src/odhcp6c.c | 65 +++-
src/odhcp6c.h |3 ++
3 files changed, 112 insertions(+), 5 deletions(-)
diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index 9b03227..b727818 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -26,6 +26,7 @@
#include sys/time.h
#include sys/ioctl.h
#include sys/socket.h
+#include arpa/inet.h
#include netinet/in.h
#include net/if.h
@@ -95,6 +96,8 @@ static int64_t t1 = 0, t2 = 0, t3 = 0;
static int request_prefix = -1;
static enum odhcp6c_ia_mode na_mode = IA_MODE_NONE, pd_mode = IA_MODE_NONE;
static bool accept_reconfig = false;
+// Server unicast address
+static struct in6_addr server_addr = IN6ADDR_ANY_INIT;
// Reconfigure key
static uint8_t reconf_key[16];
@@ -156,6 +159,7 @@ int init_dhcpv6(const char *ifname, int request_pd, int
sol_timeout)
htons(DHCPV6_OPT_SIP_SERVER_A),
htons(DHCPV6_OPT_DNS_SERVERS),
htons(DHCPV6_OPT_DNS_DOMAIN),
+ htons(DHCPV6_OPT_UNICAST),
htons(DHCPV6_OPT_NTP_SERVER),
htons(DHCPV6_OPT_AFTR_NAME),
htons(DHCPV6_OPT_PD_EXCLUDE),
@@ -371,7 +375,29 @@ static void dhcpv6_send(enum dhcpv6_msg type, uint8_t
trid[3], uint32_t ecs)
0, ALL_DHCPV6_RELAYS, ifindex};
struct msghdr msg = {srv, sizeof(srv), iov, cnt, NULL, 0, 0};
- sendmsg(sock, msg, 0);
+ switch (type) {
+ case DHCPV6_MSG_REQUEST:
+ case DHCPV6_MSG_RENEW:
+ case DHCPV6_MSG_RELEASE:
+ case DHCPV6_MSG_DECLINE:
+ if (!IN6_IS_ADDR_UNSPECIFIED(server_addr)
+ odhcp6c_addr_in_scope(server_addr)) {
+ srv.sin6_addr = server_addr;
+ if (!IN6_IS_ADDR_LINKLOCAL(server_addr))
+ srv.sin6_scope_id = 0;
+ }
+ break;
+ default:
+ break;
+ }
+
+ if (sendmsg(sock, msg, 0) 0) {
+ char in6_str[INET6_ADDRSTRLEN];
+
+ syslog(LOG_ERR, Failed to send DHCPV6 message to %s (%s),
+ inet_ntop(AF_INET6, (const void *)srv.sin6_addr,
+ in6_str, sizeof(in6_str)), strerror(errno));
+ }
}
@@ -653,7 +679,8 @@ static int dhcpv6_handle_advert(enum dhcpv6_msg orig, const
int rc,
{
uint16_t olen, otype;
uint8_t *odata, pref = 0;
- struct dhcpv6_server_cand cand = {false, false, 0, 0, {0}, NULL, NULL,
0, 0};
+ struct dhcpv6_server_cand cand = {false, false, 0, 0, {0},
+ IN6ADDR_ANY_INIT, NULL, NULL, 0, 0};
bool have_na = false;
int have_pd = 0;
@@ -691,6 +718,8 @@ static int dhcpv6_handle_advert(enum dhcpv6_msg orig, const
int rc,
} else if (otype == DHCPV6_OPT_PREF olen = 1
cand.preference = 0) {
cand.preference = pref = odata[0];
+ } else if (otype == DHCPV6_OPT_UNICAST olen ==
sizeof(cand.server_addr)) {
+ cand.server_addr = *(struct in6_addr *)odata;
} else if (otype == DHCPV6_OPT_RECONF_ACCEPT) {
cand.wants_reconfigure = true;
} else if (otype == DHCPV6_OPT_IA_PD request_prefix) {
@@ -765,6 +794,7 @@ static int dhcpv6_commit_advert(void)
odhcp6c_add_state(STATE_SERVER_ID, hdr, sizeof(hdr));
odhcp6c_add_state(STATE_SERVER_ID, c-duid, c-duid_len);
accept_reconfig = c-wants_reconfigure;
+ server_addr = c-server_addr;
if (c-ia_na_len)
odhcp6c_add_state(STATE_IA_NA, c-ia_na, c-ia_na_len);
if (c-ia_pd_len)
@@ -884,6 +914,8 @@ static int dhcpv6_handle_reply(enum dhcpv6_msg orig,
_unused const int rc,
continue;
dhcpv6_parse_ia(ia_hdr, odata + olen + sizeof(*ia_hdr));
+ } else if (otype == DHCPV6_OPT_UNICAST olen ==
sizeof(server_addr)) {
+ server_addr = *(struct in6_addr *)odata;
} else if (otype == DHCPV6_OPT_STATUS olen = 2) {
uint8_t *mdata = (olen 2) ? odata[2] : NULL;
uint16_t mlen = (olen 2) ? olen - 2 : 0;
@@ -1163,7 +1195,18 @@ static void dhcpv6_handle_status_code(const enum
dhcpv6_msg orig,
break;
case DHCPV6_UseMulticast:
- // TODO handle multicast status code
+ switch(orig) {
+ case DHCPV6_MSG_REQUEST:
+ case
[OpenWrt-Devel] [packages] sound/mpd: update to mpd 0.16.8
updating to latest mpd requres more work on dependencies (libmms,libaudiofile,libstdcpp) - mpd isn't hosted on sourceforge anymore - fix: https://dev.openwrt.org/ticket/14422 Issue 1: could not replicate Issue 2: update to last mpd 0.16 series fixes compile, its linked to ffmpeg version Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de --- sound/mpd/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/mpd/Makefile b/sound/mpd/Makefile index 19f9b06..baa8059 100644 --- a/sound/mpd/Makefile +++ b/sound/mpd/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=mpd -PKG_VERSION:=0.16.5 +PKG_VERSION:=0.16.8 PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 -PKG_SOURCE_URL:=@SF/musicpd -PKG_MD5SUM:=f7564cff12035f6a1112cce770655df7 +PKG_SOURCE_URL:=http://www.musicpd.org/download/mpd/0.16/ +PKG_MD5SUM:=b412a9d0b3457bea1bb87904a8f80c04 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) PKG_BUILD_PARALLEL:=1 -- 1.8.4.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mtd_get_mac_ascii bugfix
The mtd_get_mac_ascii utility function was broken. This fixes it.
Signed-off-by: Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us
Index: package/base-files/files/lib/functions.sh
===
--- a/package/base-files/files/lib/functions.sh (revision 38679)
+++ b/package/base-files/files/lib/functions.sh (working copy)
@@ -248,15 +248,13 @@
local part
local mac_dirty
- . /lib/functions.sh
-
part=$(find_mtd_part $mtdname)
if [ -z $part ]; then
echo mtd_get_mac_ascii: partition $mtdname not found! 2
return
fi
- mac_dirty=$(strings $part | sed -n 's/'$key'=//p')
+ mac_dirty=$(strings $part | sed -n 's/^'$key'=//p')
# canonicalize mac
printf %02x:%02x:%02x:%02x:%02x:%02x 0x${mac_dirty//:/ 0x}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] lantiq: DGN3500 fixups
Just fixing up a few things for the Netgear DGN3500.
Signed-off-by: Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us
Index: target/linux/lantiq/dts/DGN3500.dtsi
===
--- a/target/linux/lantiq/dts/DGN3500.dtsi (revision 38679)
+++ b/target/linux/lantiq/dts/DGN3500.dtsi (working copy)
@@ -2,7 +2,7 @@
/ {
chosen {
- bootargs-append = console=ttyLTQ0,115200 init=/etc/preinit;
+ bootargs = console=ttyLTQ0,115200 init=/etc/preinit;
};
memory@0 {
Index: target/linux/lantiq/base-files/etc/uci-defaults/02_network
===
--- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
(revision 38679)
+++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
(working copy)
@@ -78,6 +78,8 @@
;;
DGN3500*)
+ lan_mac=$(mtd_get_mac_ascii uboot-env ethaddr)
+ wan_mac=$(macaddr_add $lan_mac 1)
ucidef_set_interface_lan eth0.1
ucidef_add_switch switch0 1 1
ucidef_add_switch_vlan switch0 1 3 2 1 0 5t
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial NAND support for WNDR4300
Hi Stefan, ... Correct. I had to modify ubox to make it work correctly with JFFS2 on emulated MTD devices. On my device, when using ubox without any patchs, I get errors, but it worked somehow... Weird. For me it was working only at the first boot after flashing the image, but any modifications in the fs has been lost after subsequent reboots. I already tested UBIFS on the device by manually overlaying it, technically things look good. But to support proper UBIFS instead of JFFS2 we would need another bunch of changes to ubox and also quite a lot of changes to the init scripts. What do you think, were to begin on this matter? I have no idea, I did not look into that too deep yet. AFAIK the WAN port is not connected to the second ethernet interface, so we are using VLANs to separate that from the LAN ports. It is working, but currently it uses the same MAC address as the LAN interface. Additionally, this MAC address is a randomly genereated one. We should read the correct MAC from the flash and set the interface MAC addresses based on that. You're right, its already configured correctly on eth0.2. Just tested the WAN port, looks good on my device. Thanks for your great work! Having mainline OpenWRT on it, I really like this device! ;) -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] tools: adapt addpattern for WD's Range Extender
2013.11.02. 21:13 keltezéssel, Christian Lamparter írta: A few things had to be changed to add support for these devices: - support code patterns with 8 characters - new board definition for the range extender device Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add My Net Wi-Fi Range Extender device
2013.11.02. 21:14 keltezéssel, Christian Lamparter írta: This patch adds a new device definition for a Western Digital device. The hardware seems to be based on Qualcomm Atheros DB120 design. Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AA (3.3.8) and AR9XXX Kernel bug ? (Emergency Thaw)
AA DISTRIB_REVISION=r38621 In the past few days i may have stumble on a possible kernel bug that has effect on AR9xxx From all routers that i have been using to test the compiled images only 3 fully works apparently without problems while the others end up by freezing after some time. The difference between the working ones and the malfunctioning ones is the chip. Routers affected : DIR-615-C1 (Atheros AR9130) and TL-WR841N 8.3 (AR9341 SoC) Router NOT affected: Dir 601 A1 (Atheros AR7240 rev 2) Dir 615 E1 ((Atheros AR7240) Dir 615 E3 ((Atheros AR7240) Tp-link tl wr703 The only errors i can obtain from any logs before i completely lose serial console access and the router freezes are: 395.83] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) Sync show-task-states(T) Unmount show-blocked-tasks(W) [ 395.86] SysRq : Show Regs [ 395.86] Cpu 0 [ 395.86] $ 0 : 8032 80063340 802c8000 [ 395.86] $ 4 : 1000f400 00fe [ 395.86] $ 8 : f400 81ab [ 395.86] $12 : 80e3a1e4 0001 0001 0047 [ 395.86] $16 : 8032 8032 8031 80311ca1 [ 395.86] $20 : 802d 81ff [ 395.86] $24 : 004764b8 80095220 [ 395.86] $28 : 802c8000 802c9ed0 81ff 80064ba8 [ 395.86] Hi: 005c [ 395.86] Lo: 2b183d00 [ 395.86] epc : 80063360 0x80063360 [ 395.86] Tainted: G O [ 395.86] ra: 80064ba8 0x80064ba8 [ 395.86] Status: 1000f403KERNEL EXL IE [ 395.86] Cause : 00804000 [ 395.86] PrId : 00019374 (MIPS 24Kc) [ 396.08] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) Sync show-task-states(T) Unmount show-blocked-tasks(W) Related links: https://bugzilla.kernel.org/show_bug.cgi?id=47741 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/984273 Just like this one: https://forums.gentoo.org/viewtopic-t-801565-view-previous.html?sid=cf2b78f9e57bf60c9e80057332a367ad Also get these: [12891.19] net_ratelimit: 23 callbacks suppressed [12896.20] net_ratelimit: 4608 callbacks suppressed [46741.06] net_ratelimit: 3 callbacks suppressed I am willing to test patches and or fixes for this issue if anyone has any feedback regarding this problem. I was not able to find much helpful information about it. I would also like to know if anyone else is using the same AA revision (or close) with the same atheros chip and gets the same problem. -- Site: http://wirelesspt.net Mesh: http://tinyurl.com/wirelesspt Admin: http://wirelesspt.net/wiki/Cmsv Twitter: http://twitter.com/wirelesspt Youtube: https://youtube.com/wirelesspt Suporte técnico via sms: 91 19 11 798 Donativos/Paypal: http://tinyurl.com/doar-verba Chave publica PGP/SSH: http://wirelesspt.net/arquivos/pk Licença deste conteúdo: https://creativecommons.org/licenses/by-nc-sa/3.0/pt/ Email assinado digitalmente pelo emissor assegurando autenticidade 0x782BF73E.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Add patch to fix ipset timeout setting problem
Hi.
I've sent these patches to fix an ipset bug some time ago but didn't get
any feedback. Could you please let me know if something is wrong with the
patch or format I've used to send it so I could fix that.
Thanks!
2013/10/31 Nikolay Martynov mar.ko...@gmail.com
Fixes #14325
Signed-off-by: Nikolay Martynov mar.ko...@gmail.com
---
.../utils/ipset/patches/001-timeout-size.patch | 28
++
1 file changed, 28 insertions(+)
create mode 100644
package/network/utils/ipset/patches/001-timeout-size.patch
diff --git a/package/network/utils/ipset/patches/001-timeout-size.patch
b/package/network/utils/ipset/patches/001-timeout-size.patch
new file mode 100644
index 000..b9ff4e2
--- /dev/null
+++ b/package/network/utils/ipset/patches/001-timeout-size.patch
@@ -0,0 +1,28 @@
+diff --git a/lib/parse.c b/lib/parse.c
+index 8ea8542..440ef8f 100644
+--- a/lib/parse.c
b/lib/parse.c
+@@ -1292,15 +1292,20 @@ ipset_parse_timeout(struct ipset_session *session,
+ enum ipset_opt opt, const char *str)
+ {
+ int err;
+- unsigned long long num = 0;
++ unsigned long long llnum = 0;
++ uint32_t num = 0;
+
+ assert(session);
+ assert(opt == IPSET_OPT_TIMEOUT);
+ assert(str);
+
+- err = string_to_number_ll(session, str, 0, UINT_MAX/1000, num);
+- if (err == 0)
++ err = string_to_number_ll(session, str, 0, UINT_MAX/1000, llnum);
++ if (err == 0) {
++ /* Timeout is expected to be 32bits wide, so we have
++ to convert it here */
++ num = llnum;
+ return ipset_session_data_set(session, opt, num);
++ }
+
+ return err;
+ }
--
Thanks.
Nikolay.
--
Martynov Nikolay.
Email: mar.ko...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] zram backport for Attitude Adjustment
On 8 Nov 2013 00:41, Ben West b...@gowasabi.net wrote: As someone who runs AA r38247 patched to include zram support, I can add anecdotal experience that some processes don't behave well when paged to swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh nodes, and I've found that services like olsrd, coovachilli, and wpa_supplicant seem to behave erratically if they're swapped out and then back in. For this reason, I only enable 3MBytes of swap, preferring not to depend on it for normal operation. Only enough so that a node can detect when it's in a low-memory state and do something to recover (e.g. reboot). Have you tried turning down swappiness? The default setting likes to swap things out quicker then you would think. I've not had opportunity to test whether this problem also happens with the newer kernel under BB. On Thu, Nov 7, 2013 at 4:10 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 11/07/2013 12:08 AM, Fernando Frediani wrote: Hi Hauke, What you mean by zram worked differently ? As far as I know zram (previously known as compcache) has been merged to the Linux Kernel at 3.2 so it should be there on 3.3 as well (check drivers/staging/zram). In Kernel 3.3 zram depends on XVMALLOC being build into the kernel, but in OpenWrt our plan was to build zram completely in a module so if someone does not want it nothing changes. I have talked to Bastien in another conversation and he mentioned he has a WRT54G running fine with Barrier Breaker (which has zram as a kmod package), but not sure it's enabled by default or not. I'm interested to to hear if it's having any improvements (how effective the swap zram is being used) and if it is a stripped down build (no LuCI and other packages) or a normal build. Also how big the swap zram should be ? 6MB (as kalua script suggests) or 8MB (half of the memory) ? Yes Bastien made the patch which introduced zram support. If you want that in AA, it should be possible to make it also build as a kernel module. When it is there you can try out what is the best size. I have seen a couple of people saying they have managed to flash brcm47xx Attitude Adjustment to WRT54G routers but got instability issues (slowness or disconnects). Yes flashing works, it just runs out of memory very often and the OOM killer starts to kill processes. So if Barrier Breaker is working fine on WRT54G (with zram activated?) then what would be the challenges to port that work already done back to Attitude Adjustment ? I do not know if it works fine on these devices, but if it does with some traffic going over the router over some time then we should try to backport zram support. Best regards, Fernando On 6 November 2013 18:17, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 11/06/2013 05:15 PM, Fernando Frediani wrote: Hello Hauke, I have seen a few emails from you on openwrt-devel list about the zram module and also saw it is already present on the trunk(Barrier Breaker). Was wondering if there is any work going on or will be to backport it to Attitude Adjustment then perhaps we can run it on the good and old WRT54G and similar models with 16MB ? How difficult is it to backport to AA as it is already done for trunk ? Thanks and best regards, Fernando Hi Fernando, I have no plan to backport zram to Attitude Adjustment. Attitude Adjustment uses kernel 3.3 and there zram worked differently or was not included at all, I do not know exactly. But I would like to see zram backported to AA and would like to see a nice patch. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ 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
