Hi!
Community networking initiatives (like Freifunk/Funkfeuer and many
others in developing countries like Air Jaldi in India) are running now
large scale layer 3 meshes (up to 800 mesh nodes in a single IBSS cell).
A problem has always been the stability of the ad-hoc mode in large
ad-hoc cells. Typical problems are steady TSF timestamp skews, MAC timer
skews and subsequent lockups, failed or endlessly repeating IBSS merges
to the same cell and hence IBSS cell-splits.
Currently there is only one open-source driver (not entirely open-source
because of the binary HAL blob) which is up to the challenge of such
networks - Madwifi (Not the vanilla code from madwifi-project.org, but
the patched Madwifi from OpenWRT Kamikaze maintained by OpenWRT
developer Felix Fietkau).
It would be great to have a few drivers in the kernel that are up to the
challenge, too. Hence this is a feature request. Let me explain what has
been done to Madwifi to cope with the problems.
Madwifi can be forced to bypass IBSS merges and stick to a certain
IBSS-ID by issuing a command like:
iwconfig athX ap 02:CA:FF:EE:BA:BE
This was not sufficient to fix stability problems with Madwifi, as TSF
time stamp skews were still messing up a hardware timer related to the
ATIM window which caused stuck beacons/stuck transmit queues. The
workaround for Atheros was to switch the hardware into AP mode so it
doesn't try to adjust its hardware timers to TSF time stamps. Hence
beacons have to be generated in software which is not precise enough.
(IMHO TSF time stamps are pretty much superfluous in adhoc mode because
I guess we can savely forget about power saving mechanisms in a large
scale mesh cloud anyway, I propose to deliberately let software
generated beacons lag behind the TSF time stamps in order to avoid
confusing other ad-hoc peers)
If someone wants to experiment with Madwifi in this mode, create the
adhoc VAP with the "nosbeacon" option. (Example: wlanconfig ath0 create
wlandev wifi0 wlanmode adhoc nosbeacon)
So these wireless mesh communities have at least one perfectly working
solution for wireless interfaces for Atheros SoC/PCI/PCI-E devices(
well, almost perfect because of the timer precision issues). It would be
great if ath5k and ath9k could be used in the same way, too.
We are lacking support for at least one USB chipset as well.
Zydas/Atheros 5007UG would be great. USB would open up the opportunity
to connect desktop PCs to mesh networks at low cost / build cheap mesh
supernodes (routers with more than two wireless interfaces). It would be
awesome to use USB devices, because USB dongles could be easily built
into the antennas and save the cost and RF losses of expensive
pigtails/RF-plugs/RF-cables. Interfaces usually placed in close
proximity on one motherboard and thus all interfering with each other
could be seperated up to 10 meters away from each other.
Antenna/USB-WLAN<--------------5m USB cable -------------> Router
<--------------- 5m USB cable -------------> USB-WLAN/Antenna
Cheers,
Elektra
Hi again!
> Try it out! For me It works fine now.
http://wireless.kernel.org/download/compat-wireless-2.6/
(not compat-wireless-old, its less stable, use kernel >=3D 2.6.27 and c=
ompat-wireless)
Please let me know if you find a IBSS specific problem. I think it shou=
ld be fixed in a short time.
Regards
Alina
--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/[email protected]
Hello elektra,
I have asked you help debugging. In my little backyard all works fine n=
ow.
> A problem has always been the stability of the ad-hoc mode in large
> ad-hoc cells.
After my patches IBSS should now as stable as STA mode with the used lo=
w-level driver is.
> Typical problems are steady TSF timestamp skews, MAC timer
> skews and subsequent lockups, failed or endlessly repeating IBSS merg=
es
> to the same cell and hence IBSS cell-splits.
=46ixed BSSIDs are supported now in compat-wireless and the repeating I=
BSS merges to the same BSSID are fixed. (at mac80211 layer)
> It would be
> great if ath5k and ath9k could be used in the same way, too.
Try it out! For me It works fine now.
> We are lacking support for at least one USB chipset as well.
> Zydas/Atheros 5007UG would be great.
I work with the ar9170 driver and same Draft-N chipset which is the rep=
lacement for the ZyDAS chipset. It works okay for me, it only doesn't s=
upport rate control like minstrel for now.
Regards
Alina
P.S.:
http://git.kernel.org/?p=3Dlinux%2Fkernel%2Fgit%2Flinville%2Fwireless-t=
esting.git&a=3Dsearch&h=3DHEAD&st=3Dauthor&s=3Dx-alina%40gmx.net
--=20
Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? Der kann`s mit all=
en: http://www.gmx.net/de/go/multimessenger01
On Wed, Mar 18, 2009 at 01:00:54PM +0100, elektra wrote:
> Community networking initiatives (like Freifunk/Funkfeuer and many
> others in developing countries like Air Jaldi in India) are running now
> large scale layer 3 meshes (up to 800 mesh nodes in a single IBSS cell).
> A problem has always been the stability of the ad-hoc mode in large
> ad-hoc cells. Typical problems are steady TSF timestamp skews, MAC timer
> skews and subsequent lockups, failed or endlessly repeating IBSS merges
> to the same cell and hence IBSS cell-splits.
Elektra,
Would you be interested in joining us in Berlin as part of FUDCon
(and adjacent to LinuxTag) to talk about your project and its needs?
https://fedoraproject.org/wiki/FUDCon:Berlin_2009
The FUDCon guys are being nice enough to provide us some space.
It would be good if we could reward them with a few talks that might
have general community interest. Plus, you would have an opportunity
to deal directly with some of the key wireless developers in the
community.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.