From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 18:48:57 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 BE27216A403 for ; Wed, 29 Nov 2006 18:48:57 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C99243C9D for ; Wed, 29 Nov 2006 18:48:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kATImj4g020902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 10:48:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <456DD60C.2000208@errno.com> Date: Wed, 29 Nov 2006 10:48:44 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> In-Reply-To: <20061128132902.GA19150@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:48:57 -0000 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)? 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. Sam