linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benoit PAPILLAULT <benoit.papillault@free.fr>
To: Daniel Golle <daniel.golle@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: some ideas about pseudo_adhoc (as rtl8187 cannot do beacon generation)
Date: Sat, 13 Feb 2010 09:31:58 +0100	[thread overview]
Message-ID: <4B76637E.8040709@free.fr> (raw)
In-Reply-To: <4B750C6E.9000208@gmail.com>

Daniel Golle a écrit :
> hi!
> i've got an rtl8187l and want to use it in Ad-Hoc mode (actually 
> pseudo_adhoc would actually even be enough!). i researched a little 
> bit and found out that ad-hoc-, master- and mesh-mode are unsupported 
> due to the lack of beacon generation support in the mac80211 version 
> of the rtl8187 driver.
> as the softmac card probably doesn't support generating beacons in 
> firmware, does that mean we need to setup a beacon generation fork 
> repeatedly calling
> ieee80211_beacon_get
> and then sending the beacon? (very roughly, i'm guessing after reading 
> any 802.11 code for 20 minutes)
> probably a timing-critical task which needs to bypass the usual 
> buffers and such i can imagine...
TSF synchronisation is indeed critical since lots of mecanism like 
power-save, IBSS merges, ... requires a proper TSF. I don't know how 
accurate kernel timers are, but they might not match the IBSS expectation.
>
> anyway. pseudo_adhoc (i.e. ad-hoc without beacons) is a nice thing and 
> works great for use with user-space mesh-routing solutions such as 
> OLSR, batman or babel. however, i guess as pseudo_adhoc is violating 
> the standards (though it is very usefull) it might never be supported 
> by anything else than proprietary drivers made by Atheros (afaik).
>
> so. i want to use this hardware (RTL8187L) for this task (OLSR). any 
> ideas? where should i start wasting my brain-time?
Pseudo-IBSS is just like IBSS except :
- you don't send beacons
- BSSID is fixed at 00:00:00:00:00:00 (so SSID is useless .... and since 
there's no beacon anyway).

Maybe you could image an IBSS-like mode where :
- you don't send beacons (or at least don't rely on them)
- you still reply to Probe Request by Probe Response (so you can still 
scan, search for an SSID and synchronize the BSSID). However, you can 
have splits without proper handling of IBSS merges...

I would implement this latter since it's closer to the standard 802.11 
IBSS mode, which means less modifications in current and less 
interoperability problems.

>
> ot: anyone ever tried compiling the FullMAC r8187 driver (aircrack) 
> for Atheros/MIPS systems?
>
> cheers
>
> daniel
Regards,
Benoit


      reply	other threads:[~2010-02-13  8:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-12  8:08 some ideas about pseudo_adhoc (as rtl8187 cannot do beacon generation) Daniel Golle
2010-02-13  8:31 ` Benoit PAPILLAULT [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B76637E.8040709@free.fr \
    --to=benoit.papillault@free.fr \
    --cc=daniel.golle@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).