From patchwork Mon Jun 24 14:35:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mihai Moldovan X-Patchwork-Id: 253855 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from maxx.maxx.shmoo.com (maxx.shmoo.com [205.134.188.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "maxx.shmoo.com", Issuer "CA Cert Signing Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id AD1FC2C0089 for ; Tue, 25 Jun 2013 00:35:24 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 660429C1AF; Mon, 24 Jun 2013 10:35:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgyU1P-6TEwx; Mon, 24 Jun 2013 10:35:18 -0400 (EDT) Received: from maxx.shmoo.com (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id DE6E99C197; Mon, 24 Jun 2013 10:35:13 -0400 (EDT) X-Original-To: mailman-post+hostap@maxx.shmoo.com Delivered-To: mailman-post+hostap@maxx.shmoo.com Received: from localhost (localhost [127.0.0.1]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 7890C9C188 for ; Mon, 24 Jun 2013 10:35:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at maxx.shmoo.com Received: from maxx.maxx.shmoo.com ([127.0.0.1]) by localhost (maxx.shmoo.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cmnp-wvsel5 for ; Mon, 24 Jun 2013 10:35:07 -0400 (EDT) Received: from Root24.de (powered.by.root24.eu [91.121.15.64]) by maxx.maxx.shmoo.com (Postfix) with ESMTP id 2B7F19C197 for ; Mon, 24 Jun 2013 10:35:07 -0400 (EDT) Received: from nopileos.local (home.ionic.de [85.183.67.131]) by Root24.de (Postfix) with ESMTPSA id 333763B00679 for ; Mon, 24 Jun 2013 16:35:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ionic.de; s=default; t=1372084506; bh=xY1pm7DZYD3FL7piZtkXLN2BcZDD5RDvGQt6SO0Fs1w=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cnScW7YqvZ+TiDXvgjUqr72IO6fkHI85wv3TPEo1GDIyXXdR44iLwdIwc32PJMVw1 WHXNNIz1WMUGvmmqPiL4c65p0+5aNpD7VrSOzp/9HZgD9sUw555C3m7znbhqma9PML eWb7hKh3PuWwT3QbJLqUOiE7+b6/XZkig+VNUFqk= Message-ID: <51C85919.7090704@ionic.de> Date: Mon, 24 Jun 2013 16:35:05 +0200 From: Mihai Moldovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: hostap@lists.shmoo.com Subject: Re: Dropped frames (unauthorized port) in AP mode References: <51C0D052.2000206@ionic.de> <20130622075929.GA3989@w1.fi> <51C772D0.1080302@ionic.de> <20130624104316.GA3797@w1.fi> In-Reply-To: <20130624104316.GA3797@w1.fi> X-Enigmail-Version: 1.5.1 X-BeenThere: hostap@lists.shmoo.com X-Mailman-Version: 2.1.11 Precedence: list List-Id: HostAP Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hostap-bounces@lists.shmoo.com Errors-To: hostap-bounces@lists.shmoo.com * On 24.06.2013 12:43 PM, Jouni Malinen wrote: > How long after starting hostapd did you try to connect? Just to make > sure there are no issues with bridge ports not being ready, I'd wait 10 > seconds even if STP is turned off. I generally waited about 30 seconds after starting hostapd, been doing stuff like reading/flushing dmest right after starting it. But even if hostapd runs for hours, the result is the same. Moreover, I tried to get the bridge out of the equation and removed the bridge parameter entirely from hostapd.conf, then tried connecting with a station again. Interestingly, my kernel is still dropping some frame and the ethertype of that frame is still 0x0006, so this doesn't look like a bridging issue. The only device within the bridge this time around was eth(er)0, which shouldn't be "connected" to the wifi devices anymore. > That looks pretty strange.. Based on the length and timing of the > frames, the EAPOL-Key msg 1/4 from the AP could be encrypted. This > should not be the case unless some very strange key configuration was > somehow applied by something else than hostapd. This seems to imply that > EAPOL frames are getting through TX path since otherwise there should be > no unicast Data frames here, though. It's getting stranger: the very same setup works fine with kernel version 3.0.2, but stopped working in-between. IIRC, about the time, when hostapd stopped creating a monitor interface and using that for AP mode. At the very same time, TX status support has been implemented in mac80211 by Johannes Berg (commit a729cff8ad5120d0d5172ec28a3843d1cb458f79). After reverting his commit, I was able to use hostapd on 3.5.x - with a monitor interface being used, so I suspect the kernel being broken in this respect. I haven't been able to revert the commit on top of 3.9.6 due to more sophisticated merge conflicts. Thus my idea: can I disable usage of TX status and the new monitorless AP mode and instead have hostapd work "in the old way" for the time being? I'd still like to have the kernel bug fixed, but in the meantime have a working hostapd version. Commit 73a3c6ffca0c0292289c4fc598402b4227c85faf by nbd disables monitor usage when detecting TX status support... I have crafted a trivial patch to enable monitor mode unconditionally for me: if (drv->device_ap_sme && drv->use_monitor) { /* With this patch, my notebook is able to authenticate. So... what's the real culprit? :) dmesg is still showing a dropped frame, but this does indeed seem to be harmless (ethertype == ... line patched in by myself): wifi1: Allocated STA f8:1e:df:dd:01:f7 wifi1: moving STA f8:1e:df:dd:01:f7 to state 2 wifi1: moving STA f8:1e:df:dd:01:f7 to state 3 wifi1: Inserted STA f8:1e:df:dd:01:f7 wifi1: dropped frame to f8:1e:df:dd:01:f7 (unauthorized port) wifi1: ethertype == "0x6", sdata->control_port_protocol == "0x888e" wifi1: Rx A-MPDU request on f8:1e:df:dd:01:f7 tid 0 result 0 wifi1: moving STA f8:1e:df:dd:01:f7 to state 4 >> I'm seeing a lot of null packets going from my notebook, is that normal? > It looks unnecessary in this specific case, but maybe it is some kind of > reaction to Beacon frames and related to power saving (but that station > did not seem to go sleep mode within this period). Maybe that's related to SMPS being deactivated. That's fine though, let's ignore this. :) Mihai diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c index f705a0c..6b44f46 100644 --- a/src/drivers/driver_nl80211.c +++ b/src/drivers/driver_nl80211.c @@ -3189,7 +3189,7 @@ static int wpa_driver_nl80211_capa(struct wpa_driver_nl80211_data *drv) * If poll command and tx status are supported, mac80211 is new enough * to have everything we need to not need monitor interfaces. */ - drv->use_monitor = !info.poll_command_supported || !info.data_tx_status; + drv->use_monitor = 1; //!info.poll_command_supported || !info.data_tx_status;