Date: Tue, 8 May 2001 09:19:55 -0700 (PDT) From: Doug Ambrisko <ambrisko@ambrisko.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Doug Ambrisko <ambrisko@ambrisko.com>, Matt Peterson <matt@peterson.org>, "Ron 'The InSaNe One' Rosson" <insane@lunatic.oneinsane.net>, freebsd-mobile@FreeBSD.ORG Subject: Re: Bay Networks Baystack 650 Wireless LAN Message-ID: <200105081619.f48GJtg21421@ambrisko.com> In-Reply-To: <20010507220442.A5215@Odin.AC.HMC.Edu> "from Brooks Davis at May 7, 2001 10:04:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis writes: -- Start of PGP signed section. | On Mon, May 07, 2001 at 08:09:17PM -0700, Doug Ambrisko wrote: | > I have a bunch of fixes for the Aironet stuff. Still need to do some | > more work but I cleaned up the read and write functions. They should be | > a little faster and deal with with odd size transfers. I also included | > your ifocnfig patches in my and made an include file to turn them one | > and off. This way I could resolve merge conflicts. | | Any reason you need to turn them off now that read and write are fixed? | If not, then I'll just roll yours into my tree so I pull them out in my | standard patchset. Yes since I generate the patches relative to cvs. I now include your changes in my patch set. Since your patches aren't in FreeBSD -current or -stable if I leave your patches enabled then the driver fails. (I think I ran into the problem but it has been a while). Since we have conflicting changes (ie I have patches to your patches) I just make mine relative to cvs. Of course if we got this stuff checked in then CVS would deal with managing the changes and life would be good! I think the big problem with our patchsets is that we are going to have conflicts and people will need either my "an" changes or yours and if people try to use both at the same time they have merge hell. So that why I just included all of your "an" changes in mine but added a switch to turn them on or off. I guess if you want to take all of the "an" changes as I make them available that is fine. However, I've found that sometimes slowly then just posting patches on the web. "send-pr" usually takes a long time before commited. I still have a few in the queue that aren't being looked at or acted on. | > Are your BPF changes for better snooping to deal with 802.11 stuff? | > Ethereal can deal with 802.11 packets. Linux has some feature | > to be able to connect Ethereal to the raw 802.11 packets for sniffing. | > Part of the code to support this is being added to the Linux driver. | > For FreeBSD I was thinking of tying the raw 802.11 packets into | > Netgraph and then tie Netgraph into Ethereal and then we could sniff | > 802.11 packets from the Aironet cards. The Aironet code is to enable | > the sniffing is fairly easy. If we do this in general then other | > cards such as the wi ones could tie into Netgraph the same way and | > just work. Also if Ethereal was taught about frame relay that would | > just work as well. | | My idea is that you should be able to set and ioctl to choose which | level of decapsilation bpf reports (and, if possiable, sends) at. If we | can send and recieve probe and response messages we can both search for | APs better and watch for other people looking for our APs. Okay we should be able to support that. I in theory have code for that but not in the "an" driver yet. BTW one Linux guy did a hack of extracting the 802.3 header out of the 802.11 packet and prepended the 802.3 header. This way he could pass the 802.11 encapsulated packet up through normal BPF channels to user-land. Then he modified Ethereal to strip the fake 802.3 pre-pended header and then used Ethereal's 802.11 parser to sniff things. Note this is a dedicated snifer since it's not a valid 802.3 packet. An interesting idea. However, with netgraph we can dump anything into netgraph and then attach processing modules. So for example we could do a 802.11 <-> 802.3 module and everyone could share it. I think Julian and someone is working on that. Then we could sniff at the 802.11 raw level or at 802.3 level. It would be nice to have a machine on the network doing normal network stuff and be able to sniff all raw 802.11 packets. If you get a framework started I can make changes to the Aironet driver to support it for sniffing. It shouldn't take long to do. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105081619.f48GJtg21421>