This patch helps properly detect a WNDRMAC device. Before this
patch the model is detected as "NETGEAR ?????????N".
Signed-off-by: Roman A. aka BasicXP <x12ozmouse@ya.ru>
SVN-Revision: 32453
This adds kmod-leds-wndr3700-usb package to a default build for
WNDR3700, WNDR3800 and WNDRMAC in order to support the green USB LED.
Signed-off-by: Roman A. aka BasicXP <x12ozmouse@ya.ru>
SVN-Revision: 32452
This patch adds support for the Korean made Petatel PSR-680W Wireless CDMA Router.
The platform is based on Ralink RT3052.
http://wiki.openwrt.org/toh/petatel/psr-680w
Signed-off-by: Dmitry Shmygov <shmygov at rambler.ru>
SVN-Revision: 32450
Hi,
yes, it is true...
In the standard, unpatched trunk is zlib_inflate.ko compiled, but not included
in any package... So, my previous version was functional, but with system bug.
Here is fixed patch.
On Wed, Jun 13, 2012 at 05:00:02PM +0200, Jo-Philipp Wich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi.
>
> Shouldn't you also add CONFIG_ZLIB_DEFLATE to KCONFIG then?
>
> ~ Jow
> - -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/YqrcACgkQdputYINPTPM6dgCfYDgzK1XHiKDJNSdc/+HgIoRp
> HSgAoKdUxcqXzHqTLiyEkiQqCnDuuVmu
> =0DUX
> - -----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/YqvIACgkQdputYINPTPNMagCePNwPSYHfoCd5eXywQ+sTATqQ
> 2CQAoJW/Fez+DqflHlJVcvng/LvsfrCm
> =s6B0
> -----END PGP SIGNATURE-----
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Signed-off-by: Michal Heppler <mhepp@ics.muni.cz>
SVN-Revision: 32444
Hi,
I found that openssl did not compile on the uml target under x86_64. The
attached patch should
correct this and is working for me. Is this the right way to do it?
thanks,
Thomas
SVN-Revision: 32443
insight GDB version 6.8-1 sources have apparently changed.
The original file is no longer available upstream.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
SVN-Revision: 32438
This patch enables few extra kernel options for the kvm_guest subtarget:
- Tickless kernel to avoid timer ticks in idle guests, reduces CPU usage
- Enable paravirtualization steal time support
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
SVN-Revision: 32436
kmod-ipt-nathelper-extra is missing the package nf_conntrack_broadcast.ko
if it is not included into the kmod-ipt-nathelper-extra packge the modules
nf_conntrack_snmp and nf_nat_snmp_basic cant get loaded:
[ 44.500000] nf_conntrack_snmp: Unknown symbol nf_conntrack_broadcast_help (err 0)
[ 44.664000] nf_nat_snmp_basic: Unknown symbol nf_nat_snmp_hook (err 0)
Signed-off-by: Peter Wagner <tripolar@gmx.at>
SVN-Revision: 32434
This patch adds support for manually configuring 6rd tunnels. It depends on
the netifd patches I sent earlier, which add 6rd support.
A basic interface configuration looks like:
config interface 'wan6'
option proto '6rd'
option peeraddr '192.0.2.1'
option ip6prefix '2123::'
option ip6prefixlen '16'
option ip4prefixlen '0'
Where ip4prefixlen is optional and actually defaults to 0, which would use all
bits of the IPv4 in the calculated IPv6 subnet.
I believe it should be possible to configure a regular 6to4 tunnel using this,
and that we may want to merge the two eventually, but there are some larger
differences between the two at the moment:
- 6rd addresses can be more difficult to calculate. My ISP, for example, has
a setup with a v6 mask of 43 bits, and a v4 mask of 19.
- 6to4 has support for configuring radvd. This is something we want, of
course, but it seems best to deal with this in a separate patch.
Just creating a new package looked like the quickest way to get this in.
This work is based on the 6in4 package, and work by Stijn Tintel.
Signed-off-by: Stéphan Kochen <stephan@kochen.nl>
SVN-Revision: 32431
BCM6338 and BCM6338 have their MSG_CONTROL register width of 8-bits instead of
16-bits. We were previously using a 16-bits write which corrupted the first
byte of the TX FIFO. Also the message type was always set to Full-duplex even
in the case of half-duplex messages.
SVN-Revision: 32409
