I haven't been able to get this thing to respond properly after flashing with April 23 experimental or the 20050202 obsolete snapshot.  Can't ping it, can't telnet or SSH, and nothing responds on port 80. 

When it's first flashed, it tries to reboot, but the DMZ light never lights up, so I don't think it was making it through its firstboot stages.  After waiting 10 minutes to be sure it wasn't doing anything, I unplugged it, waited a few, and plugged it back in..  This time,  the power light blinked irregularly for a little while, and then went solid.  The lan light I'm plugged into blinks with network activity.  WLAN light is off.  The DMZ light lights during bootup as it should and shuts back off.

I tried the exerimental build found at http://openwrt.inf.fh-brs.de/~nbd/gcc34/ because it supposedly had some tweaks to make it more v1.1 friendly, but had the same results.

The only thing that makes it behave like expected is Satori 4.  It seems to work perfectly with Satori. 

So is there something I'm missing?  What's in openwrt that makes my v1.1 router hang?  does somebody have an OpenWRT build that they are using on their G v1.1 right now? experimental or stable?  I'd love to try it!

Thanks

Are you using the right binary?  You don't mention if you have a G or a GS. Make sure the binary you use matches your hardware, eg on the WRT54GS use the image named openwrt-wrt54gs-squash.bin

note: The stable release will not run on either the Gv2.2 or GSv1.1

Really, what do you think?

If the experimental image doesn't work for you, you're either using the wrong binary or you flashed it wrongly. I use tftp-hpa from Linux out of the following script - & works fine, every time.

#!/bin/bash
echo "
rexmt 1
timeout 1800
trace
verbose
status
put $1
status" | /usr/bin/tftp -m binary wrt

I also had some problems flashing the experimental firmware on an asus wl-500g.  Issuing a "mtd unlock OpenWrt" and then "mtd erase OpenWrt" was a way for me to get a successful  boot after the new experimental firmware download.

(Last edited by acoul on 17 May 2005, 04:03)

frogzoo, thanks for your quick reply. 

Actually, I mentioned that early on the post.  It's a G, v1.1.  And I'm using the G image, squashfs indeed.

It's not apparent that I'm having any trouble whatsoever in the flashing stage.  Just as you, I've got a tried-and-true method that's always worked for me.  The right number of bytes get stuffed in there.  Flashing by web administration and tftp both work every time.  It's after the reboot that the problems climb out.

I'm using tftp-server rpm from my distribution, I don't think that's tftp-hpa you mentioned.  I'll try the hpa one to rule it out and get back at you.
Gosh I wasn't paying attention when I wrote this.  tftp-server of course doesn't matter.  but the tftp client I'm using isn't the hpa one if I recall correctly

Thanks!

(Last edited by mrmoj on 17 May 2005, 06:03)

acoul, the only way I can talk to my box is with Satori 4's 'command shell' -- after an openwrt flash of any kind, I can't speak with it.  So, if I'm stuck in Satori, I wonder if mtd will even be able to find anything called OpenWrt? 

Thanks for your suggestion, I'll poke around!

Moj

mrmoj, in this case, I'd suspect your squashfs is giving you trouble with bits left over from a previous install probably.

You need to boot into failsafe mode (WAIT for DMZ to flash (indicates WRT startup) & THEN press reset - DMZ will now flash 3x/second). Once WRT is up, run

#firstboot

Also there are a few issues with experimental - some of the NVRAM variable names have changed. If you have a G, I'd say you'd get better mileage with using the latest stable snapshot - see here
http://openwrt.org/OpenWrtDocs/Installi … b8d1e78138

For good measure, then after reboot, run

mtd erase nvram
reboot

This will erase your NVRAM and CFE will restore the defaults on reboot.

5 bucks says you do all 3 of the above, and you'll have a working router.

(Last edited by frogzoo on 17 May 2005, 06:51)

I can get it into failsafe mode as evidenced by the 3/sec DMZ light, but it's questionable how failsafe this is, since it doesn't respond to telnet, ssh, http, pings, or arp who-has requests.  Thus, not quite sure how to tell it to re-tailor its partition with the firstboot utility without a serial console into CFE.  Satori's command shelly toy can't find mtd in the path, so no erasure there, unless anybody can confirm mtd's in there and where it's located.

At the top of the OpenWRT page you provided the url to, I clicked the link named 'here' for stable binaries.  A note that says use_experimental_release and a folder called OBSOLETE.  In the Obsolete folder, I've tried 20050202, and now 20041127.  I can't get 20041127 to even enter failsafe mode.  I am assuming that these _are_ the stable binaries, only marked OBSOLETE 'cause the experimental works in most instances?

For kicks I tried the image at http://openwrt.org/downloads/experimental-old/bin from a month prior, but of course no go. 

I should add a serial port to figure this madness out?  Or just give it to you for your time I've wasted?

Seriously though, what can I do if the router won't assume the proper ip and state when I tell it to go failsafe?  at this point, assuming that the prior owner didn't corrupt anything too badly with a prior install, /etc/sysconf should be a link to /rom/etc/sysconf, which will contain the proper failsafe config.  If /etc/sysconf is corrupt somehow and is not a link to the proper file, that's what firstboot will fix, right? 

Of course, it could be anything else too.  It really seems like the serial console is the way to go.

Thanks for all your help!

Mojo

Use the latest binary from here
http://openwrt.org/downloads/snapshots/OBSOLETE/

Yes, curiously "obsolete" is also the "stable" release

In failsafe mode, the IP should be 192.168.1.1

And you need to be plugged into the LAN port #1.

I am plugged into LAN port 1, I have manually configured myself as 192.168.1.2/24 -- and, per my previous message, I _have_ tried a few stable images:

How many of these images should I successfully try flashing my router with before I give up and ask again

How do I run the firstboot script if my router won't enter failsafe mode?

It would be impossible without a serial console, right?    How come nobody says "if your router won't enter failsafe mode here's a possible reason..."  Is it physically impossible for openwrt to fail entering failsafe mode?

Have you tried booting the Linksys firmware?

I have been unable to find a linksys rom smaller than the size limit for tftping in the boot_wait period, but since satori flies I will use it to upload the latest linksys one.  Didn't linksys just release one that disables the ping hack, however?

As far as I know, any image < 3meg can be tftp'd without problems.

Yes, latest Linksys firmware has disabled the ping hack. Somewhere the docs mention which version works.

So I tried latest experimental but with jffs2 partition instead of squashfs, and it worked beautifully.  first things first though:

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "pmon"
mtd1: 003b0000 00010000 "linux"
mtd2: 00170000 00010000 "rootfs"
mtd3: 00010000 00010000 "nvram"
mtd4: 001c0000 00010000 "OpenWrt"
root@OpenWrt:/# mtd unlock OpenWrt;mtd erase OpenWrt;mtd unlock nvram;mtd erase nvram;mtd unlock rootfs;mtd erase rootfs;mtd unlock linux;mtd erase linux
Unlocking OpenWrt ...
Erasing OpenWrt ...
Unlocking nvram ...
Erasing nvram ...
Unlocking rootfs ...
Erasing rootfs ...
/bin/ash: mtd: Input/output error
/bin/ash: mtd: Input/output error
root@OpenWRT:/# ls
/bin/ash: mtd: Input/output error
root@OpenWRT:/#

Oops, mebbe I should have left the nvram alone, no more boot_wait period...   HAHA can't believe I pressed enter on that line...  DMZ light doesn't even light any more, just continually reboots.  Definately got my work cut out for me
frogzoo, thank you for all your help, suggestions, and patience.  You've gotten me on the right track!

(Last edited by mrmoj on 18 May 2005, 18:25)

You wiped the filesystem, nvram and the firmware.

Upload the firmware again, should boot with default nvram values.

This was apparently a blessing in disguise.  In all my experience with OpenWRT on the G v2.2, the power light was solid on power up and all through the DMZ light.  With this G v1.1 I've been having problems with, the light was having an epileptic staggered blink (approx like 10100110) on powerup.   I had just assumed it was a difference between the hardware revisions, but now that I blanked it's mind entirely and recovered with failsafe mode by shorting the data lines on the flash chip per void main's howto, the power light is solid on bootup just like the v2.2s.  madness.  So as far as I can see, it's all perfect now, with squashfs on the latest experimental. 

I'm not sure, however, that shorting the address lines on the flash chip at bootup would have fixed everything without having gotten openwrt-jffs2 in there and erased everything with mtd.  It's as frogzoo originally said,

I just couldn't erase it.  madness!

Thanks everybody