Hi.
I've done some more digging and came up with following:
- The problem only appears when eth0 is used as vlan tagged port -
the frame is longer in this case.
- TEW-632BRP has a ar8216 switch chip. This chip seem to have nice
'feature' of adding two byte header to each packet that arrive
This patch updates libssh2 to version 1.4.3 and also adds its
pkgconfig file to pkgconfig path.
Signed-off-by: Jiri Slachta
---
libs/libssh2/Makefile |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libs/libssh2/Makefile b/libs/libssh2/Makefile
index 01f538f..4410cd
Subject: [PATCH] ar71xx: Add platform machine support for the WNR2000v4
From: Ralph Perlich
This patch adds platform machine support for the Netgear WNR2000v4.
Signed-off-by: Ralph Perlich
---
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -1
Hi folks,
Just thought I should bring to the attention of the list a bit of a
problem that's been uncovered in NTP.
https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks
https://isc.sans.edu/diary/NTP+reflection+attack/17300
Unfortunately I'm not in a position right now to either
Save time by touching /etc/config/sysfixtime, so it's
included in backups
Introduce save_time_interval config (in days) to choose
how often time is saved to flash (default 30)
Use busybox ntpd -S option so time is saved regularly
and not only on clean shutdown/reboot
Fix time on startup if system t
Thanks. Using some (maybe flawed) logic I deducted that bluetooth
devices should all have product='a12/1/*' so I'll match with that.
Hope this info helps also others reading this later...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http
On 2013-12-28 15:45, Jiri Slachta wrote:
> Hi!
>
>>
>> This "cover-letter" is nice, but 2 of the patches miss a proper
>> changelog - pointing at least to the upstream commit-id.
>> As an example Linux-stable [1].
>> A new uClibc 0.9.33.x is overdue...
>
> So what should I do? Should I wait for
Hi!
>
> This "cover-letter" is nice, but 2 of the patches miss a proper
> changelog - pointing at least to the upstream commit-id.
> As an example Linux-stable [1].
> A new uClibc 0.9.33.x is overdue...
So what should I do? Should I wait for next uClibc release or just resend those
patches with
On Sat, Dec 28, 2013 at 2:51 PM, Jiri Slachta wrote:
> Hello,
>
> please consider three previous patches as a patchset. Those patches were
> backported from uClibc
> master which fixes DNS hangups etc..
>
> The patchset:
> http://patchwork.openwrt.org/patch/4650/
> http://patchwork.openwrt.org/pa
Hello,
please consider three previous patches as a patchset. Those patches were
backported from uClibc
master which fixes DNS hangups etc..
The patchset:
http://patchwork.openwrt.org/patch/4650/
http://patchwork.openwrt.org/patch/4649/
http://patchwork.openwrt.org/patch/4648/
Further details a
Signed-off-by: Jiri Slachta
---
.../137-inet_fix_threaded_res_init.patch | 12
1 file changed, 12 insertions(+)
create mode 100644
toolchain/uClibc/patches-0.9.33.2/137-inet_fix_threaded_res_init.patch
diff --git
a/toolchain/uClibc/patches-0.9.33.2/137-inet_fix_threa
Signed-off-by: Jiri Slachta
---
.../136-inet_make_res_init_thread_safe.patch | 55
1 file changed, 55 insertions(+)
create mode 100644
toolchain/uClibc/patches-0.9.33.2/136-inet_make_res_init_thread_safe.patch
diff --git
a/toolchain/uClibc/patches-0.9.33.2/136-in
This patch moves res_init() back above #undef _res. It fixes dns resolving
issue in OpenWrt
(uClibc related - OpenWrt ticket #11929). It is a backport from uClibc master.
Further details are there:
http://git.uclibc.org/uClibc/commit/libc/inet/resolv.c?id=20b69920b299585265eb100d0b67e1097ccb1092
On 2013-12-23 20:00, Catalin Patulea wrote:
> Signed-off-by: Catalin Patulea
> ---
> One more fix. Tested by Manp on this thread:
> https://forum.openwrt.org/viewtopic.php?pid=220700#p220700
Committed in r39174, thanks.
- Felix
___
openwrt-devel mailing
On Sat, Dec 28, 2013 at 9:59 AM, Thomas Strobel wrote:
> Dear all,
>
> does anyone of you maybe have information about the JTAG chain of an AVM
> Fritzbox 3370? Can anyone help me with finding out which devices are
> connected to the JTAG chain, and what their instruction register lengths
> are? O
Dear all,
does anyone of you maybe have information about the JTAG chain of an AVM
Fritzbox 3370? Can anyone help me with finding out which devices are
connected to the JTAG chain, and what their instruction register lengths
are? Or even better, does anyone happen to have a configuration file for
On 28/12/13 05:36, jonsm...@gmail.com wrote:
On Fri, Dec 27, 2013 at 4:16 PM, John Crispin wrote:
Hi
i just pushed a patch that i think will fix the issue. can you please test
it as i don't have access to a rt5350 board right now
Didn't fix it. Still same failure.
ok, i'll have access to a
17 matches
Mail list logo