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.