From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 14:21:51 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B15616A416 for ; Thu, 30 Nov 2006 14:21:51 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D35843CB3 for ; Thu, 30 Nov 2006 14:21:41 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 4A63333CBE; Thu, 30 Nov 2006 16:21:46 +0200 (SAST) Date: Thu, 30 Nov 2006 16:21:46 +0200 From: John Hay To: Sam Leffler Message-ID: <20061130142146.GA50022@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061130120217.GA41346@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 14:21:51 -0000 > > Ok, I built a kernel without all those options, but it didn't make a > difference. I also tried sta mode and it still looks the same. Some > new info that I have is that when I do a tcpdump on the arm box itself, > adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing > packets looks ok, but with it 2 bytes are added between the ether (802.11) > header and the ip(v6) header. Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used a lot, so I guess this is the correct way go. I nobody has anything against it, I can commit it. With this patch traffic seems to flow normally over the atheros wifi link. I have not done too much testing, but olsrd works and I can ssh to it. I see a lot of rix packets: Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1 I don't see it on our wrap and soekris boxes, but they are running 6-stable... Well I have seen it, but that was if I put the link in 11b mode, not in 11a or 11g mode. I'm using 11a at the moment. Sam, are they related to the rate changes you made recently? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org --- net80211/ieee80211_input.c.org Fri Nov 24 10:57:10 2006 +++ net80211/ieee80211_input.c Thu Nov 30 15:27:33 2006 @@ -736,8 +736,8 @@ struct ether_header *eh; struct llc *llc; - if (m->m_len < hdrlen + sizeof(*llc) && - (m = m_pullup(m, hdrlen + sizeof(*llc))) == NULL) { + if (m->m_len < hdrlen + LLC_SNAPFRAMELEN && + (m = m_pullup(m, hdrlen + LLC_SNAPFRAMELEN)) == NULL) { /* XXX stat, msg */ return NULL; } @@ -746,7 +746,7 @@ if (llc->llc_dsap == LLC_SNAP_LSAP && llc->llc_ssap == LLC_SNAP_LSAP && llc->llc_control == LLC_UI && llc->llc_snap.org_code[0] == 0 && llc->llc_snap.org_code[1] == 0 && llc->llc_snap.org_code[2] == 0) { - m_adj(m, hdrlen + sizeof(struct llc) - sizeof(*eh)); + m_adj(m, hdrlen + LLC_SNAPFRAMELEN - sizeof(*eh)); llc = NULL; } else { m_adj(m, hdrlen - sizeof(*eh)); --- net80211/ieee80211_output.c.org Fri Nov 24 10:57:10 2006 +++ net80211/ieee80211_output.c Thu Nov 30 15:22:19 2006 @@ -500,7 +500,7 @@ ieee80211_mbuf_adjust(struct ieee80211com *ic, int hdrsize, struct ieee80211_key *key, struct mbuf *m) { -#define TO_BE_RECLAIMED (sizeof(struct ether_header) - sizeof(struct llc)) +#define TO_BE_RECLAIMED (sizeof(struct ether_header) - LLC_SNAPFRAMELEN) int needed_space = hdrsize; if (key != NULL) { @@ -527,7 +527,7 @@ * We know we are called just before stripping an Ethernet * header and prepending an LLC header. This means we know * there will be - * sizeof(struct ether_header) - sizeof(struct llc) + * sizeof(struct ether_header) - LLC_SNAPFRAMELEN * bytes recovered to which we need additional space for the * 802.11 header and any crypto header. */ @@ -675,7 +675,7 @@ } /* NB: this could be optimized because of ieee80211_mbuf_adjust */ - m_adj(m, sizeof(struct ether_header) - sizeof(struct llc)); + m_adj(m, sizeof(struct ether_header) - LLC_SNAPFRAMELEN); llc = mtod(m, struct llc *); llc->llc_dsap = llc->llc_ssap = LLC_SNAP_LSAP; llc->llc_control = LLC_UI;