at home:

nas -P /var/run/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 66 -r [key] -h 127.0.0.1 -p 1812 -t 36000 -s [pid] -w 6 -g 14400

at work:

nas -P /var/run/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 132 -k [key] -s [pid] -w 6 -g 14400

I should also note that I installed the old nas first, then overwote the 3 files you mentioned.  Did it this way in order to get the scripts that come with the old nas.

(Last edited by netprince on 7 May 2007, 17:31)

Hmm, you should install the whiterussian packages for wl and nas because of the scripts and files, kamikaze scripts will not work on whiterussian.

Then you overwrite the wl, nas and libbcmcrypto.so files and you are done.

I build this patch just to overcome the stability problems, it's a kind of bandage for whiterussian, but kamikaze has all of this resolved plus is a lot better.

So people please, always consider using kamikaze instead as it's the future.

I can't really see using Kamikaze in production network, considering the rapid change and lack of documentation at this point.  Bulk of the Wiki documents WhiteRussian as far as I can see.

The work in this thread is very important work. I would love to see it result in a "last gasp" more stable release of WhiteRussian.  Unless Kamikaze is starting to approach an RC1 status which I haven't read anything about.

(Last edited by vincentfox on 7 May 2007, 20:19)

The Whiterussian tree is old, and it's obsolete. It was was showing signs of aging around RC4 and has been declining ever since. It was a mistake to let Whiterussian continue so long. Kamikaze kept pace with the new kernels, updated busybox, new drivers, all sorts of bells and whistles while Whiterussian remained relatively inert.

The plan had always been to switch over to Kamikaze; in fact we were supposed to have switched over to kamikaze over a year ago, but we got caught up in one of those pointless discussions along the lines of "kamikaze isn't ready yet", so there were more Whiterussian releases, basically just stalling for time. Eventually we came to the decision that Whiterussian was just too old to maintain so 0.9 was intended as the "it's dead jim" release.

While I can appreciate the work solca has done copying various bits of Kamikaze back into Whiterussian, you have no idea how frustrating it is to be faced with another Whiterussian release. I know this will result in the "but kamikaze isn't ready yet" (it already has,) but you need to understand that Whiterussian is dead, and unless we can get the users to move on, OpenWrt itself is dead.

If you're waiting for an invitation to use Kamikaze, it's this post. Let's not stall things any further with Whiterussian; we need help from the users if we're ever going to get Kamikaze out.

Hmm, I didn't realize the devs were keeping such a close eye on this thread.  Apologies for my speculation.  In any case I think this and the parent thread served a very useful purpose in exploring this issue with Broadcom drivers.  I learned some interesteing things along the way just seeing it explored in this way.

Is there any kind of timeline for something for lack of a better term called RC1?  As a non-developer it's a bit intimidating to pick what snapshot to use.  Probably I am worrying too much, but picking among date-coded firmware I have no idea whether this one or that one will brick my WRT. I at least have some reasonable assurance something labelled RC has been flashed by enough people to be less risky.  I don't even really care if there's a new RC every couple of weeks randomly chosen from snapshots, but picking these out simplifies things immensely for a user population when discussing issues.

(Last edited by vincentfox on 7 May 2007, 21:52)

I just wanted to second vincentfox's thoughts.  I have been waiting for kamikaze to reach some sort of RC status as well.  I've got quite a time investment in scripts for whiterussian.   The scripts depend heavily on nvram vars, so much of that will need to be rewritten/adjusted/retested.  I have been waiting for things to settle down before I begin the task. 

This is just an idea: I realize that kamikaze stretches across a larger set of hardware, but perhaps the broadcom support could be wrapped up into a kamikaze-broadcom-beta release.  It might persuade more whiterussian users to make the switch.  Also, the devs wouldn't have to rush the support for other hardware.

Yeah that sounds more like it, a beta.  But I have no intent of going too far down this path. The devs will do what is best.  The important thing I wanted to get across, is something a little more solid and less of a moving target than nightly snapshots is what will sell users on flashing Kamikaze onto their routers.  I care not what form it takes.  With that comment I will shut my mouth on this topic as I know how I hate kibitzing when I am doing real work, I imagine the devs here feel the same.

Good news, with Solcas version 3 patch applied to SVN, the boot problems I was experiencing with images generated through image builder seem to be resolved. Association with Intel 2200BG adapters also seems to work well. Thanks yet again for all your effort solca.

@mbm
I fully agree that we should all move over to Kamikaze sooner rather than later. I tried to do this my self last week and downloaded a daily snapshot image and ImageBuilder. I was truly impressed and set up 2 Broadcom test units, a Belkin F5D7231-4P and Buffalo WHR-G54S. Both these routers had previously run Whiterussian with no problems, but under the Kamikaze snapshot images they were unable to get a WAN IP address from my Netgear DG824 ADSL router. Kamikaze simply relayed DHCP addresses from my ADSL router to my PC's. I found a thread with a similar problem and posted my own experience.

http://forum.openwrt.org/viewtopic.php?id=8435

Unfortunately, this problem forced me to move back to Whiterussian. I think the point here, is that Whiterussian has proven itself in a production evironment and moving over to Kamikaze can still prove to be problematic. I am personally very keen to move over (once I can reliably get WAN IP addresses), you guy's have done an excellent job with Kamikaze and it is definitely far superior to Whiterussian.

Please open a ticket for this issue if there is not one https://dev.openwrt.org

My take on the Whiterussian vs Kamikaze issue:

Kamikaze is better than Whiterussian, period.

But IMHO Kamikaze have 2 fundamental flaws:

-Forgetting the WRTs.  I must said OpenWRT (as it's name implies) was first a broadcom derived devices project, you can't simply drop support for something so successful like the NVRAM variable storage.  The more I think about it, the more I like it's simplicity and functional approach.  You can flash whatever firmware you want, your valuable settings are there.  You need to upgrade, downgrade, whatever you decide your data is there.  Kamikaze with all the bells and whistles will not support the NVRAM approach.  I must say think about it again, at least for the broadcom derived devices.  I was thinking in a new tool that if installed will overwrite anything necessary in /etc from NVRAM storage.  In this way people could decide if they stay with NVRAM or switch to a file based configuration.  People, please let me know if some of you would find it useful.

-Kamikaze is like Debian Sid, everyday will be updates for it, I myself run Sid on personal boxen, but my production servers run Debian stable/oldstable.  OpenWRT is like any other distro and it needs to frozen up the repos and work on stabilization like everybody else, and then release something that will not change except for security/stability.

So Kamikaze must fill this 2 holes, do it properly and will continue to be the most successful firmware for WRTs and now all kind of devices.

In the meantime personally I'll focus on helping Kamikaze as I know it's better, simply that for my production environments is not there yet, so I'll continue maintaining my unofficial patch until Kamikaze become ready for action.

I really would love to switch from WR RC6 to Kamikaze but I'm bound to the WRT54GL v1.0.
And I need WPA2-Enterprize to work here...

Solca,

Are you planning to continue hosting this patched version of the v0.9 firmware images on Galileo for now?

I am planning to flash some new WRT units soon. Just wondering if I and others should squirrel away copies now in case this is just a momentary thing for you.

@booBot, Kamikaze not supported on GL v1.0?  I was planning to test Kamikaze tomorrow I guess I need to catch up on what it will actually work on.

(Last edited by vincentfox on 9 May 2007, 00:06)

vincentfox, if you want a backup, do it with the patch, anyway I'm using the firmware so I'll keep it there for a while.

I tried out the new driver, it works much better with respect to my intel clients.  The only problem I have now is the same lc described, I've had both routers lose network access overnight.    Both of which are for my own personal testing, so there was no load. 

I agree with Solca. NVRAM: This is a huge advantage of WR. I flash something and the settings are still there. Solcas proposal how this can be dealt with in kamikaze makes sense. His point about stability can even be found on dev.openwrt.org: WR is called "stable branch", kamikaze "development branch". So I hope that kamikaze will reach an RC1 state soon.

I have found the NVRAM feature to be an advantage in our community WISP. I feel reasonably confident about flashing a remote WRT unit up to a new WhiteRussian and it just works without a lot of post-install redo.  For Kamikaze I will have to find some equivalent way to backup all relevant network settings and restore them after a flash.  It's not insurmountable, but it's an issue that will require some man-hours and documentation on the problem.  The worst case of physical router swaps to upgrade is not desirable, some of these WRT are in locations requiring climbing and physical hazards that I prefer to avoid whenever possible.

Well, this thread is getting further and further off topic, , but I would expect that since the settings are all based on config files it should be possible to easily dump these to a central machine and then push them to a new WRT when setting it up fresh.

It would probably be good to move further Kamikaze talk over to Kamikaze discussions forum.

I started a new thread for this issue: http://forum.openwrt.org/viewtopic.php?pid=48282

New patch version, in this patch I try to minimize differences with upstream Whiterussian just to be able to load the newest propietary Broadcom's wl driver.  That should solve the ebtables memleak, and the shfs and fuse builds.

Next version will decouple ip_conntrack from the kernel in order to load it dynamically as not everybody just bridging or routing need it.  In this way it will not waste precious resources.

Nice work solca, Congrats !!

Version 5 is out now.  As the changelog suggests it convert all netfilter's static modules to external loadable modules, this is extremely useful when you are just routing or bridging and you don't need firewall functionality, specially the (in)famous ip_conntrack module which tracks every single connection even when you don't have a single iptables rule, that's why very important to avoid it at all costs.

If nothing major shows up this is my last patch in the series, I think it is in very good shape as it stabilizes Whiterussian without regressions and all changes are orthogonal and clean, IMHO it should land in Whiterussian svn but that's not my call.

Thanks to all for the testing and support!

Thanks for v5!!

I ran into a problem with v5 (and v4): When installing this qos script http://files.eschauzier.org/qos-re_1.05_all.ipk the following error messages come up:

Configuring qos-re
RTNETLINK answers: Invalid argument
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: Invalid argument
We have an error talking to the kernel

I use the the same kernel config/moduls as usual. What could be responsible for this?

Do you install the 'Traffic Schedulers (kmod_sched)' and probably the 'Intermediate Queueing device (kmod_imq)' packages?

Yes, both packages are installed. I have been digging into this for a few hours - I hope I'll find out what's happening. By the way, your v3 is still up and running for almost 3 days now. To test v5 I first must solve this problem. Maybe it is a package incompatibility issue.

I try that package, it just warn me that I need this packages:

kmod-sched kmod-ipt-conntrack iptables-mod-conntrack kmod-ipt-ipopt iptables-mod-ipopt kmod-ipt-extra iptables-mod-extra ip kmod-imq iptables-mod-imq tc kmod-ipt-filter iptables-mod-filter

No error messages in logread or dmesg:

imq driver loaded.
IPP2P v0.8.1_rc1 loading
HTB init, kernel part version 3.17
HTB: quantum of class 10040 is small. Consider r2q change.
HTB init, kernel part version 3.17

and tc reports:

root@wrt:~# tc class show dev vlan1
class htb 1:1 root rate 50000bit ceil 50000bit burst 4799b cburst 4799b
class htb 1:10 parent 1:1 leaf 8001: prio 1 rate 25000bit ceil 50000bit burst 1599b cburst 1599b
class htb 1:20 parent 1:1 leaf 8002: prio 2 rate 10000bit ceil 50000bit burst 1600b cburst 1599b
class htb 1:30 parent 1:1 leaf 8003: prio 3 rate 10000bit ceil 50000bit burst 1600b cburst 1599b
class htb 1:40 parent 1:1 leaf 8004: prio 4 rate 5000bit ceil 50000bit burst 1600b cburst 1599b
root@wrt:~# tc class show dev imq0
class htb 1:1 root rate 100000bit ceil 100000bit burst 4799b cburst 4799b
class htb 1:10 parent 1:1 leaf 8005: prio 1 rate 50000bit ceil 100000bit burst 1599b cburst 1599b
class htb 1:20 parent 1:1 leaf 8006: prio 2 rate 20000bit ceil 100000bit burst 1600b cburst 1599b
class htb 1:30 parent 1:1 leaf 8007: prio 3 rate 20000bit ceil 100000bit burst 1600b cburst 1599b
class htb 1:40 parent 1:1 leaf 8008: prio 4 rate 10000bit ceil 75000bit burst 1600b cburst 1599b

So it seems to work correctly here.

Are you sure you have all that dependencies installed and when you build your own firmware do you first issue 'make dirclean' to clean the new build?