Just recover with serial console or put it in download mode and reflash the whole thing, those are your only options

Yes. Serial access and download mode. Start reading at post #300.

Matthias, you have a magical aura: i've spent a lot of time today using info from post of drizzt81 without success (even tried a lot of revisions of upgrade software). And now i've scored, so a LOT of respects to you.

Nevermind, i like to migrate to Backfire's firmware. What's step was wrong during changing MAC?

UPD: by the way, after recover all settings are present: router ip, SSID, wpa2 settings and key, mac address clone. I've downgraded from backfire to 2.0.17 and didn't loose anything. Is it normal?

(Last edited by behemoth_kat on 8 Apr 2010, 20:15)

Yes, this is normal as the NVRAM partition is untouched by OpenWrt. And that's where the stock firmware stores its settings.

(Last edited by maddes.b on 8 Apr 2010, 21:22)

Use the console via TTL-serial cable connection.
Issue:

Copy & paste the output here.
You have and old problem if looks like this:

Okay, now i got the same router status 3 times doing only one setting change and then apply it. It doesn't belong to MAC address change. All three times i got that some kind of 'bricked router' when i change to "40MHz and above channel" in wifi section. All symptoms are the same as my first time: i switch this option from "20MHz" to "40 and above", apply it, webgui tried to reload and timeout. Router keeps ip's, SSID and blah blah blah, blink all LEDs as normal, wifi scanners shows network encription, etc., accept my WEP key and so on. But NO access to webgui, no ping to router, connect but cannot put any file to router using tftp.

@behemoth_kat:
It seems you didn't read the known issues info before flashing Backfire. See post #814.
It was already mentioned there.

So the mac fix works when you stay at "20 MHz".

(Last edited by maddes.b on 8 Apr 2010, 22:22)

I uploaded a tar.gz of the stock rootfs from WRT350Nv2 firmware 2.0.20: ftp://ftp.maddes.net/openwrt/trunk/orio … /binaries/
Get it while you can, maybe it could be handy for you sometime.

Nope, i read a lot on pg.33. and some from last RC1-RC3 tickets on backfire dev website. But nobody mentioned that 'g+n wide mode doesn't work' statement means 'bricked router'.

I'd say bricked is a pretty bold claim, you seriously need to brake u-boot in a flash attempt in order to be unable to restore with the download mode. When you do break u-boot there's still JTAG access, though JTAG from scratch is the one bit about the wrt350nv2 where we are in the dark. Cause Linksys didn't provide us the full sources... but still, with time that should be possible.

If you ask me u-boot's the only thing needs patching in order to call this device fully supported.

- edit -
One more thought about changing MAC addresses. Sure it's good to having set the proper MACs to all interfaces, however, if you only use one wrt350n in your network you really don't need to change the MAC in order for the device to work. Okay, so maybe you have an ISP which requires a certain MAC, you'll only need to set the MAC for your WAN side, which is already supported in the /etc/config/network script. If it gives you so much trouble why not wait for a new release from OpenWRT which includes the MAC patch.

(Last edited by dirkNL on 8 Apr 2010, 23:46)

Just having the MAC addresses in /etc/config/network broke network access when I upgraded to backfire since the other script was missing. I had to comment them out from the serial console for networking to start working again.

yes, that's true. But i should use two linksys router to cover my appartment and like to move both router to backfire.

I always flash new versions without keeping my config (e.g. sysupgrade -n) and start from scratch.
This avoids any issues with tests and changes I done to the previous versions.
If you are sure that you did not change anything special in the old version, then keeping the config should be fine.

For fast setup I wrote two simple scripts:
* the first sets up the network and other essential stuff (lan, wan, dhcp, timezone, dropbear)
* the second updates the package list, installs all needed packages and configures uci as wanted

To set it up within some minutes I do the following:
a) telnet to router, change root password to enable SSH
b) use WinSCP to connect to the router and copy all necessary files and scripts to it
c) ssh to the router, execute first script, then reboot
d) ssh to the router, execute second script, then reboot
e) ssh to the router, install webif (X-Wrt), do manual changes, then reboot
    P.S.: To remove luci use: opkg --autoremove --force-removal-of-dependent-packages remove luci-core luci-theme-base luci-nixio
Takes roughly 5 minutes, mainly for downloading and rebooting (which I prefer over restarting all services - that's only for initial setup).

Updated post #375 accordingly.

(Last edited by maddes.b on 9 Apr 2010, 10:19)

Hello everybody,

I am not a linux expert, but when I saw that the Backfire OpenWrt 10.03 was finally released, I decided to use it on my WNR854T router.

After some time and some worries (I lost once the Luci interface when I tried to remove the english interface), it is running without too many issues. I have however one concern: it is not really clearly described in the device page, but the Wifi does not seem to be supported (it is written "disabled" not "not available"...). I also read in this thread that there was some work on the wifi driver: could someone tell me when this function will eventually be available ?

Thank you in advance

PS: all my interfaces' MAC adresses are wrong but that does not seem to create issues (as far as I can see..).

Created a backfire build with the mac address patches and kernel 2.6.32.11 for people who want to test it.
No web interface included!!! Use at your own risk!!!
ftp://ftp.maddes.net/openwrt/backfire/orion/

Update:
Rebuild with r20886, this time including luci, and again with mac address patches and kernel 2.6.32.11.
Use at your own risk!!!
ftp://ftp.maddes.net/openwrt/backfire/orion/

Update 2:
If you want to switch to the webif (X-Wrt) interface, then take care that in package "webif - 0.3-4893" the file /etc/httpd.conf is missing.

# remove luci
opkg --autoremove --force-removal-of-dependent-packages remove luci-core luci-theme-base luci-nixio

# add webif
opkg install webif

# check if missing file exists
ls -la /etc/httpd.conf

# if not, then add missing file
echo '/cgi-bin/webif/:root:$p$root' >/etc/httpd.conf
echo '/cgi-bin/webif/:admin:$p$root' >>/etc/httpd.conf

# restart web server
/etc/init.d/uhttpd restart

(Last edited by maddes.b on 16 Apr 2010, 20:37)

@ maddes.b 

I got the reply from Nilred that because I'm not a developer here,
he will not even let me test the WIFI patch     whatever...

He says that the patch does work tho.

Now that there are a growing number of 854T users willing to test, maybe you can get him to give you
the patch for inclusion in your builds.

As always, thanks for your help 

(Last edited by jammers on 14 Apr 2010, 23:36)

To add to jammers' point,  there are many of us willing (& eagerly waiting) to test 854T wifi patch when its made available...

Hint, hint.
There is (some kind of) a typo:
+    { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, },
/drivers/net/wireless/mwl8k.c already has a similar line:
    { PCI_VDEVICE(MARVELL, 0x2a0c), .driver_data = MWL8363, },
Who cares to recompile for a byte difference when dd (hexedit) will do?
So there is (some kind of) a typo, too:
mv fmimage_8XX1.fw fmimage_8363.fw
mv helper_8XX1.fw helper_8363.fw
BTW the (same) hack from which I'm inspired is now making it's way upstream!

diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index ac65e13..4e58ebe 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -3851,6 +3851,7 @@ MODULE_FIRMWARE("mwl8k/helper_8366.fw");
 MODULE_FIRMWARE("mwl8k/fmimage_8366.fw");
 
 static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = {
+    { PCI_VDEVICE(MARVELL, 0x2a0a), .driver_data = MWL8363, },
     { PCI_VDEVICE(MARVELL, 0x2a0c), .driver_data = MWL8363, },
     { PCI_VDEVICE(MARVELL, 0x2a24), .driver_data = MWL8363, },
     { PCI_VDEVICE(MARVELL, 0x2a2b), .driver_data = MWL8687, },

Thanks a lot!

I need some more help with debricking...  I put the 03/29/10 build on my wnr854t, and got it up & running.  Then, for some reason, it got bricked.  I think i was in luci interface doing something basic when it happened. 

Now it keeps giving the "### JFFS2 LOAD ERROR<0> for uImage!" and "Bad magic number error".    After some digging, i found someone here with the bad magic nbr issue was able to flash the jffs builds and then put netgear firmware.  I tried doing just that, but it does not fix the issue for me. 

Any suggestions.  Thanks

================================================================
U-Boot 1.1.1 (Apr 18 2007 - 16:05:00) Marvell version: 1.7.3

DRAM CS[0] base 0x00000000   size  32MB
DRAM Total size  32MB
[8192kB@ff800000] Flash:  8 MB
Addresses 20M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (20M - 16M): Done

Soc: 88F5181 B1
CPU: ARM926 (Rev 0) running @ 500Mhz
SysClock = 166Mhz , TClock = 166Mhz

USB 0: host mode
PCI 0: PCI Express Root Complex Interface
PCI 1: Conventional PCI, speed = 33000000
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0
### JFFS2 loading 'uImage' to 0x400000
Scanning JFFS2 FS: ..... done.
find_inode failed for name=uImage
load: Failed to find inode
### JFFS2 LOAD ERROR<0> for uImage!
## Booting image at 00400000 ...
Bad Magic Number...do_bootm
Start Gemtek tftpd for Netgear GE RT!
TFTP Server IP is : 192.168.1.1
Load address: 0x400000

(Last edited by nd_100 on 15 Apr 2010, 17:15)

Hi.

I got the WNR854T wifi card working (With the mwl8k dirver). Only in STA mode right now. But its a little progress.
Wrote about it here https://forum.openwrt.org/viewtopic.php?id=15590.

I followed the HOWTO in order to compile openwrt with block-mount enabled. Made wrt350nv2-uImage & root.squashfs and dd them in mtdblock0 & mtdblock1.
When I reboot, I have the "Bad Magic Number" in U-Boot. Don't understand what's wrong.

What is the good way for flashing a new kernel (read and re-read the thread, but can't find the good solution) ?
How to build a sysupgrade image, since sysupgrade seems to be the simpliest way to flash ?

Thx

@baxter:
Which HOWTO?
Did you start with post #300, read it and also read the other posts about flashing mentioned in it? (especially #375 and #341)

Sysupgrade is already there, if you used the latest trunk.

(Last edited by maddes.b on 20 Apr 2010, 22:55)

The howto on roofs on USB : http://wiki.openwrt.org/doc/howto/rootf … nalstorage

I sumarise the flashing techniques:
- JTAG (I prefer not to...)
- direct on U-Boot, risk of destroying the U-Boot or Ercom loaders
- in linux
  - with dd (what I've done)
  - with sysupgrade

I finally rebuild all the images and reflash with dd => its now ok (think I've missed something during images building)

Sysupgrade is avalable in openwrt, but how do we build a good image to upgrade with sysupgrade (e.g. building wrt350n.bin for sysupgrade -n /tmp/wrt350n.bin)? Is there an option in building configuration (menuconfig) or something else ?

@baxter:
According to your answer, you did not read the mentioned posts thoroughly as then you would know that it is called "openwrt-wrt350nv2-squashfs.img". Please read posts #300, #375 and #341, it's for your own good. (Note: not meant offensively)

(Last edited by maddes.b on 20 Apr 2010, 22:55)