Slashdot Mirror

The rules of the contest say this:

Required elements for web interface pages:

• Full description (requirements)
  • Required elements for web interface pages:
    • Copyright - use "(C) 2008 Ubiquiti Networks, Inc. All rights reserved." as non-intrusive text

Does this mean entrants do not own the copyright to the web design portion of the contest?

(Btw, in case you thought this was just about adding a web-based front-end to an existing product, think again: this is about designing intuitive user interfaces for complex networking options. Not a trivial task.)

It looks like the overall discussion quickly drifted away from the actual topic and the further degrades into insults and endless discussions about cli vs. gui / enduser vs. professional etc. But hey, this is slashdot so I think it's expected.

Anyway, I think that most people miss the point here. The challange is about to implement a (new) gui for the Ubiquity Router Station, based on AirOS which is actually a snapshot of the OpenWrt Kamikaze trunk with some patches added for board support and another proprietary hal to drive the Atheros cards used with the board.

The RouterStation is not exactly a SOHO device, it's a bare embedded board featuring a fast MIPS cpu and three MiniPCI slots, POE and some other fuzz.

It has higher specs then the average Broadcom gear and is intended for larger infrastructure deployments, like wisps etc.

So far on the target hardware. Since one requirement is to use OpenWrt/AirOS as base operating system, one can rule out Tomato (which ppl quickly suggested) since it's built on top of the former disclosed Linksys SDK for WRT54G devices and relies heavily on a Linux 2.4 kernel to use bcm43xx wireless phy. Part of the original Linksys firmware design was the use of nvram as central configuration storage which is abandonned in nowadays Kamikaze releases. Anyway - I think it's nearly possible to rip the gui off an existing firmware project and refactor it to run on top of OpenWrt, it would be easier to just start from scratch.

Now the list of required features is pretty long and includes stuff that's not present in (half) open source firmwares like Tomato, DD-Wrt or OpenWrt. It includes things like bgp/ospf routing, bonding, snmp or layer 2 firewalling (ebtables, arp nat ...) just to name a few. That are things a normal ui designer can't draft without the support of one or more networking experts who actually know whats this about and how it's done properly. Some of that features also are inherently complex and can't be fully abstracted away with some fancy ui elements and a short help text on each page. On the other hand an ui allows to present complex relations like traffic flow, qos behaviour, wifi signal stength etc. in a visual way that can't be accomplished with a cli-only interface.

The to-be-developed ui is not intended for casual users that just want to hook up a bunch of computers and get into the internet. It's also not intended to be used by people who don't have a clue about networking or don't want to learn about the principles of the involved technologies. You have to keep in mind that the interface should be able to handle multiple wifi cards with multiple wireless networks each, that it should ease the setup of complex network configurations without limiting the amount of possible options. It's also not about a fancy web 2.0 portal or shiny flash interfaces, just to please possible customers.

Imho the ui should also be designed in such a way that it allows a smooth coexistance with cli-based workflows. Neither Tomato nor DD-Wrt provide such abilities since the underlying system is optimized to be used by the ui and hardly intuitive to use via the cli. Think of it like the relation of Linux and Xorg. You can uninstall all X related stuff and still have a functional system where you can access all resources etc.

Another fact to worry about is the portability of such an ui - if one wants to make it into a generic interface for OpenWrt, it would have to support a wide range of hardware from simple Linksys boxes to X86 gear like Avila or Alix boards, tt would have to support wireless configuration for madwifi, legacy broadcom and mac80211 based wireless drivers, each with different ways of configuration. Oh - and it should support kernel 2.4 and 2.6 which becomes a real pain if one relies on sysfs for state information.

Also the choice of the programming language and framework matters, one could go ahea

It looks like the overall discussion quickly drifted away from the actual topic and the further degrades into insults and endless discussions about cli vs. gui / enduser vs. professional etc. But hey, this is slashdot so I think it's expected.

Anyway, I think that most people miss the point here. The challange is about to implement a (new) gui for the Ubiquity Router Station, based on AirOS which is actually a snapshot of the OpenWrt Kamikaze trunk with some patches added for board support and another proprietary hal to drive the Atheros cards used with the board.

The RouterStation is not exactly a SOHO device, it's a bare embedded board featuring a fast MIPS cpu and three MiniPCI slots, POE and some other fuzz.

It has higher specs then the average Broadcom gear and is intended for larger infrastructure deployments, like wisps etc.

So far on the target hardware. Since one requirement is to use OpenWrt/AirOS as base operating system, one can rule out Tomato (which ppl quickly suggested) since it's built on top of the former disclosed Linksys SDK for WRT54G devices and relies heavily on a Linux 2.4 kernel to use bcm43xx wireless phy. Part of the original Linksys firmware design was the use of nvram as central configuration storage which is abandonned in nowadays Kamikaze releases. Anyway - I think it's nearly possible to rip the gui off an existing firmware project and refactor it to run on top of OpenWrt, it would be easier to just start from scratch.

Now the list of required features is pretty long and includes stuff that's not present in (half) open source firmwares like Tomato, DD-Wrt or OpenWrt. It includes things like bgp/ospf routing, bonding, snmp or layer 2 firewalling (ebtables, arp nat ...) just to name a few. That are things a normal ui designer can't draft without the support of one or more networking experts who actually know whats this about and how it's done properly. Some of that features also are inherently complex and can't be fully abstracted away with some fancy ui elements and a short help text on each page. On the other hand an ui allows to present complex relations like traffic flow, qos behaviour, wifi signal stength etc. in a visual way that can't be accomplished with a cli-only interface.

The to-be-developed ui is not intended for casual users that just want to hook up a bunch of computers and get into the internet. It's also not intended to be used by people who don't have a clue about networking or don't want to learn about the principles of the involved technologies. You have to keep in mind that the interface should be able to handle multiple wifi cards with multiple wireless networks each, that it should ease the setup of complex network configurations without limiting the amount of possible options. It's also not about a fancy web 2.0 portal or shiny flash interfaces, just to please possible customers.

Imho the ui should also be designed in such a way that it allows a smooth coexistance with cli-based workflows. Neither Tomato nor DD-Wrt provide such abilities since the underlying system is optimized to be used by the ui and hardly intuitive to use via the cli. Think of it like the relation of Linux and Xorg. You can uninstall all X related stuff and still have a functional system where you can access all resources etc.

Another fact to worry about is the portability of such an ui - if one wants to make it into a generic interface for OpenWrt, it would have to support a wide range of hardware from simple Linksys boxes to X86 gear like Avila or Alix boards, tt would have to support wireless configuration for madwifi, legacy broadcom and mac80211 based wireless drivers, each with different ways of configuration. Oh - and it should support kernel 2.4 and 2.6 which becomes a real pain if one relies on sysfs for state information.

Also the choice of the programming language and framework matters, one could go ahea

Check http://www.ubnt.com/downloads/ff_big.jpg for a nice chart or frequencies. Big image, but nice.

http://www.ubnt.com/products/sr71a.php

With that name I really was expecting a much stealthier router.

That's nothing that a bit of camo paint and not plugging it in in the first place can't solve, of course...

np: Spooky - Shelter (Open (Disc 1))

http://www.ubnt.com/products/sr71a.php

Cheers, Ed

As someone that has probably made every mistake that can possibly be made in this industry, I believe I might have some valuable insight. If you have LoS (Line of Sight) meaning that both antenna will be able to see each other without being obstructed by anything, the Ubiquiti NanoStations are an unbeatable solution. These radios cost $79.95/each (retail) and are reasonably easy to setup. http://www.microcom.us/ns2.html Online forum help is available here: http://forum.ubnt.com/forum/ Now, if you have a situation where trees or perhaps a house obscure your view between antennas you would be better served with a 900MHz solution. Deliberant is the place to pick those up at a reasonable (albeit higher) cost. http://www.deliberant.com/landing/ http://www.ligowave.com/?q=products/ligoap/ligoap-900 And just so we understand each other, I do not work for either company, I do not get any commission and you aren't going to get a better price by mentioning my name - I'm just trying to help out for all the help SlashDot have been to me over the years. In fact, it's nice to finally be able to give back.

I work for a WISP, and we have been using the Ubiquity PowerStation 2 or PowerStation 5 (2.4 or 5 GHz, respectively) radios for some time. He can get a 2.4 or 5 GHz model, well, a pair of them, and set them up as access point and subscriber module. They work well, we have used them for shots of several miles. If he gets the 5GHz model, he can set it up so other people cannot just get his bandwidth. They are flat panel outdoor radios, designed to be easily installed and configured. Simple GUI interface, and best of all, they run about $169 each. www.ubnt.com

You want two of these:

http://ubnt.com/products/ns2.php

Out door rated, $79 a peice. They are powerful, outdoor, directional access points. You can mount one outside of each home and point them at each other. With line of sight, they will easily do 500 meters. They will plug in ethernet on each side of the connection.

You may need to mount them high to get around trees and hills. It all depends. The higher you are, the better off you'll be.

I have personaly used these devices. They are amazing for the price. I'd pay double if I had to. Nothing comes close.

-Tripp

Ubiquiti Networks sells Atheros-based Mini-PCI cards that may fit your criteria, and the company has been quite good to deal with in my experience.