If I am not wrong, it seems that the wi driver, when in monitor mode, will skip
8 bytes of data input (filling it in with random values).
We notice in if_wi.c:
case 7:
switch (rx_frame->wi_whdr.i_fc[0] & IEEE80211_FC0_TYPE_MASK) {
Mmhh,
must have been blind... i was looking for it a very long time (without
my eyes .)
Thanks !!!
Robert
On Thu, Aug 14, 2003 at 11:21:36PM -0600, M. Warner Losh wrote:
> : Is there a better way to toggle the start address for 16 bit and 32 bit
> : cards with sysctl??
>
> u_long cbb_s
: Is there a better way to toggle the start address for 16 bit and 32 bit
: cards with sysctl??
u_long cbb_start_16_io = CBB_START_16_IO;
TUNABLE_INT("hw.cbb.start_16_io", (int *)&cbb_start_16_io);
SYSCTL_ULONG(_hw_cbb, OID_AUTO, start_16_io, CTLFLAG_RW,
&cbb_start_16_io, CBB_START_16_IO,
On Wed, Aug 13, 2003 at 01:44:15PM +0200, Robert Blacquière wrote:
> Hi,
>
> I have some problems getting wi cards working. I've traced the behavour
> of it.
>
> It assigns the first io memory 0x100-0x13f and the card fails to work.
> I plugin a second wi card and it gets 0x180-0x1bf and the ca
Hi,
I have some problems getting wi cards working. I've traced the behavour
of it.
It assigns the first io memory 0x100-0x13f and the card fails to work.
I plugin a second wi card and it gets 0x180-0x1bf and the card works.
I've 2 different cards one ASUS spacelink Prism 2.5 card and a Lucent
On Wed, Jul 16, 2003 at 03:01:15PM +0100, Bruce Cran wrote:
> wi0: bad alloc 2f2 != 1f7, cur 0 nxt 0
> wi0: device timeout
> wi0: device timeout
> wi0: timeout in wi_cmd 0x0021; event status 0x0008
i get these too with a mini pci card and 5.1. so the problem is not
related to the pci adapter.
i a
bout 2 years), my take is that the wi driver in -current is
borked useless, at least for some cards (It worked in 5.0 but broke on
the way to 5.1 IIRC).
just my .01 EUR...
--
--
Eric Anderson Systems Administrator Centaur
at came up there didn't help).
Since I can use the cards perfectly between two 4.8 boxes (and have
been for about 2 years), my take is that the wi driver in -current is
borked useless, at least for some cards (It worked in 5.0 but broke on
the way to 5.1 IIRC).
just my .01 EUR...
> I
I've just reinstalled a 'desktop server' from FreeBSD 4.8 to -CURRENT, and
am finding quite a few problems with the 802.11b driver.I'm trying to use
it as a access point, so I've tried setting the flag0,adhoc mediaopt, since
ibss-master which I had used under 4.8 didn't work. This appeared to
Network Associates Laboratories
On Sat, 21 Jun 2003, BSDVault wrote:
> A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear
> MA-311 card that supports HostAP mode. The issue is that I get a busy bit
> error. The exact error starts with the following.. THIS ONLY
> Date: Sat, 21 Jun 2003 00:32:45 -0400
> From: BSDVault <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear
> MA-311 card that supports HostAP mode. The issue is that I get a busy bit
> error.
A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear
MA-311 card that supports HostAP mode. The issue is that I get a busy bit
error. The exact error starts with the following.. THIS ONLY OCCURS WHEN
WEP IS ENABLED:
wi0: timeout in wi_seek to fc00/0; last status 800b
We then
I've just committed the right fix for this (which is to nuke the bogus
KASSERT). I have one or two other fixes in the pipe for lucent cards,
but had hoped to get them 'perfect' rather than 'a lot better' before
committing them. Since my time has been short, I'll go ahead and try
to commit the 'be
In message: <[EMAIL PROTECTED]>
"Sam Leffler" <[EMAIL PROTECTED]> writes:
: > * Alfred Perlstein <[EMAIL PROTECTED]> [030316 21:19] wrote:
: > > um..
: > >
: > ...
: > 840 _FLAGS_OUTRANGE) {
: > 841 WI_UNLOCK(sc);
: > 842 return;
: > 843
> * Alfred Perlstein <[EMAIL PROTECTED]> [030316 21:19] wrote:
> > um..
> >
> ...
> 840 _FLAGS_OUTRANGE) {
> 841 WI_UNLOCK(sc);
> 842 return;
> 843 }
> 844 KASSERT((ifp->if_flags & IFF_OACTIVE) == 0,
> 845 ("wi_
* Alfred Perlstein <[EMAIL PROTECTED]> [030316 21:19] wrote:
> um..
>
...
840 _FLAGS_OUTRANGE) {
841 WI_UNLOCK(sc);
842 return;
843 }
844 KASSERT((ifp->if_flags & IFF_OACTIVE) == 0,
845 ("wi_start: if_flags %x\
um..
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc027719a in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc0277403 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0227ac2 in wi_start (ifp=0xc1985000) at /usr/src/sys/dev/wi/if_wi.c:845
#4 0xc02dd413
f undefined references to various
> > ieee80211_*. Looks like I might be missing a header file.
>
> from UPDATING:
>
> 20030115:
> A new version of the wi driver has been imported into the tree.
> One now must have device wlan in the config file for it to operate
A new version of the wi driver has been imported into the tree.
One now must have device wlan in the config file for it to operate
properly.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0
I am trying to upgrade my main laptop system to CURRENT, but the kernel
fails to build. I get lots of undefined references to various
ieee80211_*. Looks like I might be missing a header file.
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-p
Can you run a small test? Can you build a kernel w/o wi? Further,
can you do
sysctl hw.pccard.cis_debug=1
before you insert the card (or put the hw=1 part in
/boot/loader.conf) and send me the result?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curre
Hello,
I encounter a strange problem with an old rs-232 serial pccard on current (just
cvsup'ed).
The card works quite well on 5.0-RELEASE, but it it is detected as a wlan
card on current, and the system attempts to run the wi driver. This calls ther
debugger, and the (continue) command r
> dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's. This
> required the application know whether it was talking to a
> prims/wavelan/symbol card so was replaced by WI_RID_SCAN_APS which
> provides a device-independent interface. I changed wicontrol to
> deal with this; it would be good
> > : dstumbler breaks; on startup it reports
> > : "unable to ioctl device socket: Input/output error".
> >
> > As root or no?
>
> I have a rebuilt system finally that I could test this against and I'm
> actually getting a different error message on startup of dstumbler:
>
> error: unable to i
> : dstumbler breaks; on startup it reports
> : "unable to ioctl device socket: Input/output error".
>
> As root or no?
I have a rebuilt system finally that I could test this against and I'm
actually getting a different error message on startup of dstumbler:
error: unable to ioctl device soc
> : dstumbler breaks; on startup it reports
> : "unable to ioctl device socket: Input/output error".
>
> As root or no?
As root, with interface up and configured.
Magnus
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> A couple things regarding this new wireless driver - the
> wepkey option to ifconfig no longer seems to work; I get a
> "SIOCS80211: Invalid argument". Secondly and more importantly,
> even when the wepkey is set via wicontrol, I can't seem to get
> any connectivity at all anymore.
>
I fixed th
A couple things regarding this new wireless driver - the
wepkey option to ifconfig no longer seems to work; I get a
"SIOCS80211: Invalid argument". Secondly and more importantly,
even when the wepkey is set via wicontrol, I can't seem to get
any connectivity at all anymore.
ifconfig wi0:
flags
: dstumbler breaks; on startup it reports
: "unable to ioctl device socket: Input/output error".
As root or no?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> > NB the new wi(4) is probably also an issue for ports/net/bsd-airtools,
> > to be resolved or documented before MFC. (copied maintainer)
>
> Why, did they not work/build after the commit? I didn't try all the ports
> that depend on the driver but the API (ioctls) should be unchanged except
> f
Hi Sam,
The new "device wlan" option is pushing the kern.flp over the limit
during make release. Maybe it can be moved to mfsroot.flp?
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the m
> On Thu, 16 Jan 2003, Sam Leffler wrote:
> >...
> > to your config files. This probably belongs in UPDATING.
>
> NB the new wi(4) is probably also an issue for ports/net/bsd-airtools,
> to be resolved or documented before MFC. (copied maintainer)
Why, did they not work/build after the commit?
On Thu, 16 Jan 2003, Sam Leffler wrote:
>...
> to your config files. This probably belongs in UPDATING.
NB the new wi(4) is probably also an issue for ports/net/bsd-airtools,
to be resolved or documented before MFC. (copied maintainer)
Magnus
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
Sorry, for the new wi driver you need to add:
device wlan
to your config files. This probably belongs in UPDATING.
Sam
- Original Message -
From: "Matt Haught" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 9:59 PM
Subject
I just committed a new version of the wi driver. This driver is very
different in that it depends on a common core implementation of the 802.11
state machine and mgmt protocols. There should be no visible differences
(for now) between the old driver and the new but beware. If you encounter
below, sorry if anyone started looking into the problem.
Will try different machine and see what happens
Jason
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Jason
Sent: Friday, April 12, 2002 7:38 AM
To: Freebsd Current
Subject: WI Driver issues, compi
wi driver (which I believe is the driver for my
card, with is prism 2 based) (listed at the very bottom is the content
of my kernel config file). The card is a PCI card which believe is realy
an isa card with a bridge to guts of the pcmcia wireless adapter tacked
onto it. When I run the compile
wi driver (which I believe is the driver for my
card, with is prism 2 based) (listed at the very bottom is the content
of my kernel config file). The card is a PCI card which believe is realy
an isa card with a bridge to guts of the pcmcia wireless adapter tacked
onto it. When I run the compile
In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: %i is because I lost a flamewar to get %i added to kernel printf,
: it has been fixed.
I was thinking of just committing the one line change and avoiding the
flamewar :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
In message <[EMAIL PROTECTED]> "Alan Edmonds" writes:
: I'm not sure if the %i is a problem the kernel printf or
I didn't checkin the small patch to the kernel printf for %i support
yet. Ignore it for now.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
* Alan Edmonds <[EMAIL PROTECTED]> [011208 17:42] wrote:
>
> Here's a data point for you Warner. I have an Intel PRO 2011
> 802.11b adapter (Symbol Spectrum24 OEM) card. Works just fine
> under -current and the wi driver. After a yesterday's rebuild
> I notice
Here's a data point for you Warner. I have an Intel PRO 2011
802.11b adapter (Symbol Spectrum24 OEM) card. Works just fine
under -current and the wi driver. After a yesterday's rebuild
I noticed the wi driver displaying this on booting.
$ dmesg
FreeBSD 5.0-CURRENT #3: Sat Dec 8 19
Thanks Yamamoto san ! This works really rather nicely and has reduce the
number of tx errors tremendously (Though not completely and xmit
failed/device timeout is still there).
Thanks !
Dw.
On Mon, 11 Dec 2000, YAMAMOTO Shigeru wrote:
> Hi, all.
> I send a patch for wi driver.
>
[[ Followups to freebsd-mobile please ]]
In message <[EMAIL PROTECTED]> YAMAMOTO Shigeru writes:
: I send a patch for wi driver.
Thank you yamamoto-san. I'll have to see if this works with the prism
II based boards that I have here that aren't supported by the an
driver.
: #C
Hi, all.
I send a patch for wi driver.
Some cases, we have errors,
'wi0: tx buffer allocation failed'
and
'wi0: mgmt. buffer allocation failed'
Thease errors are caused by bugs in wi driver.
#Current wi driver has initialization and resource allocation mistakes.
And thi
Blaz Zupan writes:
| I'm trying to make the wi (WaveLan) driver work in -current. It appears
| that some changes to the pccard code have broken it (or that I can't find
| out how to configure it correctly, although I have done it under 3.3 with
| success). I have this in my config file:
It needs
I'm trying to make the wi (WaveLan) driver work in -current. It appears
that some changes to the pccard code have broken it (or that I can't find
out how to configure it correctly, although I have done it under 3.3 with
success). I have this in my config file:
controller card0
controller
47 matches
Mail list logo
