Re: Orinoco monitor mode?
Miles Nordin <[email protected]> 11 Aug 2002 14:43:48 -0400
| Newsgroups | gmane.network.wireless.bsd.airtools |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "ts" == Tony Saign <[email protected]> writes: >>>>> "mp" == Mathieu Perrin <[email protected]> writes: ts> Does the wi driver in FreeBSD support monitor mode for an ts> Orinoco card? I heard Orinoco does not have a monitor mode, so I bought one of the ``Z Com'' Taiwan 5-volt PRISM2.5 cards which are being resold by demarctech.com. Unless something has changed recently, I believe the Lucent firmware and MAC preclude RF monitor mode and Host AP mode. However, from what we've heard in other posts on this list, RF monitor mode may not work correctly for any card. The ridiculous packet sizes Mathieu found below may also be a problem specific to dwepcrack, not the wi driver, since ethereal seemed to read them, but he doesn't seem to know for sure---and I note that ethereal probably only reads the first few bytes of the captured packet, not the whole thing, which could explain why it works and a WEP cracker that needs the whole packet does not. so, Orinoco or not, the workingness of RF monitor mode depends on a few unknowns and your interpretation of ``works.'' mp> Our problem was that we couldn't find the wepkey, even when we mp> had 7 or 8 millions packets ( using FMS attack ). mp> While trying to find why we always have too few weak packets, mp> we found that dwepcrack used only 3000 or 4000 packets ( from mp> a dumpfile of 400 000 packets ), and found only 200 weaks IVS. mp> So we investigated into weakksa.c, and found an average value mp> of wi_h-> wi_dat_len of about 50000, while you reject all mp> packets with wi_dat_len greater than 2304 ( MAX_PKT_SIZE ). mp> We are very surprised by this value of 50000. We collected mp> traffic from a ftp transfer between an AP and a FreeBSD client mp> ( prism2 ) with a tcpdump running on a linux ( cisco card ). mp> So here are our thougths : mp> - incorrect casting of the output of pcap_next() in mp> struct wi_h ( wi_h = (struct wi_rx_frame *)pkt; ) mp> - maybe our dumps are flawed ( althought ethereal can mp> read them ) mp> - maybe we are totally nuts.... :) -- BigBy sped off, laughing, through a megaphone.