No, that is doing the opposite. The initial patch was to enable port8 as CPU port. This never worked. For some reason it is impossible to get this to work. I've spent quite a bit of time to get that to work, but did not manage. Whenever I tried to use port8 as CPU port the vlan tag would not pop up in the data. The patch I pointed at is reverting/bypassing the patch you just pointed at.

Here's the diff: http://git.openwrt.org/?p=15.05/openwrt … ac22fc5989

It's clearly adding that code, not removing. "bcm53xx: add workaround for Netgear R8000 network"

I understand it is difficult to see the little changes which were made. But lets make this very clear: If you sync trunk and build it then you'll get a version which will use port8 as CPU port for the switch. If you build CC then this latter patch will set it back to port 5:

++      if (of_machine_is_compatible("netgear,r8000"))
++              sw_dev->cpu_port = 5;

Take a look at the patch you initially pointed at:

       else if (of_machine_is_compatible("netgear,r8000"))
                        sw_dev->cpu_port = 8;

So show me a patch on trunk after the may patch you pointed which configures the cpu port to 5 for the an r8000 build.......

Doh, you are right of course

In any case, the switch port has nothing to do with the reported kernel panics where the kernel fails to find any ubifs.

Ok, so that is what I'm trying to figure out. What exactly is/are the problem(s). All I wanted to say is that trunk wont work without modifications (to the source code), so don't run that, but is that all?

The problems with the ubifs (actually it already reports errors during the mtd parsing, at least I noticed that in the first log) I can not solve. If CC is run on an r8000 and you get those kind of problems then I assume that a new version of R8000 was released with a different flash configuration which is causing a problem, at least that is what I would make of it. I'm just not familiar enough with that stuff to fix it, nor do I have that problem, so I cant debug it either. But I also read reports which I think seems to indicate that some people have flashed trunk (buildbot image), that didn't work (don't know for what reason), then switched back to CC and that started failing as well (where it initially worked). If that is the case then I can give that a try locally and see if I can figure out why not. I'd like to understand what people have done and what is failing. As said if your r8000 doesn't work with any openwrt image and never has then I probably cant do much as I cant reproduce. If it used to work, but after reflashing some images (trunk) it fails on CC (which used to work) then that is something I could give a try.

@meulman

> I can only relate my own experience, but this is what happened to me.

I went from Stock firmware to : https://downloads.openwrt.org/chaos_cal … x/generic/

My R8000 NEVER ran that fast on wireless or wired clients, it was just amazing.

In blind faith I guess, 3 days later or so, I flashed the trunk image straight. The router became unpingable, even though it looked like it booted properly(from the light array). My only option then was serial recovery/tftp, which I flashed the stock firmware back. Then I decided to put the firmware from the above link back on as it WAS working fantastic. Then the same error occured. Router rebooted, looked fine, but was unpingable.

Weird thing is, just for fun and to make sure I wasn't crazy.....(some argue that point .... I flashed the trunk image for two days on both my R7000, and AC56U, with NO issues. It seems to be unique to the R8000, for me anyway.

I was thinking of asking you anyway in regards to the above post, could it be some fragments getting stuck in nvram? Maybe the Netgear firmware isn't cleaning nvram out? I am running DD-WRT on the R8000 right now, is it worth erasing dd-wrt nvram, flashing Netgear oem, then trying the Openwrt image again? What sucks is it would have to wait for the weekend for me now.

Well, that is clear. As explained, trunk on r8000 wont work without any modification to the source. The ethernet switch wont work and you wont be able to access your router anymore. The only thing left to do is connect to the serial port and use CFE/tftp(d) to flash an other image.

So the CC image did boot again, but you were not able to access it anymore. When reflashing (through CFE) the router goes back to ip address 192.168.1.1. It will also loose all wireless configuration. So you have to use ethernet (and browse to 192.168.1.1) to reconfigure it. Did you try that?

192.168.1.1 was unpingable, on any Ethernet port.

Edit:

"arp -a"  told me to do bad things to myself, so did "ipconfig".

(Last edited by mojolacerator on 19 Oct 2015, 14:48)

Ok, then I will give that a try, build a fresh trunk version, flash it, boot it, flash back to cc and see what it does. This will take some time...

Edit: As you have console (UART) connected to R8000, can you type ifconfig -a and see that it is using the ip address 192.168.1.1?

(Last edited by meuleman on 19 Oct 2015, 14:50)

my apologies if I am not understanding, when I recovered and flashed the OEM firmware back, it was using 192.168.1.1.

I am running DD-WRT (prefer openwrt....just sayin'...) every flash after is using 192.168.1.1

(Last edited by mojolacerator on 19 Oct 2015, 14:55)

When you flash CC image and have an UART connected which, then you can access the device through uart. Once it has booted just press enter and you will see a prompt like this:

root@OpenWrt:/#

Then type the command 'ífconfig -a' and it will show all interfaces. There will be many, but the one which is most interesting is 'br-lan' which will show if the interface is up and which ip address it has. Also eth0.1 is interesting as it will show whether the device has received/transmitted any packets on any of the 4 ethernet connections.

Perhaps, the CC image might use some configuration/setting which makes it use a different IP address. By giving that command you will know that the image has booted correctly (by just being able to access it) and it will give some more information about the state of the fixed and wireless connections.

@meuleman

If I understood correctly, I should flash the image that craps it out, then follow those steps through serial to check it out?
Might take a couple days to do that, in full work week mode right now.

I have tried "ipconfig" through ethernet (windows cmd line) after getting no ping on 192.168.1.1. If I remember correctly, the gateway address is blank.

(Last edited by mojolacerator on 19 Oct 2015, 15:54)

Yes please, the CC image for the r8000 (openwrt-15.05-bcm53xx-netgear-r8000-squashfs.chk) from this link:

https://downloads.openwrt.org/chaos_cal … x/generic/

If you could do that and perhaps post the boot log and the log of 'ifconfig -a' (it is linux, so ifconfig, not ipconfig), then that would be great. Just tried to reproduce and I'm unable to.

Build  CC
Build Trunk,
Flashed CC, verified it working.
Flashed Trunk, verified ethernet failed.
Flashed CC, verified it working.

After reflashing CC build it was working fine again, ethernet was configured and device was pingable and accessible through web-interface. All flashing was done though CFE/tftpd.

So perhaps a trunk build with the same switch port configuration as in CC would be worth a try?

EDIT: I'm currently building an image of trunk that has the same switch configuration as the working CC build as pointed out by meuleman. I've also downgraded the kernel to 3.18 (same as CC), I'm guessing the MTD related errors could be a regression with the newer untested kernel.

If anyone would like to try, check back in a couple of hours

(Last edited by arokh on 20 Oct 2015, 08:04)

When I could flash this image, all 3 radios were active.
https://downloads.openwrt.org/chaos_cal … x/generic/

Oh for those guys trying to connect with serial port, here is an useful picture I found:

Here is the translation of the Chinese text:

Serial port TTL
From up to down:
VCC(3.3V)
GND
TXD
RXD
PS: Please do not use VCC...

(Last edited by xkszltl on 20 Oct 2015, 22:20)

hey guys im new here and a complete nOOB need help on a router NEXX Nexx WT3020 . I managede to get openwrt on it but now dont know what to do. Im planning to get a pptp Host setted up on it. If anybody can point me out on how to do this most apreciate it my skype paulotav2.Thanks guys

I found this extremely helpful as well:

http://www.myopenrouter.com/article/how … gear-r8000

Just like to point out for the record that obviously there is something strange with my R8000 as I'm still having the "No UBI partition/no rootfs detected" kernel panic even with arokh's latest image. Really annoyed as the problem occurs waaay too early in the boot process for me to have any clue how to try and debug it. Is there a version number or revision on the PCB somewhere that we can compare to at least determine if I've got some wacky/wierdo unit compared to the ones that work?

Hm, so it's not a problem with the kernel then. Only some units? Didn't know there were different revisions. Could the partition table just be messed up somehow during flashing?

One thing to notice:
Seems that the stock firmware can do some configuration that won't be erased by reflashing openwrt or itself. Such as LAN IP

Just a side question. Does any one compare the wifi signal strength and range between stock and OpenWRT?

I didn't test stock and seems the range is not good compare to other router (WRT1900AC).

So, if it's the same for both firmware, then I'm think it's either hardware or software limitation for now.

@xkszltl, hi, is that your point of view that R8000 works well on OpenWrt cc final? I am also from China and currently looking for good AC router for op. WRT1200AC frustrated me due to its unstable wireless driver.

And what about the strength of 2.4GHz/5G signal? It does not matter that much, the stability of wireless does, as I deployed another two wireless AP in my apartment.

I have both WRT1900AC and R8000. WRT1900AC uses the same driver as WRT1200AC and I also suffer from random frozen and have to reboot manually.

I use WRT1900AC as my main router which hosts multiple VPN (IPSEC/L2TP, OPENVPN, Cisco Anyconnect) and it works really will except the wireless issue.

I hosted the same configuration on R8000 and use as my main. Stability wise, it's much better than WRT1900AC where no maintenance is required. The only catch is the wifi signal and range is not good on R8000.

R8000 has less range and signal strength which I don't know is due to OpenWRT driver or it's the same spotty even if using stock firmware.

With OpenWRT, 5G signal is not very good, maybe not enough to cover a big house(I'think 150m^2 maybe its limit). But 2.4G is quite good.
For stability, I think is good enough for home user, but don't expect it can do 24*365 without anything wrong.
I use enterprise solution at home for my gateway/firewall/core switch, and use R8000 just as an AP or temp gateway/NAS in traveling.