[OpenWrt-Devel] random crashes on ar71xx - [OpenWrt-Commits] r43560 - trunk/target/linux/ar71xx/patches-3.14
Hi,
there were a pile of random crashes that people reported on on ar71xx.
the unaligned patch that we carry with us had a null pointer deref. the
attached commit fixes this bug.
If you have recently seen such crashes please update to r43560 and see
if the crashes are gone now.
John
Original Message
Subject: [OpenWrt-Commits] r43560 - trunk/target/linux/ar71xx/patches-3.14
Date: Mon, 8 Dec 2014 11:48:28 +0100
From: openwrt-comm...@openwrt.org
Reply-To: OpenWrt SVN Commits openwrt-comm...@lists.openwrt.org
To: openwrt-comm...@lists.openwrt.org
Author: nbd
Date: 2014-12-08 11:48:28 +0100 (Mon, 08 Dec 2014)
New Revision: 43560
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
Log:
ar71xx: fix invalid pointer accesses caused by unaligned access hacks
(#18455)
Signed-off-by: Felix Fietkau n...@openwrt.org
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
===
---
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:04:50 UTC (rev 43559)
+++
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:48:28 UTC (rev 43560)
@@ -319,32 +319,26 @@
ptr--;
}
if (tunnel-parms.o_flagsGRE_KEY) {
-@@ -841,9 +841,9 @@ static inline int ip6gre_xmit_ipv6(struc
+@@ -841,7 +841,7 @@ static inline int ip6gre_xmit_ipv6(struc
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
-@@ -1288,9 +1288,9 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+@@ -1285,7 +1285,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -573,7 +573,7 @@ static bool ipv6_hop_jumbo(struct sk_buf
@@ -741,7 +735,7 @@
if (xb)
return i * 32 + 31 - __fls(ntohl(xb));
}
-@@ -668,12 +672,13 @@ int ip6_dst_hoplimit(struct dst_entry *d
+@@ -670,17 +674,18 @@ int ip6_dst_hoplimit(struct dst_entry *d
static inline void ip6_flow_hdr(struct ipv6hdr *hdr, unsigned int tclass,
__be32 flowlabel)
{
@@ -757,6 +751,12 @@
}
static inline __be32 ip6_flowlabel(const struct ipv6hdr *hdr)
+ {
+- return *(__be32 *)hdr IPV6_FLOWLABEL_MASK;
++ return net_hdr_word((__be32 *)hdr) IPV6_FLOWLABEL_MASK;
+ }
+
+ static inline u8 ip6_tclass(__be32 flowinfo)
--- a/include/net/secure_seq.h
+++ b/include/net/secure_seq.h
@@ -2,6 +2,7 @@
@@ -873,7 +873,7 @@
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
-@@ -3631,14 +3631,16 @@ static bool tcp_parse_aligned_timestamp(
+@@ -3629,14 +3629,16 @@ static bool tcp_parse_aligned_timestamp(
{
const __be32 *ptr = (const __be32 *)(th + 1);
___
openwrt-commits mailing list
openwrt-comm...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] random crashes on ar71xx - [OpenWrt-Commits] r43560 - trunk/target/linux/ar71xx/patches-3.14
Is this a trunk only issue or Barrier Breaker and trunk issue?
On Dec 8, 2014 6:55 PM, John Crispin blo...@openwrt.org wrote:
Hi,
there were a pile of random crashes that people reported on on ar71xx.
the unaligned patch that we carry with us had a null pointer deref. the
attached commit fixes this bug.
If you have recently seen such crashes please update to r43560 and see
if the crashes are gone now.
John
Original Message
Subject: [OpenWrt-Commits] r43560 - trunk/target/linux/ar71xx/patches-3.14
Date: Mon, 8 Dec 2014 11:48:28 +0100
From: openwrt-comm...@openwrt.org
Reply-To: OpenWrt SVN Commits openwrt-comm...@lists.openwrt.org
To: openwrt-comm...@lists.openwrt.org
Author: nbd
Date: 2014-12-08 11:48:28 +0100 (Mon, 08 Dec 2014)
New Revision: 43560
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
Log:
ar71xx: fix invalid pointer accesses caused by unaligned access hacks
(#18455)
Signed-off-by: Felix Fietkau n...@openwrt.org
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
===
---
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:04:50 UTC (rev 43559)
+++
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:48:28 UTC (rev 43560)
@@ -319,32 +319,26 @@
ptr--;
}
if (tunnel-parms.o_flagsGRE_KEY) {
-@@ -841,9 +841,9 @@ static inline int ip6gre_xmit_ipv6(struc
+@@ -841,7 +841,7 @@ static inline int ip6gre_xmit_ipv6(struc
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
-@@ -1288,9 +1288,9 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+@@ -1285,7 +1285,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -573,7 +573,7 @@ static bool ipv6_hop_jumbo(struct sk_buf
@@ -741,7 +735,7 @@
if (xb)
return i * 32 + 31 - __fls(ntohl(xb));
}
-@@ -668,12 +672,13 @@ int ip6_dst_hoplimit(struct dst_entry *d
+@@ -670,17 +674,18 @@ int ip6_dst_hoplimit(struct dst_entry *d
static inline void ip6_flow_hdr(struct ipv6hdr *hdr, unsigned int tclass,
__be32 flowlabel)
{
@@ -757,6 +751,12 @@
}
static inline __be32 ip6_flowlabel(const struct ipv6hdr *hdr)
+ {
+- return *(__be32 *)hdr IPV6_FLOWLABEL_MASK;
++ return net_hdr_word((__be32 *)hdr) IPV6_FLOWLABEL_MASK;
+ }
+
+ static inline u8 ip6_tclass(__be32 flowinfo)
--- a/include/net/secure_seq.h
+++ b/include/net/secure_seq.h
@@ -2,6 +2,7 @@
@@ -873,7 +873,7 @@
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
-@@ -3631,14 +3631,16 @@ static bool tcp_parse_aligned_timestamp(
+@@ -3629,14 +3629,16 @@ static bool tcp_parse_aligned_timestamp(
{
const __be32 *ptr = (const __be32 *)(th + 1);
___
openwrt-commits mailing list
openwrt-comm...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits
___
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] random crashes on ar71xx - [OpenWrt-Commits] r43560 - trunk/target/linux/ar71xx/patches-3.14
trunk only, this is a regression that happened when the patches were
updated from 3.10-3.14
On 08/12/2014 11:56, Alpha Sparc wrote:
Is this a trunk only issue or Barrier Breaker and trunk issue?
On Dec 8, 2014 6:55 PM, John Crispin blo...@openwrt.org
mailto:blo...@openwrt.org wrote:
Hi,
there were a pile of random crashes that people reported on on ar71xx.
the unaligned patch that we carry with us had a null pointer deref. the
attached commit fixes this bug.
If you have recently seen such crashes please update to r43560 and see
if the crashes are gone now.
John
Original Message
Subject: [OpenWrt-Commits] r43560 -
trunk/target/linux/ar71xx/patches-3.14
Date: Mon, 8 Dec 2014 11:48:28 +0100
From: openwrt-comm...@openwrt.org mailto:openwrt-comm...@openwrt.org
Reply-To: OpenWrt SVN Commits openwrt-comm...@lists.openwrt.org
mailto:openwrt-comm...@lists.openwrt.org
To: openwrt-comm...@lists.openwrt.org
mailto:openwrt-comm...@lists.openwrt.org
Author: nbd
Date: 2014-12-08 11:48:28 +0100 (Mon, 08 Dec 2014)
New Revision: 43560
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
Log:
ar71xx: fix invalid pointer accesses caused by unaligned access hacks
(#18455)
Signed-off-by: Felix Fietkau n...@openwrt.org mailto:n...@openwrt.org
Modified:
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
===
---
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:04:50 UTC (rev 43559)
+++
trunk/target/linux/ar71xx/patches-3.14/902-unaligned_access_hacks.patch
2014-12-08 10:48:28 UTC (rev 43560)
@@ -319,32 +319,26 @@
ptr--;
}
if (tunnel-parms.o_flagsGRE_KEY) {
-@@ -841,9 +841,9 @@ static inline int ip6gre_xmit_ipv6(struc
+@@ -841,7 +841,7 @@ static inline int ip6gre_xmit_ipv6(struc
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
-@@ -1288,9 +1288,9 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+@@ -1285,7 +1285,7 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
dsfield = ipv6_get_dsfield(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_TCLASS)
- fl6.flowlabel |= (*(__be32 *) ipv6h IPV6_TCLASS_MASK);
+ fl6.flowlabel |= net_hdr_word(ipv6h) IPV6_TCLASS_MASK;
if (t-parms.flags IP6_TNL_F_USE_ORIG_FLOWLABEL)
-- fl6.flowlabel |= ip6_flowlabel(ipv6h);
-+ fl6.flowlabel |= ip6_flowlabel((const struct ipv6hdr
*)net_hdr_word(ipv6h));
+ fl6.flowlabel |= ip6_flowlabel(ipv6h);
if (t-parms.flags IP6_TNL_F_USE_ORIG_FWMARK)
- fl6.flowi6_mark = skb-mark;
-
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -573,7 +573,7 @@ static bool ipv6_hop_jumbo(struct sk_buf
@@ -741,7 +735,7 @@
if (xb)
return i * 32 + 31 - __fls(ntohl(xb));
}
-@@ -668,12 +672,13 @@ int ip6_dst_hoplimit(struct dst_entry *d
+@@ -670,17 +674,18 @@ int ip6_dst_hoplimit(struct dst_entry *d
static inline void ip6_flow_hdr(struct ipv6hdr *hdr, unsigned int
tclass,
__be32 flowlabel)
{
@@ -757,6 +751,12 @@
}
static inline __be32 ip6_flowlabel(const struct ipv6hdr *hdr)
+ {
+- return *(__be32 *)hdr IPV6_FLOWLABEL_MASK;
++ return net_hdr_word((__be32 *)hdr) IPV6_FLOWLABEL_MASK;
+ }
+
+ static inline u8 ip6_tclass(__be32 flowinfo)
--- a/include/net/secure_seq.h
+++ b/include/net/secure_seq.h
@@ -2,6 +2,7 @@
@@ -873,7 +873,7 @@
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
-@@ -3631,14 +3631,16 @@ static bool tcp_parse_aligned_timestamp(
+@@ -3629,14 +3629,16 @@ static bool tcp_parse_aligned_timestamp(
{
const __be32 *ptr = (const __be32 *)(th + 1);
[OpenWrt-Devel] [PATCH uqmi 1/2] Separation of decoding User Data Header from decoding 7 bit message
It is preparation for supporting 8 bit and 16 bit encoding. Moving out
this code from decode_7bit_field() allows to reuse it in caller
function where other than 7 bit decoding will take place.
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
commands-wms.c | 48 +++-
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/commands-wms.c b/commands-wms.c
index 5f159ce..9760d85 100644
--- a/commands-wms.c
+++ b/commands-wms.c
@@ -158,13 +158,13 @@ pdu_decode_7bit_str(char *dest, const unsigned char
*data, int data_len, int bit
return len;
}
-static void decode_udh(const unsigned char *data)
+static int decode_udh(const unsigned char *data)
{
const unsigned char *end;
- unsigned int type, len;
+ unsigned int type, len, udh_len;
- len = *(data++);
- end = data + len;
+ udh_len = *(data++);
+ end = data + udh_len;
while (data end) {
const unsigned char *val;
@@ -185,29 +185,15 @@ static void decode_udh(const unsigned char *data)
break;
}
}
+
+ return udh_len + 1;
}
-static void decode_7bit_field(char *name, const unsigned char *data, int
data_len, bool udh)
+static void decode_7bit_field(char *name, const unsigned char *data, int
data_len, int bit_offset)
{
- const unsigned char *udh_start;
- char *dest;
- int pos_offset = 0;
-
- if (udh) {
- int len = data[0] + 1;
-
- udh_start = data;
- data += len;
- data_len -= len;
- pos_offset = len % 7;
- }
-
- dest = blobmsg_alloc_string_buffer(status, name, 3 * (data_len * 8 /
7) + 2);
- pdu_decode_7bit_str(dest, data, data_len, pos_offset);
+ char *dest = blobmsg_alloc_string_buffer(status, name, 3 * (data_len *
8 / 7) + 2);
+ pdu_decode_7bit_str(dest, data, data_len, bit_offset);
blobmsg_add_string_buffer(status);
-
- if (udh)
- decode_udh(udh_start);
}
static char *pdu_add_semioctet(char *str, char val)
@@ -375,8 +361,20 @@ static void cmd_wms_get_message_cb(struct qmi_dev *qmi,
struct qmi_request *req,
data += 7;
}
- cur_len = *(data++);
- decode_7bit_field(text, data, end - data, !!(first 0x40));
+ data++;
+ int bit_offset = 0;
+
+ /* User Data Header */
+ if (first 0x40) {
+ int udh_len = decode_udh(data);
+ data += udh_len;
+ bit_offset = udh_len % 7;
+ }
+
+ if (data = end)
+ goto error;
+
+ decode_7bit_field(text, data, end - data, bit_offset);
blobmsg_close_table(status, c);
return;
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uqmi 2/2] Added support for 8 bit and 16 bit encoded SMS messages
Message is presented as string of hexadecimal pairs in JSON output.
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
commands-wms.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/commands-wms.c b/commands-wms.c
index 9760d85..74f50aa 100644
--- a/commands-wms.c
+++ b/commands-wms.c
@@ -239,6 +239,15 @@ static void wms_decode_address(char *name, unsigned char
*data, int len)
blobmsg_add_string_buffer(status);
}
+static void blobmsg_add_hex(struct blob_buf *buf, const char *name, unsigned
const char *data, int len)
+{
+ char* str = blobmsg_alloc_string_buffer(buf, name, len * 2 + 1);
+ for (int i = 0; i len; i++) {
+ str += sprintf(str, %02x, data[i]);
+ }
+ blobmsg_add_string_buffer(buf);
+}
+
#define cmd_wms_delete_message_cb no_cb
static enum qmi_cmd_result
cmd_wms_delete_message_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
@@ -318,10 +327,6 @@ static void cmd_wms_get_message_cb(struct qmi_dev *qmi,
struct qmi_request *req,
/* Data Encoding */
dcs = *(data++);
- /* only 7-bit encoding supported for now */
- if (dcs 0x0c)
- goto error;
-
if (dcs 0x10)
blobmsg_add_u32(status, class, (dcs 3));
@@ -374,9 +379,24 @@ static void cmd_wms_get_message_cb(struct qmi_dev *qmi,
struct qmi_request *req,
if (data = end)
goto error;
- decode_7bit_field(text, data, end - data, bit_offset);
- blobmsg_close_table(status, c);
+ switch(dcs 0x0c) {
+ case 0x00:
+ /* 7 bit GSM alphabet */
+ decode_7bit_field(text, data, end - data, bit_offset);
+ break;
+ case 0x04:
+ /* 8 bit data */
+ blobmsg_add_hex(status, data, data, end - data);
+ break;
+ case 0x08:
+ /* 16 bit UCS-2 string */
+ blobmsg_add_hex(status, ucs-2, data, end - data);
+ break;
+ default:
+ goto error;
+ }
+ blobmsg_close_table(status, c);
return;
error:
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar8216: enable cpu port to receive arp and broadcast frames for ar8236
Signed-off-by: Weijie Gao hackpas...@gmail.com --- target/linux/generic/files/drivers/net/phy/ar8216.c | 9 + target/linux/generic/files/drivers/net/phy/ar8216.h | 3 +++ 2 files changed, 12 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c b/target/linux/generic/files/drivers/net/phy/ar8216.c index 558b9f7..91e090a 100644 --- a/target/linux/generic/files/drivers/net/phy/ar8216.c +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c @@ -947,6 +947,15 @@ ar8236_init_globals(struct ar8xxx_priv *priv) ar8xxx_rmw(priv, AR8216_REG_GLOBAL_CTRL, AR8316_GCTRL_MTU, 9018 + 8 + 2); + /* enable cpu port to receive arp frames */ + ar8xxx_rmw(priv, AR8216_REG_ATU_CTRL, + AR8236_ATU_CTRL_RES, AR8236_ATU_CTRL_RES); + + /* enable cpu port to receive multicast and broadcast frames */ + ar8xxx_rmw(priv, AR8216_REG_FLOOD_MASK, + AR8236_FM_CPU_BROADCAST_EN | AR8236_FM_CPU_BCAST_FWD_EN, + AR8236_FM_CPU_BROADCAST_EN | AR8236_FM_CPU_BCAST_FWD_EN); + /* Enable MIB counters */ ar8xxx_rmw(priv, AR8216_REG_MIB_FUNC, AR8216_MIB_FUNC | AR8236_MIB_EN, (AR8216_MIB_FUNC_NO_OP AR8216_MIB_FUNC_S) | diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h b/target/linux/generic/files/drivers/net/phy/ar8216.h index f6df7c8..d437398 100644 --- a/target/linux/generic/files/drivers/net/phy/ar8216.h +++ b/target/linux/generic/files/drivers/net/phy/ar8216.h @@ -40,6 +40,8 @@ #define AR8216_REG_FLOOD_MASK 0x002C #define AR8216_FM_UNI_DEST_PORTS BITS(0, 6) #define AR8216_FM_MULTI_DEST_PORTS BITS(16, 6) +#define AR8236_FM_CPU_BROADCAST_EN BIT(26) +#define AR8236_FM_CPU_BCAST_FWD_EN BIT(25) #define AR8216_REG_GLOBAL_CTRL 0x0030 #define AR8216_GCTRL_MTU BITS(0, 11) @@ -93,6 +95,7 @@ #define AR8216_ATU_CTRL_AGE_EN BIT(17) #define AR8216_ATU_CTRL_AGE_TIME BITS(0, 16) #define AR8216_ATU_CTRL_AGE_TIME_S 0 +#define AR8236_ATU_CTRL_RES BIT(20) #define AR8216_REG_MIB_FUNC0x0080 #define AR8216_MIB_TIMER BITS(0, 16) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uqmi] Fix character @ added at end of received messages
If 7 bit message encoded on 8 bit cells has one last bit occupying
whole byte it need to be padded with 7 zero bits. To not mistake
these last 7 bits with a character with code 0 (@) we need to check
length from User Data Length field and not rely on actual length
of received data. An example can be message abcdefg encoded
as 61 f1 98 5c 36 9f 01, it is decoded as abcdefg@.
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
It depends on my last patches from today.
commands-wms.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/commands-wms.c b/commands-wms.c
index 74f50aa..47d4d76 100644
--- a/commands-wms.c
+++ b/commands-wms.c
@@ -1,5 +1,8 @@
#include qmi-message.h
+#define MIN(a,b) (((a)(b))?(a):(b))
+#define CEILDIV(x,y) (((x) + (y) - 1) / (y))
+
static void cmd_wms_list_messages_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_wms_list_messages_response res;
@@ -191,8 +194,9 @@ static int decode_udh(const unsigned char *data)
static void decode_7bit_field(char *name, const unsigned char *data, int
data_len, int bit_offset)
{
- char *dest = blobmsg_alloc_string_buffer(status, name, 3 * (data_len *
8 / 7) + 2);
- pdu_decode_7bit_str(dest, data, data_len, bit_offset);
+ char *dest = blobmsg_alloc_string_buffer(status, name, 3 * data_len +
2);
+ pdu_decode_7bit_str(dest, data, CEILDIV(data_len * 7, 8), bit_offset);
+ dest[data_len] = 0;
blobmsg_add_string_buffer(status);
}
@@ -366,12 +370,13 @@ static void cmd_wms_get_message_cb(struct qmi_dev *qmi,
struct qmi_request *req,
data += 7;
}
- data++;
+ int message_len = *(data++);
+ int udh_len = 0;
int bit_offset = 0;
/* User Data Header */
if (first 0x40) {
- int udh_len = decode_udh(data);
+ udh_len = decode_udh(data);
data += udh_len;
bit_offset = udh_len % 7;
}
@@ -382,15 +387,19 @@ static void cmd_wms_get_message_cb(struct qmi_dev *qmi,
struct qmi_request *req,
switch(dcs 0x0c) {
case 0x00:
/* 7 bit GSM alphabet */
- decode_7bit_field(text, data, end - data, bit_offset);
+ message_len = message_len - CEILDIV(udh_len * 8, 7);
+ message_len = MIN(message_len, CEILDIV((end - data) *
8, 7));
+ decode_7bit_field(text, data, message_len,
bit_offset);
break;
case 0x04:
/* 8 bit data */
- blobmsg_add_hex(status, data, data, end - data);
+ message_len = MIN(message_len - udh_len, end - data);
+ blobmsg_add_hex(status, data, data, message_len);
break;
case 0x08:
/* 16 bit UCS-2 string */
- blobmsg_add_hex(status, ucs-2, data, end - data);
+ message_len = MIN(message_len - udh_len, end - data);
+ blobmsg_add_hex(status, ucs-2, data, message_len);
break;
default:
goto error;
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, I did some more poking around. I don't know if I am way off course or not, but I hope these findings trigger some ideas. Firstly, I contacted Mikrotik and actually received a response: Hello, that patch will not help you much. However, you can try to debug your FW on RB2011 as it uses same CPU and same Gbit switch chip as RB951G-2HPnD. You have to correctly initialize MAC address of switch chip to make it work. You have to do that via driver so that switch is not forwarding packets when OS is still booting. Regards, Janis K. -- Mikrotik Support I requested access to there kernel patches, instead they gave me something to look into. Since the Routerboard 2011 and the RB951G use the same processor, I took code to expose the SPI config partitions. This way I could confirm the MAC Address was indeed the same that was inside hard_config: Looking at routerboot.h I saw the 4 id inside hard_config is the RB_ID_MAC_ADDRESS_PACK. root@OpenWrt:/dev# cat /dev/mtd1 | hexdump -C 64 72 61 48 00 04 00 1a 00 00 00 00 00 08 00 04 |draH| 0010 4c 5e 0c 6d 24 43 00 00 00 04 00 0e 00 00 00 06 |L^.m$C..| That is the same MAC that is written on the board ( The bottom of the 951G has 4c 5e 0c 6d 24 43 ... 4c 5e 0c 6d 24 48 ). I then checked that MAC against eth0: root@OpenWrt:/dev# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:144 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) Interrupt:4 It all lines up. It's obviously not a MAC initialization problem. The ag71xx driver must be working correctly since RX/TX packets are showing. Since eth0 see's packets, that must mean communication between the ar8327 + ar934x is somewhat working. I'm wondering what we are missing... -- Davey On Fri, Dec 5, 2014 at 12:39 PM, David Hutchison dhutchi...@bluemesh.net wrote: Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, and a dmesg. Here is the arp result as well: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 I used to be able to do: root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch root@OpenWrt:/# swconfig list Found: switch0 - ag71xx-mdio.0 Do you not think this is an issue with ag71xx? Do you it is something in user-space? On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison dhutchi...@bluemesh.net wrote: I am using a very simple test setup with no vlans for now: root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd26:7dae:48cb::/48' config interface 'lan' option ifname 'eth0' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 5 RxPause : 0 RxMulti : 6 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 3252 Rx256Byte : 3 Rx512Byte : 4 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 223169 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 151 TxPause : 0 TxMulti : 324 TxUnderRun : 0 Tx64Byte: 208 Tx128Byte : 93 Tx256Byte : 99 Tx512Byte : 57 Tx1024Byte : 12 Tx1518Byte : 3260 TxMaxByte : 0 TxOverSize : 0 TxByte : 4960741 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 151 RxPause : 0 RxMulti : 324 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 208 Rx128Byte : 93 Rx256Byte : 99 Rx512Byte : 57 Rx1024Byte : 12 Rx1518Byte : 3260 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4960741 RxBadByte : 0 RxOverFlow : 0
Re: [OpenWrt-Devel] au1000 - 3.14 tested needed
* Bruno Randolf b...@thinktube.com [02.12.2014 13:50]:
I just tested it: up running, PCI got detected, Wifi works, looking
good... :)
the same here, ethernet + wifi working.
what is strange: the ethernet-mac is always changing
after each reboot. not sure if this was also the case
with 3.10 - bruno can you see this too?
the workaround here is to fetch it from partition yamon env:
#!/bin/sh
. /lib/functions.sh
. /lib/functions/system.sh
PARTITION=$( find_mtd_part yamon env )
MAC=$( sed -n '/ethaddr/{n;p;}' $PARTITION | tail -n1 )
MAC=$( macaddr_canonicalize $MAC )
ucidef_set_interface_macaddr lan $MAC
# in my case: 00:0e:56:00:0f:c5
# - the same which is on the sticker on the bottom side
what is also strange: 'yamonenv' is installed, but simply
does not work. i never used it before, so i'am not sure
if it was ever working...
bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] request for ar7 test hw / 3.14 testing
Not to be stupid, but how new device would do? I might have some age old ZyXEL P660-H hardware lying around our hackerspace for nothing, but old they are indeed :) Sami Olmari On Dec 8, 2014 8:19 AM, John Crispin blo...@openwrt.org wrote: Hi, i just bumped ar7, it is only compile tested. i tried getting my hands on ar7 hw, managed to get 2 boards. one does not power up and the other one has a uart connector welded and not soldered to it and fails to give stable serial output. does anyone have a working ar7 board that they want to send me ? also if anyone feels like testing the 3.14 i would appreciate the effort. John ___ 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
[OpenWrt-Devel] [PATCH RESEND 2/2] kirkwood: Iomega ix2-200: use all remaining MTD space for rootfs
Signed-off-by: Richard Kunze richard.ku...@web.de
---
.../kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch | 13 +
1 file changed, 13 insertions(+)
create mode 100644
target/linux/kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch
diff --git
a/target/linux/kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch
b/target/linux/kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch
new file mode 100644
index 000..46005c5
--- /dev/null
+++ b/target/linux/kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch
@@ -0,0 +1,13 @@
+--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+@@ -195,8 +195,8 @@
+ };
+
+ partition@40 {
+- label = uInitrd;
+- reg = 0x54 0x100;
++ label = rootfs;
++ reg = 0x40 0x1C0;
+ };
+ };
+
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RESEND 1/2] kirkwood: Iomega ix2-200: wire up the GPIO poweroff driver in the DTS file
Signed-off-by: Richard Kunze richard.ku...@web.de
---
.../linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch | 13 +
1 file changed, 13 insertions(+)
create mode 100644
target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
diff --git a/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
b/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
new file mode 100644
index 000..62f244c
--- /dev/null
+++ b/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
@@ -0,0 +1,13 @@
+--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+@@ -168,6 +168,10 @@
+ gpios = gpio1 3 GPIO_ACTIVE_LOW;
+ };
+ };
++ gpio-poweroff {
++ compatible = gpio-poweroff;
++ gpios = gpio0 17 GPIO_ACTIVE_LOW;
++ };
+ };
+
+ nand {
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] request for ar7 test hw / 3.14 testing
several older avm boxes laying arround. if yo want one or more, pm me. 2014-12-08 22:33 GMT+01:00 Sami Olmari s...@olmari.fi: Not to be stupid, but how new device would do? I might have some age old ZyXEL P660-H hardware lying around our hackerspace for nothing, but old they are indeed :) Sami Olmari On Dec 8, 2014 8:19 AM, John Crispin blo...@openwrt.org wrote: Hi, i just bumped ar7, it is only compile tested. i tried getting my hands on ar7 hw, managed to get 2 boards. one does not power up and the other one has a uart connector welded and not soldered to it and fails to give stable serial output. does anyone have a working ar7 board that they want to send me ? also if anyone feels like testing the 3.14 i would appreciate the effort. John ___ 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 -- -BEGIN PGP PRIVATE KEY BLOCK- Version: Keybase OpenPGP v1.1.3 Comment: https://keybase.io/crypto xcaGBFRIHG4BEAC5PYYUn4BxFb/n+ZwLVt88LwBmYHmvJOrCNR+k6N7bCKzpYiYn dnxNJtue881iHyCb1mJMc/YADK2pK+jna3GZszPuXcN3k5XzzTAqC2jFGlPrnp5+ NMml3ItNMR9TEnPsRkUk3lGhItDGXIupSjh/Q1vgWSFfXLnCQW3uBgiI4n64l2ck 23oAuJCJPsdeQ/7MHGjzMxLBD7brUO1mfUr+kwnayIsW6I251FPH81CBEnh3Nr/e DDntQ4BPWFscVjZrhepOfDugIc2eFDBt2nFl3Wxy7hpoLT/Wl3zMbWRikw0jOTng 9Tn74Yl+Df66MHh/5OP/7THUp5F1gMHCXqkzsdcJq5TOHNnft7B1tAy5CM+wqHwY CwwgTSmJIjeh/YFhLuX2frhdLuOsDsjD5JlavXCM7jjVZLlwWp9V6jYAW0AaGDKz mzp8qnZWTZe385n9aK4HVqvb9csNfcXRW3H6U1tKsksoedPPWbb40ydfH3bcbes6 0/1exAdeVCmQZtxOlXtk7XU4fj9ng2s1n8K2dHaRWCITN64bDo9oEx7uXvYG2lDs o4W5FqtA/1URzjMKAUey37/5Gcg57KDVeK4UfGPm8wgrPmWF7faseOzv8T+HAMpJ Fz9EW12wlcd7U5gD9/gmBuCCwvIJAH53EhiY64NywTrVTFsOzBdOIVOG+QARAQAB /gkDCA2j/9YLAa5FYIqNZwzILMtiY1r1d2J4FX+lFM5ZzdTrWGei7A5tTMA3GJly LnYBVTVVoMO1n0sSRhhdeQlyYnqF3itrdcZid0GTv4yIkb3R755LDnXMGot/aj/z 2Pz9/FKLjUu3VCg0wyVw6mabMRloEBE07MjFxkzU+PALLW13HwoIsJxjun/rBeVM A4HpgG+tqa7mvKuaXE6QZ7CCnYBnBPntzk2Xk/fkoxSlurvGlKCyP4y2nDWB1tGa WXUhGo08J5T4nf2ANRQqBqWtzuLKyzmP5m5KEDzWfS+SWwfBF+z71u93bt0dGKFg srh4jTI4gXIu3lTfDOJVEBUi0YghDW2v+ZVOk+L2lwqFZz7d6nDrlE0ztAU3yhSq HgmGMAyeMwyFxfV9c+6wM6XkXL1Yx8oDaSx6XwS0CE2hG3nBZVXkzWNGQDCZxxPh xC3k1Dt3gZ79WahvwJznnAPS2vosZsKNmqU2fh+4TCLy7MppxXFuNpmeCLdIn/T0 BOUryFdlGdS8Z5ikWSKGLGKLemIlNOGdH+qSTbv9Dj+0hVCy8HQOLex+ThLc43mJ ZUTZhLrDiSyQBO5eb4kSWtjfaDuIKvM1dXm9oh/cuTKBTf8yM67DCcKD6rWYk7w4 t12K67nGYxzprWWEpoHv+XcnHJ7/bXGZJlP4EeiWvdLkszq/YVxnR/Tp/rkF1EDH bm5BPqivb35TCEhdUS21bzT/odv21eGCCZ4l/OurvnCwlq2OU2PhJa+vD5xvr9U6 Kh5vSlt6yobj/QYOInAwERZp+JOUur616ZZFt9208eO9oc4XOwj08C2pNsAoyx8O ApopMLbV5l9HRNfzMo5Tt9fr13Uu2EDa9OMKx7HYkbNQbzaicTKOPHue8KmtDTe9 D+A8bKDzu5s4VEKfizS5FpfTchx9YdmzGeucbCqUVK/S/CM3DB6zztQbU3Jx6SKJ cRyvSa5GB1Pf10D7jHhj8A+VXvoYOrBSx9oUdflBIxHbuLrNEiewlvVbb2EqMslZ OgroXRNeC8/Y2/Aena4dISnmR1yCsZ4bupdLldw64W+DF/64+xacYy6oFtoLZfRq f6092OPZjVsU1Gj/0zay2Cf4+RAcD+OLFPpV+YqaNM8xrP4jWmVj2ZlhOLw+C3WY 1gDAN85uSB0MitNUR2vd6O3K9jCX/vrea7FN6rvdp8DROSfmmVD/04SFe/px20br 3oBomrrppY9R63c3gvWPYpl+uaW+optFjl9WJagR8SkzE5JJqC8MqdcWrtTaei8q r3yO86wXtVDtCMnu8FamXZRvzuRjC8VTX9Wlwz902jWkL+1PqaVeG4lE86dQNbH0 lwAAzpzVBn5QT8UBEpqUmbg0TRg+AtUJc1n5zJmfAVfhY7GqrcKms0L0c0Sjv2PT IUJ7SEu8VTzvrggp0gOTVel30A6JivT7fk5k5lZ86xTGI7JxvNoB0s3rRsVdu0m3 w5AvwqMsnGBAthumI+Sn5ufWQ+0y4j0H4NXMiHFi53fBUi8Lq6ZEbCj8C2lJvEQq j+L5vfxpcdQ2ob/CEbrBkNRXVRcAmjlICYeLuZxq1dlk7QrHSqpWg2tvZ4fg6Iev AY4xVe/mVgwiOJJEPXmyLTG2cndSwfkVI3bmbmRi7pHHLyOpVuc8Q8HrckN/QE2Z 8nZxO3J31V7ym4RoqP7Wqhen0ZFFtuGf2KJWzVZylJsBPgmV4ldXqL7Ftm9pc02z uMwxKsVZC2HAbFwWW5hDrsvWUsn+Yo85JIU/NxL3YjNkpUPjly0UkDbNJ2tleWJh c2UuaW8vaGVpbmk2NiA8aGVpbmk2NkBrZXliYXNlLmlvPsLBbQQTAQoAFwUCVEgc bgIbLwMLCQcDFQoIAh4BAheAAAoJEGG7M6BETdd9AsMQALdN6V4nYS8WXIx1PGXF CdHk3f1X4iq2dlmQNj+9GDSFTtUAhVSs4UorLDj48iU7QvdnJU8rpMKLr5swrv4N FVxQ2tIGWMuPGbX+19G3i3oc4cuEPEK+4veTeBhKl6ISZslcc8YKYgsjvEptb6AH Uc7FobFHOaxTvgAsi+IJmovax3pHyO9AAsTHnz/uBl4wgOk83RUPLQx1/PIon9hm D19Btl0fY8H4QIwzshGobmyt0UuS+ggbqN7XZfrln4ChxcitKOXKO7BaH9RAid9H 9LZJL90iOnFZiPkuUnuGKMUErwTqj4Zx5ixZTPRC7hJpttbEzLM4ZmZ8ZxdUK2RN v5hYe4DK/doEz+BmhyzF1ZWO0bjL7g4eWMsd7wFUqwTklmeTGRtWtHf5hEAgyJ4n wvrqi/uUFcI4bwrZ9Ltvftih5rol6zS7HiWU64FsrlFXQ5lWW/D3TvnH8hNEgVWB /zGxKqn1b1B8r1tsOMIH7S82o91LFHB+JDKVd7ZYQQE2HcTBjDk6pcwBxQ39TWGD 75voxIj+m8XBACSM4ny4SnfeaxDFBneyP2of2WXEAEN7oy9kWTODOs8AzNs4Uw10 hHZFYjhmC594Du/EAsoZhQmRNIBgMJoxWztrISewYXQs5E0Ao+O8MygAU5/zqEY9 PLeqRquNzDxUXL2dL33gEx/ux8MGBFRIHG4BCADLroo+vNvaU1mxIfbtin0Sw7+F TUVWoLRfkPLRGEwBznNraa8H4U6yccylwUq+h2zjooHzZMS5dnOgs2+PZzFMrXO6 JX2q1ptwAYCxh4Ft2G3ptAFa3rsL2MVSgymknQvNf0OVlcHkOxrbh6O5Hp0nRnpd pUpBsiRqFHG04tLBr5vRSkBxo3ms5xTv1bPNLUtlRg5bu+Chy5sJC8i0rCPb5f6J IBBP0+F2z57h0xvGzUBNBYES1oQe0Ae5Shx6oosVS2aiqxPovWHxKBJol4TmtUTI KwRK5g1cg9PSWOBJZvNgQE/UI6UQXLOO+s06ys9LknJ/Ukso+NbrNe2BeFOvABEB
