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.

Two recent changes in my build & testing process:

1) I have bought also WNDR3700v2 with 16 MB flash, as long as they are on the market (before the Broadcom-based v3 will retire v2). I am switching that to be my main router, so in future I am daily running the v2 firmware builds myself, not the traditional v1 ones. I will keep also the v1 as a secondary router, possibly with WDS activated, so also the v1 firmware will get regular usage. (There is no practical difference in the firmwares, as the build process just makes both versions from identical kernel etc.)

2) I figured out an easy and secure way to attach my own configuration to the flashable firmware. I have been using a USB stick to store the needed files for both Backfire and Trunk, but I wanted to simplify the process, as I have been regularly switching between trunk & Backfire.

In practice I only need a couple of config files, as all other defaults are tailored to my needs already in the built firmware openly available in my FTP directory. The list of my config files is short: /etc/config/dhcp, firewall, luci_statistics, qos, wireless and radvd, /etc/dropbear/authorized_keys for having SSH key-based authentication and /etc/vsftpd.conf for FTP server.

I package those files with tar, separately for v1 & v2 and backfire & trunk, 4 filesets in total, each has size less than 4 kB.
That tar.gz file is then encrypted with ccrypt and included in the firmware (e.g. /etc/v1trunk.cpt and v2trunk.cpt in the trunk build.)
I am including the needed ccrypt package in the build.
Additionally, there is a short shell script for easy unpacking the settings file to /etc
This adds a few kilobytes to the firmware size, but not much. In practice, the size of the flashed firmware remained the same.

The unpacking script /etc/hnsettings.sh :

#!/bin/sh
cp -f $1 /tmp/HNsettings.cpt
if [ "$?" -eq 0 ] ; then
  ccdecrypt -vf /tmp/HNsettings.cpt
  if [ "$?" -eq 0 ] ; then
    tar -xzv -f /tmp/HNsettings -C /etc
  fi
fi

Screenshot of a script run:

root@OpenWrt:~# cd /etc/
root@OpenWrt:/etc# ./hnsettings.sh v2trunk.cpt
Enter decryption key:
Decrypting /tmp/HNsettings.cpt
config/
config/radvd
config/network
config/firewall
config/luci_statistics
config/qos
config/wireless
config/dhcp
dropbear/
dropbear/authorized_keys
vsftpd.conf
root@OpenWrt:/etc#

This enables me to pretty easily restore all settings after a flash. Of course, should I change some settings permanently, I need to rebuild those encrypted settings archives.

(Last edited by hnyman on 5 Sep 2011, 18:28)

Thanks for the heads-up. Regarding the preconfigured settings, are you saying that we can overlay our own settings when installing? I'm not sure how this might add functionality above the usual upgrade scenario.

tt wrote:

Regarding the preconfigured settings, are you saying that we can overlay our own settings when installing? I'm not sure how this might add functionality above the usual upgrade scenario.

For the other "end users" of my firmware, there is no real benefit, as there is no way to include your settings in my flash image.

That is merely a suitable way for those who create the original firmwares (and also put them available for download by others) to include own personal settings in the build, without forcing everybody to use the private settings and without revealing personal settings like WLAN passkeys etc., but still have them easily available.

My firmware continues to ship with generic default settings, but I can now easily unpack my real settings from the encrypted archive file.  Additionally, a hardware reset will revert my firmware to the normal generic settings, but the real settings are also there, easily available without any file transfer or a USB memory stick.

I wrote that previous explanation for two reasons: I wanted to highlight the reason for three new files in /etc directory and I wanted to explain the method for others who compile own flash images.

Probably you know, in case you do not:
http://www.bufferbloat.net/
http://www.bufferbloat.net/projects/cerowrt
http://www.bufferbloat.net/projects/iscwrt
http://www.bufferbloat.net/projects/uberwrt

I don't know what's what, but they concentrate on IPv6 and testing and bufferbloat.

Regarding bufferbloat, I stumbled upon this: http://bryanpendleton.blogspot.com/2010 … twork.html
Sadly he doesn't say a word on virtual software interfaces, and how they affect things further. Like: physical interface1=eth0, virtual1=eth0.2 and then virtual2=pppoe-dsl

As far as I know, that stuff has nothing do with my vanilla Openwrt build. Their work is supposedly more targeted for improving the underlying architecture / resource usage of routers etc.

I think they target simple settings as well, not only stuff that has to be applied with C-code patches.

hnyman wrote:

1) I have bought also WNDR3700v2 with 16 MB flash, as long as they are on the market (before the Broadcom-based v3 will retire v2). I am switching that to be my main router, so in future I am daily running the v2 firmware builds myself, not the traditional v1 ones.

Do you happen to know whether there are any issues loading a config file from a v1 install onto a fresh v2 one? Thinking to make a similar switch, myself! Not that I need anywhere near 16MB. Like you, I run only router stuff on my router.

tt wrote:

Do you happen to know whether there are any issues loading a config file from a v1 install onto a fresh v2 one? Thinking to make a similar switch, myself! Not that I need anywhere near 16MB. Like you, I run only router stuff on my router.

I copied my v1 config files to the v2, and it succeeded for all other config files except /etc/config/wireless. The wireless config includes the MAC address for each radio device, so using v1 config in a new v2 (or in another v1) will fail: I had suddenly 4 radios (2 with old MACs from v1, and 2 auto-detected but unconfigured from v2). Replacing the old v1 MACs in config with the proper v2 MAC addresses cured that.

I only copied those 10 files listed above, so it is possible that trying to copy the full contents of /etc or /etc/config might fail for similar hardware ID related reasons.

But otherwise the devices are practically identical, so the config files should be interchangeable in principle.

hnyman wrote:

it succeeded for all other config files except /etc/config/wireless.

Good point. Checking my v1 config, I don't see any other hardware dependencies, and it looks like simply deleting /etc/config/wireless from the settings tarball would be an easy solution. This would give the install a chance to probe for other capabilities and initialize the cards cleanly, then it's just two tabs to finish setup. I'll give it a try if I do end up making the switch.

I have created and included a new 'rng-tools' package after r28242 for preventing /dev/random block sue to entropy exhaustion. See ticket #9631 for more info on entropy exhaustion on ar71xx devices: https://dev.openwrt.org/ticket/9631

The rng-tools' rngd daemon feeds pseudo-random numbers from /dev/urandom to /dev/random.

Index: /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile
===================================================================
--- /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile    (revision 0)
+++ /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile    (revision 0)
@@ -0,0 +1,37 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=rng-tools
+PKG_VERSION:=3
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://downloads.sourceforge.net/project/gkernel/rng-tools/3/
+PKG_MD5SUM:=fa305916ec101c85c0065aeceb81a38d
+
+PKG_FIXUP:=libtool
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/rng-tools
+  SECTION:=utils
+  CATEGORY:=Utilities
+  DEPENDS:=+USE_UCLIBC:argp-standalone
+  TITLE:=Daemon for adding entropy to kernel entropy pool
+  URL:=http://sourceforge.net/projects/gkernel/
+endef
+
+ifdef CONFIG_USE_UCLIBC
+CONFIGURE_VARS += \
+    LIBS="-largp"
+endif
+
+define Package/rng-tools/install
+    $(INSTALL_DIR) $(1)/etc/init.d
+    $(INSTALL_BIN) ./files/rngd.init $(1)/etc/init.d/rngd
+    $(INSTALL_DIR) $(1)/usr/bin
+    $(INSTALL_BIN) $(PKG_BUILD_DIR)/rngtest $(1)/usr/bin/
+    $(INSTALL_DIR) $(1)/sbin
+    $(INSTALL_BIN) $(PKG_BUILD_DIR)/rngd $(1)/sbin/
+endef
+
+$(eval $(call BuildPackage,rng-tools))
Kronyx wrote:

I have this image https://forum.openwrt.org/viewtopic.php … 22&p=1 already installed on my WNDR3700V2, but i want to try your release, can i just take your factory image and upload it on my router ?

If you already have a running OpenWrt image in the router, then use the "sysupgrade" image and install it from the existing LuCI interface .

Perfect, Thanks for your quick reply !

@hnyman, sorry to bother you again, what is the difference between the backfire and the trunk version on your FTP ?

Thanks

Backfire is the "stable" 10.03 branch, but is to some extent based on March 2010 status of Openwrt. 
Trunk/"Attitude Adjustment" is the development version.
http://wiki.openwrt.org/about/history

I have been using both just to make sure that both builds work, alternating maybe weekly. Personally I slightly prefer Backfire, as trunk is not offering anything really new/different for me, and Backfire used to have slightly lower system load.

Trunk is the more adventurous one, as there are some changes every day. There are only rare changes to Backfire. On the other hand, trunk has all the newest features and add-ons available.
https://dev.openwrt.org/timeline

I too prefer the Backfire version, and have been running hnyman's various backfire builds for months. One very annoying behavior in Trunk is that the upgrade scenario doesn't preserve all the settings - the router IP network always resets to the default for instance (192.168.1.x), and I have to manually correct it. I guess if I never upgraded the version, I wouldn't care, but that's kind of the point of running OpenWRT. :-)

Bottom line, as a pure router package I don't think you can go wrong with either version. The core package is simple and stable, and all the opkg's install just fine.

Is this a good time to again say thanks for maintaining these builds? Much appreciated!

I must say that i prefer the backfire too, the trunk have some minor problems as described by tt, the only question i have so far is how can i access my USB drive connected on the router ? I see it on the mount points as /dev/sda1 but when i try to connect on \\10.1.1.1\ i see nothing ...

Mounted file systems
Filesystem    Mount Point    Available    Used
/dev/root
/rom
0.00 B / 4.38 MB
100% (4.38 MB)
tmpfs
/tmp
29.95 MB / 30.27 MB
1% (328.00 KB)
tmpfs
/dev
512.00 KB / 512.00 KB
0% (0.00 B)
/dev/mtdblock4
/overlay
9.71 MB / 10.13 MB
4% (428.00 KB)
mini_fo:/overlay
/
0.00 B / 4.38 MB
100% (4.38 MB)
/dev/sda1
/mnt/sda1
1.64 GB / 698.63 GB
100% (697.00 GB)
Mount Points
Mount Points define at which point a memory device will be attached to the filesystem
Enabled    Device    Mount Point    Filesystem    Options    Root    Check    

?
?
?
defaults
no
no
 

Label: Share
/mnt/sda1
ntfs
defaults
no
no
 



Thanks.

Kronyx wrote:

I must say that i prefer the backfire too, ... the only question i have so far is how can i access my USB drive connected on the router ? I see it on the mount points as /dev/sda1 but when i try to connect on \\10.1.1.1\ i see nothing ...

You should be able to access it quite normally (as a directory) from the Linux terminal command line prompt.
My build does not include any filesharing packages like Samba, MiniDLNA etc. If you want that kind of functionality, you have to install and configure the packages with opkg from the repository.

(Last edited by hnyman on 1 Oct 2011, 16:13)

Thanks for your reply, i have tried with Samba but no luck, i'm gona try to find something more user friendly !

No changes in the actual functionality during the month, but I have rebuilt the whole thing. I noticed that there was unnecessary bloat from old dependencies, (as the .config file does not remove dependent packages when you remove the one originally causing the other package to get included.)

To avoid going through 'make menuconfig' and manually selecting all the things when making the .config cleanup, I pruned the .config file leaving only the needed settings & packages and made a file '.config.init' out of that. This .config.init file can be used to overwrite .config and then run 'make defconfig' to get the the dependent packages and platform-related defaults added there.

Example of my trunk .config.init:

CONFIG_TARGET_ar71xx=y
CONFIG_TARGET_ar71xx_generic_WNDR3700=y
CONFIG_PACKAGE_block-mount=y
CONFIG_BUSYBOX_CONFIG_TRACEROUTE6=y
CONFIG_PACKAGE_curl=y
CONFIG_PACKAGE_vsftpd=y
CONFIG_PACKAGE_hostapd-utils=y
CONFIG_WPA_SUPPLICANT_INTERNAL=y
CONFIG_PACKAGE_wpad=y
# CONFIG_PACKAGE_wpad-mini is not set
CONFIG_PACKAGE_6in4=y
CONFIG_PACKAGE_6to4=y
CONFIG_PACKAGE_aiccu=y
CONFIG_PACKAGE_ip6tables=y
CONFIG_PACKAGE_luci=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-app-ddns=y
CONFIG_PACKAGE_luci-app-diag-devinfo=y
CONFIG_PACKAGE_luci-app-firewall=y
CONFIG_PACKAGE_luci-app-qos=y
CONFIG_PACKAGE_luci-app-radvd=y
CONFIG_PACKAGE_luci-app-statistics=y
CONFIG_PACKAGE_luci-app-upnp=y
CONFIG_PACKAGE_luci-app-wol=y
CONFIG_PACKAGE_luci-proto-6x4=y
CONFIG_PACKAGE_kmod-fs-ext2=y
CONFIG_PACKAGE_kmod-fs-ext3=y
CONFIG_PACKAGE_kmod-fs-ext4=y
CONFIG_PACKAGE_kmod-fs-msdos=y
CONFIG_PACKAGE_kmod-fs-ntfs=y
CONFIG_PACKAGE_kmod-fs-vfat=y
CONFIG_PACKAGE_kmod-nls-cp1250=y
CONFIG_PACKAGE_kmod-nls-cp437=y
CONFIG_PACKAGE_kmod-nls-cp850=y
CONFIG_PACKAGE_kmod-nls-iso8859-1=y
CONFIG_PACKAGE_kmod-nls-iso8859-15=y
CONFIG_PACKAGE_kmod-nls-utf8=y
CONFIG_PACKAGE_kmod-leds-wndr3700-usb=y
CONFIG_PACKAGE_kmod-usb-storage=y
CONFIG_ATH_USER_REGD=y
CONFIG_PACKAGE_htop=y
CONFIG_PACKAGE_nano=y
CONFIG_PACKAGE_ccrypt=y
CONFIG_PACKAGE_collectd-mod-conntrack=y
CONFIG_PACKAGE_collectd-mod-ping=y
CONFIG_PACKAGE_mount-utils=y
CONFIG_PACKAGE_rng-tools=y

Interesting idea. I've pretty much had it at going through menuconfig by hand and selecting all my packages. Can you provide more details on your build process?

My normal scripts are here: https://forum.openwrt.org/viewtopic.php … 30#p140330
Basically updating sources and feeds, running defconfig and then menuconfig to make any changes, if necessary.

But should I want to start building the .config from a clean slate, I can replace .config with that short .config.init before the build process, and "make defconfig" would then fix it by adding the dependent modules. After make defconfig, the new .config is long (and identical to the old full .config before cleanup).

I started by grepping away from .config all the #lines, and then looked carefully about the dependencies between the remaining lines (packages). I removed those lines that would be automatically included by having another package. For example, having 'luci-app-wol' automatically includes the underlying 'etherwake' module, etc. (Finally I had to add one # line to exclude wpad-mini as the full wpad is already there and wpad-mini is not needed, but as a device default it might get otherwise to the build config).

In practice, those modules that I had earlier manually selected in menuconfig, are left in .config.init. There might still be 1-2 unnecessary lines there, but it looks short enough already now. (For example, luci-proto-6x4 already selects 6in4 and 6to4, so those two are unnecessary in principle.)

(Last edited by hnyman on 31 Oct 2011, 09:55)

Did you remove the "ntpclient" package intentionally? I installed the wndr3700 (non-v2) 28681 build and had to manually install the ntp stuff manually. I'm taking a look for differences and noticed some changes in the default kmods, were there any other changes/deletions?

New build looks pretty nice overall. The web interface is a little slicker and has some nice improvements.

[edit] Hmm, I notice luci-app-ntpc is gone altogether so I'm guessing this is a change in the openwrt distro. And the browser gui now has a time sync function. Is ntp support being replaced?

(Last edited by tt on 3 Nov 2011, 03:54)

tt wrote:

Did you remove the "ntpclient" package intentionally?
...
Hmm, I notice luci-app-ntpc is gone altogether so I'm guessing this is a change in the openwrt distro. And the browser gui now has a time sync function. Is ntp support being replaced?

Yep, busybox built-in ntpd replaced rdate wholly, and that is also supposed make separate ntpclient redundant...
https://dev.openwrt.org/changeset/28613
https://lists.openwrt.org/pipermail/ope … 12691.html
https://lists.openwrt.org/pipermail/ope … 12692.html

But that change naturally requires that you either copy the new default settings for ntpd to /etc/config/system or replace your old one with a new containing the settings. https://dev.openwrt.org/changeset/28612 … /files/etc

Otherwise the changes were only due to dependency changes revealed in connection with the .config rebuild. For example, the button handling kmod was changed a few months ago, but the old kmod does not get removed from .config automatically. (And I intentionally left the strace utility away.)

(Last edited by hnyman on 3 Nov 2011, 06:55)

Well good riddance to rdate, but the lack of a migration for the ntpclient settings to /etc/config/system is a small annoyance. In any case, after editing it by hand, all seems well - the "Time Synchronization" frame is populated in System->System and ntpd is running.

I take it I can get rid of /etc/config/timeserver and /etc/config/ntpclient now?