Does the release of 7.06 mean we're supposed to be using it now instead of White Russian?  I've been using WR for a while now with no problems.  I have a new WRT54GL that I want to put OpenWRT on for work, but I can't tell what the new stable platform is. 

Thanks.

-sig

In my experience, no. The documentation just is not there, and there is not enough people around to give you good advise for stupid newbee questions.

I am now happily back to Whiterussian after a frustrating round with Kamikaze.

OK.  Thanks.  That's the impression I'm getting.  Especially for the WRT54GL with its Broadcom wireless.

-sig

It might depend on what features you're looking for.  I've had some issues with earlier builds of Kamikaze but when I did a clean install of the official 7.06 and used only the packages supplied with the 7.06 build, it's been pretty reliable - and I use it for work.  I'm using the 2.4 kernel with wireless enabled, ntpclient, WPA-PSK encryption, qos, ez-ipupdate and have a DMZ set up - on a WRT54GL.  I run one wired client, 3 wireless clients, a VOIP phone and a video phone.  This configuration might satisfy the requirements of many users.  The documentation is a bit thin but that's part of the challenge, fun and satisfaction  of being an early adopter.  If you've got a spare router with WhiteRussian, what's the down side?  If you run into trouble, just plug in the spare router.

(Last edited by regloss on 25 Jun 2007, 23:15)

Interesting.  Has anyone done a side-by-side comparison of Kamikaze and White Russian listing what one can do that the other can't?  I don't have a ton of extra time or any spare routers, so this is it.  If I have the time, I like to play with this stuff and don't mind the light documentation, but since I don't have the time and just want to get something running, maybe WR would be the better solution?

Thanks.

-sig

sigsegv - Since you mentioned that you had 'a new WRT54GL' and had been running WR for a while, it sounded like you had multiple routers.  If you don't have the luxury of a spare router, I'd stick with WR 0.9 for a while.  It took me several install cycles to get to where I'm happy with Kamikaze for my requirements.

Ah, yeah.  I have put WR on some home routers, but there are no spare ones here at work.  Thanks for the advice.

-sig

I assume Kamikaze will eventually stabilize, but don't expect everything to work right now. In particular:

* qos-re isn't available
* Webif^2, for me, is unstable
* Raw documentation is an understatement; some of it is outdated even for White Russian
* iptables seems broken: port forwarding works, but I can't open ports locally (e.g. SSH, VPN to the router)
* Even functioning packages have broken components, e.g. ntpclient's broken hotplug script.

My platform is an Asus WL-500g (original). Those with a Broadcom device are likely better served for now with White Russian; most of Kamikaze's immediate benefits seem to be for platforms that support Linux 2.6.

My WRT54GL is up and running 7.06 happily.  Wasn't too much work to get it all configured.

Yeah, I had to edit the ntpclient hotplug script to get it working correctly, although I haven't had any problems with iptables ... forwarding ports and opening a local port (for SSH from WAN) are working fine for me.

I can only agree with everyone.  Kamikaze isn't ready for the masses by a long shot.  Heck, even ntpclient doesn't come with a working script - that tells me a lot right there.

In all fairness, I think a lot of work is still too focussed and there's been no settling time for other details to catch up.

(Last edited by Bill_MI on 26 Jun 2007, 03:17)

Which method did you use to open local ports? I've tried via /etc/firewall.user, /etc/config/firewall, and 'ol fashioned iptables via command line.

google snat

I am not having trouble with NAT (although this has been broken in OpenWRT in the past).

Mine is in firewall.user ... I removed the input_wan and prerouting_wan chains, and just use *_rule -i $WAN:

What I have (obviously won't work without the lists and such) ... :

for IP in ${WHITELIST}; do
        for PORT in ${ROUTER_TCP}; do
                iptables -t nat -A prerouting_rule -i $WAN -s $IP -p tcp --dport $PORT -j ACCEPT
                iptables        -A input_rule      -i $WAN -s $IP -p tcp --dport $PORT -j ACCEPT
        done
done

So ... eh ... removing the whitelist stuff ... this should do it for port 22:

iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
iptables        -A input_rule      -i $WAN -p tcp --dport 22 -j ACCEPT

Or ... with the _wan chains:

iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

(Last edited by Duon on 26 Jun 2007, 04:17)

iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

This is verbatim of what's in firewall.user but doesn't work for me (tried again to confirm).

iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
iptables        -A input_rule      -i $WAN -p tcp --dport 22 -j ACCEPT

I attempted the above substituting eth1 for $WAN...still no go. Something has to be wrong with iptables or there's some sort of block I'm unaware of. There's no way forwarding, which is inherently more error prone, works every time but I'm stumped with simply opening one port. I've never had a problem with this in White Russian or Linux 2.3 when iptables was introduced--or on ipchains, ipfwadm, ipfw, or pf for that matter. I even got the atrocious PIX 506 forwarding ports some years back. Hell, I'll even throw in Cisco and Riverstone core routers, though those things are a few steps beyond NAT. The only time I recall having this much trouble was with Zoom and Westell DSL devices--bad design on Westell's part and bad firmware (always!) with Zoom. At one point I seemed to be Zoom's only field feedback for their X6 DSL units.

I appreciate your assistance, Duon. While fixing the problem is the best solution, bolstering my case is good as well. I'll speak louder regarding this issue if it's not fixed by next release. OpenWRT is pretty good about magically resolving crippling issues. I'll just revert to White Russian if it gets too annoying.

(Last edited by Whelkman on 26 Jun 2007, 05:26)

I am running an older Kamikaze build r7048 and I had no problem using the basic stuff in /etc/config/firewall:

accept:proto=tcp dport=22

I also use the forwarding rules such as this complex example for a VOIP appliance:

forward:proto=udp dport=69,1024-1151,21024-21046,16384-16385,2427,2727,2429,2432,50231-50235:192.168.x.x

Here's a copy of the /etc/firewall.user in use on Kamikaze 7.06.  I generally comment out ports 22, 80 and 8100 just to keep things a bit more secure.

WRT54GL v1.0 Kamikaze 7.06
WHR-HP-G54 Kamikaze 7.06

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

# The following chains are for traffic directed at the IP of the
# WAN interface

iptables -F input_wan
iptables -F forwarding_wan
iptables -t nat -F prerouting_wan

# DMZ outgoing
iptables -A forwarding_rule -i eth0.2 -o eth0.1 -j ACCEPT
iptables -A forwarding_rule -i eth0.2 -o eth0.0 -j ACCEPT

### Open port to WAN
## -- This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT
## -- This allows port 80 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_wan -p tcp --dport 80 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 80 -j ACCEPT

### Port forwarding
## -- This forwards port 8100 on the WAN to port 80 on 192.168.1.100
iptables -t nat -A prerouting_wan -p tcp --dport 8100 -j DNAT --to 192.168.1.100:80
iptables        -A forwarding_wan -p tcp --dport 80 -d 192.168.1.100 -j ACCEPT
## -- This forwards ports 5060-5061 on the WAN to 192.168.1.100
iptables -t nat -A prerouting_wan -p udp --dport 5060:5061 -j DNAT --to 192.168.1.100
iptables        -A forwarding_wan -d 192.168.1.100 -j ACCEPT

### DMZ
## -- Connections to ports not handled above will be forwarded to 192.168.2.2
iptables -t nat -A prerouting_wan -j DNAT --to 192.168.2.2
iptables        -A forwarding_wan -d 192.168.2.2 -j ACCEPT

I wouldn't recommend using KK yet.It's simply to unstable and untested. Even the so called 7.06 "release" is not ready for the masses.

I you are happy with WR 0.9 stick to it.

My impression is that WhiteRussian is also much faster than Kamikaze.
I tried WhiteRussian 0.9 and various Kamikaze releases (7.06 included), with 2.4 and 2.6 kernel on my WRT54GL
I think and hope that Kamikaze shall come a very good distribution. At now, the only great advantage is that it can support more devices than WhiteRussian.
If you want just use your WRT54 (without making development on it), I would reccomend WhiteRussian too.

It's unfortunate that it's not. After installing it I like the method of using configuration files to set up the router over nvram (though there are pluses and minuses). The only problem is that when I did use the simple setup it didn't work. I'm looking forward to the next release(s) where it might become more reliable and documented. The fact that OpenWrt is expanding it's hardware support is amazing and a great outlook for the future as Wireless N is coming!

Kamikaze solved my problem which I had. My nvram content disappeared periodically but the other partitions don't.
With Kamikaze i don't care about the nvram. It's really stable since i installed (2 weeks ago), however I'm using only as router+ap with default install.
Port forward and opening works fine for me.

I really like the idea that only the etc should backed up and not nvram+etc.

The worst problem I just encountered. The failsafe functionality is not working. Fortunately I have an Asus WL-500G Deluxe, so reflashing  again went easily with the Tool provided by Asus.

In 7.07 failsafe is fixed and it's great!
Kamikaze step by step is going to be a stable system, but I think it's not yet mature and stable as WhiteRussian.

I recently thought I'd give KK 7.09 a try after a WR RC6 install had been performing fantastically 24x7 for ~13months. Only once, last week, did I ever had to reboot the router due to a problem. In that respect I think KK has been a victim of WR's success.
After reading this thread I was put off upgrading. However, I managed to get my hands on a 2nd Buffalo WHR-HP-G64 and decided to give it a go. I'm not sure I would've ever bothered, without the 2nd router, considering WR's reliability.
Well I have now tried KK on both routers and WR is a thing of the past for me. I'm glad I didn't let this thread put me off, so that's why I'm adding to it.
I much prefer the config file format, having found nvram fiddly and non-intuitive. I'm happier knowing that all components have been updated; kernel, modules, commands esp. busybox, openwrt scripts, etc.. That's despite the fact I am forced to use kernel 2.4 as I need wireless on the broadcom hardware in the WHR-HP-G54.
I previously used qos-re which worked perfectly for many months. However, there is no KK package for that. Though I managed to manually install it, here are the modified scripts.
But after reinstalling KK a few times I tired of that and thought I'd try qos-scripts again (wasn't really mature the last time I used it in Nov 2006), because there is a KK package and I just thought I'd see if it truly performed as well as qos-re. Well so far I can't really tell a difference. qos-scripts seems to work just fine, so I think I will ditch qos-re for providing no benefit, having a non-KK config file and having a non-KK package.
Cheers.

It is much better, but there's still a lot missing if you're on broadcom. I don't think it will be as far as WR untile 2.6 has good drivers out. But I do use KK because the config file format is so much better.