[OpenWrt-Devel] GNUnet for Battlemesh
Dear OpenWRT-hackers, i am from the project EDN that has the goal to increase privacy and security for everyone's communication - especially in and by open wireless communities. For that reason we want to test several promising projects. One of it is GNUnet that we aim to have running in the Battlemesh. For that purpose there has already been done some effort/: https://github.com/openwrt/packages/tree/master/net/gnunet To make it really happen we plan one or more meetings in Leipzig, Halle or Berlin, depending on the people willing to come. Who likes to learn and support GNUnet for the Battlemesh is welcome!:) More info at https://wiki.freifunk.net/GNUnet-meets-OpenWRT All the best Demos -- EDN https://wiki.c3d2.de/Echt_Dezentrales_Netz/en Title: GNUnet-meets-OpenWRT – wiki.freifunk.net GNUnet-meets-OpenWRT Aus wiki.freifunk.net Wechseln zu: Navigation, Suche Inhaltsverzeichnis [Verbergen] 1 GNUnet meets OpenWRT 1.1 Envisioned use-cases 1.2 Show during Battlemesh 1.3 Brainstorming topics 2 Time and Location for the Initial meeting 3 Contact GNUnet meets OpenWRT GNUnet-meets-OpenWRT has the goal to prepare GNUnet for the upcoming Battlemesh in the first week in august. Using the packaging of GNUnet for OpenWRT provided by dangowrt, we are now able to deploy portions of GNUnet to WLan router - Kudos! To prepare GNUnet for the Battlemesh, we need your help: set-up GNUnet in a way that allows for running the Battlemesh benchmarks on top of GNUnet VPN. The benchmarks mainly use ping and iperf. refine and test its configuration and packaging especially clean up the packaging of gnunet-utils (Currently, some scripts require openssl, some other require certtool) remove dependencies towards libraries too big or not useful for small storage-limited devices migrate scripts to use OpenWRT provided tools Envisioned use-cases The goal is to have reproducible recipies to get stuff running out-of-the-box, at least: only cadet (wrt841 and such) cadet + vpn + gns (routers with 8mb flash) cadet + gns + datastore (nas devices and plugs to donate 24/7 storage) Ideally we'll also get started on: cadet + gns + conversation (basic "feature-phone") cadet + vpn + gns + conversation + datastore + fs (all currently available features) ??? fs- file sharing Show during Battlemesh The following things would be useful to show during Battlemesh: Basic setup of GNUnet on OpenWrt How to use GNUnet VPN on OpenWrt How to use GNUnet's GNS on OpenWrt How to visualize CADET (i.e. real-time topology graph) Brainstorming topics Router Web-UI integration of basic GNUnet services, ie. cadet, vpn and gns. It should allow users to manage EGOs, integrate GNS with dnsmasq and easily setup VPN links. -> we need a GNUnet-plugin for rpcd, see -> we need a neet luci2 UI using that interface. using GNUnet as a distributed PKI infrastructure which could be usable as an authentication-layer for wpa_supplicant, e.g. on 802.11s instead using SAE.The current GNUnet-way to directly use WiFi via injection is limited to very low transfer speeds using injection (ie. layer-1). I imagine that this or other existing out-of-band connections to GNUnet could be used for session-setup/keying on P2P/"WiFi-Direct", 802.11s or Ad-Hoc mode and subsequently enjoy the performance of UDPv6 over the now setup layer-2 (+link-local-layer-3) link. This would bring about a huge performance gain and if built around the wpa_supplicant's control socket to setup a GO it could even work on some smartphones with broken/jailed fullmac wifi...It would also be very useful for wireless community networks as it would finally allow participants to technically implement individual pico-peering agreements -- not only for authentication and keying, but also for channel selection and minimum-transfer-rate agreements/ consensus. Time and Location for the Initial meeting Time: Dudle Poll Location: Dudle Poll (or where ever) Contact If you have got a question or want to come write an email. To get the lists public key for encryption send an empty unsigned message. To subscribe to the EDN-mailinglist send your public key. What is EDN? Von „https://wiki.freifunk.net/index.php?title=GNUnet-meets-OpenWRT&oldid=29122“ Kategorie: Konferenzen Navigationsmenü Webteam | Impressum | Kontakt Worum geht's? Wie mache ich mit? Wiki Meine Werkzeuge FamoosDiskussionEinstellungenBeobachtungslisteBeiträgeAbmelden Namensräume Seite Diskussion Varianten Ansichten Les
Re: [OpenWrt-Devel] Alsa-lib (libasound) segfaults on TLS variable (musl on mips)
* Szabolcs Nagy [2015-06-24 22:57:54 +0200]:
> the bug is that mips tls access uses a hard coded -32768
> offset relative to whatever __tls_get_addr returned.
>
> and musl did not account for this offset.
>
only affects mips shared objects with 'static __thread' variables,
extern __thread variables worked fine (and only those were
tested in the libc-tests).
> the attached patch fixes the issue for me,
> we will fix it in musl soon.
better patch attached that undoes the offset for extern tls
vars in relocs handling.. (and with more consistent naming)
diff --git a/arch/mips/pthread_arch.h b/arch/mips/pthread_arch.h
index f8e35ae..904a248 100644
--- a/arch/mips/pthread_arch.h
+++ b/arch/mips/pthread_arch.h
@@ -13,4 +13,6 @@ static inline struct pthread *__pthread_self()
#define TLS_ABOVE_TP
#define TP_ADJ(p) ((char *)(p) + sizeof(struct pthread) + 0x7000)
+#define DTP_OFFSET 0x8000
+
#define CANCEL_REG_IP (3-(union {int __i; char __b;}){1}.__b)
diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c
index b77c6f6..b4ca410 100644
--- a/src/ldso/dynlink.c
+++ b/src/ldso/dynlink.c
@@ -337,7 +337,10 @@ static void do_relocs(struct dso *dso, size_t *rel, size_t rel_size, size_t stri
*reloc_addr = def.dso->tls_id;
break;
case REL_DTPOFF:
- *reloc_addr = tls_val + addend;
+#ifndef DTP_OFFSET
+#define DTP_OFFSET 0
+#endif
+ *reloc_addr = tls_val + addend - DTP_OFFSET;
break;
#ifdef TLS_ABOVE_TP
case REL_TPOFF:
diff --git a/src/thread/__tls_get_addr.c b/src/thread/__tls_get_addr.c
index 3633396..94ea03c 100644
--- a/src/thread/__tls_get_addr.c
+++ b/src/thread/__tls_get_addr.c
@@ -1,6 +1,10 @@
#include
#include "pthread_impl.h"
+#ifndef DTP_OFFSET
+#define DTP_OFFSET 0
+#endif
+
void *__tls_get_addr(size_t *v)
{
pthread_t self = __pthread_self();
@@ -8,9 +12,9 @@ void *__tls_get_addr(size_t *v)
__attribute__((__visibility__("hidden")))
void *__tls_get_new(size_t *);
if (v[0]<=(size_t)self->dtv[0])
- return (char *)self->dtv[v[0]]+v[1];
- return __tls_get_new(v);
+ return (char *)self->dtv[v[0]]+v[1]+DTP_OFFSET;
+ return (char *)__tls_get_new(v)+DTP_OFFSET;
#else
- return (char *)self->dtv[1]+v[1];
+ return (char *)self->dtv[1]+v[1]+DTP_OFFSET;
#endif
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211: ath9k: fix qca956x name also
Signed-off-by: Roman Yeryomin
---
.../patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch | 8
1 file changed, 8 insertions(+)
diff --git
a/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
b/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
index 2674efb..c005c00 100644
---
a/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
+++
b/package/kernel/mac80211/patches/385-ath9k_hw-fix-device-ID-check-for-AR956x.patch
@@ -18,3 +18,11 @@ Signed-off-by: Felix Fietkau
}
val = REG_READ(ah, AR_SREV) & AR_SREV_ID;
+@@ -3169,6 +3170,7 @@ static struct {
+ { AR_SREV_VERSION_9550, "9550" },
+ { AR_SREV_VERSION_9565, "9565" },
+ { AR_SREV_VERSION_9531, "9531" },
++ { AR_SREV_VERSION_9561, "956X" },
+ };
+
+ /* For devices with external radios */
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alsa-lib (libasound) segfaults on TLS variable (musl on mips)
* Ted Hess [2015-06-23 18:04:35 -0400]:
> Segfault in 'snd_lib_error_set_local' (error.c) referencing
> static __thread snd_local_error_handler_t local_error;
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0041b164 in snd_lib_error_set_local ()
> (gdb) bt
> #0 0x0041b164 in snd_lib_error_set_local ()
> #1 0x0041fb68 in try_config ()
> #2 0x00420d80 in snd_device_name_hint ()
> #3 0x0040a3be in pcm_list ()
> #4 0x0040e92a in main ()
> (gdb) disas
> Dump of assembler code for function snd_lib_error_set_local:
> 0x0041b12c <+0>: lui gp,0x8
> 0x0041b130 <+4>: addiu gp,gp,23668
> 0x0041b134 <+8>: addu gp,gp,t9
> 0x0041b138 <+12>: addiu sp,sp,-16
> 0x0041b13c <+16>: lw t9,-29872(gp)
> 0x0041b140 <+20>: sw ra,12(sp)
> 0x0041b144 <+24>: sw s0,8(sp)
> 0x0041b148 <+28>: sw gp,0(sp)
> 0x0041b14c <+32>: move s0,a0
> 0x0041b150 <+36>: addiu a0,gp,-29376
> 0x0041b154 <+40>: jalr t9
> 0x0041b158 <+44>: nop
> 0x0041b15c <+48>: lui v1,0x0
> 0x0041b160 <+52>: addu v1,v1,v0
> => 0x0041b164 <+56>: lw v0,-32768(v1)
> 0x0041b168 <+60>: sw s0,-32768(v1)
thanks for the report
the bug is that mips tls access uses a hard coded -32768
offset relative to whatever __tls_get_addr returned.
and musl did not account for this offset.
the attached patch fixes the issue for me,
we will fix it in musl soon.
diff --git a/arch/mips/pthread_arch.h b/arch/mips/pthread_arch.h
index f8e35ae..626b9bb 100644
--- a/arch/mips/pthread_arch.h
+++ b/arch/mips/pthread_arch.h
@@ -13,4 +13,6 @@ static inline struct pthread *__pthread_self()
#define TLS_ABOVE_TP
#define TP_ADJ(p) ((char *)(p) + sizeof(struct pthread) + 0x7000)
+#define DTV_OFFSET 0x8000
+
#define CANCEL_REG_IP (3-(union {int __i; char __b;}){1}.__b)
diff --git a/src/thread/__tls_get_addr.c b/src/thread/__tls_get_addr.c
index 3633396..bcc9be3 100644
--- a/src/thread/__tls_get_addr.c
+++ b/src/thread/__tls_get_addr.c
@@ -1,6 +1,10 @@
#include
#include "pthread_impl.h"
+#ifndef DTV_OFFSET
+#define DTV_OFFSET 0
+#endif
+
void *__tls_get_addr(size_t *v)
{
pthread_t self = __pthread_self();
@@ -8,9 +12,9 @@ void *__tls_get_addr(size_t *v)
__attribute__((__visibility__("hidden")))
void *__tls_get_new(size_t *);
if (v[0]<=(size_t)self->dtv[0])
- return (char *)self->dtv[v[0]]+v[1];
- return __tls_get_new(v);
+ return (char *)self->dtv[v[0]]+v[1]+DTV_OFFSET;
+ return (char *)__tls_get_new(v)+DTV_OFFSET;
#else
- return (char *)self->dtv[1]+v[1];
+ return (char *)self->dtv[1]+v[1]+DTV_OFFSET;
#endif
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revert 46119 (hardening: make override variables more intuitive)
Hi, Le 24 juin 2015 16:19, "Steven Barth" a écrit : > > Hi Etienne, > > I don't get your issue. 46119 only unifies the override variables, > meaning if a package maintainer wants to override e.g. RELRO he now > only needs to add PKG_RELRO:=0 instead of adding two for both RELRO > modes. > Sorry i looked at it on my phone and really too quickly, and missed the ifdef before each changes Just ignore me and continue the good work! > > Cheers, > > Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] oldpackages for CC
On 24/06/2015 16:25, Karl Palsson wrote: > > Steven Barth wrote: >> oldpackages are obsolete and in many instances riddled with security >> issues. >> They should not be used at all. > > Right, but that's not really relevant here. This is about packages > which are up to date, have maintainers, but are not in old packages, and > not in the for-15.05 branch, they're only in the master branch. > then the maintainer should send a PR to have it merged in for-15.05 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] oldpackages for CC
Steven Barth wrote: > oldpackages are obsolete and in many instances riddled with security > issues. > They should not be used at all. Right, but that's not really relevant here. This is about packages which are up to date, have maintainers, but are not in old packages, and not in the for-15.05 branch, they're only in the master branch. Saso, oldpackages wasn't being built as binaries anyway, so this should only really matter if you're building your own images right? You can proably just file an issue/pull on the packages repo on github to get a package moved the for-15.05 branch. It shouldn't be problematic in cases like these, given that it didn't exist there, so can't really be considered any sort of major version change. Sincerely, Karl Palsson___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Revert 46119 (hardening: make override variables more intuitive)
Hi Etienne, I don't get your issue. 46119 only unifies the override variables, meaning if a package maintainer wants to override e.g. RELRO he now only needs to add PKG_RELRO:=0 instead of adding two for both RELRO modes. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] px5g-standalone: fix compilation after fortify-headers
* Hannu Nyman [2015-06-23 22:05:54 +0300]: > px5g-standalone: fix compilation after fortify-headers > > New fortify-headers functionality (default after r46117) is apparently > conflicting with gcc "-pedantic" option. The package px5g-standalone fails > to compile due to "error: #include_next is a GCC extension" errors. See > https://dev.openwrt.org/ticket/19975 > > Fix the compilation of px5g-standalone by removing the "-pedantic" gcc option. it seems to me that adding __extension__ in front of the include_next line in the fortify headers make the warning go away. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Revert 46119 (hardening: make override variables more intuitive)
Hi all, Please reread r46119 Relro full != relro partial Fortify source 1 != fortify source 2 Ssp != ssp strong Regards Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
