[Click] wifi and madwifi.stripped

[Peter De Cleyn]

Thanks John!

I tried every possible version (including the -ng) but seemed to have
skipped the "old" driver. Everything compiles fine now, the driver get
loaded and I can activate the raw mode!

Peter

On 10/31/05, John Bicket <jbicket at gmail.com> wrote:
>
> You can use the madwifi driver, which works with 2.6, and has a 'raw
> device' which allows you to send/receive
> 802.11 frames. Don't use the madwifi-ng code, I haven't finished porting
> the changes to it yet.
>
> On 10/31/05, Peter De Cleyn < peter.decleyn at gmail.com> wrote:
> >
> > Is there any news on the madwifi story? I would like to use the
> > madwifi-stripped functionality, but due to other constraints, I'm forced to
> > use a 2.6 kernel, for which no click-wifi-patch is available (yet).
> >
> > Is there anyone who has successfully deployed a click/madwifi set up
> > using a 2.6. kernel and is willing to share its expertise or do you have
> > some clues for me to get me started?
> >
> > thanks,
> >
> > Peter
> >
> > On 9/17/05, Bob Keyes < bob at sinister.com> wrote:
> >
> > >
> > >
> > > On Thu, 12 May 2005, John Bicket wrote:
> > >
> > > > I have been incorporating the changes from the madwifi.stripped
> > > > driver into the actual madwifi driver. As a result, I won't
> > > > be maintaining the madwifi.stripped driver any longer.
> > >
> > > Does this incorporate all the features need for RoofNet? so
> > > madwifi.stripped is no longer required for roofnet, but a somehwat
> > > modern
> > > version of madwifi? If so, what versions of madwifi have your changes?
> > >
> > >
> > > > Instead of making the device driver send and receive raw 802.11
> > > > packets on the normal device (ie. athX), I have added a second
> > > "phony"
> > > > device to the madwifi driver that handles all of that (called
> > > athXraw).
> > > > This allows the use of the normal 802.11 stack as well as the
> > > ability
> > > > to run other protocols (ie roofnet) at the same time. If you want to
> > > > bypass the normal 802.11 stack you can use monitor mode, which
> > > > still allows packet transmission using the raw interface.
> > > >
> > > > The code is currently in the madwifi BSD branch, which you can
> > > checkout
> > > > using:
> > > > cvs -z3 - d:pserver:anonymous at cvs.sourceforge.net :/cvsroot/madwifi
> > > co -r
> > > > BSD madwifi
> > >
> > > Were these changes ever incorporated into the Linux version of
> > > madwifi, or
> > > is the a canonical way to compile the BSD version of madwifi in Linux?
> > > > You must use a sysctl to activate the rawdevice if you are running
> > > the
> > > > driver:
> > > > /sbin/sysctl -w dev.ath0.rawdev=1
> > > >
> > > > Also, you can make the rawdevice use headers in addition
> > > > to just 802.11 frames. You can run
> > > > /sbin/sysctl -w dev.ath0.rawdev_type=X
> > > > where X is
> > > > 0: raw 802.11 frames
> > > > 1: prism headers (ie you can use PrismEncap/PrismDecap)
> > > > 2: radiotap headers (ie you can use RadiotapEncap/RadiotapDecap)
> > >
> > > These sysctls are available in my madwifi driver, but I am still
> > > getting
> > > errors:
> > >
> > > ToDevice(ath0) send: Message too long
> > >
> > > and occasionally:
> > >
> > > ToDevice(ath0) send: Network is down
> > >
> > > and I want to make sure these are not due to using an incorrect
> > > version of
> > > madwifi
> > >  _______________________________________________
> > > click mailing list
> > > click at amsterdam.lcs.mit.edu
> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> > >
> >
> >
>