Return-path: Received: from 30.mail-out.ovh.net ([213.186.62.213]:44694 "HELO 30.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752244AbZK2RzX (ORCPT ); Sun, 29 Nov 2009 12:55:23 -0500 Message-ID: <4B12B58A.1010808@free.fr> Date: Sun, 29 Nov 2009 18:55:22 +0100 From: Benoit PAPILLAULT MIME-Version: 1.0 To: Gertjan van Wingerde CC: rt2x00 Users List , linux-wireless@vger.kernel.org Subject: Re: [rt2x00-users] [PATCH v2] rt2x00: Further L2 padding fixes. References: <1259495278-2264-1-git-send-email-gwingerde@gmail.com> <4B128613.8060906@free.fr> <4B128C4E.5030008@gmail.com> <4B12ADA1.6010401@free.fr> <4B12B272.9090607@gmail.com> In-Reply-To: <4B12B272.9090607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Gertjan van Wingerde a ?crit : >> I fully disagree here. It's a bit of chicken-egg problem. I'm using >> monitor mode to debug other wireless drivers, so I need a tool that >> gives me the frame as it appears on the radio medium, be it invalid or >> not. And I do see lots of invalid 802.11 frames in real life that are >> generated by bogus drivers or intended to be bogus in order to crash >> wireless drivers. > > So, what do you suggest we do here? > > If we don't know what kind of data is given (clearly even the ieee80211 header > is malformed), then how can we detect what padding has been added by the hardware. > We know that the hardware puts padding between the header and the payload, but in > this case we don't even have a full header. > The only sane thing to do here is to assume that no padding has been applied at all. > > Also, do we know how mac80211 reacts to these kinds of frames, so is it safe to > pass it to mac80211? Here is my feeling : - for padding, we need to understand how the hardware behaves. My test shows that hardware uses the frame_control field to computes L2PAD flag, even if the header is malformed. Padding is always applied after 802.11 header, if the frame is long enough. Otherwise, no padding of course. I've tested on ath9k where ath9k provides FCS field and here FCS can be used to check we did proper unpadding. Using ath9k, I then found how rt2800 works. - regarding invalid frames (yes, they do exists), they must be passed to upper layers (here mac80211). If mac80211 crashes on invalid frame, then mac80211 should be fixed. A quick check in ieee80211_rx() shows that ieee80211_rx_monitor() does this work already (ie, invalid frames are forwarded to monitor interfaces and then ignored by other interfaces). Regards, Benoit