wi driver reads wrong first 8 bytes when in monitor mode in data packets
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) {
case IEEE80211_FC0_TYPE_DATA:
hdrlen = WI_DATA_HDRLEN;
data is then read according to the hdrlen offset.
if (wi_read_bap(sc, fid, hdrlen, mtod(m, caddr_t) + hdrlen,
datlen + 2) == 0) {
in if_wavelan_ieee.h:
#define WI_DATA_HDRLEN 0x44
#define WI_MGMT_HDRLEN 0x3C
#define WI_CTL_HDRLEN 0x3C
we notice that data frames seem to have an 8 byte "header" extra
we then notice
/*
* all data packets have a snap (sub-network access protocol) header that
* isn't entirely definied, but added for ethernet compatibility.
*/
struct wi_snap_frame {
u_int16_t wi_dat[3];
u_int16_t wi_type;
};
(it is 8 bytes)
It seems like if the llc/snap is treated as a "802.11 header" per se and not act
ual data. (Maybe this was the mentality of the developers).
Under "normal" circumstances this is ok, since many people do not care about sna
p/llc when in monitor mode. Infact, the ip header will be just fine.
However when auditing wep, those 8 bytes are crucial (since the first 3+1 bytes
contain IV information) and the first few bytes of cyphertext are normally used
in known plaintext attacks. Infact, bsd-airtools will probably not work at all.
I am running:
FreeBSD tribal.sorbonet.org 5.2-BETA FreeBSD 5.2-BETA #5: Wed Nov 26 05:24:11 GM
T 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SORBO i386
A very basic patch which seems to works is:
if_wavelan_ieee.h.diff:
** CUT
*** if_wavelan_ieee.h.orig Wed Nov 26 06:00:58 2003
--- if_wavelan_ieee.h Wed Nov 26 05:08:08 2003
***
*** 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x44
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
--- 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x3C
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
** CUT
Andrea Bittau
[EMAIL PROTECTED]
http://www.darkircop.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with wi driver.
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_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,
> "Starting ioport for 16-bit cards");
>
>
> so hw.cbb.start_16_io
>
> Warner
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?
OpenBSD: He guys you left some holes out there!
pgp0.pgp
Description: PGP signature
Re: problems with wi driver.
: 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,
"Starting ioport for 16-bit cards");
so hw.cbb.start_16_io
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with wi driver.
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 card works. > > I've 2 different cards one ASUS spacelink Prism 2.5 card and a Lucent > Orinoco Gold card. It does not matter which sequence i follow the first > card will fail but the second works. > > some debug info: > Hi, I fixed it somehow illegal by changing the src/sys/dev/pccbb/pccbb.c line 121: #define CBB_START_16_IO 0x100 to #define CBB_START_16_IO 0x140 And now my wireless cards work. Is there a better way to toggle the start address for 16 bit and 32 bit cards with sysctl?? dmesg output with debug info: CBB EVENT 0x6 Waking up thread Status is 0x3510 cbb0: card inserted: event=0x, state=3510 cbb_pcic_socket_enable: cbb0: cbb_power: 5V start (3000) < sc->membase (4000) end () > sc->memlimit (403f) pcib2: device pccard0 requested decoded memory range 0x3000-0x pccard0: CIS version PC Card Standard 5.0 pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, pccard0: Manufacturer code 0x156, product 0x2 pccard0: function 0: network adapter, ccr addr 3e0 mask 1 pccard0: function 0, config table entry 1: I/O card; irq mask ; iomask 6, io space 0-3f; io16 irqpulse irqlevel pcib2: device pccard0 requested decoded I/O range 0x140-0x cbb_pcic_socket_enable: cbb0: cbb_power: 0V cbb0: cbb_power: 5V start (3000) < sc->membase (4000) end () > sc->memlimit (403f) pcib2: device pccard0 requested decoded memory range 0x3000-0x wi0: at port 0x180-0x1bf irq 11 function 0 co nfig 1 on pccard0 pcib2: device wi0 requested decoded I/O range 0x180-0x1bf pcib2: device pccard0 requested decoded I/O range 0x180-0x1bf pcib2: device wi0 requested decoded I/O range 0x180-0x1bf wi0: 802.11 address: 00:02:2d:03:69:67 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (6.6.1) wi0: bpf attached wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: bad alloc 3e6 != ff, cur 0 nxt 0 acpi_acad0: acline initialization done, tried 7 times acpi_tz0: _AC2: temperature 53.0 >= setpoint 40.0 acpi_tz0: switched from NONE to _AC2: 53.0C Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
problems with wi driver.
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 Orinoco Gold card. It does not matter which sequence i follow the first card will fail but the second works. some debug info: Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x2 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:08 bifur kernel: CBB EVENT 0x6 Aug 12 22:23:08 bifur kernel: Waking up thread Aug 12 22:23:45 bifur kernel: Status is 0x3910 Aug 12 22:23:45 bifur kernel: cbb1: card inserted: event=0x, state=3910 Aug 12 22:23:45 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 3V Aug 12 22:23:45 bifur kernel: start (3000) < sc->membase (4000) Aug 12 22:23:45 bifur kernel: end () > sc->memlimit (403f) Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded memory ran ge 0x3000-0x Aug 12 22:23:45 bifur kernel: pccard1: CIS version PC Card Standard 5.0 Aug 12 22:23:45 bifur kernel: pccard1: CIS info: ASUS, 802_11b_PC_CARD_25, Versi on 01.00, Aug 12 22:23:45 bifur kernel: pccard1: Manufacturer code 0x2aa, product 0x2 Aug 12 22:23:45 bifur kernel: pccard1: function 0: network adapter, ccr addr 3e0 mask 1 Aug 12 22:23:45 bifur kernel: pccard1: function 0, config table entry 1: I/O card; irq mask ; iomask 6, iospace 0-3f; io16 irqpulse irqlevel Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded I/O range 0x100-0x Aug 12 22:23:45 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 0V Aug 12 22:23:45 bifur kernel: cbb1: cbb_power: 3V Aug 12 22:23:45 bifur kernel: start (3000) < sc->membase (4000) Aug 12 22:23:45 bifur kernel: end () > sc->memlimit (403f) Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded memory range 0x3000-0x Aug 12 22:23:45 bifur kernel: wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 Aug 12 22:23:45 bifur kernel: pcib2: device wi0 requested decoded I/O range 0x10 0-0x13f Aug 12 22:23:45 bifur kernel: pcib2: device pccard1 requested decoded I/O range 0x100-0x13f Aug 12 22:23:45 bifur kernel: pcib2: device wi0 requested decoded I/O range 0x10 0-0x13f Aug 12 22:23:45 bifur kernel: wi0: timeout in wi_cmd 0x0021; event status 0x8000 Aug 12 22:23:45 bifur kernel: wi0: 802.11 address: 00:e0:18:bd:78:7e Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: using Unknown Lucent chipwi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: Aug 12 22:23:45 bifur kernel: wi0: Lucent Firmware: Station (0.0.0) Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: WI_RID_OWN_CHNL failed, using first channel! Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: wi_cmd: busy bit won't clear. Aug 12 22:23:45 bifur kernel: wi0: bpf attached Aug 12 22:23:45 bifur kernel: wi0: bpf attached Aug 12 22:23:45 bifur kernel: wi0: 11b rates: Aug 12 22:23:48 bifur kernel: CBB EVENT 0x6 Aug 12 22:23:48 bifur kernel: Waking up thread Aug 12 22:23:51 bifur kernel: Status is 0x3510 Aug 12 22:23:51 bifur kernel: cbb0: card inserted: event=0x, state=3510 Aug 12 22:23:51 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 5V Aug 12 22:23:51 bifur kernel: start (3000) < sc->membase (4000) Aug 12 22:23:51 bifur kernel: end () > sc->memlimit (403f) Aug 12 22:23:51 bifur kernel: pcib2: device pccard0 requested decoded memory range 0x3000-0x Aug 12 22:23:51 bifur kernel: pccard0: CIS version PC Card Standard 5.0 Aug 12 22:23:51 bifur kernel: pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, Aug 12 22:23:51 bifur kernel: pccard0: Manufacturer code 0x156, product 0x2 Aug 12 22:23:51 bifur kernel: pccard0: function 0: network adapter, ccr addr 3e0 mask 1 Aug 12 22:23:51 bifur kernel: pccard0: function 0, config table entry 1: I/O card; irq mask ; iomask 6, iospace 0-3f; io16 irqpulse irqlevel Aug 12 22:23:51 bifur kernel: pcib2: device pccard0 requested decoded I/O range 0x100-0x Aug 12 22:23:51 bifur kernel: cbb_pcic_socket_enable: Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 0V Aug 12 22:23:51 bifur kernel: cbb0: cbb_power: 5V Aug 12 22:23:51 bifur kernel: start (3000) < sc->membase (4000) Aug
Re: errors using wi driver in -CURRENT
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 also get the 'busy bit won't clear' errors, reports of that showed up on -mobile before i think. i did not have this problem with stable. i did not look into it, for i have other things to worry about right now. also, all i could do would be suppling bug reports, i do now have the knowledge for fixing this myself. cheers, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: errors using wi driver in -CURRENT
I only seem to have problems when trying to connect to access points or devices with authmode set to shared, but when I set everything to OPEN, but still use a WEP key, I can make it work (as a client, not as an access point). I would agree something is seriously borked and really wish the authmode stuff would work. I'm willing to help in any way I can, but I'm not much of a C programmer or driver hacker to begin work on it myself.. Eric Soeren Schmidt wrote: It seems Bruce Cran wrote: Just to chime in here, I've spent 2 weeks of various trial and errors to get two Lucent Wavelan's (one 4.8, one -current) to talk to each other. Dispite my more or less futile experiments this would not work no matter what (even asking on -mobile and trying what 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... -- -- Eric Anderson Systems Administrator Centaur Technology Attitudes are contagious, is yours worth catching? -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: errors using wi driver in -CURRENT
It seems Bruce Cran wrote: Just to chime in here, I've spent 2 weeks of various trial and errors to get two Lucent Wavelan's (one 4.8, one -current) to talk to each other. Dispite my more or less futile experiments this would not work no matter what (even asking on -mobile and trying what 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'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 work, > but other computers couldn't connect. Now, using just 'adhoc' other > computers can connect, but whenever any use the network, the rate shown in > 'ifconfig wi0' drops to 2MBit/s and I only get about 100KB/s bandwidth. Also, > whenever I try to reset the media and/or mediaopt settings using eg > 'ifconfig wi0 media DS/11Mbps mediaopt adhoc', the driver or card seems > to go a bit buggy, with messages like: > > wi0: bad alloc 2f2 != 1f7, cur 0 nxt 0 > wi0: device timeout > wi0: device timeout > wi0: timeout in wi_cmd 0x0021; event status 0x0008 > > when I run 'ifconfig' wi0 output stalls for a few seconds, locking the system, > while another kernel error message appears. I'm using the card with a > PCI converter card, and the card itself is: > > wi0: at port 0x100-0x13f irq 11 function 0 config 1 on > pccard0 > wi0: 802.11 address: 00:01:02:03:04:05 > wi0: using Lucent Technologies, WaveLAN/IEEE > wi0: Lucent Firmware: Station (8.36.1) > wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > on initial configuration, the Media line of ifconfig is: > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps (none) > > when I was recently getting ~35KB/s to the card, the 'OACTIVE' flag on the > interface was set. > > I can provide more information which can help in diagnosing the problem, if > required. > > -- > Bruce Cran > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
errors using wi driver in -CURRENT
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 work, but other computers couldn't connect. Now, using just 'adhoc' other computers can connect, but whenever any use the network, the rate shown in 'ifconfig wi0' drops to 2MBit/s and I only get about 100KB/s bandwidth. Also, whenever I try to reset the media and/or mediaopt settings using eg 'ifconfig wi0 media DS/11Mbps mediaopt adhoc', the driver or card seems to go a bit buggy, with messages like: wi0: bad alloc 2f2 != 1f7, cur 0 nxt 0 wi0: device timeout wi0: device timeout wi0: timeout in wi_cmd 0x0021; event status 0x0008 when I run 'ifconfig' wi0 output stalls for a few seconds, locking the system, while another kernel error message appears. I'm using the card with a PCI converter card, and the card itself is: wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:01:02:03:04:05 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.36.1) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps on initial configuration, the Media line of ifconfig is: media: IEEE 802.11 Wireless Ethernet DS/11Mbps (none) when I was recently getting ~35KB/s to the card, the 'OACTIVE' flag on the interface was set. I can provide more information which can help in diagnosing the problem, if required. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wi driver has WEP issues on both 5.0 and 5.1
I've seen this on my older Wavelan card, but not my more recent PRISM card. If I run with WITNESS compiled in, I don't see it, which suggests a timing issue. This came up at USENIX a couple of times and I know Scott and Warner were discussing potential sources and fixes; Scott noticed there were a lot of card resets in the new code not present previously, so one theory was that we needed a delay for a bit to settle during the reset. I've CC'd Warner and Scott to bug them. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] 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 OCCURS WHEN > WEP IS ENABLED: > > wi0: timeout in wi_seek to fc00/0; last status 800b > > We then move on to : > > wi0: wi_cmd: busy bit won't clear. > > This seems to cycle until the next error: > > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: mgmt. Buffer allocation failed > > Then back through the entire error sequence again. Eventually the box will > freeze as these errors cycle and then free up again when it starts back at > the timeout error. I was hopeful that the new wi driver in 5.1 would > address this problem as I know several persons with Prism chipsets that have > this very same issue on 5.0 and 5.1. > > Please respond directly as I am not on -current mailing list. > > Thanks > > Ray > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wi driver has WEP issues on both 5.0 and 5.1
> 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. 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 move on to : > > wi0: wi_cmd: busy bit won't clear. > > This seems to cycle until the next error: > > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: mgmt. Buffer allocation failed > > Then back through the entire error sequence again. Eventually the box will > freeze as these errors cycle and then free up again when it starts back at > the timeout error. I was hopeful that the new wi driver in 5.1 would > address this problem as I know several persons with Prism chipsets that have > this very same issue on 5.0 and 5.1. > > Please respond directly as I am not on -current mailing list. I have seen the same ting, but only when three is an attempt to associate with an AP that has a different WEP key. It can happen with either 40 or 108 bit encryption. As a result, I now build my kernel without the wi driver and only load it when I need it. I don't know if Warner has seen this. Cross-post to FreeBSD lists is frowned upon, but I am tempted to send this to mobile. It's where these issues are most heavily discussed. I'm not sure if I ever saw this with V4.6 or 4.7. I have seen it on V5 since I moved to current late last year. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wi driver has WEP issues on both 5.0 and 5.1
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 move on to : wi0: wi_cmd: busy bit won't clear. This seems to cycle until the next error: wi0: failed to allocate 1594 bytes on NIC wi0: tx buffer allocation failed wi0: mgmt. Buffer allocation failed Then back through the entire error sequence again. Eventually the box will freeze as these errors cycle and then free up again when it starts back at the timeout error. I was hopeful that the new wi driver in 5.1 would address this problem as I know several persons with Prism chipsets that have this very same issue on 5.0 and 5.1. Please respond directly as I am not on -current mailing list. Thanks Ray ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wi driver
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 'better' ones today and work towards making those more perfect in the fullness of time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wi driver
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 }
: > 844 KASSERT((ifp->if_flags & IFF_OACTIVE) == 0,
: > 845 ("wi_start: if_flags %x\n", ifp->if_flags));
: > 846
: > 847 memset(&frmhdr, 0, sizeof(frmhdr));
: >
: > >
: > > What's up here?
: >
: > It's a race, we shouldn't be inspecting the ifp without a lock.
: >
: > I think this kassert should be removed.
: >
: > Do you guys concurr?
:
: Warner has this pending with some other fixes; perhaps he can accelerate
: doing the commit? The assert is actually just bogus (if_start can be called
: under certain conditions with IFF_OACTIVE set.
This is part of my commit. The KASSERT is totally bogus.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: wi driver
> * 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\n", ifp->if_flags));
> 846
> 847 memset(&frmhdr, 0, sizeof(frmhdr));
>
> >
> > What's up here?
>
> It's a race, we shouldn't be inspecting the ifp without a lock.
>
> I think this kassert should be removed.
>
> Do you guys concurr?
Warner has this pending with some other fixes; perhaps he can accelerate
doing the commit? The assert is actually just bogus (if_start can be called
under certain conditions with IFF_OACTIVE set.
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: wi driver
* 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\n", ifp->if_flags));
846
847 memset(&frmhdr, 0, sizeof(frmhdr));
>
> What's up here?
It's a race, we shouldn't be inspecting the ifp without a lock.
I think this kassert should be removed.
Do you guys concurr?
--
-Alfred Perlstein [EMAIL PROTECTED]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
wi driver
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 in ieee80211_mgmt_output (ifp=0xc1985000, ni=0xc1985478,
m=0xc0ba8800, type=160) at /usr/src/sys/net/if_ieee80211subr.c:550
#5 0xc02df439 in ieee80211_send_disassoc (ic=0xc1985000, ni=0xc1985478,
type=160, reason=8) at /usr/src/sys/net/if_ieee80211subr.c:1668
#6 0xc02e05b2 in ieee80211_new_state (ifp=0xc1985000, nstate=8, mgt=-1)
at /usr/src/sys/net/if_ieee80211subr.c:2262
#7 0xc0229313 in wi_info_intr (sc=0xc1985000)
at /usr/src/sys/dev/wi/if_wi.c:1531
#8 0xc0226ffd in wi_intr (arg=0xc1985000) at /usr/src/sys/dev/wi/if_wi.c:599
#9 0xc01af153 in pccard_intr (arg=0xc1911900)
at /usr/src/sys/dev/pccard/pccard.c:1196
#10 0xc01b51a8 in cbb_intr (arg=0xc0b98200)
at /usr/src/sys/dev/pccbb/pccbb.c:1046
(kgdb) up
#3 0xc0227ac2 in wi_start (ifp=0xc1985000) at /usr/src/sys/dev/wi/if_wi.c:845
845 ("wi_start: if_flags %x\n", ifp->if_flags));
(kgdb) list
840 if (sc->sc_flags & WI_FLAGS_OUTRANGE) {
841 WI_UNLOCK(sc);
842 return;
843 }
844 KASSERT((ifp->if_flags & IFF_OACTIVE) == 0,
845 ("wi_start: if_flags %x\n", ifp->if_flags));
846
847 memset(&frmhdr, 0, sizeof(frmhdr));
848 cur = sc->sc_txnext;
849 for (;;) {
(kgdb) print *ifp
$1 = {if_softc = 0xc1985000, if_name = 0xc0409bbd "wi", if_link = {
tqe_next = 0x0, tqe_prev = 0xc0b99208}, if_addrhead = {
tqh_first = 0xc1982400, tqh_last = 0xc1982060}, if_klist = {
slh_first = 0x0}, if_pcount = 0, if_bpf = 0xc1911800, if_index = 3,
if_unit = 0, if_timer = 1, if_nvlans = 0, if_flags = 35907,
if_capabilities = 0, if_capenable = 0, if_ipending = 0, if_linkmib = 0x0,
if_linkmiblen = 0, if_data = {ifi_type = 6 '\006', ifi_physical = 0 '\0',
ifi_addrlen = 6 '\006', ifi_hdrlen = 24 '\030', ifi_recvquota = 0 '\0',
ifi_xmitquota = 0 '\0', ifi_mtu = 1500, ifi_metric = 0,
ifi_baudrate = 1100, ifi_ipackets = 18096, ifi_ierrors = 0,
ifi_opackets = 11877, ifi_oerrors = 47, ifi_collisions = ,
ifi_ibytes = 4567681, ifi_obytes = 1120601, ifi_imcasts = 6436,
ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_hwassist = 0,
ifi_unused = 0, ifi_lastchange = {tv_sec = 1047770516, tv_usec = 70680}},
if_multiaddrs = {tqh_first = 0xc18b35a0, tqh_last = 0xc18b3580},
if_amcount = 0, if_output = 0xc02db640 ,
if_input = 0xc02dbd30 , if_start = 0xc0227a10 ,
if_done = 0, if_ioctl = 0xc0228230 ,
if_watchdog = 0xc02280d0 , if_poll_recv = 0, if_poll_xmit = 0,
if_poll_intren = 0, if_poll_slowinput = 0, if_init = 0xc0227060 ,
if_resolvemulti = 0xc02dc520 , if_snd = {ifq_head = 0x0,
ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 50, ifq_drops = 0, ifq_mtx = {
mtx_object = {lo_class = 0xc045f6e0, lo_name = 0xc0409bbd "wi",
lo_type = 0xc041619d "if send queue", lo_flags = 196608, lo_list = {
tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4,
mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc1985108},
mtx_contested = {le_next = 0x0, le_prev = 0x0}}}, if_poll_slowq = 0x0,
if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc198511c},
if_broadcastaddr = 0xc0467140 "ÿÿ", if_label = {l_flags = 0,
l_perpolicy = {{l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}, {
l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0
What's up here?
--
-Alfred Perlstein [EMAIL PROTECTED]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't build wi driver in current
> Date: Fri, 14 Mar 2003 12:38:52 -0800 > From: Brooks Davis <[EMAIL PROTECTED]> > > > On Fri, Mar 14, 2003 at 12:31:31PM -0800, Kevin Oberman wrote: > > 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. > > 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 > properly. > > -- Brooks > How embarrassing! I even remembered seeing this, but looked at GENERIC and didn't find it, so I though I must have been thinking of something else. Now when I look at GENERIC, I see it. Thanks! R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't build wi driver in current
On Fri, Mar 14, 2003 at 12:31:31PM -0800, Kevin Oberman wrote: > 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. 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 properly. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Can't build wi driver in current
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-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel if_wi.o: In function `wi_attach': if_wi.o(.text+0x70d): undefined reference to `ieee80211_rate2media' if_wi.o(.text+0x84d): undefined reference to `ieee80211_ifattach' if_wi.o: In function `wi_detach': if_wi.o(.text+0x903): undefined reference to `ieee80211_ifdetach' if_wi.o: In function `wi_stop': if_wi.o(.text+0x14d5): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_start': if_wi.o(.text+0x1904): undefined reference to `ieee80211_encap' if_wi.o(.text+0x1942): undefined reference to `ieee80211_find_node' if_wi.o(.text+0x19b8): undefined reference to `ieee80211_wep_crypt' if_wi.o: In function `wi_watchdog': if_wi.o(.text+0x1e74): undefined reference to `ieee80211_new_state' if_wi.o(.text+0x1e8c): undefined reference to `ieee80211_watchdog' if_wi.o: In function `wi_ioctl': if_wi.o(.text+0x22f9): undefined reference to `ieee80211_ioctl' if_wi.o: In function `wi_media_change': if_wi.o(.text+0x23af): undefined reference to `ieee80211_media2rate' if_wi.o: In function `wi_media_status': if_wi.o(.text+0x256c): undefined reference to `ieee80211_rate2media' if_wi.o: In function `wi_sync_bssid': if_wi.o(.text+0x2666): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_rx_intr': if_wi.o(.text+0x2a5d): undefined reference to `ieee80211_input' if_wi.o: In function `wi_info_intr': if_wi.o(.text+0x2faf): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_get_cfg': if_wi.o(.text+0x3ad0): undefined reference to `ieee80211_cfgget' if_wi.o: In function `wi_set_cfg': if_wi.o(.text+0x409b): undefined reference to `ieee80211_cfgset' if_wi.o: In function `wi_dump_pkt': if_wi.o(.text+0x5538): undefined reference to `ieee80211_dump_pkt' *** Error code 1 I thought I might have hit an update in progress, but a new cvsup saw nothing. (Might be the first time I have ever done a cvsup to . and not gotten a single file.) Any ideas? Anyone else seeing it? R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: old serial RS-232 pccard and wi driver.
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-current" in the body of the message
old serial RS-232 pccard and wi driver.
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 reboot the machine, and that at boot, or after any card insertion. I don't know if the machine is very relevant but ... DELL Inspiron 8000 laptop.. The acpi is loaded, and seems to work. An Adaptec apa-1460 pccard works well too, (the IRQ (11) is correctly handled). Here is the message at boot: pccard1: CIS checksum failed. wi0: "Socket Communications Low Power wlan card" at port 0x100-0x107 irq 11= fun1 wi0 init failed. panic block: (sleep mutex" wi0 not locked @ /usr/src-current/src/sys/devwi/= if_w3 debugger (panic) stopped at: debugger+0x54: xchgl %ebx,in_debugger.0. Sorry if I have forgotten something. Best regards raoul [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
> 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 if dstumbler did likewise. > Otherwise I can look at adding a backwards compatibility entry for > WI_RID_SCAN_REQ. I've updated the sources with the new wlan request type and I'm not getting anyfurther than before. All of the bsd-airtools have all kinds of nifty hacks to support the various interfaces and quirks of each of the cards. I think I'm going to dable with the various bsd-airtools and update them to use the same interface that wicontrol does and see if I can't kill off as many card specific quirks as I can. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
> > : 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 socket: Invalid argument > > From ktrace: > > 43042 dstumbler CALL sigaction(0x12,0x280b5850,0) > 43042 dstumbler RET sigaction 0 > 43042 dstumbler CALL socket(0x2,0x2,0) > 43042 dstumbler RET socket 3 > 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) > 43042 dstumbler RET ioctl 0 > 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) > 43042 dstumbler RET ioctl -1 errno 22 Invalid argument > 43042 dstumbler CALL sigaction(0x12,0x280b5838,0x280b5850) > 43042 dstumbler RET sigaction 0 > 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) > 43042 dstumbler RET poll 0 > 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) > 43042 dstumbler RET poll 0 > 43042 dstumbler CALL write(0x1,0x806,0x5e) > 43042 dstumbler GIO fd 1 wrote 94 bytes >"\^[[52;22H\^[[34m\^[[1m[\^[[31m error: unable to ioctl device socket: \ > Invalid argument \^[[C\^[[39;49m\^[[m\^O" > 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 if dstumbler did likewise. Otherwise I can look at adding a backwards compatibility entry for WI_RID_SCAN_REQ. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
> : 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 socket: Invalid argument >From ktrace: 43042 dstumbler CALL sigaction(0x12,0x280b5850,0) 43042 dstumbler RET sigaction 0 43042 dstumbler CALL socket(0x2,0x2,0) 43042 dstumbler RET socket 3 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) 43042 dstumbler RET ioctl -1 errno 22 Invalid argument 43042 dstumbler CALL sigaction(0x12,0x280b5838,0x280b5850) 43042 dstumbler RET sigaction 0 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) 43042 dstumbler RET poll 0 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) 43042 dstumbler RET poll 0 43042 dstumbler CALL write(0x1,0x806,0x5e) 43042 dstumbler GIO fd 1 wrote 94 bytes "\^[[52;22H\^[[34m\^[[1m[\^[[31m error: unable to ioctl device socket: \ Invalid argument \^[[C\^[[39;49m\^[[m\^O" wistat.c, line 225 seems to be the offending line that is no longer working. Does dstumbler need to be updated or is this a bug in the new wlan code? -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
> : 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
Re: new wi driver problems
> 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 the setting of the wepkey by ifconfig but still have to track down why wep doesn't work (looks like xmit is fine but rcvd packets are being dropped by the card). FWIW you can enable debugging info for the 802.11 state machine with: sysctl debug.ieee80211=1 and get 802.11 frames by the driver printed with: ifconfig wi0 debug link2 Setting the sysctl value to >1 will give more verbose output which is unlikely to be useful. I have to commit some mods to tcpdump and bpf before you can use tcpdump to tap packets at the 802.11 link layer. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new wi driver problems
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=8843 mtu 1500 inet6 fe80::202:2dff:fe0c:ec4b%wi0 prefixlen 64 scopeid 0x3 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:02:2d:0c:ec:4b media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid myssid 1:myssid stationname "FreeBSD WaveLAN/IEEE node" channel 7 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit dmesg: wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:02:2d:0c:ec:4b wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (7.52.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps uname: FreeBSD sartre.redundancy.org 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Fri Jan 17 12:15:30 PST 2003 root@:/usr/obj/user/src/sys/SARTRE i386 But I'm unable to ping my gateway, a -STABLE box with the same card. I did recompile with device wlan, and tried the generic kernel as well. Disabling WEP has no effect. Could someone give me a pointer as to how to debug this? Thanks, David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
: 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
Re: HEADS UP: new wi driver
> > 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
> for the AP scanning stuff which is why I had to make mods to wicontrol.
Ok, this is what's up with bsd-airtools:
dstumbler breaks; on startup it reports
"unable to ioctl device socket: Input/output error".
I gross-hacked dstumbler to record what it is really trying to
do (I won't decipher the ioctl cmd just now):
ioctl(,
0x80206939,
);
the ifreq is initialized to zeros except ifr_data, which
points at a struct wi_req containing the following:
wi_req = {
0x0001, /* wi_len */
0xfce1, /* wi_type */
{
0x,
... /* full of zeros */
0x,
} /* wi_val[WI_MAX_DATALEN] */
}
The card is a Lucent Orinoco as follows:
wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1
wi0: 802.11 address: 00:02:2d:1d:25:98
wi0: using Lucent Technologies, WaveLAN/IEEE
wi0: Lucent Firmware: Station (8.10.1)
wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Hope this helps,
Magnus
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
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 message
Re: HEADS UP: new wi driver
> 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? I didn't try all the ports that depend on the driver but the API (ioctls) should be unchanged except for the AP scanning stuff which is why I had to make mods to wicontrol. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
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] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new wi driver
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: Re: HEADS UP: new wi driver > I got this when trying to buildkernel with a cvsup from ~11:30PM EST Jan 15. > > ---snip--- > cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys > -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werro r > vers.c > linking kernel > if_wi.o: In function `wi_attach': > if_wi.o(.text+0x74d): undefined reference to `ieee80211_rate2media' > if_wi.o(.text+0x88d): undefined reference to `ieee80211_ifattach' > if_wi.o: In function `wi_detach': > if_wi.o(.text+0x943): undefined reference to `ieee80211_ifdetach' > if_wi.o: In function `wi_stop': > if_wi.o(.text+0x14d5): undefined reference to `ieee80211_new_state' > if_wi.o: In function `wi_start': > if_wi.o(.text+0x1904): undefined reference to `ieee80211_encap' > if_wi.o(.text+0x1942): undefined reference to `ieee80211_find_node' > if_wi.o(.text+0x19b8): undefined reference to `ieee80211_wep_crypt' > if_wi.o: In function `wi_watchdog': > if_wi.o(.text+0x1e74): undefined reference to `ieee80211_new_state' > if_wi.o(.text+0x1e8c): undefined reference to `ieee80211_watchdog' > if_wi.o: In function `wi_ioctl': > if_wi.o(.text+0x22f9): undefined reference to `ieee80211_ioctl' > if_wi.o: In function `wi_media_change': > if_wi.o(.text+0x23af): undefined reference to `ieee80211_media2rate' > if_wi.o: In function `wi_media_status': > if_wi.o(.text+0x256c): undefined reference to `ieee80211_rate2media' > if_wi.o: In function `wi_sync_bssid': > if_wi.o(.text+0x2666): undefined reference to `ieee80211_new_state' > if_wi.o: In function `wi_rx_intr': > if_wi.o(.text+0x2a5d): undefined reference to `ieee80211_input' > if_wi.o: In function `wi_info_intr': > if_wi.o(.text+0x2faf): undefined reference to `ieee80211_new_state' > if_wi.o: In function `wi_get_cfg': > if_wi.o(.text+0x3ad0): undefined reference to `ieee80211_cfgget' > if_wi.o: In function `wi_set_cfg': > if_wi.o(.text+0x40e5): undefined reference to `ieee80211_cfgset' > if_wi.o: In function `wi_dump_pkt': > if_wi.o(.text+0x5588): undefined reference to `ieee80211_dump_pkt' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/ICY. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > mars# uname -a > FreeBSD mars.testserver.net 5.0-CURRENT FreeBSD 5.0-CURRENT #24: Wed Jan 15 > 10:13:14 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ICY > i386 > > > If you need more info, feel free to ask. > > Matt > > _ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: new wi driver
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 problems please contact me (or Warner). This work is the first step towards significant improvements in the wireless support. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: WI Driver issues, compile of kernel dies, after fidling it drops to db>
I hate replying to my own posts.. Anyways.. It appears The machine I was using as a test machine Either does not support pci 2.2 or is hosed (I'm voting for the latter as the bios seems to be losing its settings every so often)... So you can ignore the long winded issues I type 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, compile of kernel dies, after fidling it drops to db> Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the 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, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db> prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db> And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel "/boot/kernel/kernel" at 0xc03b8000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 9 IOAPIC
WI Driver issues, compile of kernel dies, after fidling it drops to db>
Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the 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, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db> prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db> And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel "/boot/kernel/kernel" at 0xc03b8000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 9 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 IOAPIC #0 intpin 19 -> irq 5 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: p
WI Driver issues, compile of kernel dies, after fidling it drops to db>
Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the 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, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db> prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db> And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel "/boot/kernel/kernel" at 0xc03b8000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 9 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 IOAPIC #0 intpin 19 -> irq 5 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: p
Re: wi driver: firmware %i.%i problem?
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 "unsubscribe freebsd-current" in the body of the message
Re: wi driver: firmware %i.%i problem?
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" in the body of the message
Re: wi driver: firmware %i.%i problem?
* 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 noticed the wi driver displaying this on booting. > > $ dmesg > FreeBSD 5.0-CURRENT #3: Sat Dec 8 19:32:20 GMT 2001 > root@ernest:/usr/obj/usr/src/sys/TPAD > . > wi0 at port 0x280-0x2c7 iomem 0xd4000-0xd43ff irq 9 flags 0x1 slot 0 on pccard0 > wi0: 802.11 address: 00:02:b3:04:b8:b8 > wi0: using RF:PRISM2 MAC:HFA3841, Firmware: %i.%i variant %i > $ > > I'm not sure if the %i is a problem the kernel printf or > with my card. I'm still using the stock pccard.conf > file with the 0x1 flag. The card works fine. > BTW, it's using version 2.xx firmware from Intel. > > I am not seeing the dhclient problem reported by others. %i is because I lost a flamewar to get %i added to kernel printf, it has been fixed. About your card, you may have luck checking your vendor's site for a firmware upgrade. Upgrading my cards (Addtron) really worked wonders. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wi driver: firmware %i.%i problem?
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:32:20 GMT 2001 root@ernest:/usr/obj/usr/src/sys/TPAD . wi0 at port 0x280-0x2c7 iomem 0xd4000-0xd43ff irq 9 flags 0x1 slot 0 on pccard0 wi0: 802.11 address: 00:02:b3:04:b8:b8 wi0: using RF:PRISM2 MAC:HFA3841, Firmware: %i.%i variant %i $ I'm not sure if the %i is a problem the kernel printf or with my card. I'm still using the stock pccard.conf file with the 0x1 flag. The card works fine. BTW, it's using version 2.xx firmware from Intel. I am not seeing the dhclient problem reported by others. Thanks, -- Alan Edmonds [EMAIL PROTECTED] London, England To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for wi driver
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. > > 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 this patch includes WEP support code for PrismII chip. > Original WEP support code was writen by Onoe at NetBSD. > But WEP support code does not work many PrismII based cards on FreeBSD. > We need more hack. > > Thanks, > --- > YAMAMOTO Shigeru Internet Initiative Japan Inc. > <[EMAIL PROTECTED]> Network Engineering Div. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 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.
: #Current wi driver has initialization and resource allocation mistakes.
I noticed that you fixed the bus_alloc_resource for the IOPORT to
always be 64 bytes long, aligned on a 64-byte boundary. Are there
other mistakes as well?
: And this patch includes WEP support code for PrismII chip.
: Original WEP support code was writen by Onoe at NetBSD.
: But WEP support code does not work many PrismII based cards on FreeBSD.
: We need more hack.
Thanks for the update. I can report that my lucent gold card still
works after these changes. I have a few questions about the code.
: +#ifdef foo
: wi_cmd(sc, WI_CMD_INI, 0);
: DELAY(10);
: wi_cmd(sc, WI_CMD_INI, 0);
: +#endif
: DELAY(10);
: -#ifdef foo
: if (wi_cmd(sc, WI_CMD_INI, 0))
: device_printf(sc->dev, "init failed\n");
: CSR_WRITE_2(sc, WI_INT_EN, 0);
: @@ -633,7 +678,7 @@
:
: /* Calibrate timer. */
: WI_SETVAL(WI_RID_TICK_TIME, 8);
: -#endif
: +
: return;
: }
:
If I'm reading this part of the patch collrectly, all wireset does is
put a delay 10 (100ms) into the compiled in code. Is that right?
Why did you do that? Also, is there some reason that tsleep can't be
used instead (well, other than it being soon replaced with msleep)?
: sc->iobase = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid,
: - 0, ~0, 1, RF_ACTIVE);
: + 0, ~0, (1 << 6),
: + rman_make_alignment_flags(1 << 6) | RF_ACTIVE);
I've run into this problem and made hacks to pccardd to only try
things on a "natural" boundary for the size of the i/o block. This
likely is the right thing to do in the driver.
BTW, here are my changes to pccardd. They also try to increase the
verbosity of the reports. Down around the patch for lines 722(715)
you'll find where I do the check. There's also some sprintf
reductions in these changes. I've been running with them on my main
wireless server for a few weeks now and they seem OK, but I hesitate
to commit them.
Does this mean that all of your wireless cards now work with FreeBSD?
Or are there still some issues?
Thank you again for your efforts.
Warner
Index: cardd.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/pccard/pccardd/cardd.c,v
retrieving revision 1.64
diff -u -r1.64 cardd.c
--- cardd.c 2000/10/20 13:08:18 1.64
+++ cardd.c 2000/11/19 04:42:00
@@ -42,7 +42,7 @@
#include "cardd.h"
static struct card_config *assign_driver(struct card *);
-static int assign_io(struct slot *);
+static char * assign_io(struct slot *);
static int setup_slot(struct slot *);
static void card_inserted(struct slot *);
static void card_removed(struct slot *);
@@ -279,7 +279,7 @@
card_inserted(struct slot *sp)
{
struct card *cp;
- int err;
+ char *reason;
usleep(pccard_init_sleep);
sp->cis = readcis(sp->fd);
@@ -362,27 +362,10 @@
}
if ((sp->config = assign_driver(cp)) == NULL)
return;
- if (err = assign_io(sp)) {
- char *reason;
-
- switch (err) {
- case -1:
- reason = "specified CIS was not found";
- break;
- case -2:
- reason = "memory block allocation failed";
- break;
- case -3:
- reason = "I/O block allocation failed";
- break;
- default:
- reason = "Unknown";
- break;
- }
-logmsg("Resource allocation failure for \"%s\"(\"%s\") "
- "[%s] [%s]; Reason %s\n",
-sp->cis->manuf, sp->cis->vers,
-sp->cis->add_info1, sp->cis->add_info2, reason);
+ if ((reason = assign_io(sp)) != NULL) {
+logmsg("Resource allocation failure for \"%s\"(\"%s\"): "
+"%s\n", sp->cis->manuf, sp->cis->vers, reason);
+ free(reason);
return;
}
@@ -593,11 +576,12 @@
* assign_io - Allocate resources to slot matching the
* configuration index selected.
*/
-static int
+static char *
assign_io(struct slot *sp)
{
str
patch for wi driver
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 this patch includes WEP support code for PrismII chip.
Original WEP support code was writen by Onoe at NetBSD.
But WEP support code does not work many PrismII based cards on FreeBSD.
We need more hack.
Thanks,
---
YAMAMOTO ShigeruInternet Initiative Japan Inc.
<[EMAIL PROTECTED]> Network Engineering Div.
Index: if_wi.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/i386/isa/if_wi.c,v
retrieving revision 1.29
diff -u -r1.29 if_wi.c
--- if_wi.c 2000/11/30 18:52:31 1.29
+++ if_wi.c 2000/12/11 04:46:37
@@ -231,10 +231,34 @@
struct wi_ltv_gen gen;
struct ifnet*ifp;
int error;
+ u_int32_t flags;
sc = device_get_softc(dev);
ifp = &sc->arpcom.ac_if;
+ /*
+* XXX: quick hack to support Prism II chip.
+* Currently, we need to set a flags in pccard.conf to specify
+* which type chip is used.
+*
+* We need to replace this code in a future.
+* It is better to use CIS than using a flag.
+*/
+ flags = device_get_flags(dev);
+#defineWI_FLAGS_PRISM2 0x1
+ if (flags & WI_FLAGS_PRISM2) {
+ sc->wi_prism2 = 1;
+ if (bootverbose) {
+ device_printf(dev, "found PrismII chip\n");
+ }
+ }
+ else {
+ sc->wi_prism2 = 0;
+ if (bootverbose) {
+ device_printf(dev, "found Lucent chip\n");
+ }
+ }
+
error = wi_alloc(dev);
if (error) {
device_printf(dev, "wi_alloc() failed! (%d)\n", error);
@@ -320,6 +344,12 @@
wi_read_record(sc, &gen);
sc->wi_has_wep = gen.wi_val;
+ if (bootverbose) {
+ device_printf(sc->dev,
+ __FUNCTION__ ":wi_has_wep = %d\n",
+ sc->wi_has_wep);
+ }
+
bzero((char *)&sc->wi_stats, sizeof(sc->wi_stats));
wi_init(sc);
@@ -589,7 +619,21 @@
{
int i, s = 0;
+ /* wait for the busy bit to clear */
+ for (i = 0; i < WI_TIMEOUT; i++) {
+ if (!(CSR_READ_2(sc, WI_COMMAND) & WI_CMD_BUSY)) {
+ break;
+ }
+ DELAY(10*1000); /* 10 m sec */
+ }
+
+ if (i == WI_TIMEOUT) {
+ return(ETIMEDOUT);
+ }
+
CSR_WRITE_2(sc, WI_PARAM0, val);
+ CSR_WRITE_2(sc, WI_PARAM1, 0);
+ CSR_WRITE_2(sc, WI_PARAM2, 0);
CSR_WRITE_2(sc, WI_COMMAND, cmd);
for (i = 0; i < WI_TIMEOUT; i++) {
@@ -621,11 +665,12 @@
static void wi_reset(sc)
struct wi_softc *sc;
{
+#ifdef foo
wi_cmd(sc, WI_CMD_INI, 0);
DELAY(10);
wi_cmd(sc, WI_CMD_INI, 0);
+#endif
DELAY(10);
-#ifdef foo
if (wi_cmd(sc, WI_CMD_INI, 0))
device_printf(sc->dev, "init failed\n");
CSR_WRITE_2(sc, WI_INT_EN, 0);
@@ -633,7 +678,7 @@
/* Calibrate timer. */
WI_SETVAL(WI_RID_TICK_TIME, 8);
-#endif
+
return;
}
@@ -646,6 +691,23 @@
{
u_int16_t *ptr;
int i, len, code;
+ struct wi_ltv_gen *oltv, p2ltv;
+
+ oltv = ltv;
+ if (sc->wi_prism2) {
+ switch (ltv->wi_type) {
+ case WI_RID_ENCRYPTION:
+ p2ltv.wi_type = WI_RID_P2_ENCRYPTION;
+ p2ltv.wi_len = 2;
+ ltv = &p2ltv;
+ break;
+ case WI_RID_TX_CRYPT_KEY:
+ p2ltv.wi_type = WI_RID_P2_TX_CRYPT_KEY;
+ p2ltv.wi_len = 2;
+ ltv = &p2ltv;
+ break;
+ }
+ }
/* Tell the NIC to enter record read mode. */
if (wi_cmd(sc, WI_CMD_ACCESS|WI_ACCESS_READ, ltv->wi_type))
@@ -675,6 +737,35 @@
for (i = 0; i < ltv->wi_len - 1; i++)
ptr[i] = CSR_READ_2(sc, WI_DATA1);
+ if (sc->wi_prism2) {
+ switch (oltv->wi_type) {
+ case WI_RID_TX_RATE:
+ case WI_RID_CUR_TX_RATE:
+ switch (ltv->wi_val) {
+ case 1: oltv->wi_val = 1; break;
+ case 2: oltv->wi_val = 2; break;
+
Re: wi driver
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 to be converted to newbus. I've done this to Bill Paul's Aironet driver for -current (however, his driver doesn't work with an access point correctly but the driver for Linux does so I have some work to do). You can use the /sys/dev/ed driver as a model. I don't have a card like that to test with. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wi driver
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 pcic0 at isa? port 0x3e0 irq 10 iomem 0xd device wi0 at isa? port? irq? ...and this in /etc/pccard.conf: io 0x240-0x360 irq 3 5 10 11 13 15 memory 0xd4000 96k card "Lucent Technologies" "WaveLAN/IEEE" config 0x1 "wi0" 7 insert echo WaveLAN/IEEE inserted insert /etc/pccard_ether wi0 remove echo WaveLAN/IEEE removed remove /sbin/ifconfig wi0 delete After bootup, the ISA-to-pccard bridge is found: pcic0: at port 0x3e0 iomem 0xd irq 10 on isa0 pccard0: on pcic0 pccard1: on pcic0 Just before going multiuser, pccardd seems to kick in and try to configure the wi interface, but I get this on the console: devclass_alloc_unit: wi0 already exists, using next available unit number ...and there is no wi0 interface (and no wi1, ...). Any idea? Running -current as of two days ago. Tried with and without hardwiring the pcic0 to a specific IO address and IRQ, the result is the same. Any idea? Blaz Zupan, [EMAIL PROTECTED], http://home.amis.net/blaz/ Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
