From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 15 04:50:03 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81078106564A; Wed, 15 Feb 2012 04:50:03 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from felyko.com (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6638FC1D; Wed, 15 Feb 2012 04:50:03 +0000 (UTC) Received: from [10.0.1.3] (c-50-131-226-51.hsd1.ca.comcast.net [50.131.226.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id E7E803981E; Tue, 14 Feb 2012 20:50:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rui Paulo In-Reply-To: Date: Tue, 14 Feb 2012 20:50:02 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3F2E258F-1F82-48D7-AAAD-546BCB03EDE2@freebsd.org> References: To: Monthadar Al Jaberi X-Mailer: Apple Mail (2.1257) Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Fragment and 11s inconsistency X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 15 Feb 2012 04:50:03 -0000 On 2012/02/14, at 14:14, Monthadar Al Jaberi wrote: > Hi, > > I cant verify this yet, but isn't there something wrong in current FreeBSD? > > lets say an 11s data frame need to be fragmented in ieee80211_encap: > if (addqos) > hdrsize = sizeof(struct ieee80211_qosframe); > else > hdrsize = sizeof(struct ieee80211_frame); > ... > if (vap->iv_opmode == IEEE80211_M_MBSS) { > ... > if (!IEEE80211_IS_MULTICAST(eh.ether_dhost)) > hdrsize += IEEE80211_ADDR_LEN; /* unicast are 4-addr */ > meshhdrsize = sizeof(struct ieee80211_meshcntl); > } > ... > if (__predict_true((m->m_flags & M_FF) == 0)) { > /* > * Normal frame. > */ > m = ieee80211_mbuf_adjust(vap, hdrspace + meshhdrsize, key, m); > } > M_PREPEND(m, hdrspace + meshhdrsize, M_DONTWAIT); > if (txfrag && !ieee80211_fragment(vap, m, hdrsize, > key != NULL ? key->wk_cipher->ic_header : 0, vap->iv_fragthreshold)) > goto bad; > > This means we send meshcontrol only in first segment, because we never > add meshhdrsize to hdrsize... Yes, this is a bug. Thanks for finding it. > but in mesh_input > switch (type) { > case IEEE80211_FC0_TYPE_DATA: > ... > meshdrlen = sizeof(struct ieee80211_meshcntl) + > (mc->mc_flags & 3) * IEEE80211_ADDR_LEN; > hdrspace += meshdrlen; > ... > /* > * Potentially forward packet. See table s36 (p140) > * for the rules. XXX tap fwd'd packets not for us? > */ > if (dir == IEEE80211_FC1_DIR_FROMDS || > !mesh_isucastforme(vap, wh, mc)) { > mesh_forward(vap, m, mc); > ... > if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { > m = ieee80211_defrag(ni, m, hdrspace); > if (m == NULL) { > > This seems wrong to me, how can we potentially forward before defragin > the frame? this will fail cause sub-frag have no mesh control as code > shows above. > > shouldnt the defrag code be moved above? Yes, another bug. > I am attaching a patch that both moves the defrag, validates that mesh > control is present and makes 11s data frames QoS and set Mesh control > bit present to 1 as the amendment specifies. There are some typos in your patch ("This is in constrast to Draf 4.0."). Can you please rewrite this code: + *(uint16_t *)qos = *(uint16_t *) + (((IEEE80211_IS_MULTICAST(wh->i_addr1) && + dir == IEEE80211_FC1_DIR_FROMDS)) ? + ((struct ieee80211_qosframe *)wh)->i_qos : + ((struct ieee80211_qosframe_addr4 *)wh)->i_qos); In ieee80211_encap(), why didn't you add meshhdrsize to ieee80211_fragment()? Would be nice to test this before committing. Thanks, -- Rui Paulo