Just a note, be aware that you most likely run into problems with this build. Since official dd-wrt has currently no support for this unit. This build and previous builds from tathagata contain binaries + kernel from netgear oem + upgrade routines, that may not be compatible with dd-wrt and introduce bugs that are not contained in dd-wrt + these binaries most likely lack features that are included in dd-wrt broadcom drivers etc.
Therefore if you want to test out dd-wrt on this unit it is probably ok to use it, but you should be prepared to hook up a USB-TTL adapter in case something goes wrong or if you want to return to OEM fw.
R7000 support will get into dd-wrt once we have a unit. That is also the reason, why there is R6300v2 R6250 is currently not supported, we just don't have a unit to work with. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 11 Oct 2013 Posts: 8 Location: United States
Posted: Fri Oct 11, 2013 17:51 Post subject:
@madhatter01 - Read that thread, the firmware did not work for me, and it seems to be based on an older kernel?
@kong - Thanks for all that you do!! I'm sending you a Netgear Nighthawk R7000 today. I'll send a small Paypal donation to dd-wrt today as well. All this in the hopes that dd-wrt can "officially" support this fantastic router soon. Of course, I'm anxious to use dd-wrt on my own R7000, and I hope you can succeed with a latest kernel build for it as well. I'll send you a PM......
Just a note, be aware that you most likely run into problems with this build. Since official dd-wrt has currently no support for this unit. This build and previous builds from tathagata contain binaries + kernel from netgear oem + upgrade routines, that may not be compatible with dd-wrt and introduce bugs that are not contained in dd-wrt + these binaries most likely lack features that are included in dd-wrt broadcom drivers etc.
Therefore if you want to test out dd-wrt on this unit it is probably ok to use it, but you should be prepared to hook up a USB-TTL adapter in case something goes wrong or if you want to return to OEM fw.
R7000 support will get into dd-wrt once we have a unit. That is also the reason, why there is R6300v2 R6250 is currently not supported, we just don't have a unit to work with.
Is it necessary to send routers in or would remote access to a computer with TTL/Serial and Ethernet generally be sufficient for getting a build added? Or is specialized equipment needed to add these to DD-WRT builds?
Just a note, be aware that you most likely run into problems with this build. Since official dd-wrt has currently no support for this unit. This build and previous builds from tathagata contain binaries + kernel from netgear oem + upgrade routines, that may not be compatible with dd-wrt and introduce bugs that are not contained in dd-wrt + these binaries most likely lack features that are included in dd-wrt broadcom drivers etc.
Therefore if you want to test out dd-wrt on this unit it is probably ok to use it, but you should be prepared to hook up a USB-TTL adapter in case something goes wrong or if you want to return to OEM fw.
R7000 support will get into dd-wrt once we have a unit. That is also the reason, why there is R6300v2 R6250 is currently not supported, we just don't have a unit to work with.
Is it necessary to send routers in or would remote access to a computer with TTL/Serial and Ethernet generally be sufficient for getting a build added? Or is specialized equipment needed to add these to DD-WRT builds?
Sometimes it is enough if we get infos from serial console. But one little mistake/bug and a unit can be permanently broken. E.g. overlock detection is not working and you pres the wrong button in the webif, boom unit will be dead. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Just a note, be aware that you most likely run into problems with this build. Since official dd-wrt has currently no support for this unit. This build and previous builds from tathagata contain binaries + kernel from netgear oem + upgrade routines, that may not be compatible with dd-wrt and introduce bugs that are not contained in dd-wrt + these binaries most likely lack features that are included in dd-wrt broadcom drivers etc.
Therefore if you want to test out dd-wrt on this unit it is probably ok to use it, but you should be prepared to hook up a USB-TTL adapter in case something goes wrong or if you want to return to OEM fw.
R7000 support will get into dd-wrt once we have a unit. That is also the reason, why there is R6300v2 R6250 is currently not supported, we just don't have a unit to work with.
Is it necessary to send routers in or would remote access to a computer with TTL/Serial and Ethernet generally be sufficient for getting a build added? Or is specialized equipment needed to add these to DD-WRT builds?
Sometimes it is enough if we get infos from serial console. But one little mistake/bug and a unit can be permanently broken. E.g. overlock detection is not working and you pres the wrong button in the webif, boom unit will be dead.
Would that be a software bug in general from a DD-WRT test build? I would think the risk of that breaking something would be about the same regardless who has it if the same person built it and was testing remotely. Just wondering, why not just add busybox and telnet/ssh to the stock oem firmware and get the information needed from that, then you wouldn't even have to deal with annoying serial connections right?
Posted: Sat Oct 12, 2013 11:55 Post subject: Re: Netgeear R7000
Lightsword wrote:
Would that be a software bug in general from a DD-WRT test build? I would think the risk of that breaking something would be about the same regardless who has it if the same person built it and was testing remotely. Just wondering, why not just add busybox and telnet/ssh to the stock oem firmware and get the information needed from that, then you wouldn't even have to deal with annoying serial connections right?
The overclocking is just an example. Someone else had this unit and when he pressed save after flashing he did not notice that the cpu clock in the gui showed 200mhz and even if he had noticed it he wouldn't have known the consequence. We have experience and know this kind of stuff + we don't have to give anyone instructions which probably takes longer then adding support for it. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Posted: Sat Oct 12, 2013 12:45 Post subject: Re: Netgeear R7000
<Kong> wrote:
Lightsword wrote:
Would that be a software bug in general from a DD-WRT test build? I would think the risk of that breaking something would be about the same regardless who has it if the same person built it and was testing remotely. Just wondering, why not just add busybox and telnet/ssh to the stock oem firmware and get the information needed from that, then you wouldn't even have to deal with annoying serial connections right?
The overclocking is just an example. Someone else had this unit and when he pressed save after flashing he did not notice that the cpu clock in the gui showed 200mhz and even if he had noticed it he wouldn't have known the consequence. We have experience and know this kind of stuff + we don't have to give anyone instructions which probably takes longer then adding support for it.
Well, I guess that makes sense for most users, but I would assume if you had serial hooked up most brick issues would be recoverable in general aside from frying it. BTW is there any reason you wouldn't be able to use the necessary kernel configs and boot requirements from the stock firmware configs most of the time? That seems like a really easy way to get a lot of hardware specific information on these routers to me rather than having to serial debug them.
Posted: Sat Oct 12, 2013 20:00 Post subject: Re: Netgeear R7000
Lightsword wrote:
Well, I guess that makes sense for most users, but I would assume if you had serial hooked up most brick issues would be recoverable in general aside from frying it. BTW is there any reason you wouldn't be able to use the necessary kernel configs and boot requirements from the stock firmware configs most of the time? That seems like a really easy way to get a lot of hardware specific information on these routers to me rather than having to serial debug them.
Normal brick issues yes, but once cfe gets corrupted or if you mess up settings that are used by the cfe, serial won't help anymore only jtag.
Yes there are multiple reason why we cannot use most of their stuff.
-they use drivers that require a broadcom license and you cannot redistribute it without permission, so their kernel config differs
-they usually don't have a multi source firmware, asus lately does support a few models with one source. This way it is possible to spot possible values by searching for model names others just hardcode it in the sources and you have a hard time finding these values. Its just faster to hook up serial and dump nvram
-they use old kernels, we now use latest stable linux kernel, so we can support newer external hardware e.g. large drives with 4k sectors etc.
-we support hundreds of models in one source
-they also come with bugs and we need to fix those and not wait for fixes by oems in drivers or kernels, for example tomato cannot fix any issue in the wireless driver by themselves but have to wait for asus etc. to release a new driver with a fix. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Wasn't really talking about pulling in any large amount of code or anything, just searching for certain config variables and anything else needed in the oem source that DD-WRT typically need to boot or for routerdetection. Is it just memory and cpu configuration and that type of thing usually to get a router to bootup? One thing interesting is that a lot of the time, oem source already has the cfe bin dumped already sitting in a directory. From what I can tell quite a lot of routers use some sort of variant of cybertan firmware with fairly straight forward make configs, although some like asus seem to do their own type of thing but the configs seem all fairly similar, same architecture and so on. Attached some pulled configs for WD AC1300, they seem to have nvram configs although I'm not sure if that's typically enough to add a new device. If I knew what specific broadcom config variables were usually needed to add a router I might be able to find them.
@kong - Thanks for all that you do!! I'm sending you a Netgear Nighthawk R7000 today. I'll send a small Paypal donation to dd-wrt today as well. All this in the hopes that dd-wrt can "officially" support this fantastic router soon. Of course, I'm anxious to use dd-wrt on my own R7000, and I hope you can succeed with a latest kernel build for it as well. I'll send you a PM......
@kong - I also sent a small donation for R7000 support.
@kong - Thanks for all that you do!! I'm sending you a Netgear Nighthawk R7000 today. I'll send a small Paypal donation to dd-wrt today as well. All this in the hopes that dd-wrt can "officially" support this fantastic router soon. Of course, I'm anxious to use dd-wrt on my own R7000, and I hope you can succeed with a latest kernel build for it as well. I'll send you a PM......
@kong - I also sent a small donation for R7000 support.
Hehehe, well the donation probably went to dd-wrt paypal account, while I used to have my own donation button inside my old K26 kongmod builds I did not bother do do this in my current builds anymore. Basically it was not worth the effort. I think I received maybe 60€/year, not even enough to get a router, but luckily sometimes people manage to ship one and there is a unit on its way now. So I'm confident that the R7000 and maybe R6300v2 + R6250 will soon be supported. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
I'll send you a PM......