[Announce] Intel PRO/Wireless 2100 802.11b driver
James Ketrenos
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Timothy Miller
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. :)
Arjan van de Ven
> 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)
Dax Kelson
> 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
James Ketrenos
> 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
Marcel Holtmann
> 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
James Ketrenos
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
vda
> 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
Jeff Garzik
> *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
bert hubert
> 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
Timothy Miller
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?
Jeff Garzik
>
>
> 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
Disconnect
> *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 <lk...@sigkill.net>
Jean Tourrilhes
>
> 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
Joel Jaeggli
>
> 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 majo...@vger.kernel.org
> 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 joe...@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Jan De Luyck
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-----
James Ketrenos
>>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
Jan De Luyck
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-----
Stephen Hemminger
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:shemm...@osdl.org
Open Source Development Lab http://developer.osdl.org/shemminger
James Ketrenos
> 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
Bill Davidsen
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
Bill Davidsen
> *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
Lincoln Dale
>Hmmm... As you may know, I'm a chip designer...
>
>Are there not open specs on the wireless protocols? Could we not design
>government have to say about an open-source implementation? Are there
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.