Date: Wed, 29 Nov 2006 10:48:44 -0800 From: Sam Leffler <sam@errno.com> To: John Hay <jhay@meraka.org.za> Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem Message-ID: <456DD60C.2000208@errno.com> In-Reply-To: <20061128132902.GA19150@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456DD60C.2000208>