Dashboard/CnC Command and Control..... ideas

[Ian]

Greetings all!!

Looks as though we are ready to put our heads together to get this
Open Source Command 'n Control, dashboard or whatever you want to call
it on the road!! We need a few php writers and ideas for the
framework. We have a basic dashboard available now from Open-Mesh.
However most of us want more control & more flexibility..... Each
network manager has his/her own needs and we need available a fully
flexible Open Source Offering. Please post below any thoughts and
suggestions. Maybe we can all work alongside Joe Bowser at freethenet-
ca and/or Mikes dashboard at NetEquality maybe can be developed
further.... thoughts and ideas welcomed...

Ian

[John Kevlin]

As far as frameworks are concerned I have used Xaraya in the past and am now evaluating Seagull.  Both are MVC,  Xaraya is not OO, while Seagull is.  If you would like more info on either let me know.
John

[Andrew Gearhart]

I've been mulling my reply on this for a while now. Here's my take:

I love the idea of having a project where we are 100% in control, however, the problem with that is that to do so requires that we write all of it ourselves. Given the complexity of the project... the time required would (imho) either be too long or too expensive. That means it serves us well to look into something that is existing as a starting point.

There are a number of different starting points to work from. There is lots of work in several areas which are nice but have a number of limited features. The one project that is very far along is WifiDog. WifiDog is an open source solution for hotspots. WifiDog has a strong enough backbone that several groups have forked WifiDog to their own tastes and needs. It integrates with a number of different packages. WifiDog, of course, is built for hotspots not wireless mesh networks. Joe Bowser has ported WifiDog to Ruby on Rails and calls his project DogOnRails (DoR). This is a project that he's worked on extensively since about the middle of 2007. DoR has all of the features of WifiDog at this time. The last feature that he worked on was throttling of bandwidth on a per user basis (reducing the impact of bandwidth hungry users). Some of the recent discussion of DoR can be found in these messages from the FreeTheNet-CA mailing list:

• A status update from mid December:
  http://groups.google.com/group/freethenet-ca/msg/c9bf8cd348d99f02
• A short comparison between open-mesh.com and Merhaki/DogOnRails:
  http://groups.google.com/group/freethenet-ca/msg/73f4189b0f23c74f

Despite what one person has said, I do believe that Joe is working extensively with other developers. In the last listed message he even asks for experienced rails developers to login and help out. All of the code for Merhaki and DogOnRails are available in their own repositories...

• Merhaki (firmware for atheros based wireless): http://launchpad.net/merhaki
• DogOnRails (web based management utility for mesh networks): http://code.google.com/p/dogonrails/

Our group and others out there that are after the same goal would be better served if Joe could perhaps find someone (Joe, if you're listening... I'm volunteering) to work with Joe to build community interaction and help bring new developers into the DoR fold.

All of that said... if you are inclined to start a brand new project and burn your development time on this type of effort when others are already on the ground running with the wind at their back... more power to you. However, Joe's solution (while very light on documentation and updates at this point) seems to be fitting the goals that this group is focused on with FOSS running a wireless mesh.

Cheers,
Andrew

On Jan 3, 2008 9:57 AM, Ian <ians...@gmail.com> wrote:

[Guy Jarvis]

Hi Andrew,

thanks for that backgrounder on wifidog.

I think that we certainly can and should make use of any effective
system that is available now to manage the nodes, so long as we keep
working towards the endgame of 100% open source.

Your message prompted me to look again at the feature set for wifidog
and I'm concerned by the ability for aliens to be able to sign up using
any email address for 15 minutes free access then getting free access
after that if the email was real.

This approach is fine for cafe-type free-at-point-of-use hotspots or
certain community projects but doesn't at all suit for networks that
need to secure so that only subscribers can access the service.

I guess if features can be streamlined so that there is no online
sign-up (or change that process so that there is a paypal option for
casual visitors) then fair enough.

The other general point about AAA is that the industry standard
application is radius and I don't see wifidog easily interfacing with
that (though I haven't looked too hard yet either!) - could represent a
scaleability hurdle.

Anyhow, let's see what actually becomes ready to test/use for now.

cheers,

Guy

Andrew Gearhart wrote:
> I've been mulling my reply on this for a while now. Here's my take:
>
> I love the idea of having a project where we are 100% in control,
> however, the problem with that is that to do so requires that we write
> all of it ourselves. Given the complexity of the project... the time
> required would (imho) either be too long or too expensive. That means it
> serves us well to look into something that is existing as a starting point.
>
> There are a number of different starting points to work from. There is
> lots of work in several areas which are nice but have a number of
> limited features. The one project that is very far along is WifiDog.
> WifiDog is an open source solution for hotspots. WifiDog has a strong
> enough backbone that several groups have forked WifiDog to their own
> tastes and needs. It integrates with a number of different packages.
> WifiDog, of course, is built for hotspots not wireless mesh networks.
> Joe Bowser has ported WifiDog to Ruby on Rails and calls his project
> DogOnRails (DoR). This is a project that he's worked on extensively
> since about the middle of 2007. DoR has all of the features of WifiDog
> at this time. The last feature that he worked on was throttling of
> bandwidth on a per user basis (reducing the impact of bandwidth hungry
> users). Some of the recent discussion of DoR can be found in these
> messages from the FreeTheNet-CA mailing list:
>

> * A status update from mid December:
> http://groups.google.com/group/freethenet-ca/msg/c9bf8cd348d99f02
> * A short comparison between open-mesh.com <http://open-mesh.com>

> and Merhaki/DogOnRails:
> http://groups.google.com/group/freethenet-ca/msg/73f4189b0f23c74f
>
> Despite what one person has said, I do believe that Joe is working
> extensively with other developers. In the last listed message he even
> asks for experienced rails developers to login and help out. All of the
> code for Merhaki and DogOnRails are available in their own repositories...
>

> * Merhaki (firmware for atheros based wireless):
> http://launchpad.net/merhaki
> * DogOnRails (web based management utility for mesh networks):

> http://code.google.com/p/dogonrails/
>
> Our group and others out there that are after the same goal would be
> better served if Joe could perhaps find someone (Joe, if you're
> listening... I'm volunteering) to work with Joe to build community
> interaction and help bring new developers into the DoR fold.
>
> All of that said... if you are inclined to start a brand new project and
> burn your development time on this type of effort when others are
> already on the ground running with the wind at their back... more power
> to you. However, Joe's solution (while very light on documentation and
> updates at this point) seems to be fitting the goals that this group is
> focused on with FOSS running a wireless mesh.
>
> Cheers,
> Andrew
>
> On Jan 3, 2008 9:57 AM, Ian <ians...@gmail.com

[Bill]

Hi ( or for all the Network Admins out there: SYN )

If i was to suggest a dashboard code base to expand for the purposes
of creating an open source mesh dashboard, i to would go with wifidog
http://dev.wifidog.org The quality of the code is second to none, thou
i'm kind of biased because i know php, but would be unable to even
Hello World in Ruby.

Here is an interesting article which describes some of the fundamental
differences between wifidog and Coova
http://coova.org/wordpress/index.php/2007/08/02/radius-wispr-and-wifidog/
Even thou it suggests Coova has better AAA the article does praise
Wifidog for having better Captive Portal customisation.

From the comments made in this thread already the general feeling does
steer towards using code which is already in the public domain. There
would still be a need to setup a team of developers ( say from within
the opensourcemesh group ) to bring together the various components of
the complete mesh management system.

Parts of the system:

Mesh Node Components
OpenWRT Kamikaze
Batman and RO.B.IN
Wifidog

Dashboard Components
Wifidog Auth
Mesh Node Management
Members Portal

Having written all this, i just did a little more research and found
that http://www.bcwireless.net have what looks to be 100% the same
goals as are being discussed here! I have contacted Matthew Asham from
bcwireless.net to see if there is a possibility to coordinate with
them, to avoid duplicating volunteer's efforts and to help strengthen
the great work they have already done to date.

JoeB: If you are reading this please do get in touch. The work that
you and the bcwireless.net society is doing sounds amazing.

[Andrew Gearhart]

A note for everyone: I'm not saying here that I think it would be bad for another competing 100% FOSS solution to be generated. Perhaps even one using a framework such as Seagull or some other interesting framework. If I felt that way... I wouldn't be supporting DoR... since WifiDog really is already done in many respects using PHP and PostgreSQL. However, I believe there is a bit to be gained from the language shift (despite having to learn Rails myself to understand it... a process I'm currently undergoing) and somebody who is building software to meet the same goals that I'm after... a 100% FOSS solution... which is what the Merhaki-DogOnRails solution is targeting.

The part that frightens me is that we're all starved for development time and we're looking at an independent brand-new solution from ideas rather than trying to tie-up lose ends on an existing solution that is aiming for the same goals.

To address your concerns Guy:
WifiDog does in fact support RADIUS servers as a method of authentication. This is per a response to a trouble ticket stating that it doesn't... here: http://dev.wifidog.org/ticket/396
and further expanded upon in the documentation here:
http://dev.wifidog.org/wiki/doc/developer/WiFiDogRadiusWISPr

Regarding the free-for-20-minutes model... I'm not sure where you got the idea that WifiDog only supported that model. There are a number of different models that are supported by virtually any captive portal solution. The question is whether or not the user has access in the authentication server. Since you're talking about using RADIUS servers for authentication... your RADIUS servers would need to handle whether or not the user has access... If you grant them access after simply providing an email address... that's your ball of wax to deal with... you know what I mean? Since the authorizations can be performed against a number of different sources including RADIUS and LDAP servers... I'd imagine that they can require payment prior to access being provided. I'd assume (a big assumption I know...) that most of the WISPs listed on their "the people using wifiDog" page here:
http://dev.wifidog.org/wiki/Community
are probably using some sort of payment-authorization system. Also, according to one of the main contributors... virtually any sort of scheme for allow/preventing access will be able to easily be created once the TokenArchitecture is implemented. This came from one of the core wifidog developers, but I wasn't able to get an exact timeline on when that is to be implemented. My general understanding from his brief comments is that it is currently in development.

Honestly, however, I haven't gotten that deep with either wifiDog or DogOnRails to be able to determine if payment based authentication is implemented or merely on the roadmap. I (highly) doubt that there are no implemented models for removing the unpaid access. Add to this the fact that while DogOnRails is heavily based upon wifiDog ... it isn't wifiDog. It is a port of the PHP-PostgreSQL WifiDog to a Ruby-On-Rails DogOnRails application. So... they may not have exactly the same feature set... but based upon everything that Joe has said so far... the similarities are ... well... more than just similarities... they're near mirror images (after translation).

Forgive me if the rest of this sounds like a rant... its the end of the day and I'm trying to be as non-ranting as possible... but... it probably is... and I'm sorry if it is.
<rant>I'm feeling a bit like Richard Stallman (the complained about parts... not the "I created the free software world and am a god for doing so parts.") for being so emphatic about the idea that DogOnRails is FOSS and Open-Mesh.com isn't... and that as a result... Open-Mesh.com isn't an acceptable final solution. But... man... let's think about why we're here. Many of us were burned by other solutions that weren't 100% open. Open-Mesh.com is largely open... but isn't quite there because of the closed dashboard. Their dashboard is NOT FOSS... its just FS. Don't misunderstand and think that I'm saying we should turn a cold shoulder to the firmware. With Antonio (of ROBIN) working closely with Open-Mesh.com firmware... there's definitely a feather in their cap there. But, as NetEquality has stated before... the scripts from within the firmware can be rewritten to work with other AAA systems. Why not be looking at the differences between Open-Mesh.com firmware and the Merhaki firmware to try to bring these two firmwares together? THAT is what we need to focus on with Joe Bowser (Merhaki-DogOnRails), Antonio (ROBIN) and Mike (NetEquality). I think we're approaching the point where the firmware is nearly nailed on Accton based hardware (FON, Meraki) and the Intel platform sounds like it is coming along as well from our UK cohorts.... as Ian pointed out... we just need the integration from firmware to dashboard. I think turning our backs on DogOnRails just because Joe hasn't responded to a few emails is a bit drastic.
</rant>
<breath type=deep />

Happy New Year and its great to be back in the mix with you folks!

Cheers, :-)
Andrew

[Andrew Gearhart]

ACK Bill, great to hear another WifiDog/DoR vote. From the joining of our two threads, looks like the better AAA that Coova has is due to the token architecture that WifiDog is currently working on... I shot an email to see what Joe's plans are with DoR and the token architecture. Hopefully that will address the questions on RADIUS and the wireless community access models that are possible with Dog (rails/wifi).

Cheers,
Andrew Gearhart
Co-Founder, OSM
Hoping to unwire ... Saint Marys, PA (USA)

[Joe Bowser]

Hey

As far as what to base the project on, there are some pretty heavy
differences between DogOnRails and WifiDog, but there are also a lot
of similarities as well.

The first big difference, other than the language issue is how much
information DogOnRails stores vs. WifiDog. WifiDog has a Content
Management System built into it, for better or for worse. This means
that there are large parts of the code that are unnecessary for most
people because once they login, they're going to redirect them to
their website, bumping up the number of hits their website gets.
Also, the world has too many Content Management systems, and I'm sure
that Drupal, Plone or Mephisto can do a better job of being a content
management system than WifiDog.

The second big difference is that DogOnRails early on was designed
with mesh networks in mind, which is why it has the hooks to gather
data from the ROBIN router. This may be redundant since most people
will use the open-mesh.com dashboard for the majority of their network
monitoring, but DogOnRails can also collect the same data.

Thirdly, DogOnRails also does a lot of Mesh Auditing. This means that
if you're running it, it has the feature added where it will track the
bandwidth of all nodes that are using your node as a gateway. This
hasn't been tested as much as I'd like it to be, and I will be
refining it in the next few months.

As for RADIUS authentication, WifiDog has RADIUS authentication, and
DogOnRails doesn't have it yet. I'm not saying that DogOnRails won't
ever have it, but it's not a priority for FreeTheNet Vancouver at this
time, which is what DogOnRails is written for.

Now, for the similarities:

WifiDog and DogOnRails both use the WifiDog client, which is written
in C. The only difference that I'm making to it is adding the same
packet shaping that NoDogSplash has. The reason I'm choosing
NoDogSplash to grab the code from is because that code is more
readable than the PublicIP fork, where he changed the protocol
entirely, and still hasn't given back the changes he made to the
protocol (and I doubt he will do so, since he is not obliged to under
the GPL).

WifiDog and DogOnRails both log data and generate the same statistics,
which are all connection based. DogOnRails doesn't bother with tying
them to users, because that's a waste of time, and banning a user
means nothing when banning a MAC means that the user either has to get
a new computer or figure out how to spoof a MAC, both of which are
harder than just recreating an account.

As for this token architecture, I'm not sure what you're referring
to. I asked Phillipe about it (he's one of the original developers of
WifiDog, and wrote much of DogOnRails), and he didn't know what you
were referring to either. WifiDog does use very simple token-based
authentication to connect, and it's designed that way so that the
router doesn't know what the passwords are, since routers usually
don't have great SSL connections. As far as I know, there haven't
been any changes to the WifiDog gateway in months, and the last change
was a security fix that bumped the version up to 1.14. WifiDog
development has been fairly slow in the last couple of years (forks
and reactions to forks don't help much to speed things along either).

Also, as far as using DogOnRails with ROBIN, I am talking to MikeBB
and Antonio about making it easy to switch from NoDogSplash to
WifiDog. The WifiDog that will be available will be the copy that I
am working on, but you can choose to use any WifiDog gateway you want,
whether it'd be DogOnRails, or WifiDog server.

Finally, I would like to stress the fact that DogOnRails/FreeTheNet/
Merhaki is my hobby, and not my day job (although I am allowed to work
on some features at work if they're work related), so if I don't
respond to e-mails, it's most likely that I'm not able to get to it.

Joe Bowser
Co-conspirator, FreeTheNet.ca

On 4 Jan, 20:33, "Andrew Gearhart" <andrew.gearh...@gmail.com> wrote:
> ACK Bill, great to hear another WifiDog/DoR vote. From the joining of our
> two threads, looks like the better AAA that Coova has is due to the token
> architecture that WifiDog is currently working on... I shot an email to see
> what Joe's plans are with DoR and the token architecture. Hopefully that
> will address the questions on RADIUS and the wireless community access
> models that are possible with Dog (rails/wifi).
>
> Cheers,
> Andrew Gearhart
> Co-Founder, OSM
> Hoping to unwire ... Saint Marys, PA (USA)
>

> On Jan 4, 2008 8:46 PM, Bill <b...@kingsbridgelink.co.uk> wrote:
>
>
>
> > Hi ( or for all the Network Admins out there: SYN )
>
> > If i was to suggest a dashboard code base to expand for the purposes
> > of creating an open source mesh dashboard, i to would go with wifidog

> >http://dev.wifidog.orgThe quality of the code is second to none, thou

> > i'm kind of biased because i know php, but would be unable to even
> > Hello World in Ruby.
>
> > Here is an interesting article which describes some of the fundamental
> > differences between wifidog and Coova

> >http://coova.org/wordpress/index.php/2007/08/02/radius-wispr-and-wifi...

> > Even thou it suggests Coova has better AAA the article does praise
> > Wifidog for having better Captive Portal customisation.
>
> > From the comments made in this thread already the general feeling does
> > steer towards using code which is already in the public domain. There
> > would still be a need to setup a team of developers ( say from within
> > the opensourcemesh group ) to bring together the various components of
> > the complete mesh management system.
>
> > Parts of the system:
>
> > Mesh Node Components
> > OpenWRT Kamikaze
> > Batman and RO.B.IN
> > Wifidog
>
> > Dashboard Components
> > Wifidog Auth
> > Mesh Node Management
> > Members Portal
>
> > Having written all this, i just did a little more research and found

> > thathttp://www.bcwireless.nethave what looks to be 100% the same