OpenWrt Forum Archive

Topic: Build for WNDR3700/WNDR3800

The content of this topic has been archived between 9 Jul 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@hnyman

I created your build environment as mentioned on the first page, but I wanted to change the .config.init but I  can't find it.
Should it be in the /Openwrt/Trunk folder?

Thanks in advance.

yes. It is located in the same /Openwrt/trunk directory as normal .config

Ps.
in case you are not very familiar with Unix/Linux: remember to use the "-a" option with ls to see the files starting with "."
ls -la
ls -ls .c*

(Last edited by hnyman on 27 Apr 2015, 07:06)

hnyman wrote:

yes. It is located in the same /Openwrt/trunk directory as normal .config

Ps.
in case you are not very familiar with Unix/Linux: remember to use the "-a" option with ls to see the files starting with "."
ls -la
ls -ls .c*

Thank you for your explanation, yes i'm new to linux.

I am trying to build the environment to make it for the WNDR4300.

Should i make the buildroot first completely and then change the (sh) scripts as you mentioned earlier in this post?

Yesterday i was creating the buildroot changed the scripts to WNDR4300 build the image an ran in a lot of error messages.

What is unclear is that for the WNDR3700/3800 you get the files from a different location i think then the WNDR4300 because this is a nand flash.
Is this something that i should to change in the scripts?

bladeoner wrote:

I am trying to build the environment to make it for the WNDR4300.

Should i make the buildroot first completely and then change the (sh) scripts as you mentioned earlier in this post?

Yesterday i was creating the buildroot changed the scripts to WNDR4300 build the image an ran in a lot of error messages.

What is unclear is that for the WNDR3700/3800 you get the files from a different location i think then the WNDR4300 because this is a nand flash.
Is this something that i should to change in the scripts?

Well, like I meantion in https://forum.openwrt.org/viewtopic.php … 80#p251180 , most of the scripts are rather generic.

you need to edit the device line in .config.init (or with make menuconfig in actual .config, then check the difference)
(probably CONFIG_TARGET_ar71xx_nand_WNDR4300 instead of CONFIG_TARGET_ar71xx_generic_WNDR3700 )

regarding the main scripts:
* updateNmake.sh is almost device independent. A few rm commands, but those should be neutral
* createbuildinfo.sh is heavily tailored to wndr3700 series, as it contains many grep & mv commands looking for that string. But that script does not affect the build process itself, as this step is done after the build. (you might even disable this step from the updateNmake script)

hnyman wrote:

Most likely bug 19439, caused by busybox update at 45272 and most likely fixed by 45321.

Lazy question: I'm on 45222 and time to update. So, apart from the usual precautions, I can expect the config files to survive going to 45613?

tt wrote:
hnyman wrote:

Most likely bug 19439, caused by busybox update at 45272 and most likely fixed by 45321.

Lazy question: I'm on 45222 and time to update. So, apart from the usual precautions, I can expect the config files to survive going to 45613?

Yes. 45222 is earlier than the faulty busybox change.

(Last edited by hnyman on 6 May 2015, 06:29)

Using 45590, I'm experiencing a weird issue.
If my PPPoE session ever goes down, I don't get a public (native) IPv6 after it reconnects. IPv4 comes back fine no matter what.
Once I reboot the router then IPv6 works again till the next disconnection. I have no idea what could be causing this, much less where to look for clues.

please post your /etc/config/network.

Here is /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '10.0.0.100'
        option netmask '255.255.255.224'
        option broadcast '10.0.0.127'
        option dns '10.0.0.100'
        option _orig_ifname 'eth0.1 wlan0 radio1.network1'
        option _orig_bridge 'true'
        option ifname 'eth0.1'
        option ip6assign '56'

config interface 'wan'
        option ifname 'eth1'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option username '********'
        option password '********'
        option ipv6 '1'
        option keepalive '6 5'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'
        option blinkrate '2'
        option max_length '3'
        option enable_vlan4k '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'

config switch_port
        option device 'switch0'
        option port '1'
        option led '6'

config switch_port
        option device 'switch0'
        option port '2'
        option led '9'

config switch_port
        option device 'switch0'
        option port '5'
        option led '2'

config interface 'modem'
        option proto 'static'
        option ifname 'eth1'
        option delegate '0'
        option ipaddr '192.168.255.2'
        option netmask '255.255.255.248'

config interface 'wlan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '10.0.10.100'
        option netmask '255.255.255.224'
        option broadcast '10.0.10.127'
        option dns '10.0.0.100'

config interface 'wan6'
        option proto 'dhcpv6'
        option ifname 'pppoe-wan'
        option _orig_ifname '@wan'
        option _orig_bridge 'false'
        option reqprefix 'auto'
        option peerdns '0'
        option dns '2001:41d0:a:1717::1 2001:1608:10:102::acab 2a02:418:6a04:178                                                  :209:50:232:cafe'
        option reqaddress 'try'

I'm sorely lacking when it comes to IPv6 knowledge (currently addressing that but it'll take a while) and my ISP goes to extra mile to make sure anyone not willing to use their provided locked modem/router won't get any config info.

Please don't set ifname to pppoe-wan but use @wan for the wan6 interface.

That change fixes the issue.

Thank you!

There was discussion about recovering a damaged/zeroed art partition in another thread ( https://forum.openwrt.org/viewtopic.php?id=57261 ), so I made a special version of my firmware that has the mtd write-protection removed from u-boot, u-bootenv and art partitions. That enabled you to edit/overwrite u-boot and art. That is highly dangerous and can permanently brick the router. But it might still be needed at some recovery operation.

The firmware and some explanations can be found in dropbox from subdirectory art_partition_binary_contents/firmware_with_no_write_protection:
https://www.dropbox.com/sh/t52c02rm20y8 … ction?dl=0

Version: Chaos Calmer trunk r45667 2015-05-10

Behaviour in normal write-protected firmware:
---------------------------------------------
root@OpenWrt2:~# mtd unlock u-boot
Could not open mtd device: u-boot
Could not open mtd device: u-boot
root@OpenWrt2:~# mtd unlock firmware
Unlocking firmware ...
root@OpenWrt2:~# mtd unlock art
Could not open mtd device: art
Could not open mtd device: art


Behaviour in this firmware:
---------------------------
root@OpenWrt2:~# mtd unlock u-boot
Unlocking u-boot ...
root@OpenWrt2:~# mtd unlock firmware
Unlocking firmware ...
root@OpenWrt2:~# mtd unlock art
Unlocking art ...

Patch done:

--- trunk/target/linux/ar71xx/image/Makefile
+++ trunk/target/linux/ar71xx/image/Makefile
@@ -102,7 +102,7 @@
   NETGEAR_KERNEL_MAGIC = 0x33373030
   NETGEAR_BOARD = WNDR3700
   IMAGE_SIZE = 7680k
-  MTDPARTS = spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,7680k(firmware),64k(art)ro
+  MTDPARTS = spi0.0:320k(u-boot),128k(u-boot-env),7680k(firmware),64k(art)
   IMAGES := sysupgrade.bin factory.img factory-NA.img
   KERNEL := kernel-bin | patch-cmdline | lzma -d20 | netgear-uImage lzma
   IMAGE/default = append-kernel $$$$(BLOCKSIZE) | netgear-squashfs | append-rootfs | pad-rootfs
@@ -117,7 +117,7 @@
   NETGEAR_KERNEL_MAGIC = 0x33373031
   NETGEAR_ID = 29763654+16+64
   IMAGE_SIZE = 15872k
-  MTDPARTS = spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,15872k(firmware),64k(art)ro
+  MTDPARTS = spi0.0:320k(u-boot),128k(u-boot-env),15872k(firmware),64k(art)
   IMAGES := sysupgrade.bin factory.img
 endef
 

Chaos Calmer 15.05 rc1 has been released.
Announcement: https://forum.openwrt.org/viewtopic.php … 84#p276884
At least the ar71xx build seems to be based on r45695, the same revision as my own build from 2015-05-17.

There is no Chaos Calmer branch yet, but probably a branch will be created in the next few weeks. I will stop building BB14.07 soon after that. I will then build the CC15.05 branch and the trunk (renamed to D????? D?????).

hnyman wrote:

Chaos Calmer 15.05 rc1 has been released.
Announcement: https://forum.openwrt.org/viewtopic.php … 84#p276884
At least the ar71xx build seems to be based on r45695, the same revision as my own build from 2015-05-17.

There is no Chaos Calmer branch yet, but probably a branch will be created in the next few weeks. I will stop building BB14.07 soon after that. I will then build the CC15.05 branch and the trunk (renamed to D????? D?????).

Dancing Dutchman

hnyman wrote:

Chaos Calmer 15.05 rc1 has been released.
Announcement: https://forum.openwrt.org/viewtopic.php … 84#p276884
At least the ar71xx build seems to be based on r45695, the same revision as my own build from 2015-05-17.

There is no Chaos Calmer branch yet, but probably a branch will be created in the next few weeks. I will stop building BB14.07 soon after that. I will then build the CC15.05 branch and the trunk (renamed to D????? D?????).

Do you know whether a config reset is definitely needed when upgrading from BB stable?

ceri wrote:

Do you know whether a config reset is definitely needed when upgrading from BB stable?

No. 95% of the settings are identical. I have been switching between BB14.07 head and CC trunk head firmware in the same router without changing config.

hnyman wrote:
ceri wrote:

Do you know whether a config reset is definitely needed when upgrading from BB stable?

No. 95% of the settings are identical. I have been switching between BB14.07 head and CC trunk head firmware in the same router without changing config.

Good to know. Thanks

@ hnyman, is it posible to change the Regulatory Domain to another region in your source?

The problem that I'm facing is that on the 5 Ghz band I can only use 100 Mbit at this moment because it's restricted to US Domain Reg. I've a 120 Mbit internet connection so I cannot use the last 20 Mbit.

@bladeoner I have not test it, but this may be of interest:
http://luci.subsignal.org/~jow/reghack/README.txt

@hnyman, If this works, I wonder if the reghack.mips.elf file and a script to execute it properly should be put into your build.  That way if people wanted it and it was legal they could execute the script, perhaps automatically at startup.

It should be possible to change regulatory domain. I change it myself in my wifi config to match my country. But I am not including additional stuff, as the official bandwidth is enough for me.

johnthomas00 wrote:

@bladeoner I have not test it, but this may be of interest:
http://luci.subsignal.org/~jow/reghack/README.txt

@hnyman, If this works, I wonder if the reghack.mips.elf file and a script to execute it properly should be put into your build.  That way if people wanted it and it was legal they could execute the script, perhaps automatically at startup.

hnyman wrote:

It should be possible to change regulatory domain. I change it myself in my wifi config to match my country. But I am not including additional stuff, as the official bandwidth is enough for me.

@johnthomas00, I already implemented the reg domain hack without it I cannot choose AP channel 12 and 13 when changing the country in the 2,4 Ghz properties.

@hnyman thanks for your reply. The weird thing is th EEPROM is locked for 0x0 that means US, with changing the country code I see the country code is being used in the Kernel log. But it's still maximum 100 Mbit.

bladeoner wrote:

The weird thing is th EEPROM is locked for 0x0 that means US, with changing the country code I see the country code is being used in the Kernel log. But it's still maximum 100 Mbit.

Hmm.. to my knowledge, the practical speed limit for WAN-LAN traffic with WNDR3700/3800 is about 80-90 Mbit/s if you have QoS enabled (either qos or sqm). I am not sure if you would be able to get 120 Mbit even if you got wider wifi spectrum.

I built my first build from the chaos_calmer branch, which will be CC15.05 release branch. The build went ok and works otherwise ok, but the build is nor able to download rc2 packages, as the package signing key does not match.
( https://lists.openwrt.org/pipermail/ope … 33694.html ) For that reason I am not yet uploading it.

Well, I hope that devs will straighten the keys in a few days. If nothing happens, one solution might be to download the rc2 version and copy the public key from that into my private build...  The creation of the chaos_calmer branch is probably not quite complete, yet, and this kind of practical debugging is needed ;-)

Similarly, trunk has not yet been renamed to Dddd-Dddd, but that will probably happen in near future.

I will probably start creating and publishing CC15.05 builds rather soon.
I will not build new BB14.07 builds, unless some significant bug fix / security fix gets implemented.

chaos-r46002-20150616: first build from the Chaos Calmer 15.05 branch

Developers have included the correct package list signing key in CC15.05, so "opkg update" works and fetches packages from rc2 repo.

Trunk got updated to use "musl" C library instead of "uClibc", which has broken several packages. At least etherwake, aiccu and vsftpd in my build got broken.

I start building stable CC15.05 builds and will try fixing the broken packages in trunk.

(Last edited by hnyman on 16 Jun 2015, 16:00)

r46010: first build from new Dxxx Dxxx trunk (with musl instead of uclibc).

Many of the packages in buildbot snapshots are still broken due to musl, but I have fixed all the packages used in my build.

Hopefully developers reveal the new official name soon. I have changed the name to Dxxx Dxxx as an interim solution.