Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Javier Achirica (achiricattd.net)
Date: Mon Nov 12 2001 - 14:46:40 CST
Attached is a small patch for the previous I sent you that fixes a small
bug that may get triggered in an SMP test.
Anyway, please send me your current patch so we are in sync I we don't
duplicate work. Once we get the SMP part tested I'll commit the current
version to the CVS and the kernel tree.
On Mon, 12 Nov 2001, Benjamin Reed wrote:
> I have been playing around with creating a slave device for doing
> 802.11. I think I have mostly got it working. The idea is that the
> driver registers eth0 and wifi0. eth0 does ethernet and wifi0 does
> 802.11. This resolves the transmit problem. For packet reception I'm
> thinking that 802.11 data packets will go through eth0 and the rest go
> through wifi0. I finally got it mostly working last night.
> We currently have a problem: Javier did a revamp of some of the locking
> code that has not been checked in because we haven't been able to test
> on SMP. I have a leap support patch and now this wifi patch waiting
> behind the locking patch Javier did. Our normal SMP tester is busy with
> his real job, so is there anyone else out there with an SMP machine that
> could bang on Javier's new driver?
> Javier Achirica wrote:
> > On Sun, 11 Nov 2001, Bryan D. Payne wrote:
> >>>If you change TXCTL_802_3 to TXCTL_802_11 in the "txControl = ..." line
> >>>the driver will take raw 802.11 frames instead of 802.3 frames (and you
> >>>will break all protocol stacks :-)
> >>Cool. I'm glad to see that this is possible.
> >>>That should be great, but the problem is that, while doing that, the
> >>>standard connectivity should be maintained, so the problem is being able
> >>>to open a raw (802.11) socket to the interface while maintaining the rest
> >>>of the system (the protocol stack and other sockets) transmitting in 802.3
> >>>mode. For an internal application disabling that function shouldn't be a
> >>>problem, but there's something that needs to be fixed in a general purpose
> >>I agree. Perhaps the driver could look at the frames it receives and
> >>decide if each frame is an 802.11 or an 802.3. Then, it could
> >>just send the 802.11 frames straight out and convert (probably in the
> >>driver, instead of firmware) the 802.3 frames.
> >>Yeah, I know that there are some problems with the idea. Mainly
> >>performance and being able to determine if you have an 802.11 vs. 802.3
> >>frame in front of you. But, assuming that one could resolve such issues,
> >>then this would be a possible solution.
> >>Perhaps the driver could be designed to normally operate as it is
> >>currently designed. But, if someone needs this additonal capability, they
> >>could compile it with a different flag set and get something more like
> >>I've described above.
> >>>OTOH, switching the card to AP mode activates a limited AP functionality
> >>>within the firmware, so I think there isn't a need of implementing the
> >>>full AP functionality in an user space app. The problem I have with that
> >>>is that there is no documentation about all this and I cannot test it due
> >>>to the lack of equipment. If you feel you can work on this, I can help
> >>>with it. Keep in mind that being able to transmit 802.11 frames without
> >>>switching to AP mode won't allow you to implement an AP as the card will
> >>>still be trying to associate to an AP.
> >>True. But there are some other uses for transmitting 802.11 frames that
> >>would make this useful for us as well.
> > I've been playing around with the code and I've found a easy way to
> > implement transmission of 802.11 frames without breaking anything.
> > Reception is more tricky as there's only one way to push the packet to the
> > upper layers. Although I think I can figure out how to send packets to the
> > protocol stack and to a listening application, I don't know yet how to
> > detect if the processes that has opened raw sockets wants 802.3 or 802.11
> > packets. And could be difficult to solve the scenario in which there are
> > different processes expecting each one one of the encapsulations.
> > Javier Achirica
> > _______________________________________________
> > Aironet mailing list - Aironetcsl.cse.ucsc.edu
> > http://csl.cse.ucsc.edu/mailman/listinfo/aironet
- TEXT/PLAIN attachment: diff
Aironet mailing list - Aironetcsl.cse.ucsc.edu