OpenWrt Kamikazi 8.09 & Trunk, challenge technical ToDo'

[RoundSparrow]

There is one previous thread to reference:
http://forum.ubnt.com/forum/viewtopic.php?t=6983

I think it is in the interest of the challenge participants to collaborate on many of the OpenWrt technical aspects of the challenge. At minimum, in review the rules and identifying what is currently lacking in OpenWrt development (the code is updated daily, I'm talking about trunk).

This is a starting point, I welcome additions:

1. Contest requires Ethernet bonding. This is an area where currently OpenWrt may be lacking driver support. Some discussion on this. Is work in progress that will be usable by August?

2. If an Atheros N radio is used, the ath9k driver is preference from Linux freedom perspective (it is in mainline Linux kernel). However, WDS is not supported at this time. Will WDS be usable by August? the ath9k uses a very different configuration interface from the older (undesirable) madwifi. From an OpenWrt perspective, ath9k is preference.

3. Beyond the 8.09 release there are OpenWrt additions to support N standardized configuration. Reference OpenWrt SVN 14713

4. bgp/ospf routing status in OpenWrt trunk / external packages?

5. snmp status in OpenWrt trunk / external packages?

6. layer 2 firewall (ebtables, arpm nat, etc.) status in OpenWrt trunk / external packages?


From an OpenWrt perspective, if a GUI is built for these features it should utilize or at least have comparable command-line configuration with the UCI program.

Encouragement is that on these technical and non-GUI matters that perhaps effort be made to keep up with OpenWrt progress and try to implement things such that it be on the progressing base.

[riskable]

Replies inline...

There is one previous thread to reference:
http://forum.ubnt.com/forum/viewtopic.php?t=6983

I think it is in the interest of the challenge participants to collaborate on many of the OpenWrt technical aspects of the challenge. At minimum, in review the rules and identifying what is currently lacking in OpenWrt development (the code is updated daily, I'm talking about trunk).

This is a starting point, I welcome additions:

1. Contest requires Ethernet bonding. This is an area where currently OpenWrt may be lacking driver support. Some discussion on this. Is work in progress that will be usable by August?

Bonding shouldn't be a problem. The kmod-bonding module is there and I've got it working on openwrt-x86 without any problems. FYI: If the hardware doesn't have bonding features built-in the kernel will do it in software which is very slow. I don't have a routerstation to play with so I don't know if it has such acceleration.

2. If an Atheros N radio is used, the ath9k driver is preference from Linux freedom perspective (it is in mainline Linux kernel). However, WDS is not supported at this time. Will WDS be usable by August? the ath9k uses a very different configuration interface from the older (undesirable) madwifi. From an OpenWrt perspective, ath9k is preference.

Well, the contest is about user interface--not about getting drivers working 100%. So I'd ASSUME that as long as the web interface has support for enabling WDS it shouldn't be a problem.

3. Beyond the 8.09 release there are OpenWrt additions to support N standardized configuration. Reference OpenWrt SVN 14713

Doesn't matter: 802.11n isn't in the technical requirements. Also, if your interface supports all the regular 802.11a/b/g features it should be trivial to add in 802.11n stuff when it becomes available.

4. bgp/ospf routing status in OpenWrt trunk / external packages?

quagga-bgpd and quagga-ospfd are there in the standard packages. Not sure if they work or work well. I suspect that they won't be a problem.

5. snmp status in OpenWrt trunk / external packages?

Several options: snmpd (classic), mini-snmpd, and snmpd-static (whatever that is)

6. layer 2 firewall (ebtables, arpm nat, etc.) status in OpenWrt trunk / external packages?

They work fine. No problems as far as I know. If there were problems with NAT OpenWRT would REALLY be in trouble =)

From an OpenWrt perspective, if a GUI is built for these features it should utilize or at least have comparable command-line configuration with the UCI program.

Encouragement is that on these technical and non-GUI matters that perhaps effort be made to keep up with OpenWrt progress and try to implement things such that it be on the progressing base.

As far as I know everything that Ubiquiti wants is there as far as features go. However, that's not to say there aren't some hugely ambiguous requirements. The following come to mind:

A 10. Traffic accounting (monitoring/graphing)
Since the device has such limited memory I'm not sure how effective this could be without recording traffic data somewhere else (i.e. some database server somewhere). Since this is the case I'm assuming they just want real-time info like X-WRT already provides.

B 6.4 Super Features
What the heck are "Super Features"? I'm assuming the silly vendor-specific features like, "Xtreme mode". Anyone care to comment?

C 1.1 HotSpot Gateway with RADIUS
Do they want the RADIUS server running on the RouterStation itself or do they just want something like, "the ability to configure chillispot to use a RADIUS server"? I assume the latter since running a RADIUS server on such an embedded device would be extremely constrained.

C 4.3 p2p traffic management
I wish they'd be more specific about the "p2p" part. Practically everything is p2p these days. I'm going to assume they mean things like Kazaa, eDonkey, and Bittorrent and not things like Skype.

E 7. Configuration file upload/download
For ALL configurations (e.g. the whole router and all it's software) or just system and network-specific stuff (e.g. IP/Wireless/Firewall settings)?

F 7. Speed Test
What kind of speed are we talking about here? I assume bandwidth but even that gets complicated. Speed between the client and the router or speed between the router and some Internet host?

[saneeek55]

hm.... its a very interesting

[adrianatkins]

Just bung in what you think.

No need to get all Deep about it.

Whether you win or lose, and there's always a Winner and Loser, you will learn a lot.

Maybe that's part of what the challenge is about - to see if anyone actually knows anything at all, and/or has the ability to implement it.

[adrianatkins]

> Bonding shouldn't be a problem.

It isn't.

> 2. If an Atheros N radio is used, the ath9k driver is preference from Linux

Sure. But if you can get what you want out of madwifi-ng, then use that.
If My entry fails cos of the last 0.01%, then i'll cry a bit.

> Well, the contest is about user interface--not about getting drivers working 100%.

Correct, as of today. The Winner needs to make 'em all work, so no-one may win - but we got 4 runner-up prizes .... anyway, dump it into Open Source if you don't win.

> Doesn't matter: 802.11n isn't in the technical requirements.

Right - so ignore it for now.

> 4. bgp/ospf routing status in OpenWrt trunk / external packages?

Quagga

> 5. snmp status in OpenWrt trunk / external packages?

Works well enough. Check Cisco's SNMP. Tell me the differences.

> 6. layer 2 firewall (ebtables, arpm nat, etc.)

Certainly work

> However, that's not to say there aren't some hugely ambiguous requirements.

Sure as **** there are.

> A 10. Traffic accounting (monitoring/graphing)

Nah. Script that does "ifconfig ethx" every minute or hour, then subtracts one from the other will do, then graph it. Lose the 'older' data. Ring buffer.

> B 6.4 Super Features What the heck are "Super Features"?

I dunno for sure, but then no-one else will either, so just pretend. There are very few people who will say thee nay, and fewer still who can prove you wrong.

> C 1.1 HotSpot Gateway with RADIUS

Coova Chilli is what they mean

> C 4.3 p2p traffic management

ipp2p (which was actually dropped from OpenWRT ages ago) or better, Layer-7. Odd that ipp2p is a Technical Requirement, even though it's dead.

> E 7. Configuration file upload/download

Depends on you - in my thing it just means zipping and saving config files, then unzipping them.

> F 7. Speed Test

Any old crap will do - it's a Customer Confidence thing. They Use it once, get an idea of what it means, then vaunt it as "The Standard". Dunt really matter. Use Curl or whatever - anything that gives you a clues as to the throughput.

Best idea is like Mikrotik use : a Bandwidth Test Server (1 node) and a BW Test Client (other node) - tells you what real thruput you get over a WiFi link. If you got time, make that idea work better.

Great DoS feature too.