Hi,

time to give back to the OpenWRT community. This weekend, one of our berlin community members changed one of my older wrt devices for a new g2.2 device. This gives me the opportunity to experiment a little bit. In  short: Its easy to run OpenWRT on the Gver2.2/GSver1.1 devices, you need to change 2 things:

a) patch the addpattern utility as suggested by TheRoDent. addpattern should accept the "-2" parameter then to have the bin file compatible with all wrt54 versions.

b) grab the newer et.o file from the wrt54gs.3.37.2.tgz (download from linksys) and overwrite the older et.o from wrt54gs.2.07.1.tgz in buildroot/build_mipsel/root/lib/modules/2.4.20/ The newer et.o handles both the (old) admtek and the (new) broadcom etherchip automatically.

Thats all. The older wl.o is still working *with* wireless extensions - a lot more comfortable.

The above changes are included in the Freifunk-Firmware already. If you like to give it a shot refer to http://www.freifunk.net/wiki/FreifunkFirmwareEnglish

P.S: Who the heck has deleted several directories in the OpenWRT CVS repository!? At least the ./buildroot/sources/openwrt is still needed to compile! What's wrong here?

Regards, Sven-Ola

i put ne V0.6.5 on my wrt54g V2.2 and everything works fine.
until i plug the power off.
if i plug the power on; 
linksys go to the tftp wait state and dont boot.

are there any fixes for this problem?

g.
tim

you may run into the issue already posted by mtakahar in this forum. Check out the "buildroot patch: Fix for CRC error after firstboot" topic, see http://openwrt.org/forum/viewforum.php? … ca45911385

Ah - and I forget to mention that a new version of the freifunk-firmware 0.6.6 is ready with fixes applied in a couple of minutes...

As reminded with the sticky "GPL binary" topic at the top of this Forum, I published the Freifunk-Firmware Sources, Shell-Hacks and Patchfiles on SourceForge now.

:arrow: http://ff-firmware.sourceforge.net/

I am having big troubles getting a WRT54G v2.2 to work properly. Can I use the Freifunk version of OpenWRT and delete all the stuff specific to Freifunk to get a clean and working OpenWRT? I like the way you made the v2.2 work with OpenWRT, because (if I understand it right) it stays compatible with the IPKG-packages for OpenWRT.
Thanks in advance.

Freek

Remove specific stuff? No big problem. You cannot remove the preinstalled packages, they will need some extra space in the squasfs (Read-Only) partition mounted in /rom. But the firmware is an openwrt nevertheless. I suggest removing these links:
/etc/init.d/S45firewall and /etc/init.d/S53olsrd. You may need to copy the standard S45firewall from openwrt or create your own if you need a firewall setup. After these just configure the nvram vars as needed. And of course: remove anything in /www to get rid of that web interface if you do not like it 
After these actions just do the nvram settings as usual and install packages with ipkg update/ipkg install...

Oh - one more: In failsafe mode you connect by telnet without password as usual. In normal mode telnet is disabled and ssh (e.g. PuTTY) is needed to login with the root/admin default combination. In addition to openwrt the FFF has passwords, login and getty (serial) enabled by default.

Hope it helps, Sven-Ola

And a last one: Just checked what you loose. FFF will need around 30% more in squasfs, so you will loose less than 10% in read/write jffs to install additional packets. One big preinstalled ipk is dropbear, needless to say you normally want this anyway...

Thanks a lot.

hmmm, i've tried this with my own firmware, and a stock CVS build from yesterday, and they both have the same issue.

I can send out packets on the external interface, but cannot receive.

I've completely flushed out the default firewall rules and just set INPUT & OUTPUT to ACCEPT.  No dice.

dmesg says the modules loads ok...  though lsmod says the et module is unused (whereas on a WRT54GS1.0 it says it's used)

Any ideas on this?
I'm tearing my hair out on this one, as i'm so close.

BTW: what is an "external Interface"? You need to be a bit more specific on this topic. Attach "iptables -L -n -v;iptables -t nat -L -n -v;iwconfig;ifconfig" as well.

By external interface, I mean vlan1, or the external network connection.
This is a stock CVS version, with the addpattern patch and new et.o driver included.

I'm using a WRT54GS1.1 (actually a few of them).

I've tried setting it to use dhcp and a static address, with no luck.
If I run tcpdump on a remote host, and try to ping, run udhcpc, etc...   I can see packets from my WRT, and responses are sent.  But the WRT never seems to get them.

At first glance, this looks like a firewall issue, but based on the firewall config listed below, I don't think so.  (i've tried the default iptables config from cvs as well)

I've even tried to explicitly allow connections from a particular remote host, to no avail.
I've switched cables thinking that was it...  nope.

Wireless always seems to be available, as thats how I access the box. 

This is very confusing, since the exact same firmware (without the addpattern and new et driver) works just fine on a GS 1.0.

iptables -nvL:

Chain INPUT (policy ACCEPT 1765 packets, 154K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 1520 packets, 182K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4331 packets, 583K bytes)
pkts bytes target     prot opt in     out     source               destination         

iptables -t nat -L:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

iwconfig:

lo        no wireless extensions.

eth0      no wireless extensions.

eth1      IEEE 802.11-DSF  ESSID:"linksys" 
          Mode:Master  Channel:6  Access Point: 00:12:17:BC:12:31 
          Bit Rate:24Mb/s   Tx-Power=15 dBm   
          Retry limit:0   RTS thr:off   Fragment thr:off
          Encryption key:off
          Link Quality:0/5  Signal level:-160 dBm  Noise level:-256 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

br0       no wireless extensions.

vlan0     no wireless extensions.

vlan1     no wireless extensions.

ifconfig:

br0       Link encap:Ethernet  HWaddr 00:12:17:BC:12:2F 
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6525 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3239 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:440563 (430.2 KiB)  TX bytes:534163 (521.6 KiB)

eth0      Link encap:Ethernet  HWaddr 00:12:17:BC:12:2F 
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:15748 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5388 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3247848 (3.0 MiB)  TX bytes:2092310 (1.9 MiB)
          Interrupt:5 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:12:17:BC:12:31 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6512 errors:0 dropped:0 overruns:0 frame:23337
          TX packets:4301 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:541077 (528.3 KiB)  TX bytes:732295 (715.1 KiB)
          Interrupt:4 Base address:0x1000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:996 errors:0 dropped:0 overruns:0 frame:0
          TX packets:996 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:88685 (86.6 KiB)  TX bytes:88685 (86.6 KiB)

vlan0     Link encap:Ethernet  HWaddr 00:12:17:BC:12:2F 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1100 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:162286 (158.4 KiB)

vlan1     Link encap:Ethernet  HWaddr 00:12:17:BC:12:2F 
          inet addr:192.168.2.34  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4288 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:1930024 (1.8 MiB)

netstat -rn:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.2.0     0.0.0.0         255.255.255.0   U        40 0          0 vlan1
192.168.1.0     0.0.0.0         255.255.255.0   U        40 0          0 br0
0.0.0.0         192.168.2.1     0.0.0.0         UG       40 0          0 vlan1

lsmod:

Module                  Size  Used by
wl                    348968   1
et                     22208   0 (unused)
diag                    2224   0 (unused)

Hi,

this is really funny. Normally such situation can be traced down to a routing/firewall issue (e.g. eth1 and vlan1 are in same subnet). This seems to be a vlan issue. Try "brctrl show". Is vlan1 not in bridge? Try ifconfig vlan1 down;rmmod et.o;ismod et.o. The newer et.o has to show it's special vlan programming setup. This look O.K?

P.S.: I personally have a G-2.2 device. The G-1.1 should have the same etherchip (boadcom instead of admtek) but you may need to open housing and verify.

Hope it helps, Sven-Ola

Yeah, i'm stuck on this one...

Here's what I see from brctl on bootup:

br0             8000.001217bc122f       no              vlan0
                                                        eth1

And when I rmmod/insmod et, dmesg shows:

vlan1: add 01:00:5e:00:00:01 mcast address to master interface
vlan1: del 01:00:5e:00:00:01 mcast address from master interface
vlan1: del 01:00:5e:00:00:01 mcast address from vlan interface
eth0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0

After insmod et, I run ifup wan, and then brctl shows something slightly different:

br0             8000.001217bc1231       no              eth1

I admit, i'm not too familiar with exactly how the vlan setup works, but it looks like i'll get my hands dirty with it now...

I have also confirmed the broadcom ethernet controller in the GS 1.1 is the BCM5325EKQM chip.

Well, check the dmesg kernel log. I attach a snippet of my g-2.2 which shows the normal output for insmod et...

hmm... the only difference I see are these lines:

5325E   phy=0
5325E   VLAN programming for BCM5325E-MDIO I/F switch

plus all the 1: 2: lines.

I don't see any of this in my dmesg.
I've attached my dmesg in case there's something weird i'm not seeing...

actually, I do see something strange in my dmesg, that I don't see anywhere else (other dmesg logs posted to this forum, or on my own older firmware).

This line:
ip_conntrack version 2.1 (5953 buckets, 5953 max) - 352 bytes per conntrack

My older firmware shows this:
ip_conntrack version 2.1 (256 buckets, 2048 max) - 352 bytes per conntrack

which I would consider normal numbers.

just taking a stab in the dark...

I have tried compiling from the buildroot applying the two patches for addpattern and CRC error as suggested by Sven-ola. I have added the et.o driver from release 2.3.37.6, flashed a brand new WRT54GSv1.1 that had release 2.3.37.2 on it before, and I have issues with the wired interfaces. Wireless works, wired interfaces (both vlan1 and vlan0) seem to let packets out but incoming trafic gets lost. For example, if I ping from the WRT to a wire-connected host, I see the ARP requests from the WRT on the LAN,  I also see the answers from the host I am trying to ping, but it seems that the WRT does not get the ARP answers back.

I will check my logs against the ones posted by Sven-ola and James as soon as I can, and post any differences found.

What I should really need to know is how do the vlans work with the new chipset and driver, so maybe I will find if I am missing some initialization. Does the new driver read configuration from nvram? Is it just enough to insmod it and everything should work as configured in nvram settings?

In the meantime, we have a lot of gs-v1.1 devices here. They all run without furhter changes to the freifunk firmware (old buildroot, added trx patch and newer et.o).

I never figured this one out...

I ended up just grabbing an experimental snapshot and modifying it.

It works without any issues, and I prefer the new buildroot layout (though it took a little time to find everything again 

Can you post your firmware?

I search already a openwrt build witout the freifunk implemetations... (i tike the shell and i dont need olsr)

Grettings,
Thomas

Hey,

no problem. RTFM on openwrt.org, then download http://openwrt.org/downloads/experimental/.

P.S. The Freifunk firmware is not meant to be a YAOB (yet another openwrt binary). It's for ad-hoc meshing communities. And - I may stay with the old/normal buildroot a long time. Here are the arguments for that (that's with the upcoming next version):

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "pmon"
mtd1: 003b0000 00010000 "linux"
mtd2: 000e6c00 00010000 "rootfs"
mtd3: 00010000 00010000 "nvram"
mtd4: 00250000 00010000 "OpenWrt"

(Web-UI, olsr-daemon, dropbear, iproute2/full are included in the squashfs, iwconfig working fine).