Fwd: 802.11n hardware as a research enabling platform - Seeking an experienced kernel driver developer.
Jim Forster
From: Yahel Ben-David <ya...@airjaldi.org>Date: February 26, 2010 12:26:31 AM GMT+05:30Cc: Matt Podolsky <podo...@eecs.berkeley.edu>Subject: 802.11n hardware as a research enabling platform - Seeking an experienced kernel driver developer.
802.11n hardware as a research enabling platform
Seeking an experienced kernel driver developer.
Hi,
I'm the founder and CTO of AirJaldi.Org, a social enterprise based in the Indian Himalayas at Dharamsala.
Our mission is to empower rural communities through the use of wireless network. In practice, we develop affordable technologies, operate large-scale rural networks and provide training.
The larger network we operate in India, which caters mostly to the Tibetan-community-in-exile led by the Dalai Lama, provides broadband Internet access, VoIP telephony and various other services to over 10,000 users in one of the world's harshest of environments. In addition, we operate a growing number of smaller networks, throughout India and some small pilots in Africa and Latin America.
My current focus is on R&D of our future solutions, based on affordable 802.11n gear.
Towards that end we’ve teamed with the TIER research group out of UC Berkeley led by Prof. Eric Brewer and with the De Novo Group a non-profit to productize and support these solutions.
Our ideal future solution is based on an agile TDMA MAC to provide high-bandwidth links over very long distances, while dynamically adopting to varying traffic patterns, enforcing QOS policies at the MAC layer, and ensuring fairness for multiple clients, all while overcoming long propagation delays, interference and other elements associated with long-distance wireless.
Initial details of our proposed MAC design, called JaldiMac, can be found here: http://www.eecs.berkeley.edu/~yahel/coursework/papers/JaldiMAC-CS262a-final.pdf
Although the hardware specifications for Atheros 802.11n radios are mostly freely available, and in practice used within the ath9K driver, we've learned that it's challenging to make use of the hardware for MAC protocols other then 802.11-based. It appears that much of the work around ath9K is concerned with interoperability issues and there is no intention to offer injection/reception of packets formatted in any other manner.
Since we need to do without most of the 802.11 framework in our completely fresh MAC design, we cannot use ath9K and hence are faced with the need to write a new kernel driver to allow use of the ath9K hardware without the limitations/restrictions of 802.11.
Moreover, we feel there are many compelling reasons to engage in such work and provide the community with an open-source driver to enable future research and influential solutions:
1. Since the introduction and deregulation of wifi, the proliferation of these low-cost devices drove remarkable research and development - leading to ground breaking results in wireless communications.
2. Moving beyond the capabilities of older 802.11abg devices, researchers are mostly restricted to prohibitively expensive SDRs (Software Defined Radios) for their studies. Imagine a study of a large-scale wireless mesh network using SDRs costing ~$1000 for each node!
3. Recent 802.11n hardware may offer an attractive, sometimes superior, alternative to SDRs from the research perspective and more attractive over WiMax for impacting the deserving communities we serve. Nevertheless, most development is based around the 802.11 family with little or no intentions to use the hardware beyond these restrictions.
Our intention is to support the development of a Linux kernel driver to enable use of this attractive hardware beyond the restrictions and limitations of 802.11 specs. In-fact, we have no need for any 802.11 interoperability.
Ideally, we would use tools such as the Click Modular Router to interface with this new driver and control the various MAC layer elements.
We expect such an open-source driver will inspire countless research opportunities and would lead to impactful results towards connecting the next billion Internet users.
Our research group has secured limited funding which we may use to pay for the time of an experienced kernel driver developer, leading towards these goals....
This is the reason for this email, in the hope that you could help us identify a potential developer for this project.
Needless to say, further definitions of the details are called-for, but we feel it's better done in concert with the relevant individuals who might do this work.
I wonder if you or anyone you may know would be interested to assist in this effort?
Thanks!
Yahel.
David Rowe
studying VOIP over Wifi late last year we also identified some areas of
the 802.11 protocol that are really inefficient for short VOIP packets:
http://www.villagetelco.org/2009/11/factors-affecting-village-telco-performance/
I think there is a lot to be gained by experimenting with the Wifi
protocols at the low levels. It's a challenging project though, and
it's possible you will hit some "closed source" walls like we did with
the chip vendors.
Best of luck with the project.
Cheers,
David
> > Berkeley led by Prof. Eric Brewer and with theDe Novo Group a
> --
> You received this message because you are subscribed to the Google
> Groups "village-telco-dev" group.
> To post to this group, send email to
> village-...@googlegroups.com.
> To unsubscribe from this group, send email to village-telco-dev
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/village-telco-dev?hl=en.
David Rowe
> FWIW - we are still looking for kernel driver developers as a first
> step - not much progress, surprisingly, on that front... So everything
> else is mostly stuck...
> (I will work on that paper a bit, hopefully to make it into NSDR this
> summer, so it can begin to gain some traction)...
Elektra and I have a guy in mind, we will talk to him about the position
today and let you know.
There are some disaster recovery techniques on the Mesh Potato HOWTO:
http://wiki.villagetelco.org/index.php?title=Mesh_Potato_HOWTOs
The specific trick for your problem is to use "putty" instead of telnet:
Putty passes Ctrl-C, telnet blocks it for some reason.
Cheers,
David
On Wed, 2010-03-03 at 22:47 -0800, Yahel Ben-David wrote:
>
> Hi David,
>
> Excellent post making the relations between PPM (packets per minute)
> over WiFi and the VoIP quality...!
> Once thing I'm missing the the issue of Jitter, which we find to
> affect voice more then packet loss...
> FWIW - we are still looking for kernel driver developers as a first
> step - not much progress, surprisingly, on that front... So everything
> else is mostly stuck...
> (I will work on that paper a bit, hopefully to make it into NSDR this
> summer, so it can begin to gain some traction)...
>
>
> Anyway, we already have Jim's 4 Mesh Potatoes here for almost 3
> weeks...
> I've given them to our new volunteer from Ecuador (of TIER - Eric
> Brewer found him somewhere).
> He was sick for the first two weeks and then was all excited to work
> on the MPs - for 3 days (in which he learned how to configure his
> laptop's IP)...
> Then he notified us that he's found a job and would not be working
> with us...
> I still wait for him to return 3 of the 4 units.. ;-(
>
> Hence the unexpected delay in giving you feedback, which I really
> wanted to do - but never got around to it..
>
> Nevertheless, I do have one unit and was playing with it for the last
> hour and a half (already 30min more then I allocated to it ;-)
> In my haste, I've must have screwed something up (by using "vi" on
> the /etc/config/network - changing "static" to "DHCP" on both Ethernet
> and WiFi).
> So - lost connectivity to the device (it does not get an IP from the
> DHCP servers).
> I followed one of your blog posts, where you mention that the reset
> button is unwired in the betas - and I think that's the case with
> mine.
> I then tried to telnet into redboot - and discovered that not only the
> Chinese set my default IP to be 192.168.1.188 - they also use port
> 9000 for the telnet console and not 23.
>
> Nonetheless, as soon as I successfully telnet into the box and before
> I get a chance to hit CTRL-C, the thing just looses connectivity.
> (I did this very fast multiple time).
>
> Any ideas how I can overcome this, short of soldering an RS232
> level-converter to an RJ11 jack (which pins BTW) ?
>
> Below is the capture from my telnet attempt.
>
> Thanks,
>
> Yahel.
>
>
> root@jamus:~# telnet 192.168.1.188 9000
> Trying 192.168.1.188...
> Connected to 192.168.1.188.
> Escape character is '^]'.
> == Executing boot script in 4.290 seconds - enter ^C to abort
> > > > Towards that end weג��ve teamed with the TIER research group out of UC
--
Free Telephony Project
open embedded IP-PBX hardware and software
http://www.rowetel.com/ucasterisk