From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 22 09:03:27 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2E94221 for ; Fri, 22 Nov 2013 09:03:27 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A9382387 for ; Fri, 22 Nov 2013 09:03:27 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e9so389914qcy.34 for ; Fri, 22 Nov 2013 01:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=YvtMqgph9mjHneYqN0bTQEPDJUDtkYjpgGuZkmLoAvk=; b=dARLFW+XUW24aGphHVfJbsRJC7mGukAVxWx2x157Sdvhmd/slw8fzgpOVJzmhWLjpW ZnzOUhOZfeNM0EwRQWVu0xItcEgqauUQBo/n0T8QwI87yJd3M7fIWGuld9z61riRUil7 gw/zIrj8RqT7W7ybb3nQ1YVIYYeu7Fuak3ZbAO+H9lrr6zikLYzjOiazPKcsGHDyqBCV j4eJe+HzJr8ba2NiGAMxvlWlikndWX8/1gYKHYagnREjigufJ+n/FdUutHkxcG/S3v94 TjP+IHJOyvz7KYm8PwivM180wsIpq0CwAEQAiTdQKOR7Zxl5EmjoEKu4QXTE7NiT64VH N7FA== MIME-Version: 1.0 X-Received: by 10.224.103.131 with SMTP id k3mr19626831qao.76.1385111006622; Fri, 22 Nov 2013 01:03:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 22 Nov 2013 01:03:26 -0800 (PST) Date: Fri, 22 Nov 2013 01:03:26 -0800 X-Google-Sender-Auth: pCm4ZkLJYQnkJ3EfUOyG-82MFzw Message-ID: Subject: iwn(4) issues to date From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:03:27 -0000 Hi, Here's my shortlist of iwn(4) issues. Please feel free to acquire one or more of these particular tasks. * the 6235 doesn't work. I have one, but I'm busy doing ${WORK} so chasing down why isn't on my todo list for a few weeks. Sorry. * The scan code is broken. We're not setting the active/passive values correctly, we're not setting the service maximum time field correctly. Thus, the scan command can hang when scanning passive channels. Setting these things correctly (based on iwlwifi) mostly works. service_time is a bit wonky as the iwlwifi code sets it to (blah) | (some other blah << 22) and so I've seen it scan channel 13 for 4 million microseconds, which I don't think is "right." * We should block sending scan if we've already sent a scan command (ie, we should fail that scan) if it hasn't completed. * We should block sending RXON if we've sent a scan command if it hasn't completed - we should error out * .. and then clear the scan tracking flag when we do a chipset reset. * The scan beacon timer config has to take the beacon interval into account AND make sure that we come back on channel for long enough to do traffic/hear beacons. That way we don't disassociate when we are scanning because we stopped hearing our real traffic. * The NIC is rejecting frame TX on passive channels (eg 5GHZ radar channels) until it hears a beacon. Since we're not doing software retransmit of frames in this case, we end up failing to associate reliably on these channels. The correct mechanism is to queue the frame again and when we receive a beacon, clear the "TX queue paused" flag and re-schedule frames. Maybe, if someone is evil enough, they could abuse the net80211 powersave queue to re-queue an 802.11 frame and wake up the power save queue when it's done. There's also a net80211 bug where if the scan is cancelled at the wrong spot (I think at the end) then it ends up never resetting the ss_next value to 0, and subsequent scan requests end up failing as there's no channels to scan. That also has to be fixed. I think those are the annoying bugs. They mostly show up in various company offices (Yahoo, Netflix) rather than at home. It'd also be nice to correctly use the scan infrastructure on iwn(4) to do bulk scans. net80211 scans one channel at a time. We should be able to write an iwn(4) specific scan module in the driver that registers a scan module optimised for the NIC. The NIC can scan multiple channels and send out multiple SSID probes by the firmware; it doesn't have to transition in and out of the SCAN state to do this. The intel NIC support is getting better but I really could do with some help here. I'm kind of still feeling a bit burnt out here. :-) -adrian