On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 07:44:50PM +0200, Bernhard Schmidt wrote: > > On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > > > After having another cup of coffee it's pretty obvious what's wrong. > > > The only difference between what I did and your scenario is, that I > > > didn't use > > > ifconfig iwi0 mediaopt monitor > > > but > > > ifconfig iwi0 monitor > > I haven't look in the source yet, but what is the difference between > "mediaopt monitor" and "monitor"?
The first is SIOCSIFMEDIA the other SIOCGIFFLAGS. The later probably only worked by accident.. > > > instead.. anyways.. > > > > > > Attached patched should behave better now. > > > > Sorry.. correct one this time. > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > does not work after that (and "list scan" returns no results) even if I > put adapter back to normal (from promisc and monitor modes) with > ifconfig(8). kldunloading and loading module again fixes the issue. Due to enqueueing the scan command in an infinite loop (yeah.. scanning returns every frame, that's monitor mode for that device.. *sigh*) we might increment a queue index but never actually dequeueing the command. On 'down' we clear the command queue but not the indicies resulting in the cur index not pointing to a filled entry. Attached patch should fix that. On a side note, you should never be required to run 'ifconfig dev scan', because after 'ifconfig dev up' the device is always in SCAN state (at least in station mode). Using 'ifconfig dev list scan' is sufficient enough. The 'scan' command is usally used to trigger a background scan while not being in SCAN state and those tend to get suspended pretty often (eg. when packets need to be sent), this is what you see as a hang. > Injection test "aireplay-ng -9 iwi0" still fails, but as I've been told > this is firmware issue (i.e. not possible with iwi(4)), which is also > inline with dmesg: > > <kern.crit> kernel: iwi0: firmware error > <kern.crit> kernel: iwi0: iwi_cmd: cmd 6 not sent, busy > <kern.crit> kernel: iwi0: device configuration failed > > Googling shows that people patch Linux drivers to support injection, but > I do not know if any of that information is applicable to FreeBSD. It might be possible with lots of ugly hacks to get that device sending some kind of frames, 'injecting' those frames via net80211 shouldn't be that hard. At least the code is there according to comments in ieee80211_output.c. I do not consider this worth the effort though, if someone wants to work on that, let me know. > Apart from that, machine seems stable, and monitor mode is fixed. Thanks > a lot! You're welcome :) -- Bernhard
Index: sys/dev/iwi/if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 213584) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -3267,6 +3298,7 @@ iwi_stop(void *priv) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); memset(sc->sc_cmd, 0, sizeof(sc->sc_cmd)); + sc->sc_cmd_cur = sc->sc_cmd_next = 0; sc->sc_tx_timer = 0; sc->sc_rfkill_timer = 0; sc->sc_state_timer = 0;
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
