I have attempted to modify the state of the LED's using the following command:

echo "0x01" > /proc/sys/diag

However it did nothing.  Command wasn't error'd out, just silently terminated, after doing a cat on the file in question it returned "1" as expected.   Again, the LED did NOT show any difference.

My suspicions, (And I know almost nothing about this.) is that OpenWaRT is making the power LED stop flashing once booted, to simulate the stock firmware and indicate to user that the WaRT is booted.  However the new hardware version has changed something concerning the LED's and causes the command previuosuly mentioned not to work anymore.  However I have NO clue how to fix it, just wanted to enlighten anyone that might know what's going on, 'cause I don't. 

I've restored completely my G2.2, and re-flashed with RoDents, as said.

Still the same problem with the wireless!!

any clues??

Thanks
yurgi

My hardware is GS v1.1. Using openwrt-gs-code.bin.

I tried the whole procedure again. This time I am sure that it was at 192.168.1.1 on Linksys's 3.37.2 firmware. But still I get the same result. After the successful tftp, the power led flashes. After 10 min I unpluged then repluged the power, power led flashes. And still I cannot telnet into it.

I wonder if it is possible to separate the 5 ports into differents vlans in the new WRT54G v2.2.
With the ADMTek switch it was possible with the admcfg tool and the adm.o module, or I also configured many vlans separating the ports with the adm6996.o module.
I haven't bought a new v2.2 yet so I didn't try this task.

My apologies. It would appear as if there is a problem with the wireless interface on the image I've built.

I should hopefully have it sorted out within a few hours once I've completed the full 3.37.2 integration into the OpenWRT tree.

Unfortunately, it seems like the new driver doesn't support the IOCTL's so things like iwconfig won't work anymore. Not a big issue I suppose, but sad nonetheless.

I'll look into the diag LED issue. Haven't really paid the flashing LED much attention, seeing as I don't have a front cover on my development WRT.

I have now completed a buildroot for openwrt, entirely based on the Linksys 3.37.2 code.

New snapshot image is available at http://rodent.za.net/files/openwrt/

I've confirmed that the wireless works, and the diag LED is now back to it's normal nonblinking state

Untested on a GS, but my v2.2 54G took it just fine. I took the liberty to include the "wl" utility, since a wrt without it is pretty useless.

I'll upload the buildroot as soon as I've had some dinner.

In that case I'm unfortunately of no help.  (If I was any tobegin with.)  I have a WRT54G V2.2.

LED wasn't a big concern, just confirming that the same issue was occuring with mine.

I noticed that, but didn't think anything of it, as I'm not used to what the previous versions of the WRT had, or didn't have.  I also noticed it didn't have "wl" and greatly appreciate it being included in the bin.

I'll flash the new bin tonight, I'm "working" (or pretending to be), once I get off, I'll flash it and give you my results.

I've tried it, IT WORKS!!!!

Yes, works perfectly indeed. I just want to thank RoDent for his effort and his contribution!!

By the way... I've noticed I have to bring up the wireless every time I boot up. I read somewhere to do it like this:

wlconfig vlan0 up
wlconfig eth1 up
wlconfig eth2 up
wlconfig eth3 up

being these 4 interfaces my lan_interfaces. Is it correct? Any other ways to do it?
Is it necessary to add a script to do it automatically at start up, or is there a cleaner way??
thank you

It appears as if the new "wl.o" modules leaves the interface in a "down" state when the module is inserted.

A simple "ifconfig eth1 up" in one of your startup scripts should do the trick.

Buildroot for 3.37.2 available:

http://rodent.za.net/files/openwrt/buildroot.tar.bz2

Changes (off the top of my head)
-Uses 3.37.2 kernel
-Netfilter-revert patch disabled (p-o-m seems to patch ok)
-Modified version of addpattern to set the extra flag required for the new hardware
-added a small patch to correct a compile problem in mtd (due to 3.37.3) changes

make/openwrt.mk
---------------
-various changes in the openwrt.mk file, mostly for includes, etc.
-symlink used to create "WRT54GS" subdir, so that patches can still apply cleanly
-new LINKSYSDIR variable that indicates the location of the extracted linksys code (defined in top level Makefile)
-add "customize step" to copy "wl" binary to the rootfs

Probably lots more I've forgotten. I'll go through a proper diff sometime and write up a complete changelist.

The latest version (dated 12-Jan-2005 00:09) boots on my gs v1.1. I haven't tried anything else yet.

TheRoDent
Just grabbed your new buildroot, and it completeded building successfully. However, the image it generated,
openwrt-g-code.bin is a different size than the binary from here: http://rodent.za.net/files/openwrt/
(1598464 vs 1602560)

Normally this would not bother me, but I ran file on several of the binaries in ./buildroot/build_mipsel/root/....
and I get "ERROR: corrupted section header file"
I have built openwrt from sources before (March 2004) and file correctly identifies those binaries.
My question is what might cause this, all I did was dl the tar.bz2 of buildroot, untar it and ran make.
In addition running file on the busybox in the ../busybox-1.00 directory reports "ELF 32-bit LSB MIPS-II....." as it should. And this busybox binary is a different size from the one in the target root/bin.
It's as if the make .... install is hoseing up the bin's as it populates the target root directory.

Thanks...

This size difference is interesting, but could be because I copied something additional into my root whilst I was messing around, or because I was still using the linksys addpattern utility at that point.

Also this is what my sources/dl looks like. It might be different from yours for various reasons.

-rw-r--r--  1 root root    108839 Mar  5  2004 bbc-0.54.3.tgz
-rw-r--r--  1 root root  10575077 Oct 29  2003 binutils-2.14.90.0.7.tar.bz2
-rw-r--r--  1 root root    160605 Jun  8  2004 bridge-utils-1.0.4.tar.gz
-rw-r--r--  1 root root   1118427 Oct 13 11:49 busybox-1.00.tar.bz2
-rw-r--r--  1 root root    134456 Dec 13 22:56 dnsmasq-2.19.tar.gz
-rw-r--r--  1 root root  23279245 Feb 22  2004 gcc-3.3.3.tar.bz2
-rw-r--r--  1 root root    156988 Oct 17 14:33 iptables-1.2.11.tar.bz2
-rw-r--r--  1 root root    302551 Mar 30  2004 libpcap-0.8.3.tar.gz
-rw-r--r--  1 root root    318494 Oct  9 23:55 patch-o-matic-20041009.tar.bz2
-rw-r--r--  1 root root    734588 Jan  5 23:10 sed-4.0.8.tar.gz
-rw-r--r--  1 root root    168340 Aug 31 15:26 squashfs2.0-r2.tar.gz
-rw-r--r--  1 root root   1688686 Jan  1 09:11 uClibc-20050101.tar.bz2
-rw-r--r--  1 root root    119523 Jun 18  2003 wireless_tools.26.tar.gz
-rw-r--r--  1 root root 187839483 Jan  9 10:12 wrt54gs.3.37.2.tgz

file on /usr/sbin/dnsmasq for me:

dnsmasq: ELF 32-bit LSB executable, mips-2 MIPS R3000_LE [bfd bug], version 1 (SYSV), dynamically linked (uses shared libs)file: corrupted section header size.

The "corrupted section header size" is most likely due to "sstrip" the utility used to bare-bone strip the elf-executables that goes on the image. It does some magic with the section headers. This is pretty normal. 2.07 binaries give exactly the same output.

I don't think the size difference is anything to fret about. The difference is exactly 4096 bytes, so it's probably padding.

My sources match the above with the exception of sed,   buildroot won't download a new sed if it is alreaduy installed on your system. I have sed version 4.0.7.

I get

 dnsmasq: ERROR: corrupted section header size 

I have file-4.06

I'm not going to worry about the size issue, but I think I'll do a bit of pokeing around in the Makefile(s) to see what's really going on. I might also flash your image, and then ftp over one of my bins and try to run it. That would give me a hint as to whether the bins in my build were really hosed or not.

Thanks for the help...

TheRoDent

Well I flashed your image and it worked fine, except boot_wait was set to off when it started up.
I then set boot_wait to on and re-flashed it, all-ok.
I then verified boot_wait was still on, it was.
I then flashed the image I built.
It booted and boot_wait was still on.
Things are running fine.

Great work.

I poked around in the make files & archives, and it looks like the stripping that takes place during the populating of the target root is now using "sstrip" which comes from sources/openwrt/tools/sstrip.c rather than the one from binutils.
Reading that code enlightened me as to why I got the error from file.

Thanks again...

I use file-3.37-3.1, which is probably where the difference comes in.

Interesting about the boot_wait, I'd have figured that firstboot sets that upon first bootup - firstboot hasn't changed at all, but I'm not too sure if that is how it's supposed to happen, or whether it is actually firstboot's job either.

Glad to hear it's worked.

I've tried building some of the packages, some of which are broken. Not too sure exactly why that is (patches for some failing to apply), but I've had no problems installing the current openwrt packages from openwrt.org yet, so it's not very high on my priority list.

One of the most recent builds now works on my WRT54GS v1.1. I can't remember which one, but the buildroot compiled happily and works well. I managed to mostly brick it thanks to interface-wrt, but a bootwait flash has made it all well again.

I must be missing something here.  Am I correct that the correct procedure to re-flash a WaRT is as follows:

1) Verify that boot_wait is set to on.
2) reboot WaRT and on another linux machine execute tftp to send WaRT new flash.
3) After the WaRT reboots, get telnet access.  After telnet log in and do what you need to do making sure to give firstboot plenty of time to do it's thing.
4) Make sure boot_wait is still set to on.
5) reboot and see if you can still get in.

I've done these things and it _appears_ as though it didn't flash with the new image.  Does the image overwrite _everything_?  Or does it just rewrite the OpenWaRT software?  Because my previous modifications to scripts and other portions of the file system have remained even after the flash.

tftp executes and seems as though it completed successfully, it never error'ed out, either time I performed the flash.

Am I missing something here?

Or is this a bug?  (I really doubt that. 

Edit:  I'm using the following bin:  http://rodent.za.net/files/openwrt/openwrt-g-code.bin  Could this link be for a older bin?

TIA,
Knight.

I currently purchased a WRT54GS v1.1 (I've had some experience with the older v1.0 revision). I successfully flashed RoDent's firmware and it was working fine for a while...

I'm not sure if this is specific to the v1.1 hardware, but I'm having the following problem and no one that I've spoken to with the old hardware seems to have had it (and as yet few people seem to have a v1.1). My router is effectively 'bricked' and in the following state after attempting to re-flash the firmware (a slightly modified version of RoDent's buildroot, with no significant changes that would provoke such behavior).

Upon power-on, the router is stuck in the bootloader waiting for a tftp transfer. The power LED flashes and the DMZ LED blinks approximately once every second. I transfer an image and it successfully flashes (or seems to), however, the router then becomes stuck in a state where the power LED is flashing and the DMZ LED is steady on. It will stay in this state until power cycled, where it repeats the same behavior over again (i.e., the beginning of this paragraph).

I've tried to hook up a serial console (ttyS0) using the appropriate 0v - 3.3v -> RS-232 level shifting circuitry, yet no matter what baud, bits, parity, stop bit, etc. settings I try, I simply get garbage (however, the router _is_ sending something). Of course I've tried the standard 115200 8N1 setting numerous times to no avail.

If anyone has any suggestions on how to get the router out of this state, I'd appreciate any tips

- Joe

Hello, I have problems compiling this buildroot:

make[1]: Entering directory `/home/marcos.schonfeld/WRT54G-3.37.2/buildroot/build_mipsel/WRT54GS_3_37_2_1109_US/release/src/linux/linux'
make[1]: *** No rule to make target `zImage'.  Stop.
make[1]: Leaving directory `/home/marcos.schonfeld/WRT54G-3.37.2/buildroot/build_mipsel/WRT54GS_3_37_2_1109_US/release/src/linux/linux'
make: *** [/home/marcos.schonfeld/WRT54G-3.37.2/buildroot/build_mipsel/WRT54GS_3_37_2_1109_US/release/src/linux/linux/arch/mips/brcm-boards/bcm947xx/compressed/vmlinuz] Error 2

Can anyone help me?

today morning i got 40 of v2.2 routers from linksys and until there is not available switch chip reprogramming interface similar to adm6996, i have nothing to do with them. I have found list of compatible routers from openwrt FAQ. Does anybody can suggests quick and painless hardware replacement for WRT54G v2.0 from that list? Must use same antenna connectors and exactly same openwrt firmware like older WRT54G's.

Hi,

I tried the new firmware http://rodent.za.net/files/openwrt/openwrt-gs-code.bin
on my Linksys WRT56GS and got following via serial line:
(it probably helps to debug some minor bugs)

Reading :: CODE Pattern is CORRECT!
upgrade_ver[v2.7.1] upgrade_ver[20701] 4712_ver[15000]
CODE Pattern is CORRECT!
upgrade_ver[v2.7.1] upgrade_ver[20701] 4712_ver[15000]
Done. 1602560 bytes read
fname=flash1.trx
CODE Pattern is correct! (W54S)
Programming...done. 1602528 bytes written
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: ...... 1634304 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
CPU revision is: 00029007
Primary instruction cache 8kb, linesize 16 bytes (2 ways)
Primary data cache 4kb, linesize 16 bytes (2 ways)       
Linux version 2.4.20 (root@cms2) (gcc version 3.3.3) #1 Tue Jan 11 22:51:19 SAST 2005
Determined physical RAM map:                                                         
memory: 02000000 @ 00000000 (usable)
On node 0 totalpages: 8192           
zone(0): 8192 pages.     
zone(1): 0 pages.   
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs inCPU: BCM4712 rev 1 at 200 MHz                                                                           
Calibrating delay loop... 199.47 BogoMIPS
Memory: 30396k/32768k available (1404k kernel code, 2372k reserved, 100k data, 68k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)                                       
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes) 
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Checking for 'wait' instruction...  unavailable.           
POSIX conformance testing by UNIFIX             
PCI: Disabled                     
PCI: Fixing up bus 0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket                         
Starting kswapd               
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1                                     
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
pty: 256 Unix98 ptys configured                                               
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xb8000300 (irq = 3) is a 16550A                                           
ttyS01 at 0xb8000400 (irq = 0) is a 16550A
Software Watchdog Timer: 0.05, timer margin: 60 sec
loop: loaded (max 8 devices)                       
PPP generic driver version 2.4.2
Flash device: 0x800000 at 0x1c000000
Physically mapped flash: squashfs filesystem found at block 913
Creating 5 MTD partitions on "Physically mapped flash":       
0x00000000-0x00040000 : "pmon"                         
0x00040000-0x007e0000 : "linux"
0x000e4448-0x001c5d6b : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x007e0000-0x00800000 : "nvram"                                                   
0x001e0000-0x007e0000 : "OpenWrt"
sflash: found no supported devices
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP     
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
ip_conntrack version 2.1 (256 buckets, 2048 max) - 344 bytes per conntrack
ip_conntrack_pptp version 1.9 loaded                                     
ip_nat_pptp version 1.5 loaded     
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0               
Bridge firewalling registered       
802.1Q VLAN Support v1.7 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>         
VFS: Mounted root (squashfs filesystem) readonly.   
Mounted devfs on /dev                           
Freeing unused kernel memory: 68k freed
Algorithmics/MIPS FPU Emulator v1.5   
Using /lib/modules/2.4.20/diag.o   
diag boardtype: 00000101
using v2 hardware       
led -> 00       
led -> 01
Unlocking mtd4
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xe188 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x4811 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0xb130 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0xc48c instead
... many more of this ...
Further such events for this erase block will not be printed                         
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
....
Further such events for this erase block will not be printed                         
Old JFFS2 bitmask found at 0x00045978                       
You cannot use older JFFS2 filesystems with newer kernels
JFFS2: Erase block at 0x00040000 is not formatted. It will be erased
...
Further such events for this erase block will not be printed                         
JFFS2: Erase block at 0x00180000 is not formatted. It will be erased
jffs2_read_inode(): No data nodes found for ino #6                 
jffs2_read_inode(): But it has children so we fake some modes for it
umount: /rom/dev: Device or resource busy                           
init started:  BusyBox v1.00 (2005.01.11-21:04+0000) multi-call binary
kernel.panic = 3
net.ipv4.ip_forward = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_timestamps = 0
jffs2.bbc: SIZE compression mode activated.
jffs2_read_inode(): No data nodes found for ino #10
jffs2_read_inode(): But it has children so we fake some modes for it
Using /lib/modules/2.4.20/et.o                                     
5325E   phy=FFFFFFFF
eth0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0
Using /lib/modules/2.4.20/wl.o                                 
eth1: Broadcom BCM4320 802.11 Wireless Controller 3.60.13.0
device eth0 entered promiscuous mode                       
SIOCGIFFLAGS: No such device       
bridge br0 doesn't exist; can't delete it
vlan0: add 01:00:5e:00:00:01 mcast address to master interface
device eth1 entered promiscuous mode                         
# eth2 ignored: can't find/create   
# eth3 ignored: can't find/create
br0: port 2(eth1) entering learning state
br0: port 1(vlan0) entering learning state
br0: port 2(eth1) entering forwarding state
br0: topology change detected, propagating
br0: port 1(vlan0) entering forwarding state
br0: topology change detected, propagating 
info, udhcpc (v0.9.9-pre) started         
vlan1: add 01:00:5e:00:00:01 mcast address to master interface
debug, Sending discover...                                   
#  ignored: can't find/create
awk: /proc/net/wireless: No such file or directory
Usage: wlconf <ifname> up|down
debug, Sending discover...
Starting sshd: debug, Sending discover...
OK
led -> 00

bye

waldemar

Hi, I'm interesting in separating the 5 ethernet ports into different vlans and route between them and the wireless interface. I have some wrt54g v2.0 and use the adm6996 module to program the switch but in the new v2.2 there isn't the ADMtek switch. So i searched in the forum and found this topic

http://www.openwrt.org/forum/viewtopic. … vlan+nvram

In this topic, it is said that it's possible to configure the vlanid for each port with the nvram settings. Now I don't have a wrt54g v2.2 to try this configuration so i ask anybody who has a v2.2 to try this config after I got a new v2.2 unit. Thanks in advance.

That's exactly what I'm going to test.

Are this changes going to be added to the official OpenWRT?

I had made several suggestions, but I don't see any of them ever merged, nor commented .