yeah this has a heartbleed version of openssl. you can apparently patch it by reconfiguring with -DOPENSSL_NO_HEARTBEATS but im not sure of the steps that needs.

otherwise, still no complaints. 4 days of uptime with working ipv6, which is longer than ive ever gotten with the stock firmware.

OpenWRT devs have fixed the dual stack native IPv6 issue with help from people here on the forum.
Will be building new images as soon as I get some time.

Support for WNDR3700v4 has been enabled in trunk. It is visible in make menuconfig, if you first enable "broken platforms".
https://dev.openwrt.org/changeset/40481

Or actually all 40473-40481 were for tuning wndr3700v4/wndr4300:
https://dev.openwrt.org/changeset?new=4 … x%2Far71xx

Very nice   Less code to hack whenever we do an image for these routers now!

I've noticed they've done quite a bit with regards to the LED configuration.  Perhaps the peeps in this thread will not need to do a great deal more work.

(Last edited by AdamK on 13 Apr 2014, 00:32)

Thanks, folks, especially AdamK!

I bought the WNDRv4 specifically because it was listed as compatible with DD-WRT, and I wanted a router that allowed running a dnsmasq server for DHCP with local DNS, and a VPN server. After pfaffing about all weekend trying to get dnsmasq on dd-wrt to do its job, I finally  remembered having heard about openWrt. Using AdamK's build I had dnsmasq working in no time, without hiccups. OpenWrt is really sweet, far more refined than the competition, with a great selection of packages and excellent package management.

I hope OpenVPN will be as easy to get going.

Jon

I'm happily running OpenWrt Barrier Breaker r40498, NETGEAR WNDR3700v4/WNDR4300.   It looks great!  Thanks for updating trunk to incorporate the 3700v4 patches.  (Actually, I'm happy to see that the duplicated 4300/3700v4 files have been eliminated.  That will be one less source of fixes only being applied to one router or the other.)

One thing I noticed is that the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img can't be updated via tftp on my router.  I have to reflash the factory firmware via tftp and then use the web form on the factory firmware to flash the openwrt firmware img.   I do notice that the factory firmware img file and openwrt img have different capitalization in the header.  Might this be the problem?   I don't have a serial header attached, so I can't see any gripe the unit might be spitting out.

==> factory/WNDR3700v4-V1.0.1.52.img <==
device:WNDR3700v4
version:V1.0.1.52
region:
hd_id:29763948+128+128

==> openwrt/bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img <==
device:WNDR3700V4
version:VOpenWrt.r40498
region:
hd_id:29763948+128+128

Does anyone familiar with the Makefile build macros know which one of the "WNDR3700V4" strings need to be changed to "WNDR3700v4" to test this theory?  I've tried just to edit the file with emacs and that didn't flash either, but then I might have broken some checksum by editing it like that.

Alright I have built new images for the WNDR4300 & WNDR3700v4 based on trunk revision 40509.  I've pretty much done this stock via the trunk without applying any patches from this thread so it will be most interesting to see how well these images work.

WNDR4300:
http://www.mcservices.com.au/downloads/ … actory.img

WNDR3700v4:
http://www.mcservices.com.au/downloads/ … actory.img

NOTE:  These images DO patch the OpenSSL Heartbleed bug.

(Last edited by AdamK on 14 Apr 2014, 02:27)

It should be the second occurrence on line 1219:
https://dev.openwrt.org/browser/trunk/t … file#L1219

$(eval $(call SingleProfile,NetgearNAND,64k,WNDR3700V4,wndr3700v4,WNDR4300,ttyS0,115200,$$(wndr4300_mtdlayout),0x33373033,WNDR3700V4,"",-H 29763948+128+128,wndr4300))

(The first occurrence is the profile name referenced from line 1224).

You should also be able to edit firmware by hand with a proper hex editor. I do not think that there is any further checksum. Emacs is probably too "text editor".

OK!  That was it.  I just successfully flashed a fresh OpenWRT image via tftp.  Thanks for the tip!  This will make it *much* easier to upgrade the image.  I was getting pretty frustrated doing the two step update.

diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 8234f88..2d5dc6b 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1216,7 +1216,7 @@ $(eval $(call MultiProfile,Madwifi,EAP7660D UBNTRS UBNTRSPRO UBNTLSSR71 WP543))
 endif # ifeq ($(SUBTARGET),generic)
 
 ifeq ($(SUBTARGET),nand)
-$(eval $(call SingleProfile,NetgearNAND,64k,WNDR3700V4,wndr3700v4,WNDR4300,ttyS0,115200,$$(wndr4300_mtdlayout),0x33373033,WNDR3700V4,"",-H 29763948+128+128,wndr4300))
+$(eval $(call SingleProfile,NetgearNAND,64k,WNDR3700V4,wndr3700v4,WNDR4300,ttyS0,115200,$$(wndr4300_mtdlayout),0x33373033,WNDR3700v4,"",-H 29763948+128+128,wndr4300))
 $(eval $(call SingleProfile,NetgearNAND,64k,WNDR4300V1,wndr4300,WNDR4300,ttyS0,115200,$$(wndr4300_mtdlayout),0x33373033,WNDR4300,"",-H 29763948+0+128+128+2x2+3x3,wndr4300))
 
 $(eval $(call SingleProfile,ZyXELNAND,128k,NBG6716,nbg6716,NBG6716,ttyS0,115200,NBG6716,$$(zyx_nbg6716_mtdlayout),ubi.mtd=ubiroot mem=256M))

Are you able to share your build? Thanks!

You should send the patch to the openwrt-devel mailing list to get it patched in the main source.

(If I got you right, the OEM TFTP recovery/flash mode expects a lowercase v4 there.)

(Last edited by hnyman on 15 Apr 2014, 12:17)

Worked for me and settings persist after reboot. Both wifi's were down though right after the install, don't know if that's intentional. Do work fine when enabled.
However I can't get port forwarding to actually work even though the forward is showing up fine in the web interface. I double checked how to do it using /etc/config/firewall on sites like here and there and even tried copying over their setup but then customised to the IP/Port I need, no luck still.

Am I missing something super obvious here? Shouldn't it be as easy as visiting the web interface and going to Network > Firewall > Port Forwarding, adding the new forward, save & apply and it works? Because it doesn't for me.

(Last edited by Axeia on 15 Apr 2014, 15:50)

Hi folks,

I'm new here!  Got the WNDR4300 because wanted one wich's capable running WRT.
Downloaded AdamK's Image for WNDR4300. Loaded the Image with original Netgear-Firmware WebGui.
Thanks for your development !!!

So far seems nice, but: I DO NOT GET THE PPPoE running!!!!  Tried different things - no idea why it's not connecting!
My old router is still working - connecting with no probs. So it's not an ISP-problem.

Modem is connected to yellow connector.  Interface WAN was connected to physical @wan, eth0, eth1, teql0 - but none of them worked.
Is it a bug or am I thinking wrong?  I NEED some HELP please !!

ANY Hints appreciated?
Greets to all
Rochus

Yes that is intentional and default settings with OpenWRT.  It gives you an opportunity to lock down your wifi first to prevent someone hopping on and scoring free access to your network before you have a chance to secure it.

The setting looks fine; and port forwarding works with no problems on my WNDR4300...
Are you sure the server is accepting connections on that port other than just to itself?

Try power cycling both the router AND your modem.  Don't reboot, fully power cycle both devices.  Failing that, factory default your WNDR4300.  Once factory defaulted remember to power cycle the WNDR4300 to get devices working properly (there is still a bug where you need to do this to get everything working OK)

Smart

Positive, works fine with both dd-wrt and the stock firmware. On my old wndr3700v2 it worked fine as well but I gave that one away for christmas.

Can access it over the LAN through its local IP on that port as well (from another PC). I've had the problem with all builds you have posted btw. Is anyone else having the same problem?
/etc/config/firewall reads

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option src_dport '8092'
        option dest_ip '192.168.1.100'
        option dest_port '8092'
        option name 'Steph Server'

which seems perfectly valid to me.

If I do a /etc/init.d/firewall restart I do get a

Warning: Unable to locate ipset utility, disabling ipset support

BAM!!  I'll add ipset support into a fresh image to see if that helps.

Edit:  Also I just noticed, try removing the space in your rule name.  For example instead of Steph Server, put Steph-Server.
Reload your firewall then test.  It could be nothing but try it and see if that solves it.  As I said I have no issues with my WNDR4300 so I'm assuming it will still work even without ipset...tho I am building a fresh image with that included anyway.

The next image will be based on trunk revision 40518 which also includes an updated strongswan to further patch against Heartbleed.

UPDATE:  Have tested the new image on my TP Link WDR4300 (not the Netgear just yet) and confirmed all is working, though the ipset added a good 150KB to the image size, it's getting tight so may look at where I can remove any junk.  Am now building for the WNDR4300/WNDR3700v4, will post the links in the next hour.

(Last edited by AdamK on 16 Apr 2014, 01:59)

Images are now up and live.

WNDR3700v4:
http://www.mcservices.com.au/downloads/ … actory.img

WNDR4300:
http://www.mcservices.com.au/downloads/ … actory.img

This contains the ipset utility package, and an update to Strongswan.  Note I have named the files with trunk revision 40512 instead of 40518; for some reason LuCI thinks it is still on r40512...

That is a stupidity in the Openwrt build system logic for displaying the revision. The displayed revision is the revision of the last check-in to the "main openwrt source", excluding packages, branches etc. The default logic is to use the "svn info" output, but take "Last changed revision" instead of "Revision" line. Very often there is no difference on trunk, as most check-ins go to main source. But if the last check-in is in packages (like now), the default logic does not take that into account.

I have changed it in my own build to show the real svn revision taking into account the whole repository. (I don't use git, so I have only modified the svn check):

--- scripts/getver.sh
+++ scripts/getver.sh
@@ -11,7 +11,7 @@
  
 try_svn() {
    [ -d .svn ] || return 1
-   REV="$(svn info | awk '/^Last Changed Rev:/ { print $4 }')"
+   REV="$(svn info | awk '/^Revision:/ { print $2 }')"
    REV="${REV:+r$REV}"
    [ -n "$REV" ]
 }

Thanks AdamK,
factory default and power cycle the WNDR4300 helped !

Now I can go on configuring.
Good work!
Greets R

A little bit of progress, don't get the ipset missing error anymore (as expected). And if I leave the "Enable LAN loopback" checkbox ticked it works locally. If I untick it however the forward does not work over the internet (WAN).

I tried forwarding it to another IP (my desktop running a WAMP stack) instead of my server and it doesn't work either. Is there any way I can supply useful feedback by running some commands? Router running openWRT, server running linux, desktop running windows so should be able to run pretty much any tools/application to help trace the problem, just don't know how

[edit]
Installed Wireshark on my server. Whenever I contact the server on the port I get a red line, that's not a good sign. I can't make sense of this information other than the Dst Port not being what I expected. Where is this port 51090 coming from all of a sudden?

[edit2]
Changed my server from the KDE network manager to ifup and added a DHCP lease so the server gets a static IP. No longer getting  the red line in wireshark, getting nothing from wireshark. Have confirmed the servers ip is in fact where the port forward is supposed to be going to with ifconfig. Seems to be a step in the wrong direction although it is how I'd want it configured in the long run.

(Last edited by Axeia on 16 Apr 2014, 18:03)

If you are on IPv6 you can grab it from https://www.wsrcc.com/snapshots/trunk/a … actory.img

I'm trying to not piss off my ISP by putting up an http server on IPv4.
BTW. Comcast automatically gives you an IPv6 connection.  Other ISP's make you go to www.tunnelbroker.net (aka he.net) to get a free tunnel.

Yes.  That appears to be the case.  The OEM web flash software is a bit more generous and doesn't care about the case.

Try renaming your forward from Steph Server to Steph-Server as I suggested earlier.

I cannot replicate the issue so there isn't a whole lot more I can try....

Ah should have mentioned that, I did take your advice and change the name as well as adding some more forwards to different ports with different names (no spaces/dashes). None of which work.
Enabling LAN loopback does get me things workings so I can only assume the firewall entries are being read and something other than the firewall is preventing traffic.

Thank you for your help and builds AdamK, do appreciate the effort you put into it .
I'll see if I get some help in one of the more general subforums as I'm afraid that I ran out of ideas. Worst case I'll go back to the stock firmware, dd-wrt didn't really catch my interest.

[edit]Just noticed the crazy amount of views this thread has, popular router.
[edit2] Well, got a workaround for my problem using upnp portmapper things work for others but not for me. Which is good enough as I can use the local IP anyway.

(Last edited by Axeia on 19 Apr 2014, 02:06)

dd-wrt still (unless they have recently) don't support native dual stack IPv6 OOB nor do they offer any packages or scripts to upgrade their images to support it, which for me is a show stopper.  Infact, they say to use some packages from OpenWRT devs to try and get it up and running
Their web UI is slick but I also noticed some flaws, more so when you need to do custom commands and deal with more than one public IP address.
OpenWRT on the other hand manages all of these without any real issues, and I really like how it is modular and customisable not to mention easier to build the source. 

On another note I have noticed in recent trunk commits that they are working on the UBI stuff which is related to the WNDR3700v4 and WNDR4300.  Hopefully it will not be too much longer before sysupgrade features become a reality!

(Last edited by AdamK on 21 Apr 2014, 04:01)