[sploit]

I could just build a initramfs that issues the MTD command on boot by adding it to the OpenWRT Startup Script. Would be fast and would reboot the router into tftp mode.

That would be easier huh?

[OneMoar]

that would work but I am not sure if auto nuking the firmware/nvram is the way to go reboot directly into tftpmode would be nice if it could be done without auto-nuking or at least change it to expect any .chk you throw at it
a botched mtd erase could end in permabrick if its interrupted or something unexpected happened

there has gotta be a way to get it to tftp any chk you throw it at once openwrt is loaded probly would involve including tftp client for recovery to override the cfe routine once openwrt was up that way you can use tftp32d and just have any old image renamed to say recovery.chk

I tried twice to reflash tomato from openwrt and it bombed each time eventually it crashed it self into a state where I was able to tftp the stock neargear firmware with good ol tftp2.exe (tfptd32 would't let me push a image no matter what I did)

[sploit]

I actually put that in the notes...

You cant use TFTP2 because the transfer times out with it.

As far as not being a good idea.... On the r6300v2 its a great idea because it forces it into tftp mode and awaits any valid firmware.

However I am unsure if the 6250 is different so I would have to get one and see.


Also for KONG

What router are you needing the most to be donated right now?

[OneMoar]

[OneMoar]

tftp32d would not push R6250-V1.0.4.2_10.1.10.chk

after loading vmlinuz no matter what I did so I issued a mtd erase firmware and then booted it holding the reset button which put it in tftp mode

the ping went from the stander ed 5 second wait to TTL=100 constantly until you flashed something then it would reset and load the new firmware and the light turned from steady orange to flashing green indicating waiting for image once you wrote a image with tftp2.exe it would go timeout and then destination host unreachable as it rebooted and then resume loading the new image


after that I could flash anything I wanted with tftp2.exe from windows 10 (which should't work because of 10's new netstack but it did =/ )
I tried AT first then the stock netgear firmware both images where successfully sent by tftp2.exe but only the stock netgear one took which may or may not have been because of the image size and the stablity of the openwrt session

[<Kong>]

[Xeon2k8]

Hi guys, so from I what I have understood R6250 would also brick on BS builds later than 30432?

@Kong do you know when the image size problem is going to be resolved? If it's planned to be resolved at all..

Thank you all

Edit: Ok, seems that anything lower than R6400 won't work, found these
http://svn.dd-wrt.com/ticket/5530
http://svn.dd-wrt.com/ticket/5560
http://svn.dd-wrt.com/ticket/5571

[sploit]

I cant speak for the r6400 but ..
Considering they are similar in most ways there is definitely something wrong with the builds after 09/01/2016 and the image sizes jumped by almost 3 Megs. They are bricking the r6300v2's.

Kong's builds are stable and I have flawless runtime so stick with the Kong Builds until this gets resolved with Brainslayer.

I have noticed OpenVPN issues after 09/01/2016 on Brainslayer builds on other Netgear Models also.

[merrow75]

Hello,

I attempted to load dd-wrt.K3_R6250.chk (dated 2016-09-27) onto a R6250 running v1.0.1.84_1.0.78 using the Netgear GUI.

After the GUI accepted the upload of the file, the R6250 went into rolling reboots.

It is pingable at 192.168.1.1 for a few seconds until it next reboots.

I have configured a tftp server on a Ubuntu 16.04 laptop and placed the vmlinuz (unzipped) file into the root of the tftp server

I have verified that the tftp server is working by using a tftp client to get the vmlinuz file.

But the R6250 does not pull the vmlinuz file and the rolling reboots continue.

I have installed Wireshark but it does not show any evidence that the R6250 is trying to read from the tftp server.

Any suggestions?

Thank you for your help.

[sploit]

The TFTP server has to be on 192.168.1.2.

Also if the IP is pingable for a few seconds that suggests bootwait is enabled.

[ghoffman]

the major problem with this router is that the cfe checks the header on the .chk firmware against a string in the "board_data" mtd partition, which is returned by the 'burnboardid' command in stock netgear firmware as board_id=U12H240T00_NETGEAR
if firmware was loaded which does not respect the board_data partition, or which changes the the board_data, or if the uploaded image does not contain the correct header, then the tftp ddaemon will not flash the uploaded firmware.

if the board_id partion has the correct stricng, then you have to upload a .chk image made for the r6300v2.

if the board_id partiton contains HDR0 (which occurred on mine by not going correctly back to stock from dd-wrt or tomato) then i *think* serial recovery is still required.

in my case (many times0 the router would send continual ttl=100 replies to ping, would accept a tftp'd image, but would not flash.
I tried the vmlinuz-via-tftpd many times and there was never an attempt to load the image.

the only way i got out of this mess was to tftp a hdr0 file (without he extra header in a .chk file) an issue the following coomadn on the serial console:
flash -noheader : flash1.trx

i have modofed the cfe on my R6300v2 to have boot_wait=on and board_id=U12H240T00_NETGEAR in nvram. but i havent tested the softbrick-resilience yet. i have in my head a modified xvortex cfe to get around all this board_data nonsense, but i'm not far into that project yet.

my knowledge of these subjects is entirely by extensive reading of these boards and too much time obsessing with my own devices. this is meant to be helpful and i invite more help. thank you

[sploit]

You are correct and I stated this.

If the board is awaiting firmware it will ping 100 and you have no need for the bootwait. Simply flash the firmware.

[merrow75]

Thank you for the replies.

The tftp is on 192.168.1.2 - sorry for not providing this detail earlier.

I will try again otherwise I will explore recovery via serial.

Thank you again.

[merrow75]

Quick update:

I returned the R6250 to Netgear firmware using serial recovery so at least the router is online.

I will attempt to load dd-wrt again.

[sploit]

Im gonna get one of these and see what it does via serial.

The process may be a little different on it.