Presence of airport extreme cart [was: How to get rid of sungem at boot time?]
Benjamin Herrenschmidt wrote: Besides, it's a good thing anyway as the sungem driver will deal with power management of the chip even when you are not using it, for example, for sleep mode. It's just a wrong way of thinking that you should remove drivers for HW you do not use in fact :) Hi, And what about the airport extreme card? Is there any benefit (e.g. powersaving) to remove the card while using an ibook under Linux? Yannick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt (intentionally?) brain dead?
On Thu, 2005-10-13 at 00:13 +0200, Wolfgang Pfeiffer wrote: [root@ 19:04:02]# apt-get --simulate install gconf2 Reading package lists... Done Building dependency tree... 0% Building dependency tree... Done You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: gconf2: Depends: gconf2-common (= 2.10.1-6) but it is not going to be installed Conflicts: libgconf2-4 ( 2.10.1-3) but 2.10.1-1 is to be installed gnome-core: Depends: bug-buddy (= 2.10.0) but 2.8.0-3 is to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). [root@ 19:17:06]# [root@ 19:17:06]# apt-get --simulate install gconf2 bug-buddy gconf2-common libgconf2-4 Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: gconf2-common The following packages will be upgraded: bug-buddy gconf2 libgconf2-4 3 upgraded, 1 newly installed, 0 to remove and 173 not upgraded. Inst gconf2-common (2.10.1-6 Debian:unstable) [gnome-core ] Inst libgconf2-4 [2.10.1-1] (2.10.1-6 Debian:unstable) [gnome-core ] Inst bug-buddy [2.8.0-3] (2.10.0-3 Debian:unstable) Inst gconf2 [2.10.1-1] (2.10.1-6 Debian:unstable) Conf gconf2-common (2.10.1-6 Debian:unstable) Conf libgconf2-4 (2.10.1-6 Debian:unstable) Conf bug-buddy (2.10.0-3 Debian:unstable) Conf gconf2 (2.10.1-6 Debian:unstable) [root@ 19:17:54]# Again: Is it brain dead software or a feature? Or what did I miss? Try without --simulate, and you should see. And maybe try digging a little deeper before calling something 'brain dead'... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Wed, Oct 12, 2005 at 09:29:21PM +0200, Jérôme Warnier wrote: Le lundi 10 octobre 2005 à 15:24 +0200, Sven Luther a écrit : On Mon, Oct 10, 2005 at 03:14:00PM +0200, Sven Luther wrote: On Mon, Oct 10, 2005 at 03:03:13PM +0200, Jerome Warnier wrote: Nope, they are available since a couple of weeks :) Sorry, but there is only cdrom, hd-media, and netboot in http://people.debian.org/~luther/d-i/images/daily/powerpc/. Is it netboot? Oh, damn, the floppies are still disabled then, will fix for tomorrow then. The main problem is that the drivers and other images are way too big for floppies. Ah, joeyh disabled them and forgot to reenable them once the miboot kernels entered the archive :/ So, I tried those available right now, and the boot image does not work (the Mac ejects the floppy automatically after trying to read it). Which those available right now ? The etch/sarge/testing one will never work until we free miboot, so you need the daily builds, and they should work. Also, it is well possible that your floppies or drive is dusty or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to get rid of sungem at boot time?
On Thu, Oct 13, 2005 at 09:57:00AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2005-10-13 at 00:12 +0200, Wolfgang Pfeiffer wrote: So anyone knows which app/config at boot time might be responsible for loading the sungem stuff? I already completely removed discover to fix this: sungem is your built-in ethernet. It show up on the PCI bus, thus hotplug will automatically load the driver. Besides, it's a good thing anyway as the sungem driver will deal with power management of the chip even when you are not using it, for example, for sleep mode. It's just a wrong way of thinking that you should remove drivers for HW you do not use in fact :) The problem here is assuming any kind of stability of the ethX numbers. This can't work. Ever. You need some other ways of identifying your interfaces. I don't know if debian network configure scripts provide any such thing though. You can list the modules in /etc/modules, and they will be loaded in order before any kind of auto-probing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
Le jeudi 13 octobre 2005 à 13:14 +0200, Sven Luther a écrit : On Wed, Oct 12, 2005 at 09:29:21PM +0200, Jérôme Warnier wrote: Le lundi 10 octobre 2005 à 15:24 +0200, Sven Luther a écrit : On Mon, Oct 10, 2005 at 03:14:00PM +0200, Sven Luther wrote: On Mon, Oct 10, 2005 at 03:03:13PM +0200, Jerome Warnier wrote: Nope, they are available since a couple of weeks :) Sorry, but there is only cdrom, hd-media, and netboot in http://people.debian.org/~luther/d-i/images/daily/powerpc/. Is it netboot? Oh, damn, the floppies are still disabled then, will fix for tomorrow then. The main problem is that the drivers and other images are way too big for floppies. Ah, joeyh disabled them and forgot to reenable them once the miboot kernels entered the archive :/ So, I tried those available right now, and the boot image does not work (the Mac ejects the floppy automatically after trying to read it). Which those available right now ? Those in http://people.debian.org/~luther/d-i/images/daily/powerpc/floppy (now=yesterday evening). The etch/sarge/testing one will never work until we free miboot, so you need the daily builds, and they should work. Also, it is well possible that your floppies or drive is dusty or something. Your miboot.floppy of the other day worked, and I reused the same floppies and tried with others, but boot.img did not work (it was ejected by the Mac). Friendly, Sven Luther
Re: apt (intentionally?) brain dead?
Hi Michel Hi All On Thu, Oct 13, 2005 at 01:04:59PM +0200, Michel Dänzer wrote: On Thu, 2005-10-13 at 00:13 +0200, Wolfgang Pfeiffer wrote: [ ... ] Again: Is it brain dead software or a feature? Or what did I miss? Try without --simulate, Sure. And risk that apt will remove essential packages? ... :) Apt being removing stuff is a well-known behavior currently in unstable Debian, so clearly, Michel, with all due respect: No way. :) and you should see. And maybe try digging a little deeper before calling something 'brain dead'... As you wrote: something brain dead ... things usually don't have feelings ... If previously good software is behaving brain-dead we should say/write that very clearly. After all I'm on Linux, and not on Windows 98 or Mac OS X, or so ... And please think about this current apt behavior where you don't want to install just one package as mentioned, but dozens or more instead - a typical situation for someone running unstable, I believe. I'd be definitely lost if apt would tell me then to resolve the dependencies myself, and manually ... Additionally: Given the current Debian/unstable situation it's more than crucial that apt works: http://www.debian.org/releases/unstable/: sid is subject to massive changes and in-place library updates. This can result in a very unstable system which contains packages that cannot be installed due to missing libraries, dependencies that cannot be fulfilled etc. This new apt behavior isn't that new to me .. IIRC I saw it the first time about 6 or 8 weeks ago. I didn't bother much then. But as it happened again I simply want to know whether this situation - i.e. apt says it cannot install although it can do it - is part of a new feature that I missed or a bug. If it's a bug I can live with it ... for some time ... :) ... If it's a well-known feature now please let me know. Best Regards Wolfgang -- Wolfgang Pfeiffer http://profiles.yahoo.com/wolfgangpfeiffer Key ID: E3037113 Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Thu, Oct 13, 2005 at 01:28:00PM +0200, Jérôme Warnier wrote: Le jeudi 13 octobre 2005 à 13:14 +0200, Sven Luther a écrit : On Wed, Oct 12, 2005 at 09:29:21PM +0200, Jérôme Warnier wrote: Le lundi 10 octobre 2005 à 15:24 +0200, Sven Luther a écrit : On Mon, Oct 10, 2005 at 03:14:00PM +0200, Sven Luther wrote: On Mon, Oct 10, 2005 at 03:03:13PM +0200, Jerome Warnier wrote: Nope, they are available since a couple of weeks :) Sorry, but there is only cdrom, hd-media, and netboot in http://people.debian.org/~luther/d-i/images/daily/powerpc/. Is it netboot? Oh, damn, the floppies are still disabled then, will fix for tomorrow then. The main problem is that the drivers and other images are way too big for floppies. Ah, joeyh disabled them and forgot to reenable them once the miboot kernels entered the archive :/ So, I tried those available right now, and the boot image does not work (the Mac ejects the floppy automatically after trying to read it). Which those available right now ? Those in http://people.debian.org/~luther/d-i/images/daily/powerpc/floppy (now=yesterday evening). The etch/sarge/testing one will never work until we free miboot, so you need the daily builds, and they should work. Also, it is well possible that your floppies or drive is dusty or something. Your miboot.floppy of the other day worked, and I reused the same floppies and tried with others, but boot.img did not work (it was ejected by the Mac). These are built using the exact same kernel and the exact same process, but it is possible that joeyh did more breakage in order to make it build without miboot, let me check. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt (intentionally?) brain dead?
Hi, Am Donnerstag, den 13.10.2005, 15:09 +0200 schrieb Wolfgang Pfeiffer: Try without --simulate, Sure. And risk that apt will remove essential packages? ... :) Apt being removing stuff is a well-known behavior currently in unstable Debian, so clearly, Michel, with all due respect: No way. :) a simple apt-get install foo will report you, which packages will be remove, new installed and upgraded and ask for permission. Only when foo ist the only package which will be installed, it starts immediately. If you use unstable it's normal that sometimes the dependencies don't match correctly and apt is unsure what to do. If you didn't like it, use stable ;-) Regards, Keywan -- Keywan Najafi Tonekaboni http://www.prometoys.net PGP Fingerprint: D5A1 A22E 3758 C9B4 57D2 3CAF EE52 1A78 C6A0 6934 [EMAIL PROTECTED]:/# apt-get --purge remove dominion After unpacking world will be freed. You are about to do something potentially beneficial To continue type in the phrase 'Yes, do as We say!' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to get rid of sungem at boot time?
airport isn't (yet) auto-detected by hotplug (soon). When that will happen, your airport driver will also be automagically loaded and there is no way to know which one will end up eth0 and which one will end up eth1. this is a good argument for bsd style network interfaces /dev/vr0 /dev/fxp0 /dev/fxp1 etc ive always been a big fan of that convention, as the whole ethX randomness drives me nuts. mind you, im not sure how the linux world would feel about suddenly changing. i believe scsi has (had?) similar problems that dev's where handed out in order unlike ide, where they are linked to a certain 'interface' anyway assuming the powers that be decided to go with bsd style interfaces, you could just sym link them or create second device entries with the same major and minor numebrs perhaps ben could push through bsd style nic dev file naming ;) Dean -- WWW: http://dean.bong.com.au LAN: http://www.bong.com.au EMAIL: [EMAIL PROTECTED] or [EMAIL PROTECTED] ICQ: 16867613 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt (intentionally?) brain dead?
On Thu, 2005-10-13 at 15:09 +0200, Wolfgang Pfeiffer wrote: On Thu, Oct 13, 2005 at 01:04:59PM +0200, Michel Dänzer wrote: On Thu, 2005-10-13 at 00:13 +0200, Wolfgang Pfeiffer wrote: Again: Is it brain dead software or a feature? Or what did I miss? Try without --simulate, Sure. And risk that apt will remove essential packages? ... :) Apt being removing stuff is a well-known behavior currently in unstable Debian, Without asking for confirmation first? That's news to me, definitely hasn't done that here. Ever. If you explicitly tell it not to ask first, maybe... so clearly, Michel, with all due respect: No way. :) So you don't want to see for yourself that there's no problem with apt but instead with the packages you're trying to install. Fine. But please save yourself and everybody else some precious time and spare us your pointless rants. Thanks. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: How to get rid of sungem at boot time?
On 10/13/05, Dean Hamstead [EMAIL PROTECTED] wrote: airport isn't (yet) auto-detected by hotplug (soon). When that will happen, your airport driver will also be automagically loaded and there is no way to know which one will end up eth0 and which one will end up eth1. this is a good argument for bsd style network interfaces /dev/vr0 /dev/fxp0 /dev/fxp1 etc That is utterly crap naming convention. if I have two nics from the same producer, then I'm in the same place as before. That naming convention just reduces the randomness in some corenr cases, as most use two or more identical ethernet cards, when needed. Mixed configs is rare and hapens mostly only in amateur environments. It does not help in proffesional ones (or maybe I am missing some detail) I am _totaly_ sure there is a way to assign a certain ethX number to a specific kernel module in some config files (/etc/network/interfaces and/or /etc/modules or alike; unfortunately I can't remember right now). I made this at some point in the past on a server with 4 nic-s. perhaps ben could push through bsd style nic dev file naming ;) I rather he not. :) (Bare in mind I am a Linux world memeber ;-) -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: Airport Extreme works on linux!
Looks like the folks over at http://linux-bcom4301.sourceforge.net/ are making some progress in this area as well. Check this out. http://bcm43xx.berlios.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt (intentionally?) brain dead?
On Thu, Oct 13, 2005 at 03:15:24PM +0200, Michel Dänzer wrote: On Thu, 2005-10-13 at 15:09 +0200, Wolfgang Pfeiffer wrote: On Thu, Oct 13, 2005 at 01:04:59PM +0200, Michel Dänzer wrote: On Thu, 2005-10-13 at 00:13 +0200, Wolfgang Pfeiffer wrote: Again: Is it brain dead software or a feature? Or what did I miss? Try without --simulate, Sure. And risk that apt will remove essential packages? ... :) Apt being removing stuff is a well-known behavior currently in unstable Debian, Without asking for confirmation first? That's news to me, definitely hasn't done that here. Ever. If you explicitly tell it not to ask first, maybe... so clearly, Michel, with all due respect: No way. :) So you don't want to see for yourself that there's no problem with apt but instead with the packages you're trying to install. Fine. Please: Read the message where I pasted apt's error messages *and* the output of my manual intervention shortly after: If you do you can see that there was no problem with the packages I was trying to install. Instead it was a problem with apt not automatically being able or willing to suggest a solution. I had to do it myself. And I repeat from my previous message, what you ignored in your response: And please think about this current apt behavior where you don't want to install just one package as mentioned, but dozens or more instead - a typical situation for someone running unstable, I believe. I'd be definitely lost if apt would tell me then to resolve the dependencies myself, and manually ... Yes, I made a grammar mistake. Instead of: And please think about this current apt behavior where you don't want to install just one package it should have said: And please think about this current apt behavior if you don't want to install just one package ['if' instead of 'where'] But you understood me in spite of it, right? And yes: Later I thought perhaps the ProblemResolver argument would have helped ... But given the probs I had the last time with apt even with this argument I doubt it would have helped. But not having tried it was a mistake. Indeed. In spite of the fact it was me who found it :) But please save yourself and everybody else some precious time and spare us your pointless rants. Thanks. [ ... ] Wow. So far I thought putting a finger to problems might help. Even if I do that without the soft words of a priest, and in spite of the technical mistakes I make. But I'm able to learn. Especially if even people like you don't see anything else than pointless rants in my postings. Regards Wolfgang -- Wolfgang Pfeiffer http://profiles.yahoo.com/wolfgangpfeiffer Key ID: E3037113 Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to get rid of sungem at boot time?
Hi Ben Hi All First this: Removing sungem(_phy) at boot time helps getting airport up (more in the test report #1 at the end of this mail) And yes, I believe you, Ben, when you write it's no good to remove these drivers .. :) On Thu, Oct 13, 2005 at 09:57:00AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2005-10-13 at 00:12 +0200, Wolfgang Pfeiffer wrote: So anyone knows which app/config at boot time might be responsible for loading the sungem stuff? I already completely removed discover to fix this: sungem is your built-in ethernet. It show up on the PCI bus, thus hotplug will automatically load the driver. Besides, it's a good thing anyway as the sungem driver will deal with power management of the chip even when you are not using it, for example, for sleep mode. It's just a wrong way of thinking that you should remove drivers for HW you do not use in fact :) Thanks for letting me know. That's new for me. The problem here is assuming any kind of stability of the ethX numbers. This can't work. Ever. You need some other ways of identifying your interfaces. I don't know if debian network configure scripts provide any such thing though. apt-get remove discover1-data discover1 libdiscover1 but to no avail so far ... Where are these apps/files that load this ethernet crap? Hal, udev, hotplug? It's not crap, it's your ethernet interface and the drivers should be loaded :) And yes, it's probably hotplug. I already grepped the whole /etc/ area for the eth pattern and such, but nothing so far ... And sure, I know I can blacklist sungem altogether somewhere in /etc/hotplug .. But I think it's brain-dead to firstly let some routine/script try loading a driver I don't want, Bla bla bla bla.. [ ... ] ... OK. Given your lessons above. ... :) Just in case: No, sungem is not loaded via /etc/modules. Ah yes, nearly forgot that: Loading my airport card manually after booting works like charm, after unloading the airport etc./sungem(_phy) drivers. So it seems it's simply a lousy boot time set up being responsible for the mess airport isn't (yet) auto-detected by hotplug (soon). Oh. Again thanks for letting me know. So this makes the errors look logic for me ... When that will happen, your airport driver will also be automagically loaded and there is no way to know which one will end up eth0 and which one will end up eth1. Again: My primary target is to get *sensibly* rid of sungem and sungem_phy being loaded at boot time. I'm sure if you put your machine on the floor, then jump on it several times until it splits in at least 3 or 4 pieces, sungem will no longer be loaded at boot time. [ ... ] OK. I'll try that. But before I'll send you the results from playing with sungem/airport settings :) .. : 3 little tests: 1: removing sungem sungem_phy via /etc/hotplug/blacklist and then loading airport at boot time set to eth1 via /etc/network/interfaces results in a working airport driver: I checked that success via the 'iwconfig' output and by actually and successfully connecting to www with the radio card - tested it with about 3 reboots of the machine .. 2: But if a do the same as above, but instead set the radio card to eth0 instead of eth1 airport doesn't work. I didn't even make it to my wireless router with orinoco. Tested that with 2 reboots 3: 2 reboots with these settings/results: doing the same as in #1 (eth1) but instead load the the sungem sungem_phy drivers results in no radio connection, not even until the wireless router. I told the system via /etc/network/interfaces to map eth1 to airport but instead I got this # ifconfig eth1 Link encap:Ethernet HWaddr [ deleted ] [deleted] loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1465 errors:0 dropped:0 overruns:0 frame:0 TX packets:1465 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:411186 (401.5 KiB) TX bytes:411186 (401.5 KiB) [the lo output above slightly varied from reboot 1 to reboot 2 in the RX packets, TX packets etc sections ..] # iwconfig lono wireless extensions. eth0 no wireless extensions. eth1 no wireless extensions. sit0 no wireless extensions. eth2 IEEE 802.11-DS ESSID: Nickname:HERMES I Mode:Managed Frequency:2.422 GHz Access Point: 00:00:00:00:00:00 Bit Rate:11 Mb/s Tx-Power=15 dBm Sensitivity:1/3 Retry limit:4 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Now things become complicated a bit: eth1, that I thought I set via the interfaces file to orinoco, is seen by the system as an ethernet card, as it
Re: Orinoco/hermes (original Airport) WPA support status
On Mon, Oct 10, 2005 at 03:05:23PM +0200, Soeren Sonnenburg wrote: On Sun, 2005-10-09 at 21:59 +0200, Wolfgang Pfeiffer wrote: On Thu, Oct 06, 2005 at 11:50:56PM +0200, Wolfgang Pfeiffer wrote: On Thu, Oct 06, 2005 at 09:16:10PM +0200, Soeren Sonnenburg wrote: On Wed, 05 Oct 2005 11:15:23 +, Julien BLACHE wrote: Hi, What's the status of WPA support in the orinoco driver ? Back in July, it wasn't supported, IIRC. Has anything happened since then ? Any plans ? I would also like to know the answer ... All I realize is that since 2.6.13 the orinoco driver no longer works with waproamd (it was when used with some cvs snapshot of may this year). No WPA with Orinoco - only WEP - IINM. Please check the archives for more: At least that's probably true for the the old Orinoco card: This card is about 2 or 3 years old, and I had to open up the Titanium IV to install it ... Wait, as kernel 2.6.14 has these config options now CONFIG_IEEE80211 CONFIG_IEEE80211_CRYPT_WEP CONFIG_IEEE80211_CRYPT_CCMP CONFIG_IEEE80211_CRYPT_TKIP IIUC you don't even need 2.6.14: 2.6.8 or higher seems to be OK. You can get the whole IEEE80211 stack from http://ieee80211.sourceforge.net/ The contents of their tarball, IINM [output edited for better readability here], about 2 or 3 weeks old:: $ tar -tzvf ieee80211-1.0.3.tgz ieee80211-1.0.3/ ieee80211-1.0.3/net/ ieee80211-1.0.3/net/ieee80211.h.orig ieee80211-1.0.3/net/ieee80211_crypt.h ieee80211-1.0.3/net/ieee80211.h ieee80211-1.0.3/Makefile ieee80211-1.0.3/LICENSE ieee80211-1.0.3/remove-old ieee80211-1.0.3/ieee80211_module.c ieee80211-1.0.3/ieee80211_crypt_ccmp.c ieee80211-1.0.3/ieee80211_geo.c ieee80211-1.0.3/idvals ieee80211-1.0.3/GIT_SHA1 ieee80211-1.0.3/ieee80211_crypt_tkip.c ieee80211-1.0.3/ieee80211_rx.c ieee80211-1.0.3/ieee80211_tx.c ieee80211-1.0.3/ieee80211_wx.c ieee80211-1.0.3/INSTALL ieee80211-1.0.3/CHANGES ieee80211-1.0.3/ieee80211_crypt.c ieee80211-1.0.3/ieee80211_crypt_wep.c Excerpt from the INSTALL file: ___ KERNEL REQUIREMENTS - 2.6 - -- ----- -- - - This subsystem is designed for the 2.6 kernel series. It should only be used with 2.6.8 or higher. OPTIONAL: WPA Support If you wish to enable WPA support, you also need to enable the following Crypto library modules (in addition to those required for WEP above): Michael MIC (CONFIG_CRYPTO_MICHAEL_MIC) AES (CONFIG_CRYPTO_AES_586) ieee80211 uses the WEP encryption and decryption algorithms provided by the Linux kernel. As such, in order to use WEP you must enable the Crypto library support (CONFIG_CRYPTO) and the following algorithms: ARC4 cipher algorithm (CONFIG_CRYPTO_ARC4) You also need to enable the following from Library routines: CRC32 (CONFIG_CRC32) Check for these with: % for i in CRYPTO_ARC4 CRC32; do \ grep CONFIG_INSTALL \ /lib/modules/2.6.10/build/include/linux/autoconf.h; done --- HTH Best Regards Wolfgang -- Wolfgang Pfeiffer http://profiles.yahoo.com/wolfgangpfeiffer Key ID: E3037113 Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt (intentionally?) brain dead?
On Thu, 2005-10-13 at 18:24 +0200, Wolfgang Pfeiffer wrote: So far I thought putting a finger to problems might help. Even if I do that without the soft words of a priest, and in spite of the technical mistakes I make. But I'm able to learn. Especially if even people like you don't see anything else than pointless rants in my postings. It may have to do with the tone you use in said postings ... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
