Hello Hnyman,
I am a new user of your builds. I thank you.
From your first post I should be able to intall any package of "attitude adjustment"
This is not the case for the package "ebtables" (http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/ar71xx/generic/packages/)

I need this package to use IPV6 Free Telecom, a French ISP using 6rd.

I usually do the following ahter installing ebtables:

ebtables -t broute -A BROUTING -p ! ipv6 -i eth1 -j DROP
ebtables -A FORWARD -p ! ipv6 -o eth1 -j DROP
brctl addif br-lan eth1
ebtables -A OUTPUT -p ! ipv6 -o eth1 -j DROP

Thanks

(Last edited by Manani on 31 Oct 2012, 20:47)

I can not check the integrity of the image file when upgrading by doing:
WNDR3700-attitude-r34013-2012-10-30-1901-md5sums -c WNDR3700-attitude-r34013-2012-10-30-1901-md5sums

Am i doing something wrong?

Indeed, the kernel modules kmod-fs-nfs[d] and kmod-fs-nfs-common cannot be replaced by their 'generic' cousins -- as I know from experience. Everything else about NFS can be put or forced into place if you care.

Read https://forum.openwrt.org/viewtopic.php?id=39961

The md5sums file is just a text file containing the checksum list, (and the filenames contained in the file are coming from the original compiler and do not quite match the final names). Check the firmware file's md5 checksum manually and compare to the value in the list.

(I use the list to compare the checksum value shown in the LuCI GUI, when flashing a new version.)

(Last edited by hnyman on 31 Oct 2012, 21:46)

Thank you for your answer.
I have read several times the discussion that you show me (I speak little English). That means I can not use ebtables with your version even if I can force the installation?

It means that you can try to force it (with opkg options), but as the package has been compiled at a different time than my version, the package might not be 100% compatible with the kernel in my version. And that might then crash your system. On the other hand, it might work.

@hnyman, in your build feature, you have the following:

It appear that the kernel has been patched for more entropy on https://dev.openwrt.org/changeset/33559. So is the rng-tools still necessary?

No, and it is not included. I switched to haveged when that was introduced, and used that for some time, but after r33559 just the built-in entropy collection:
- haveged as entropy source in trunk since 30685
- Trunk 33560: removed haveged as entropy source, as r33559 declares bug #9631 fixed in kernel

Thanks for the quick reply. I just assumed that the feature list is updated when you update the build version numbers on the first page.

I have been recently having strange trouble with my WNDR3700 builds. For some reason they seem to fail either in my 3700v2 or alternatively in 3700v1. Based on the boot log from serial console, the boot fails already at Netgear's original u-boot code, before the Openwrt's Linux kernel even gets uncompressed. As the end result, the router gets automatically stuck to the TFTP recovery mode (with the green power led slowly blinking) and it can then be recovered with TFTP using a previous factory.img version of the firmware.

Serial console's output is not very clear regarding the actual error, but that message is apparently coming from the lzma/squashfs uncompression routines in the embedded u-boot boot manager.

 Verifying Checksum ... OK
### SQUASHFS loading 'image/uImage' to 0x80800000
lzma_fs returned unexpected result 0x1
SQUASHFS error: squashfs_readdir: read_block
### SQUASHFS LOAD ERROR<0> for image!

More discussion and context can be found at https://forum.openwrt.org/viewtopic.php?id=40565

To me it looks like it is either something strange producing somehow damaged images or my routers' flash chips have started fail roughly at the same time in both routers.

I have flashed both routers over 100 times, so it might be that the flash chip is getting tired and some bits are not getting properly erased/toggled any more. Thus only those firmwares that happen to match the faulty bits do work.

I have uploaded v34174 to http://koti.welho.com/hnyman1/Openwrt/trunk_error_does_not_boot/
It works perfectly in my 3700v2, but does not work in my 3700v1. (I have already recovered my 3700v1 several times using the 34089 build...)

It would be great if somebody with v1 would be courageous and would test that 34174 build in his 3700v1 and would report if it works. If it does work, then the image is ok and the fault is in my router. If it doesn't work, there might be something wrong in the image generation process. (Most likely some recent update in Ubuntu 12.04 breaks havoc, but even that sounds strange as toolchain gets built from own sources.)

I have already ordered a new WNDR3800, so that I will be able to better test if it is a faulty flash chips in my current routers.

If anybody has debugging advice, please tell me. How to test the flash chip condition?

I have version 34135 since its release and it works fine. I'll test the version 34174 immediately. Goodbye, maybe.

I've got green power led slowly blinking with both bin and img files.

Unlocking firmware ...

Writing from <stdin> to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found
Error fixing up TRX header
Upgrade completed
Rebooting system...

I came back to r34135.

Thanks, then it probably isn't a bad flash chip in my router, but something in the actual images. Good in one sense, but bad as I have to now find out, what makes these images unusable. :-(

(Last edited by hnyman on 17 Nov 2012, 17:28)

One new person with the same problem regarding compiling wndr3700/3800 firmwares has surfaced, so this is not a hardware problem. See:
https://forum.openwrt.org/viewtopic.php?pid=183561#p183561
https://lists.openwrt.org/pipermail/openwrt-devel/2012-November/thread.html#17445

Currently it looks like that generated lzma image somehow chokes the lzma decompression in the built-in u-boot bootstrap routines in the router. As those are original Netgear stuff, the fix needs to be made for the lzma image generation. I have no idea, why this problem has surfaced now...

Check whether your distro updated some LZMA or gcc packages recently.

Looks like the reason is too large lzma dictionary size (default 23 bits = 8 MB) and/or the non-default compression options used by ar71xx for the lzma command line. Those created a file that choke the decompression routines of Netgear's u-boot. More explanation at https://forum.openwrt.org/viewtopic.php?pid=183596#p183596

Probably the devs should change the default lzma dictionary size from 23 bits (8 MB) to 20 bit or lower.

trunk-r34245-2012-11-18 works again ok in both of my routers (v1 and v2) after I made the following change.

--- trunk/target/linux/ar71xx/image/Makefile    (revision 34245)
+++ trunk/target/linux/ar71xx/image/Makefile    (working copy)
@@ -69,7 +69,7 @@
 endif
 
 define CompressLzma
-  $(STAGING_DIR_HOST)/bin/lzma e $(1) -lc1 -lp2 -pb2 $(2)
+  $(STAGING_DIR_HOST)/bin/lzma e $(1) -lc1 -lp2 -pb2 -d20 $(2)
 endef
 
 define PatchKernelLzma

I also tested with "$(STAGING_DIR_HOST)/bin/lzma e $(1) $(2) " and also that worked ;-)

(Last edited by hnyman on 18 Nov 2012, 18:15)

Good news, you overcome worry. r34245 works fine forme!

Edit: But I still can not run the 6rd.

(Last edited by Manani on 18 Nov 2012, 20:10)

I'm going to build a fresh CentOS install to attempt a build from. I find it odd that things suddenly stopped working. Out of curiosity what distro do others use for building?

I'm building OpenWrt trunk on a Ubuntu Server 12.04 x64.

(Last edited by written_direcon on 19 Nov 2012, 00:29)

juhosg has applied a modified version of the lzma dictionary size patch to trunk with r34248.
https://dev.openwrt.org/changeset/34248

I am using Ubuntu 12.04 x64 (in Virtualbox with Windows 7 x64 as the underlying host).

Hi hnyman, did you ever get a release with this working:
https://forum.openwrt.org/viewtopic.php?id=36276

Thanks

No, I dropped my trials as the new Codel logic as the main QoS works well enough. That was introduced roughly at the same time.

Thanks for the quick response

I built a test version with new kernel 3.6.7 and am running it now in my own router. Support for 3.6 & 3.7 kernels is being currently implemented in Openwrt, and the kernel has already been set as the default for some target platforms, but not ar71xx used by WNDR3700.

The version can be found from http://koti.welho.com/hnyman1/Openwrt/trunk-r34288-2012-11-21-kernel367/ and includes also the new luci-commands module.

(Last edited by hnyman on 21 Nov 2012, 20:07)