Welcome to my longest post yet. Shoutz to Bukington for the USB pic, Growell and Franz for their great contributions.
For the most part I'm going to be shining light on things, but I am still a n00b and need help sometimes, so please consider reading about my questions if you are an expert. My questions will be at the bottom of the article in its own section.
Long story short I've figured out a lot and I'm working on compiling the information on my wiki, and later disseminating it to this thread.
Here are some things I've accomplished since:
How To Compile a Latest, Working Image
How to Fix the LED issue
How to Achieve my Desire VLAN Setup
How to Successully mod with USB flash drive ExtRoot
Bare in mind, I am a novice so I am all-encompassing all the knowledge.
I realize I may be iterating some information that can be found All over the web, wiki, and forums, so I have brought it to you here in one format.
New Firmware Images 
Update
It just dawned on me, there's no reason to use these images over Growell's basic image. At first, I thought to produce images so that you could use opkg.. but the thing is that the snapshot git moves so fast, that they can easily become incompatible again.. So the best way is to compile yourself, and then add as modules <M> any new packages you want later in make menuconfig.. those will get compiled as IPK when you make.. and you can send them to router for opkg install..
</update>
So first off, the impression that was made upon this thread is that the latest trunk is mangled (bad LEDS, ethernet broken), and that by applyng franz's patch it will be fixed again. Since I've done all this and more, let me elaborate.
Since a month or more had passed since the last post, I decided to try the trunk image, or trunk compile stock, and see if progress had been made. both still behaved badly, same issues as talked about. Bad ethernet, bad LEDS.
So I patched the mach-file with franz's patch.
Not only should the mach-file be patched, but also since ./target/linux/ar71xx/base-files/etc/uci-defaults/01_leds has been changed to use wnr2000v4 led prefix, his patch must also reflect that, or vice-versa. So I've done all of that, I'm learning how to create a patchfile, will update.
Non-USB image that is already outdated hehe
Yes it's not as good as USB image but still great -- if I could find some help on the green LEDS you will see me talking about later, I need help on that.
This image is outdated because I made the USB mod, and have done a lot of work with the USB mod I don't look back.. Also there are discoveries I made after USB that's why only the USB has the new discoveries present and not this older-compiled image.. I hope it still serves your purposes well. We are cutting-edge after all
If you do not want to read my long tutorial, please consider downloading this no-USB version of the latest openwrt, however it lacks the latest bugfixes I have found . openwrt-ar71xx-generic-wnr2000v4-squashfs-sysupgrade.bin.nousb
Your WLAN LED will not work for instance, Power LED doesn't work, and not all buttons supported.. Consider this temporary that you decide to use it. although I have fixed this issue privately. I can still help you patch at least the LEDS yourself. Buttons will require kernel patching, or when I release new image whatever. Please follow my instructions exactly, trust me. If you don't trust me it isn't going to work 
.
Edit /etc/config/system -- change all sysfs entries that say 'wnr2000-v4' to say 'netgear' instead'. Save the file and do /etc/init.d/leds reload should work, if not, try reboot.
USB enabled image that is brand-spanking new
Only use this image if you are planning on doing USB mod, because it includes all the kernel modules required for it, and hence takes up more space. It also includes my latest patches. All buttons should be supported [untested] and all LEDS can be controlled/triggered except green LAN/WAN ones cannot yet be controlled [working on it, not sure if it's possible].. The thing about the green LEDS is that they seem to be controlled externally somehow. So they automatically blink on activity even tho they are not configured in the BSP (board support package).
openwrt-ar71xx-generic-wnr2000v4-squashfs-sysupgrade.bin.usb
Note: I could not add usbutils to this image [lsusb], because it made the image too big such that JFFS2 would not save.. It must be able to save in order to save an EXTROOT configuration.
Note on Flashing my images
If you flash these images from Stock Netgear 1.0.0.58 [other versions untested], you may have to use the -f flag in mtd command.. otherwise it complains "image verification failed" or something.. but the image is legit and it flashes successfully when forced.
mtd -f -r write bazz_img.bin firmware
Note about sysupgrade image being SquashFS
-- If you are n00b like me, do not be scared of SquashFS, it doesn't mean that your Linux installation is read-only, its just the firmware image, it will later use JFFS2 automatically.
If you want a USB-enabled image, with all LEDS working, you are in luck. It is my latest image so has all the bug fixes.
How to Unbrick
I am not talking about any brick.. I mean if you flashed the firmware, not the bootloader, like from Growell's tutorial:
mtd -r write blabla.img firmware
In case you have bricked your router this way, there is one way I am familiar with to restore it -- Restore factory image. It is the last solution I post. First are some untested solutions I assume you will skip but I am interested in.
Of course, you could use the serial terminal shell right? But mine did not function properly, so I could not :[. So these are the other solutions you can try.
Untested: Boot into FailSafe mode
You do this over serial line when it asks you to press keys at bootup. We want to see if we can get ethernet working.
Untested: Boot from RamDisk
I have not yet learned this, but if a small,reliable,checksum passing RamDisk unbrick image could be made, it is a faster recovery than the next method, which is the only method I know.
Tested: Restore Factory image capable of Telnet Root
From my experience, I can only get telnetenable working with NetGear firmware 1.0.0.58. Download the img.
Must have tftp client. ie. sudo apt-get install tftp
You can try doing this without serial terminal, just wait a long time 
holding the button down. But it's advocated that you work towards getting your serial hooked up if you don't want headaches down the road.
This is not a script, I want you to open TFTP and execute the following commands. lines starting with # are just comments from me to you, do not write them in.
# execute following commands in tftp
binary
rexmt 1
trace
connect 192.168.1.1
# no connection has been made yet. ;)
# Now, holding down the factory reset button on wnr2000v4, turn it on, watch serial console,
# you will see eventually it start flashing "Factory Reset" -- keep the button held still!
# wait until you see it say a different thing and it will also say the TFTPD has started listening.
# now you can run this next command
put bla-bla-insurance-person-come-help.bin
# you put the netgear firmware
Now that's done, you should see a bunch of ACK messages and data transfers.
NOTE: this method cannot be used to transfer openWrt images because they fail a Checksum check thing.
The image will be flashed and we will have stock firmware.. Now we must use UDP telnetenable.
Here is the one I use:
EXPERT NOTE: this is a mod of the TCP version and I did not modify the extended password parameter of UDP version.. but the stock router password is 'password' which fits in the new model anyways..
UDPtelnetenable.py
import sys
import socket
import array
from optparse import OptionParser
from Crypto.Cipher import Blowfish
from Crypto.Hash import MD5
TELNET_PORT = 23
# The version of Blowfish supplied for the telenetenable.c implementation
# assumes Big-Endian data, but the code does nothing to convert the
# little-endian stuff it's getting on intel to Big-Endian
#
# So, since Crypto.Cipher.Blowfish seems to assume native endianness, we need
# to byteswap our buffer before and after encrypting it
#
# This helper does the byteswapping on the string buffer
def ByteSwap(data):
a = array.array('i')
if(a.itemsize < 4):
a = array.array('L')
if(a.itemsize != 4):
print "Need a type that is 4 bytes on your platform so we can fix the data!"
exit(1)
a.fromstring(data)
a.byteswap()
return a.tostring()
def GeneratePayload(mac, username, password=""):
# Pad the input correctly
assert(len(mac) < 0x10)
just_mac = mac.ljust(0x10, "\x00")
assert(len(username) <= 0x10)
just_username = username.ljust(0x10, "\x00")
assert(len(password) <= 0x10)
just_password = password.ljust(0x10, "\x00")
cleartext = (just_mac + just_username + just_password).ljust(0x70, '\x00')
md5_key = MD5.new(cleartext).digest()
payload = ByteSwap((md5_key + cleartext).ljust(0x80, "\x00"))
secret_key = "AMBIT_TELNET_ENABLE+" + password
return ByteSwap(Blowfish.new(secret_key, 1).encrypt(payload))
def SendPayload(ip, payload):
for res in socket.getaddrinfo(ip, TELNET_PORT, socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_IP):
af, socktype, proto, canonname, sa = res
try:
s = socket.socket(af, socktype, proto)
except socket.error, msg:
s = None
continue
try:
s.connect(sa)
except socket.error, msg:
s.close()
s= None
continue
break
if s is None:
print "Could not connect to '%s:%d'" % (ip, TELNET_PORT)
else:
s.send(payload)
s.close()
print "Sent telnet enable payload to '%s:%d'" % (ip, TELNET_PORT)
def main():
args = sys.argv[1:]
if len(args) < 3 or len(args) > 4:
print "usage: python telnetenable.py <ip> <mac> <username> [<password>]"
ip = args[0]
mac = args[1]
username = args[2]
password = ""
if len(args) == 4:
password = args[3]
payload = GeneratePayload(mac, username, password)
SendPayload(ip, payload)
main()
Now, with router on, and ethernet cable plugged from this computer, recommended ethernet port 1, shouldn't matter tho.. we run the following:
python UDPtelnetenable.py 192.168.1.1 [Router MAC] admin password
Replace [ROUTER MAC] with your router's MAC address. This can easily be found over http://192.168.1.1 in your router's main Advanced Configuration page. The MAC must all uppercase and you MUST remove the ':' ie. 12:12:12:AA:BB:CC becomes 121212AABBCC
Next, try telnet 192.168.1.1 - and you should be inside an OpenWrt root shell.. You can resume your image flashing procedure now Same as before, which we hosted a TFTP server on our machine as given in Growell's tutorial on page 1 of this thread.
Getting by with Growell's Basic Img
What happened with using Growell's image, and what might happen with mine as they age, is that opkg packages from internet became too different to be compatible.. This section is an archival purpose demonstrating pitfalls I ran into trying to get opkg to work on Growell's image, and you might face these problems with mine if you try to use mine in the coming months after posting.. When in doubt learn to build the source yourself. Fortunately I show you how now.
Even if you adapt your /etc/opkg.conf to point to the new repositories.. Here's how that would have looked [I do NOT recommend trying this, this is for archival purpose only:
src/gz base http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/base
src/gz luci http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/luci
src/gz management http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/management
src/gz packages http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/packages
src/gz routing http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/routing
src/gz telephony http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/telephonyroot
But although this will enable opkg update to work, I cannot tell you how new packages will install well with it.. Because I initially decided to upgrade my installed packages, which is a BIG NONO on OpenWrt.. It bricked my router effectively.. You can find more info about Why on wiki, but opkg is risky when doing remote installaton of new packages, due to possible mismatch in kernel properties or LibC stuff. Can someone shed light on proper way to rely on opkg?
Anyways, due to the problems I ran into with opkg, and because I want to learn about compiling kernels and modifying BSP (board support package), I opted to do some kernel hacking. Also, I figured opkg would work with a new compile [which it does, I effectively installed Luci and usbutils, granted I needed USB mod to have the memory ]
Current Trunk Shortcomings
We've already identified how the current trunk image [or even self-compiled from trunk image] is faulty. For me and at least one other, the result is ethernet does not work, and the LEDs are incorrect. Since ethernet is not working and firmware starts with no wireless, the device is effectively bricked, unless maybe your serial terminal root shell works, unlike me, then maybe you can save it without modifying kernel. But that's not curing the root problem anyways, a bug in the source code, yeah?
The last place this thread left off, was that franz.flasch mentioned the cure, that we can the router working again if we replace the current trunk's mach file with his old patch (hosted in Growell's tutorial) .. So what I did was take out just the mach file from the patch and made a machfile from it. This can be done because the patch for the mach file, is really the creation of a machfile.. Once I replaced the trunk mach file, my router was working again, but with caveats. [I figured out the fix too ]
The problems you will see is that LEDs function properly, IIRC, except the WLAN will never light up.. IIRC sometimes power light is off as well.. Anyways the biggest issue was the WLAN.. But also, Franz's mach file doesn't have USB registration, and it also lacks full button support.
I will later identify how I combine the best of both worlds to create my own mach file comprised of both the trunk and Franz's mach files, so that I get the best mach file to date. WARNING: I have now modded my router to have USB port, and I am no longer sure if USB registration function in mach file firmware init causes issues with non-USB-router / kernel.
OK SO let's begin first by identifying, how can we build our own sysupgrade image from openwrt source?
How To Compile a Latest, Working Image
First off, Barrier Breaker is too old, there is no wnr2000v4 code in the release. So we must go from current trunk.
I will not explain any more on patchin the mach file. I will give important locations.
If you want to edit the mach file before attempting compilation, it will be at
target/linux/ar71xx/files/arch/mips/ath79/
if you want to modify after you've compiled once, you must change instead the
build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/linux-3.18.11/arch/mips/ath79/
Take into account how your version numbers may be different. Also, I have buildroot take care of everything. I am not using external toolchain, take care the possibility that the paths might be different.
Next step is the Feeds, although Growell listed this as optional. I always do it -- it enables me to see all packages in make menuconfig. It does not actually install anything to kernel. Do the feeds like in Growell's tutorial.
I noticed a lot of
WARNING: No feed for package 'libyaml' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'libedit' found, maybe it's already part of the standard packages?
WARNING: No feed for package 'sctp' found, maybe it's already part of the standard packages?
But I never had any problems...
then,
Make sure Target SYstem is Atheros 7XXX/9XXX
Subtarget: Generic
Target Profile: Netgear WNR2000V4
Target Images: SquashFS
I don't recall changing anything else, but you're free to have a gander
Warning: the filesize of the image is very important.. If it's too big, JFFS2 won't be able to save on reboot, which will be bad... I had a case where 3407876 bytes was too big but 3604484 fit and kept JFFS2 functioning.. Mind you I used that image to mount a USB stick 4GB so 
... So if you just didn't change anything the image should be about 3145732 bytes, which is fine size.
When it's done successfully navigate to bin/ar71xx and that's where the sysupgrade image will be, among others.. I don't know how to use the other images, although I'd love to learn what's the point of making a JFFS2 image if it already works with the Squash one.. anyways, you only need the sysupgrade image
You should be able to do the rest with all of the material laid out in this thread. [not post] see Growell's tutorial page 1
How to Fix the LED issue
For all the people wondering why is the LEDs messed up, and why do they work in franz patch? It took a lot of work and I cannot explain everything -- please understand I've only been working with OpenWrt for 4 days.
There are 2 different LED issues I've identified
I've discovered that all of the green LEDS on the board besides the WPS and POWER, seem to be controlled outside of /etc/config/system -- but from where??
They are not controlled in /etc/config/system, and they are no longer part of gpio_led structure. I cannot identify how they are controlled, but whomever submitted latest trunk knows this because they removed the green LEDS from the code as well.. However their LAN1-4 code is buggy and I fixed. The issue lies in incorrect port settings in /etc/config/system. I am still not sure why latest official code has no ethernet working out-of-box. But when I use Franz's mach, and correct the LED settings. I am golden.
I want to make patches and submit to official. How to do this?
How to Achieve my Desired VLAN Setup
Warning I'm super n00b at this. I hope someone can guide me.
I have an almost perfect setup, made possible with the graphical assistance of Luci. But I have further questions on it, so I am aiming to make a new thread asking for help. I can speak about what I've done so far conceptually.
let me see here. I have it so Ethernet 1-3 and WLAN is on its own 'network' for lack of better terms, and Ethernet 4 is on its own VLAN. I wonder if IP spoofing makes it possible to transcend the network boundaries, but I cannot answer myself..
The initial VLAN configuration on wnr2000v4 openWrt is Vlan1 and ports 0-4 are all present and untagged.
port 0 is the elusive CPU port which I don't fully understand, but must be present on all VLANs, I think... (I don't actually know this). Ports 1-4 are respectively the real ethernet jack ports 1-4.
So I made another VLAN and since it has CPU port on more than one VLAN, cpu must now be tagged on both VLANS.
now, VLAN 1 is 0t 1 2 3
VLAN2 is 0t 4
Initial Net config is 'lan' that WLAN0 and bridged with ETH1 (the ethernet switch). Eth0 is WAN FYI.
What I do is instead, bridge WLAN0 with ETH1.1.
I make a new network I call 'elan' stands for ethernetLAN. This network is on a different subnet, so IP is 192.168.2.1 as an example. Whereas the
'lan' IP is 192.168.1.1
I set physical interface to eth1.2
any other settings are inspired from 'lan' like netmask 255.255.255.0
I create a new firewall zone "elan" and set covered network to "elan" -- not sure what I'm doing, for instance if I should have one zone cover both the elan and lan.. but probably not I speculate. Allow forward to WAN, but not the other way around.. [why does this work?] doesn't wan traffic need to come into these interfaces?? I'm n00b..
In the circumstance my Ethernet 4 unit gets hacked.. I do not want to to be able to reach Luci or SSH of the router.. I also do not want gateways to respond to ping..
So I add rules to reject traffic on TCP from ELAN to any router,
I also reject ICMP from ELAN to any router.
Question -- what is the difference between Device (input) and Any Zone (forward)
At this point, my configuration does seem to work. I've tested with multiple computers, over wireless and ethernet. All results I am aiming for succeed. For example,
Ethernet computers and wireless are on same subnet.
Ethernet4 is on its own subnet..
Communication appears impossible between ELAN and LAN. Not sure how to extensively test this or further test against hacking attempts.
Ping from ELAN to any gateway IP returns unreachable, as desired.
SSH from ELAN to openWrt is refused, either gateway address.
Good good, but I do have an issue.. In the System Log, I am getting this message a lot, and haven't found online a solution to it. I barely understand it [not network guru]
Wed Apr 15 00:39:49 2015 daemon.warn odhcpd[822]: A default route is present but there is no public prefix on eth1.2 thus we don't announce a default route!
Wed Apr 15 00:39:49 2015 daemon.warn odhcpd[822]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!
Update
Actually the messages shown above display pretty frequently even on a fresh openwrt installation... Wonder what's that all about?
How to Successully mod with USB flash drive ExtRoot
Earlier posts in this thread provided good pics and explanations. I can say a little more now that I've successfully implemented this mod..
Physical
As mentioned earlier in this thread, 3.3V is ok for the flash drive, and since I already have pin headers installed on the serial, I instead grabbed the 3.3V from a via located right beneat the PWR LED. you'll see 2 vias they both supply 3.3V.
For GND, I just use the shield framing. I suggest using pin headers so you can switch D+ and D- incase you screw up.
Also, keep D+ and D- as short as possible. My wires are about 3 inches to get right about the ethernet jacks where I've mounted the USB socket with hot glue. I used to have longer wires and it wouldn't work.
Really great article here: https://forum.openwrt.org/viewtopic.php?id=37368
Despite the article, I am doing OK without a filter capacitor and without resistors..
Kernel Modules Required
kernel modules to enable in the kernel. I recommend compiling them in rather then relying on opkg [personal preference]. You can do a google search for openwrt mass storage usb to get an idea of the kernel modules.. but since I already figured it out I might as well try to see what exactly was necessary..
make menuconfig
In menuconfig, navigate to kernel modules
block devices -> kmod-scsi-core
filesystems -> kmob-fs-ext4 -- because my USB is formatted ext4 [any advice on better filesystem?]
USB support ->
kmod-usb-core
kmod-usb-storage
kmod-usb2
Don't expect to format your drive on OpenWrt, don't install utilities to do that, there's no space right now! We barely have enough to keep JFFS2 operable. Instead, pre-format your drive on the computer.
Be sure not to install ANYTHING else, as merely be enabling the aforementioned kernels, there is barely enough space for JFFS2 to allow you to save config, which is required to update /etc/config/fstab in order to perform EXTROOT at boot. I tried installing usbutils atop these packages, but it was too big.
If you want to learn how to perform EXTROOT, there a couple ways to do it (pivot overlay vs. pivot root). Pivot Root is for whatever reason not recommended on ChaosCalmer, but I did it anyways {oops}, but I'm having a fine time. So if you want to do that you can learn @ https://samhobbs.co.uk/2013/11/more-spa … wrt-router
Also OpenWrt Wiki has good knowledge on how to do it too . Google is usually best for finding openwrt wiki pages
Icy92
@Icy92 -- Recover your changes on U-boot env? Too vague man, I can't help you.. But from my experience, I only alter the bootcmd env variable from U-boot via serial, it has to be done over serial at bootup, and there's nothing to recover lol.. Have you destroyed your set of env variables? I have no problem recording my set to see if that helps..
ar7240> printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootdelay=1
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
ipaddr=192.168.1.1
serverip=192.168.1.10
dir=
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize
ethact=eth0
bootcmd=bootm 0x9f040000
stdin=serial
stdout=serial
stderr=serial
Environment size: 680/65532 bytes
ar7240>
Summary
I want to submit my patches with comments on what I've done. We already know that several people can't get ethernet working on the official trunk and the LEDS are broken.. I have fixed both in my version.. Although not perfectly. Green LEDS, how are they being handled outside of /etc/config/system? Need the answers so that we can control them too..
Questions / Observations
Green LAN/WAN Leds
I've been trying hard to understand the Green LAN / WAN LEDS. These LEDS are not controlled thru /etc/config/system like the rest of the LEDS are. Because these LEDS are externally controlled (somewhere in CPU code? or maybe another peripheral?), adding them as LEDS in the gpio_led, and trying to turn them on / off in /sys/class/leds does not work.. Also the value of brightness does never even reflect the true on/off of the LED. HOWEVER, the gpio number is correct, as when the LED is not registered as gpio_led, we can watch it in /sys/class/gpio, and watch its logic change.. Also, if we set the gpio to input-only, the external control is disabled...
So if we can figure out where is this external control coming from, we can learn how to put the green LAN/WAN led control back to /etc/config/system for greater user-level control. Right now, the current control is mysterious but it does do a job at lighting up based on LAN/WAN activity..
Does anybody have ideas where these green LEDS are getting controlled from, even when they are not registered in the led_gpio structure?
Why Ethernet does not work in Trunk
So I've figured out aforementioned why the Trunk's LEDS are broken, but why does its ethernet not function correctly. Should we bother to diagnose why, or should we simply implement the version I created which works in total? I am investigating how to create the kernel patchfile.
Why is ath9k-phy0 listed as an LED
What is this all about?? See it /sys/class/leds or in Luci as well.. What is it?? I don't see any light
Why does WLAN button not work?
Just like the Green LEDs it does not respond to GPIO toggling.. anybody?
(Last edited by bazz on 16 Apr 2015, 05:41)
