Ben,

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.

Javier Achirica

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?
>
> thanx
> ben
>
> 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
> >>>driver.
> >>>
> >>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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]