I am pleased to announce the launch of an open source development project for
the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been
created and is hosted at http://ipw2100.sf.net.
The driver, as it currently stands, is able to associate and communicate in
Infrastructure mode. Support for both 2.4 and 2.6 is available. We are
releasing this driver now as "early beta" code to get feedback and help
in the development, so expect bugs (and please report them)! Of course
Intel will continue the effort (as part of this Open Source project).
We are planning to add support of all key wireless features (adhoc, WEP, etc)
over the next few months, quicker with help from others in the community.
NOTE: Let me reiterate -- this driver is in active development. Features and
capabilities available on other operating systems have not all been implemented
at this time. This includes wireless features (adhoc, wep) as well as
performance and power savings.
I look forward to working with the community to improve and enhance the driver.
So if you have an Intel wireless 802.11b miniPCI network adapter in your
laptop... download the bits, give it a whirl, and let me know how it goes.
Please also let us know if you encounter any problems that may be related to
specific distributions.
Thanks,
James Ketrenos
James Ketrenos wrote:
> I am pleased to announce the launch of an open source development
> project for
> the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been
> created and is hosted at http://ipw2100.sf.net.
[snip]
Props to Intel! I think this'll make up for the ia32e confusion. :)
On Tue, 2004-03-09 at 21:24, James Ketrenos wrote:
> I am pleased to announce the launch of an open source development project for
> the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been
> created and is hosted at http://ipw2100.sf.net.
thank you for doing this!
The driver looks quite good on first inspection too!
(minor nitpick: please look into request_firmware for the firmware
loader)
On Tue, 2004-03-09 at 13:24, James Ketrenos wrote:
> I am pleased to announce the launch of an open source development project for
> the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been
> created and is hosted at http://ipw2100.sf.net.
I applaud Intel for starting to plug this major hole. This looks
promising.
I took a look at the website and see the GPL driver and the closed
firmware.
Is it is really *firmware*, in that it loads and executes purely within
the Intel PRO/Wireless 2100 itself and not in the linux kernel on the
main CPU? If so, bravo!
Does a similar effort exist for the upcoming Sonoma 802.11a/b/g
component? Will Linux support be available for Sonoma at launch?
Dax Kelson
Arjan van de Ven wrote:
> thank you for doing this!
> The driver looks quite good on first inspection too!
> (minor nitpick: please look into request_firmware for the firmware
> loader)
Will do.
I was going down the path of using request_firmware but needed to support older
2.4 kernels as well, so I punted for the time being and stuck with what you
currently see.
I hope to add the request_firmware approach soon [ always willing to accept a
patch :) ]
Also, for those that are interested, we have a mailing list set up for the
driver at http://lists.sourceforge.net/lists/listinfo/ipw2100-devel.
James
Hi James,
> I was going down the path of using request_firmware but needed to support older
> 2.4 kernels as well, so I punted for the time being and stuck with what you
> currently see.
the request_firmware() is part of 2.4.23 and onwards. I have a backport
of it in my Bluetooth patches down to 2.4.18. Take a look at
http://www.holtmann.org/linux/kernel/
Regards
Marcel
Dax Kelson wrote:
> Is it is really *firmware*, in that it loads and executes purely within
> the Intel PRO/Wireless 2100 itself and not in the linux kernel on the
> main CPU? If so, bravo!
Yes, it is really firmware. It is loaded from disk as a block of data and
passed to the card. The system CPU doesn't execute anything out of the
firmware, nor does the firmware know anything about the kernel.
> Does a similar effort exist for the upcoming Sonoma 802.11a/b/g
> component? Will Linux support be available for Sonoma at launch?
It is our intention to support a/b/g WLAN with a driver for Linux, but details
are being worked out so we have no dates or commitment at this time.
Thanks,
James
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 09 March 2004 21:24, James Ketrenos wrote:
> I am pleased to announce the launch of an open source development project
> for the Intel PRO/Wireless 2100 miniPCI network adapter. The project has
> been created and is hosted at http://ipw2100.sf.net.
Nice. Applied to 2.6.2 without problems.
Machine: Acer TravelMate 803LCI with Intel PRO/Wireless 2100.
02:04.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
Subsystem: Intel Corp.: Unknown device 2527
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 8500ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at d0206000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
I've tried the driver out, and here are some remarks:
1. When loading the driver, it outputs this:
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 0.0.29
ipw2100: Copyright(c) 2003-2004 Intel Corporation
Detected ipw2100 PCI device at 0000:02:04.0, dev: eth%%d, mem: 0xD0206000-0xE498BFFF -> e498b000, irq: 10
I guess the eth%%d is just cosmetic, still, it looks ugly.
2. When you load the module, and immediately rmmod it, you get an oops:
Mar 10 08:43:13 precious kernel: Unable to handle kernel paging request at virtual address ffffffd8
Mar 10 08:43:13 precious kernel: printing eip:
Mar 10 08:43:13 precious kernel: e49e8e53
Mar 10 08:43:13 precious kernel: *pde = 00002067
Mar 10 08:43:13 precious kernel: *pte = 00000000
Mar 10 08:43:13 precious kernel: Oops: 0000 [#1]
Mar 10 08:43:13 precious kernel: CPU: 0
Mar 10 08:43:13 precious kernel: EIP: 0060:[__crc_rtattr_parse+686442/4765576] Not tainted
Mar 10 08:43:13 precious kernel: EFLAGS: 00010217
Mar 10 08:43:13 precious kernel: EIP is at ipw2100_defrag_free+0x33/0x90 [ipw2100]
Mar 10 08:43:13 precious kernel: eax: debdb000 ebx: 00000000 ecx: df5c5bc0 edx: dff6f270
Mar 10 08:43:13 precious kernel: esi: ffffffd0 edi: df15c200 ebp: df15c54c esp: dad9ded8
Mar 10 08:43:13 precious kernel: ds: 007b es: 007b ss: 0068
Mar 10 08:43:13 precious kernel: Process rmmod (pid: 1194, threadinfo=dad9c000 task=df901940)
Mar 10 08:43:13 precious kernel: Stack: dfe12c00 df15c200 df15c000 dfe12c00 dad9c000 e49e6dd2 df15c200 db016de0
Mar 10 08:43:13 precious kernel: dfe12c00 e49ef264 00000000 c024ec0b dfe12c00 dfe12c54 c02ae786 dfe12c54
Mar 10 08:43:13 precious kernel: dfe12c80 e49ef2b0 e49ef2b0 c02ae7bb dfe12c54 e49ef264 c0396cd8 c02ae9fd
Mar 10 08:43:13 precious kernel: Call Trace:
Mar 10 08:43:13 precious kernel: [__crc_rtattr_parse+678121/4765576] ipw2100_pci_remove_one+0x52/0xe0 [ipw2100]
Mar 10 08:43:13 precious kernel: [pci_device_remove+59/64] pci_device_remove+0x3b/0x40
Mar 10 08:43:13 precious kernel: [device_release_driver+102/112] device_release_driver+0x66/0x70
Mar 10 08:43:13 precious kernel: [driver_detach+43/64] driver_detach+0x2b/0x40
Mar 10 08:43:13 precious kernel: [bus_remove_driver+61/128] bus_remove_driver+0x3d/0x80
Mar 10 08:43:13 precious kernel: [driver_unregister+19/40] driver_unregister+0x13/0x28
Mar 10 08:43:13 precious kernel: [pci_unregister_driver+22/48] pci_unregister_driver+0x16/0x30
Mar 10 08:43:13 precious kernel: [__crc_rtattr_parse+686758/4765576] ipw2100_exit+0xf/0x15 [ipw2100]
Mar 10 08:43:13 precious kernel: [sys_delete_module+309/336] sys_delete_module+0x135/0x150
Mar 10 08:43:13 precious kernel: [sys_munmap+68/112] sys_munmap+0x44/0x70
Mar 10 08:43:13 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Mar 10 08:43:13 precious kernel:
Mar 10 08:43:13 precious kernel: Code: 8b 56 08 85 d2 74 25 8b 82 90 00 00 00 48 74 0d ff 8a 90 00
3. Loading av5100 on this machine shows the line "Turning radio ON" which afterwards deadlocks my machine.
It does show that 'device is disabled by hardware RF switch', but the led is lit which shows that it's enabled instead.
Weird.
I can't test the actual transmitting since I've got no accesspoint handy. Will do so when at home, though.
Otherwise: great work, and thanks for finally releasing this driver!
Jan
- --
Plus ,ca change, plus c'est la m^eme chose.
[The more things change, the more they remain the same.]
-- Alphonse Karr, "Les Gu^epes"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFATslCUQQOfidJUwQRAvXMAJ46sckVYqtGSXGGF6OqArBhLUbGBgCfej11
Sn2xVq6mdaJ4GN+x1/iNDhY=
=1iy0
-----END PGP SIGNATURE-----
On Tuesday 09 March 2004 23:12, Dax Kelson wrote:
> On Tue, 2004-03-09 at 13:24, James Ketrenos wrote:
> > I am pleased to announce the launch of an open source development project
> > for the Intel PRO/Wireless 2100 miniPCI network adapter. The project has
> > been created and is hosted at http://ipw2100.sf.net.
>
> I applaud Intel for starting to plug this major hole. This looks
> promising.
>
> I took a look at the website and see the GPL driver and the closed
> firmware.
>
> Is it is really *firmware*, in that it loads and executes purely within
> the Intel PRO/Wireless 2100 itself and not in the linux kernel on the
> main CPU? If so, bravo!
*FLAME ALERT*
/me is slowly getting mad about his prism54 11g hardware
and its firmware, with neither firmware authors nor documentation
for this pile of silicon crap nowhere in sight
What's so cool about having binary firmware? Bugs are bugs,
and you won't be able to even see bugs, less fix, in it.
I don't like being at the mercy of firmware authors.
--
vda
vda wrote:
> *FLAME ALERT*
> /me is slowly getting mad about his prism54 11g hardware
> and its firmware, with neither firmware authors nor documentation
> for this pile of silicon crap nowhere in sight
>
> What's so cool about having binary firmware? Bugs are bugs,
> and you won't be able to even see bugs, less fix, in it.
> I don't like being at the mercy of firmware authors.
Well that's typical in wireless, unfortunately. Certain parts of
wireless are political tennis balls with the US govt. and FCC.
Sometimes "put it in firmware" is the only way get ever get open source
drivers at all :/
I'll pick firmware over no-driver any day.
Jeff
On Wed, Mar 10, 2004 at 10:15:19AM +0200, vda wrote:
> What's so cool about having binary firmware? Bugs are bugs,
There will always be firmware. Quite often you are lucky enough not to see
it, but in this case you do. If the card had persistent storage, we'd have
the same thing and you'd call this 'flashing'.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Jeff Garzik wrote:
> vda wrote:
>
>> *FLAME ALERT*
>> /me is slowly getting mad about his prism54 11g hardware
>> and its firmware, with neither firmware authors nor documentation
>> for this pile of silicon crap nowhere in sight
>>
>> What's so cool about having binary firmware? Bugs are bugs,
>> and you won't be able to even see bugs, less fix, in it.
>> I don't like being at the mercy of firmware authors.
>
>
>
> Well that's typical in wireless, unfortunately. Certain parts of
> wireless are political tennis balls with the US govt. and FCC. Sometimes
> "put it in firmware" is the only way get ever get open source drivers at
> all :/
>
> I'll pick firmware over no-driver any day.
>
Hmmm... As you may know, I'm a chip designer...
Are there not open specs on the wireless protocols? Could we not design
our own open-source wireless network hardware? What would the US
government have to say about an open-source implementation? Are there
patents which would impede us?
Timothy Miller wrote:
>
>
> Jeff Garzik wrote:
>
>> vda wrote:
>>
>>> *FLAME ALERT*
>>> /me is slowly getting mad about his prism54 11g hardware
>>> and its firmware, with neither firmware authors nor documentation
>>> for this pile of silicon crap nowhere in sight
>>>
>>> What's so cool about having binary firmware? Bugs are bugs,
>>> and you won't be able to even see bugs, less fix, in it.
>>> I don't like being at the mercy of firmware authors.
>>
>>
>>
>>
>> Well that's typical in wireless, unfortunately. Certain parts of
>> wireless are political tennis balls with the US govt. and FCC.
>> Sometimes "put it in firmware" is the only way get ever get open
>> source drivers at all :/
>>
>> I'll pick firmware over no-driver any day.
>>
>
>
> Hmmm... As you may know, I'm a chip designer...
>
> Are there not open specs on the wireless protocols? Could we not design
> our own open-source wireless network hardware? What would the US
> government have to say about an open-source implementation? Are there
> patents which would impede us?
These are honest questions, but with all due respect, I would rather not
dive further into the mess :)
Jeff
On Wed, 2004-03-10 at 03:15, vda wrote:
> *FLAME ALERT*
> /me is slowly getting mad about his prism54 11g hardware
> and its firmware, with neither firmware authors nor documentation
> for this pile of silicon crap nowhere in sight
>
> What's so cool about having binary firmware? Bugs are bugs,
> and you won't be able to even see bugs, less fix, in it.
> I don't like being at the mercy of firmware authors.
> --
> vda
Short list of places you have binary firmware, in no particular order:
- BIOS
- Hard drives
- CD/DVD ROM/RAM/RW/R/...
- Controller for drives
- Video card (regardless of open/closed driver status)
- Sound card
- Most 100M+ NICs
- LCD display panels
- CRT displays
- KVMs
- Printers more advanced than daisy-wheel
- Some older daisy-wheel printers
- Networking gear of all forms more complex than a cat5 inline
- USB->* (usb->serial, usb->parallel, that sort of thing)
..and to go a little farther:
- Microwave, Dishwasher, Clothes Washing machine (maybe not the latter,
since cogs/gears is sorta open source...)
- TV
- TV Cable/Sat Box
- Tivo (yep, OS is linux. with lots of binary goo. but the loader
isn't..)
- PDA (unless it runs - eg - CRL's arm bootldr)
- Cellphone
- Cordless phone
- Some corded phones
- Car, car radio, radar detector (if applicable)
- Digital/crystal watch (analog-with-gears falls under sorta-open)
- Many fridge/freezers
- Many newer coffee makers
I'm curious as to how you go through life avoiding all that. (For that
matter, hardware designers have you even more at their mercy than
firmware authors....)
I suspect the real beef here is -undocumented- firmware. With api docs
the vast majority of bugs could be worked around, and some could be
fixed. (Its a 'firmware bug' if doing something that seems legit causes
failure. Its a driver bug if the firmware docs say "this has these
[currently undocumented] side-effects, so don't follow it with
'that'"..)
--
Disconnect <[email protected]>
Timothy Miller wrote :
>
> What would the US government have to say about an open-source
> implementation?
The transmission of radio waves (any frequency, any device) is
highly regulated (FCC in US, ETSI in Europe, ...). The US governement
can't stop you from building it, but can legally prevent you to use it
and to distribute/sell it.
Otherwise, why do you think the Ham people would bother
learning morse code ?
> Are there patents which would impede us?
Yep, some fundamental parts of 802.11 are covered with
patents. Patent search cost money, so you are on your own... In 10
years, all the patents on basic 802.11 will have expired, so you can
just wait.
Good luck...
Jean
On Wed, 10 Mar 2004, Jeff Garzik wrote:
>
> Well that's typical in wireless, unfortunately. Certain parts of
> wireless are political tennis balls with the US govt. and FCC.
> Sometimes "put it in firmware" is the only way get ever get open source
> drivers at all :/
I would be nice to have firmwares for each regulatory domain the hardware
has been certified to work in. My laptops wander from country to country
and spectrum allocation/ouput limits are noticably different or more
limited than they are in the US. It would be nice to be able to be a good
citizen, or at least a law abiding resident alien. On my old cisco b cards
I could change this by flashing it, I have an old nokia b card which has a
dialog in the windows driver utility to set the regulatory domain.
The fcc isn't the only authority that we as users and chipset/card
vendors have a legal obligation to comply with.
> I'll pick firmware over no-driver any day.
likewise, but one may not be enough.
> Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting [email protected]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 10 March 2004 08:52, Jan De Luyck wrote:
> I can't test the actual transmitting since I've got no accesspoint handy.
> Will do so when at home, though.
Tested this. It works, _if_ you set the AP address first, otherwise it bails
out with 'Fatal interrupt'.
Jan
- --
YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN
DOLLHOUSE you can find!! An make it SNAPPY!!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAUAXxUQQOfidJUwQRAjzJAJ9IpEthgDjGO5pGFnzWRMU5+WmgpgCfQ2xt
oCVVPgM/duRgPUWUkWAN1kA=
=BbJ0
-----END PGP SIGNATURE-----
Jan De Luyck wrote:
>>I can't test the actual transmitting since I've got no accesspoint handy.
>>Will do so when at home, though.
>
> Tested this. It works, _if_ you set the AP address first, otherwise it bails
> out with 'Fatal interrupt'.
So you're doing something like:
# modprobe ipw2100
# iwconfig eth1 ap 00:0d:88:28:2e:91
# ifconfig eth1 up
and if you skip the iwconfig step you see the fatal interrupt?
Btw, thanks for your prior post with the oops info. There is a fix in the
latest snapshot (0.30) on http://ipw2100.sf.net.
Thanks,
James
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 11 March 2004 08:48, James Ketrenos wrote:
> Jan De Luyck wrote:
> >>I can't test the actual transmitting since I've got no accesspoint handy.
> >>Will do so when at home, though.
> >
> > Tested this. It works, _if_ you set the AP address first, otherwise it
> > bails out with 'Fatal interrupt'.
>
> So you're doing something like:
>
> # modprobe ipw2100
> # iwconfig eth1 ap 00:0d:88:28:2e:91
> # ifconfig eth1 up
I believe I wasn't awake when I typed that mail ;p
The problem is that if you try to set an IP using DHCP (in my case ISC dhcpcd
version 1.3.22pl4) without first enabling your interface, you get a fatal
interrupt.
If you enable your interface, then do a dhcp request, it works.
Why I got mixed up with the ap setting is that I first thought that was the
problem (since iwconfig eth1 showed 00:00:00:00:00:00 instead of the mac
address of the AP. It was shown in /proc/iwp2100/eth1/bssconfig though)
> Btw, thanks for your prior post with the oops info. There is a fix in the
> latest snapshot (0.30) on http://ipw2100.sf.net.
Yup, I'm compiling that one (together with 2.6.4) right now.
Maybe this should be cc-ed to the devel mailing list too?
Jan
- --
You see but you do not observe.
Sir Arthur Conan Doyle, in "The Memoirs of Sherlock Holmes"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAUB3VUQQOfidJUwQRAix/AJ9GdhYEH/MlK8AToIgnHVpdIuekywCfYQ9V
SqTUbdIeZVEDrhoSt+HJ9z0=
=Nej6
-----END PGP SIGNATURE-----
The whole /proc/ipw2100/xxx interface is ugly and a mess. It doesn't expose anything
really useful that can't be found other ways and it is buggy. It doesn't handle
more than one device; I know you don't make hardware with multiple chipsets now but
will that always be true? Also, it forgets to do properly set module owner.
If you really have to keep the interface could you consider putting it in sysfs.
Something like /sys/class/net/eth0/ipw2100/xxx with one value per file.
The way to do that is with attribute groups.
The following wrappers might help:
diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h Thu Mar 11 10:36:47 2004
+++ b/include/linux/netdevice.h Thu Mar 11 10:36:47 2004
@@ -489,6 +489,20 @@
*/
#define SET_NETDEV_DEV(net, pdev) ((net)->class_dev.dev = (pdev))
+
+static inline netdev_sysfs_add_group(struct net_device *dev,
+ const struct attribute_group *grp)
+{
+ return sysfs_create_group(&net->class_dev.kobj, grp);
+}
+
+static inline netdev_sysfs_remove_group(struct net_device *dev,
+ const struct attribute_group *grp)
+{
+ sysfs_remove_group(&net->class_dev.kobj, grp);
+}
+
+
struct packet_type {
unsigned short type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
--
Stephen Hemminger mailto:[email protected]
Open Source Development Lab http://developer.osdl.org/shemminger
Stephen Hemminger wrote:
> The whole /proc/ipw2100/xxx interface is ugly and a mess. It doesn't expose anything
> really useful that can't be found other ways and it is buggy. It doesn't handle
> more than one device; I know you don't make hardware with multiple chipsets now but
> will that always be true?
We're very interested in correcting any bugs you've found in the proc code. If
you have any more specifics it would be greatly appreciated (steps to reproduce
the problem, what you're seeing that is problematic, etc.)
Multiple interfaces should be supported with the current code; each one's
entries would show up in its own /proc/ipw2100/<if_name> directory. The single
debug_level entry in /proc/ipw2100 sets a global level for the entire driver
module; we felt it more useful to apply the debug level globally to all
potential ipw2100 devices than on a per device basis. In the event that someone
does have multiple ipw2100's in their machine and they want to be able to set
the debug_level explicitly on a per device basis, we can accomodate that rather
quickly in the code. I'm interested in hearing other's opinions on this and am
very willing to change the code if appropriate.
> Also, it forgets to do properly set module owner.
Good catch; I'll fix it in the next snapshot.
> If you really have to keep the interface could you consider putting it in sysfs.
> Something like /sys/class/net/eth0/ipw2100/xxx with one value per file.
> The way to do that is with attribute groups.
Transitioning to sysfs is one of the goals as the project develops.
That said, we have a development mailing list set up for the project if you're
interested in helping us improve the driver. You can subscribe to that list
here <http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel>
Thanks for the feedback.
James
James Ketrenos wrote:
> I am pleased to announce the launch of an open source development
> project for
> the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been
> created and is hosted at http://ipw2100.sf.net.
>
> The driver, as it currently stands, is able to associate and communicate in
> Infrastructure mode. Support for both 2.4 and 2.6 is available. We are
> releasing this driver now as "early beta" code to get feedback and help
> in the development, so expect bugs (and please report them)! Of course
> Intel will continue the effort (as part of this Open Source project).
> We are planning to add support of all key wireless features (adhoc, WEP,
> etc)
> over the next few months, quicker with help from others in the community.
>
> NOTE: Let me reiterate -- this driver is in active development. Features
> and
> capabilities available on other operating systems have not all been
> implemented
> at this time. This includes wireless features (adhoc, wep) as well as
> performance and power savings.
>
> I look forward to working with the community to improve and enhance the
> driver.
> So if you have an Intel wireless 802.11b miniPCI network adapter in your
> laptop... download the bits, give it a whirl, and let me know how it goes.
> Please also let us know if you encounter any problems that may be
> related to
> specific distributions.
Great job! Dare we hope that in the future the news 802.11[bg] unit I
have seen mentioned would also be supported in a similar manner?
-bill
vda wrote:
> *FLAME ALERT*
> /me is slowly getting mad about his prism54 11g hardware
> and its firmware, with neither firmware authors nor documentation
> for this pile of silicon crap nowhere in sight
>
> What's so cool about having binary firmware? Bugs are bugs,
> and you won't be able to even see bugs, less fix, in it.
> I don't like being at the mercy of firmware authors.
There are two common reasons for binary firmware:
1 - it runs on some sort of a state machine implemented in an ASIC or
other device for which you have no manuals or assembler.
2 - since these devices are regulated all to hell by the FCC and other
non-technical groups balancing technical advice with political pressure,
a user might code the device out of spec, causing some manner of legal
hassle.
I don't know if (1) applies here, but I'd bet (2) is applicable.
Let's be happy that we have a driver and treat the device as a black
box. There are people paid to know enought details to write firmware,
I'm happy to treat NICs and CD/DVD burners with the "buy good and update
firmware at the first problem." Keeping the old firmaware of course.
-bill
At 03:31 AM 11/03/2004, Timothy Miller wrote:
>Hmmm... As you may know, I'm a chip designer...
>
>Are there not open specs on the wireless protocols? Could we not design
>our own open-source wireless network hardware? What would the US
>government have to say about an open-source implementation? Are there
>patents which would impede us?
the issue is one of "current generation" radio units, as used in
802.11a/b/g are typically very programmable, and in many cases, can both
send & receive on frequencies well outside of the standard 802.11a/b/g
2.4GHz and 5.4GHz bands.
i'd hazard a guess and say that this is the primary reason for the concern
in releasing true "open source" for the firmware.
potentially, the equipment could be used outside of the range of
frequencies that it is intended for (and indeed FCC certified for).
i know of at least one radio that can snoop other frequencies such as
police/emergency services/ ...
cheers,
lincoln.