Changes are licensed with whatever the change author decides. All changes to ath5k so far have been dual-licensed to make them usable by the BSD community, too. It's safe to expect that this happens with ath9k-changes, too.
11b/g devices are supported by ath5k. This driver has been started as a community effort, based on a lot of reverse engineering. The availability of ath9k as true FOSS driver released by Atheros will certainly influence ath5k, too. The ath9k source contains information about chipset registers that most probably also exist on devices supported by ath5k.
So was I, the previous chips and drivers used that HAL to prevent out of spec tuning of the software radio i believe, so are they doing this in hardware now?
No firmware, no HAL, open driver. Either they can't be tuned out of spec by software, or they are hard locked at manufacture time.
> Either they can't be tuned out of spec by software, or they are hard locked at manufacture time.
Neither of both is correct. The hardware has the same capabilities as it had when just MadWifi (plus the binary-only HAL) was available as a Linux driver.
Atheros obviously understood that a blob does not help to prevent people from tuning the radio to frequencies they are not allowed to use. Luis Rodriguez is working on a in-kernel framework called "Central Regulatory Domain Agent" (CRDA) which will take care of the regulatory issues involved in running a WLAN device. He has been hired by Atheros some weeks ago, so Atheros now is sponsoring his work.
It is not "old news", you just have to read both articles again.
Back in 2006 the assessment was done by talking to a bunch of OpenBSD developers, who responded "we didn't do anything bad". So the SFLC *believed* it should be safe to work with the OpenHAL.
The recent assessment included a source code review, which basically changes the "SFLC believes it's safe" to "SFLC knows it's safe". And that obviously is worth a news item here, don't you think so?
The difference here is that a fix would have been easier and faster if all of the code was available.
The issue was completely burried in the open source part of the driver. If you look at the original report and the actual fix that would be quite easy to spot. I fail to see why not having access to the source of not even involved parts of the driver would have helped to solve this issue easier and faster.
I'll also say that the flaw would have been less likely to occur if all of the code was available.
Again, the HAL is not involved here, so the same question as above applies to this part of your rant.
A properly crafted 802.11 beacon or probe response frame will trigger the bug when a process tries to get scanning results by calling ioctl SIOCGIWSCAN.
Bringing down the interface (which ideally means the representation of the physical interface, wifi0, as well as all related VAPs such as ath0) usually prevents triggering a scan. To the best of my knowledge the wireless tools (such as iwlist) don't try to fetch scan results if the queried interface is flagged as down - which would prevent fetching scan results that probably were gathered before the interface was brought down. But on a quick glance it seems possible that custom tools could trigger the bug by calling the "faulty" ioctl without taking the interface status into account (which might make sense in some rare cases). Unloading the MadWifi module should prevent that.
But let's say it loud and clear: the best way to prevent being struck by that bug is to upgrade MadWifi to either v0.9.2.1, v0.9.3 (or, if you read this at a later point, any later version) - it's fixed since December 2006. Thanks again to Laurent Butti and his collegues for giving us the chance to react to their findings before they made them public.
Intel sponsored the study because a year ago Intel was full-blown behind Bluetooth. Bluetooth has since died a nasty death, and Intel has changed courses to embrace Wireless Ethernet.
Bluetooth died? I must have missed that one... Bluetooth never really lived so far, at least it did not live as a grown-up, just as a kid that is in the kindergarten-age. But Bluetooth currently grows up really fast (with the problems involved by fast growth...). Intel never left the Bluetooth-path, but they turned over from HomeRF to IEEE802.11b. Maybe you mixed this up with bluetooth.
As for security concerns, most products on the market today conform to Wi-Fi which is a more highly secure (and compatibile) variant of the original 802.11b specification.
Sorry, but this is wrong. WiFi is a consortium that does some tests to ensure that the theoretical interoperability achieved with the IEEE 802.11b is true in real life with the tested equipment. It is no way a better or somehow changed version of the 802.11b standard, so the WiFi-Logo does in no way tell anything about better security!
Stop it, else I will cough out my breakfast again!
Only dirty evil hackers want privacy. Where the heck do you come from? There are tons of reasons why anyone could have interest in encrypting private data. Damn, how about companies that try to keep their secrets, are those companies hiding anything illegal? Im a dirty evil hacker because Im not interested in anyone reading my private data? DROP DEAD!
cu, otaku
One interesting information in addition: here in Germany there also was a similar approach that would have forced any telecommunication provider (phone, mobile and internet) to implement an interface for surveillance institutions. Sure, they wouldnt have get any bucks for implementing it. Well, the law did not pass, but it is interesting to see that there are similar tries in other countries.
I await the moment that this law will be brought back into discussion, then they will argument as following "Hey, guys, look at NZ, there it works. Look at , there it works. We have to do it also, in order to be able to catch that bad bad guys". No, thanks.:(
cu, otaku
It is right, what you say. It would be a nice way to get those crackers and cyber criminals. But what about the possibility of industry espionage?
Who guarantees us that this tool will not be missused? I would not trust in this shit. There are other ways to prevent crimes or catch those who are responsible for it. Cutting in the flesh of "normal human beeings" as you and I is NOT the right way. Once the government has the possibility to do all these things, they will use it. And history showed more than once that they wont stick to the original purpose of this law, it will be extended to be more and more intrusive. No, forget it, this is definetly the wrong way!
Have a nice day, I will try to get my breakfast into my body again after I coughed it out while reading the article.
cu, otaku
Well, actually Microsoft seems to have enough time left for their "add composers" (whats the correct name of those people, dunno) to do such an add. And not to forget the money they have to spend for an ad that covers 2 pages in one of the best german computer mags (along with other mags).
So what? If there is one out there who wants to improve their effort to show a better text, why not?
Well, actually nobody has won this "war". Have a look what Ghandi said... we reached the "Then they fight you"-stage, this is the one right before "then you win".
The problem with this ad is another. Microsoft claims that an open source OS never can be good, as it is underlaying steady minor and big mutations. Have a look at posting #148. Windows itself is mutating since it was born, uncontrollable for anyone outside MS (and sometimes I believe even uncontrollable for MS). So they suffer the same problem that they attack Linux for.
This ad just shows one single thing: Microsoft is getting mad about Linux in a way they start to drop eggs without realizing they make themselves up as clowns.
I do not believe the Linux community has to start fighting Windows in any way. Time will show which OS is the better one, and currently (in my eyes) Linux is taking the leading position. Just my 0.02$.
cu, otaku
No, it isnt, and your opinion is wrong for most of the german people (well, there are allways some ancient-minded shitheads). If there is something you can read out of the ad, then it is _Microsoft_ assuming that one central control instance is what people want. Nothing more. And as far as I am concerned, this is wrong.
The card inside the ABS is from WaveLAN, right, but the WaveLAN tools can not be used for the ABS. One thing that works (besides the java configurator named here several times) is the Configurator from KarlNet. This company actually writes all Lucent firmware and the firmware for the ABS is also written by them.
Oh, you said "a comparable base station from Lucent... costs way more": there is a nearly 100% comparable base station from Lucent, called "AP-500", which inside is actually the same as the Airport Base Station.
Well, Cabletron is an OEM of Lucent. They lack the same problem as any other OEM lacks: they are not allowed to write a fully featured open source driver for their cards (which means that the driver would allow the linux box as access point, for example), as they would have to sign an NDA to get the relevant information from Lucent.
Changes are licensed with whatever the change author decides. All changes to ath5k so far have been dual-licensed to make them usable by the BSD community, too. It's safe to expect that this happens with ath9k-changes, too.
All recent Access Points from Lancom Systems are based on Atheros chipsets: http://lancom-systems.com
11b/g devices are supported by ath5k. This driver has been started as a community effort, based on a lot of reverse engineering. The availability of ath9k as true FOSS driver released by Atheros will certainly influence ath5k, too. The ath9k source contains information about chipset registers that most probably also exist on devices supported by ath5k.
So was I, the previous chips and drivers used that HAL to prevent out of spec tuning of the software radio i believe, so are they doing this in hardware now?
No firmware, no HAL, open driver. Either they can't be tuned out of spec by software, or they are hard locked at manufacture time.
> Either they can't be tuned out of spec by software, or they are hard locked at manufacture time.
Neither of both is correct. The hardware has the same capabilities as it had when just MadWifi (plus the binary-only HAL) was available as a Linux driver.
Atheros obviously understood that a blob does not help to prevent people from tuning the radio to frequencies they are not allowed to use. Luis Rodriguez is working on a in-kernel framework called "Central Regulatory Domain Agent" (CRDA) which will take care of the regulatory issues involved in running a WLAN device. He has been hired by Atheros some weeks ago, so Atheros now is sponsoring his work.
The new thing is a change from "we believe it's ok" to "we know it". See also here.
It is not "old news", you just have to read both articles again.
Back in 2006 the assessment was done by talking to a bunch of OpenBSD developers, who responded "we didn't do anything bad". So the SFLC *believed* it should be safe to work with the OpenHAL.
The recent assessment included a source code review, which basically changes the "SFLC believes it's safe" to "SFLC knows it's safe". And that obviously is worth a news item here, don't you think so?
Bye, Mike
The issue was completely burried in the open source part of the driver. If you look at the original report and the actual fix that would be quite easy to spot. I fail to see why not having access to the source of not even involved parts of the driver would have helped to solve this issue easier and faster.
Again, the HAL is not involved here, so the same question as above applies to this part of your rant.
Bringing down the interface (which ideally means the representation of the physical interface, wifi0, as well as all related VAPs such as ath0) usually prevents triggering a scan. To the best of my knowledge the wireless tools (such as iwlist) don't try to fetch scan results if the queried interface is flagged as down - which would prevent fetching scan results that probably were gathered before the interface was brought down. But on a quick glance it seems possible that custom tools could trigger the bug by calling the "faulty" ioctl without taking the interface status into account (which might make sense in some rare cases). Unloading the MadWifi module should prevent that.
But let's say it loud and clear: the best way to prevent being struck by that bug is to upgrade MadWifi to either v0.9.2.1, v0.9.3 (or, if you read this at a later point, any later version) - it's fixed since December 2006. Thanks again to Laurent Butti and his collegues for giving us the chance to react to their findings before they made them public.
Intel sponsored the study because a year ago Intel was full-blown behind Bluetooth. Bluetooth has since died a nasty death, and Intel has changed courses to embrace Wireless Ethernet.
Bluetooth died? I must have missed that one... Bluetooth never really lived so far, at least it did not live as a grown-up, just as a kid that is in the kindergarten-age. But Bluetooth currently grows up really fast (with the problems involved by fast growth...).
Intel never left the Bluetooth-path, but they turned over from HomeRF to IEEE802.11b. Maybe you mixed this up with bluetooth.
As for security concerns, most products on the market today conform to Wi-Fi which is a more highly secure (and compatibile) variant of the original 802.11b specification.
Sorry, but this is wrong. WiFi is a consortium that does some tests to ensure that the theoretical interoperability achieved with the IEEE 802.11b is true in real life with the tested equipment. It is no way a better or somehow changed version of the 802.11b standard, so the WiFi-Logo does in no way tell anything about better security!
cu, otakuStop it, else I will cough out my breakfast again! Only dirty evil hackers want privacy. Where the heck do you come from? There are tons of reasons why anyone could have interest in encrypting private data. Damn, how about companies that try to keep their secrets, are those companies hiding anything illegal? Im a dirty evil hacker because Im not interested in anyone reading my private data? DROP DEAD! cu, otaku
One interesting information in addition: here in Germany there also was a similar approach that would have forced any telecommunication provider (phone, mobile and internet) to implement an interface for surveillance institutions. Sure, they wouldnt have get any bucks for implementing it. Well, the law did not pass, but it is interesting to see that there are similar tries in other countries. I await the moment that this law will be brought back into discussion, then they will argument as following "Hey, guys, look at NZ, there it works. Look at , there it works. We have to do it also, in order to be able to catch that bad bad guys". No, thanks. :(
cu, otaku
It is right, what you say. It would be a nice way to get those crackers and cyber criminals. But what about the possibility of industry espionage? Who guarantees us that this tool will not be missused? I would not trust in this shit. There are other ways to prevent crimes or catch those who are responsible for it. Cutting in the flesh of "normal human beeings" as you and I is NOT the right way. Once the government has the possibility to do all these things, they will use it. And history showed more than once that they wont stick to the original purpose of this law, it will be extended to be more and more intrusive. No, forget it, this is definetly the wrong way! Have a nice day, I will try to get my breakfast into my body again after I coughed it out while reading the article. cu, otaku
That must be the reason why Windows is mutating nearly completely about every three or four years, right? lol
Well, actually Microsoft seems to have enough time left for their "add composers" (whats the correct name of those people, dunno) to do such an add. And not to forget the money they have to spend for an ad that covers 2 pages in one of the best german computer mags (along with other mags).
So what? If there is one out there who wants to improve their effort to show a better text, why not?
Well, actually nobody has won this "war". Have a look what Ghandi said... we reached the "Then they fight you"-stage, this is the one right before "then you win". The problem with this ad is another. Microsoft claims that an open source OS never can be good, as it is underlaying steady minor and big mutations. Have a look at posting #148. Windows itself is mutating since it was born, uncontrollable for anyone outside MS (and sometimes I believe even uncontrollable for MS). So they suffer the same problem that they attack Linux for. This ad just shows one single thing: Microsoft is getting mad about Linux in a way they start to drop eggs without realizing they make themselves up as clowns. I do not believe the Linux community has to start fighting Windows in any way. Time will show which OS is the better one, and currently (in my eyes) Linux is taking the leading position. Just my 0.02$. cu, otaku
No, it isnt, and your opinion is wrong for most of the german people (well, there are allways some ancient-minded shitheads). If there is something you can read out of the ad, then it is _Microsoft_ assuming that one central control instance is what people want. Nothing more. And as far as I am concerned, this is wrong.
The card inside the ABS is from WaveLAN, right, but the WaveLAN tools can not be used for the ABS. One thing that works (besides the java configurator named here several times) is the Configurator from KarlNet. This company actually writes all Lucent firmware and the firmware for the ABS is also written by them. Oh, you said "a comparable base station from Lucent ... costs way more": there is a nearly 100% comparable base station from Lucent, called "AP-500", which inside is actually the same as the Airport Base Station.
Well, Cabletron is an OEM of Lucent. They lack the same problem as any other OEM lacks: they are not allowed to write a fully featured open source driver for their cards (which means that the driver would allow the linux box as access point, for example), as they would have to sign an NDA to get the relevant information from Lucent.
Thats not a problem of the wlan card driver but one of the pcmcia-cs. As far as I know these bug should be fixed in current versions.
... else my girlfriend will leave me for laughing out my breakfast :))