Return-path: Received: from cpsmtpm-eml105.kpnxchange.com ([195.121.3.9]:60788 "EHLO CPSMTPM-EML105.kpnxchange.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751416AbZK2RmF (ORCPT ); Sun, 29 Nov 2009 12:42:05 -0500 Message-ID: <4B12B272.9090607@gmail.com> Date: Sun, 29 Nov 2009 18:42:10 +0100 From: Gertjan van Wingerde MIME-Version: 1.0 To: Benoit PAPILLAULT 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> In-Reply-To: <4B12ADA1.6010401@free.fr> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 11/29/09 18:21, Benoit PAPILLAULT wrote: > Gertjan van Wingerde a ?crit : >>> 2. If we receive a QoS DATA frame whose header_length is 26 according to >>> frame_control, but skb->len = 20, then ieee80211_get_hdrlen_from_skb() >>> will returns hdrlen = 0 based on the value of skb->len. However, this >>> function does not know if skb->len includes said padding or not, or some >>> other padding! (On RX, rt2870 usb frames are also padded at the end!). >> >> But, in that case we have received an invalid frame anyway, so the padding >> doesn't really matter. > > 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? --- Gertjan.