From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 19:39:58 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 BF59316A4C9 for ; Wed, 29 Nov 2006 19:39:58 +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 93BA143D5A for ; Wed, 29 Nov 2006 19:38:49 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 22BE933CB8; Wed, 29 Nov 2006 21:38:42 +0200 (SAST) Date: Wed, 29 Nov 2006 21:38:42 +0200 From: John Hay To: Sam Leffler Message-ID: <20061129193842.GA98569@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456DD60C.2000208@errno.com> 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: Wed, 29 Nov 2006 19:39:58 -0000 On Wed, Nov 29, 2006 at 10:48:44AM -0800, Sam Leffler wrote: > John Hay wrote: > > Hi Sam, > > > >> 3. If you want to use ath cards in the minipci slots you'll need to use > >> a newer hal than what is in CVS. I believe the tarball at > >> http://www.freebsd.org/~sam/ath_hal-20060909.tgz will work but am not > >> sure. I'm working on getting a known-good version together. > > > > I have done this, but it looks like packets (ipv6 and ipv4) are shifted > > 2 bytes: > > > > Here are part of a tcpdump on a wrap (non-arm) board showing packets > > coming from the arm board: > > tcpdump -p -i ath0 -n -s 0 -e -X ether src 00:02:6f:34:21:a2 > > ... > > 14:41:01.012648 00:02:6f:34:21:a2 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 96: 1101:fd9c:6829:597c:10:202:6fff:fe34 > 21a2:ff0e::: [|HBH] > > 0x0000: 0000 6000 0000 0028 1101 fd9c 6829 597c ..`....(....h)Y| > > 0x0010: 0010 0202 6fff fe34 21a2 ff0e 0000 0000 ....o..4!....... > > 0x0020: 0000 0000 0000 0000 0001 02ba 02ba 0028 ...............( > > 0x0030: cefe 0020 4705 c948 001c fd9c 6829 597c ....G..H....h)Y| > > 0x0040: 0010 0202 6fff fe34 21a2 0100 7338 0000 ....o..4!...s8.. > > 0x0050: 0503 .. > > 14:41:01.162480 00:02:6f:34:21:a2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 100: IP0 truncated-ip - 17578 bytes missing! 81.110.10.10 > 10.2.10.10: ip > > 0x0000: 0800 4500 0054 0027 0000 4001 516e 0a0a ..E..T.'..@.Qn.. > > 0x0010: 0a02 0a0a 0aff 0800 52b4 0203 0026 456c ........R....&El > > 0x0020: 2e95 0006 4418 0809 0a0b 0c0d 0e0f 1011 ....D........... > > 0x0030: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............! > > 0x0040: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01 > > 0x0050: 3233 3435 3637 234567 > > > > The first packet is fd9c:6829:597c:10:202:6fff:fe34:21a2 multicasting > > to ff0e::1 and the second packet is 10.10.10.2 broadcasting to > > 10.10.10.255. > > > > Doing a tcpdump on the arm itself, packets going out seems to be ok, > > but packets that it receives is shifted 2 bytes in the other direction. > > > > The low-level stuff inside the ath driver seems to work though. The > > cards are in adhoc mode and pick the other up according to "ifconfig ath0 > > list sta". > > Well you're doing better than me. I tried patching the hal.o in CVS to > deal with the ELF magic number and hit problems with DMA aborts on rx so > went off to do other work. I'm trying to get a new version together for > folks to use but am busy with real work. All my successful testing was > done w/ a version of the hal that I am not (yet) comfortable distributing. > > The above looks like something outside the driver. I forced the > ethernet header structure to be __packed to deal with a compiler issue; > do you have that change (you don't indicate what code you are running or > how you built it)? Hmmm, I'm doing what my kids do, just assume everyone knows what I do. :-) I have basically followed the instructions you posted when you merged the Gateworks/Avila code into -current. So it was -current build on the day I posted. I tried both with the hal in -current (using wackelf) and the 0909 hal you mentioned in your email. The kernel used the AVILA conf in -current changed to use the CF as root, with nfs and bootp removed and these added: options MROUTING options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPDIVERT options DUMMYNET options IPSEC options IPSEC_ESP Thinking about it, I can remove all of them and try again to make sure it isn't one of them doing it. The version of net/ethernet.h that I use is 1.27 and struct ether_header is marked as __packed. What is strange to me is that according to tcpdump on the arm box itself, the outgoing packets looks ok. > I have not tested adhoc mode. I have done some reasonable tests of sta > mode and ap mode and the only anomaly I saw was some sporadic complaints > from the tx rate control code about bogus rate indices (that I haven't > followed through on). In general operation was as expected. I did the opposite, I haven't even tried sta or ap modes. :-/ We are playing with ipv6 meshes, so my ipv4 test was just to make sure the problem wasn't an ipv6 only one. I'll try them tomorrow and see if they work better. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org