Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 2006 11:21:37 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        jhay@meraka.org.za
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Gateworks 2348 and ath problem
Message-ID:  <20061130.112137.-432838078.imp@bsdimp.com>
In-Reply-To: <20061130153149.GA53172@zibbi.meraka.csir.co.za>
References:  <20061130142146.GA50022@zibbi.meraka.csir.co.za> <20061130.080953.-490996389.imp@bsdimp.com> <20061130153149.GA53172@zibbi.meraka.csir.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20061130153149.GA53172@zibbi.meraka.csir.co.za>
            John Hay <jhay@meraka.org.za> writes:
: On Thu, Nov 30, 2006 at 08:09:53AM -0700, M. Warner Losh wrote:
: > In message: <20061130142146.GA50022@zibbi.meraka.csir.co.za>
: >             John Hay <jhay@meraka.org.za> writes:
: > : > 
: > : > 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.
: > 
: > NetBSD marks it as __packed.  That might be a safer patch.  NetBSD
: > only uses LLC_SNAPFRAMELEN in token ring code.
: 
: Well struct llc is marked as __packed. See sys/net/if_llc.h. There is
: a union llc_un inside it that isn't and I have tried with it marked
: as __packed, but it didn't help.

I noticed that :-(.  Counting bytes tells me that it should work.
Lemme take a look to see why.  It may be the harbinger of bigger
issues...

Warner

: > It might be even better if we could catch these things at compile
: > time, but doing so may be a bit of a pita to setup (how do you know
: > all the relevant types to check).
: 
: 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?20061130.112137.-432838078.imp>