Signed-off-by: Luka Perkov
---
changes in v2:
* no need to null-terminate string after sprintf()
file.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/file.c b/file.c
index 3831c54..9c1b301 100644
--- a/file.c
+++ b/file.c
@@ -27,6 +27,7 @@
#include
The base code has been taken from zstream project which was
written by Steven Barth.
Signed-off-by: Luka Perkov
CC: Steven Barth
---
changes in v2:
Use new API:
size_t b64decode(void **out, const char *in, size_t len);
size_t b64encode(char **out, const void *in, size_t len);
CMakeLists.txt
Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
Signed-off-by: Luka Perkov
---
changes in v2:
* fix return value at the end
changes in v3:
* fix another return value
ustream-polarssl.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/ustr
On Sat, Apr 11, 2015 at 11:36:14PM +0200, Felix Fietkau wrote:
> On 2015-04-11 23:23, Luka Perkov wrote:
> > Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
> >
> > Signed-off-by: Luka Perkov
> > ---
> > ustream-polarssl.c | 18 --
> > 1 file changed, 12 insertions
On 2015-04-11 23:23, Luka Perkov wrote:
> Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
>
> Signed-off-by: Luka Perkov
> ---
> ustream-polarssl.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/ustream-polarssl.c b/ustream-polarssl.c
Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
Signed-off-by: Luka Perkov
---
changes in v2:
* fix return value
ustream-polarssl.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/ustream-polarssl.c b/ustream-polarssl.c
index cbf24cb..667
Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
Signed-off-by: Luka Perkov
---
ustream-polarssl.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/ustream-polarssl.c b/ustream-polarssl.c
index cbf24cb..ce9b164 100644
--- a/ustream-polarssl.c
Update StrongSwan to 5.3.0 in BB 14.07
(https://github.com/openwrt/packages.git;for-14.07).
Changelog:
https://wiki.strongswan.org/projects/strongswan/wiki/Changelog53
Tested on mpc85xx and ar71xx.
Signed-off-by: Atanas Vladimirov
---
diff --git a/net/strongswan/Makefile b/net/strongswan/Ma
There's a few places here where things are sorted alphabetically.
You've added the uthing beside the dragino2, presumably because it's
based on the dragino2-HE module? Still, it's just another ar9331 board,
so please keep the lists sorted.
Further, the board patch lists it as being based on the
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r
On Fri, Apr 10, 2015 at 07:06:24PM +0200, Daniel Golle wrote:
> On Fri, Apr 10, 2015 at 05:58:04PM +0200, Sven Eckelmann wrote:
> > I had problems in the past with some optimization by from Felix which caused
> > situations like that. For some reason the device was not correctly reseted
> > on
> >
On 04/11/2015 09:59 AM, Rafał Miłecki wrote:
> On 5 April 2015 at 20:03, Nathan Hintz wrote:
>> The mips74k subtarget of brcm47xx configures gcc to compile for mips32r2;
>> however, the generated kernel config for 3.14 and later kernels ends up
>> with CPU_MIPS32_R1 and CPU_MIPSR1 selected. The g
On 5 April 2015 at 20:03, Nathan Hintz wrote:
> The mips74k subtarget of brcm47xx configures gcc to compile for mips32r2;
> however, the generated kernel config for 3.14 and later kernels ends up
> with CPU_MIPS32_R1 and CPU_MIPSR1 selected. The generated kernel config
> for the 3.10 kernel (Barr
Erasing all rootfs_data blocks may cause some problems with partition
identification. It won't contain MAGIC, but will be successfully mounted
with delayed blocks marking. This may be really confusing when user
reboots before JFFS2 finishes its blocks management. During the next
boot rootfs_data wi
Signed-off-by: Rafał Miłecki
---
V3: Update TODO comment to be more clear.
---
jffs2reset.c | 56 +---
1 file changed, 25 insertions(+), 31 deletions(-)
diff --git a/jffs2reset.c b/jffs2reset.c
index 1080883..778a97e 100644
--- a/jffs2reset.c
+
16 matches
Mail list logo
