Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 2006 21:38:42 +0200
From:      John Hay <jhay@meraka.org.za>
To:        Sam Leffler <sam@errno.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Gateworks 2348 and ath problem
Message-ID:  <20061129193842.GA98569@zibbi.meraka.csir.co.za>
In-Reply-To: <456DD60C.2000208@errno.com>
References:  <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061129193842.GA98569>