* Re: compat-2.6 - missing usb_poison_urb on 2.6.27
From: Luis R. Rodriguez @ 2009-07-17 15:58 UTC (permalink / raw)
To: arne.fitzenreiter; +Cc: linux-wireless
In-Reply-To: <20090717062907.78420@gmx.net>
On Thu, Jul 16, 2009 at 11:29 PM, <arne.fitzenreiter@gmx.de> wrote:
> Hi,
>
> i had problems to use the compat-wireless pack from yesterday (16.7.2009) because in kernel 2.6.27 the symbols usb_poison_urb and usb_unpoison_urb are missing. They should be first introduced with 2.6.28
> http://lxr.free-electrons.com/ident?v=2.6.28;i=usb_poison_urb
Hm, yeah I forgot to add the actual code and the header placement was incorrect.
> At my informations also usb_poison_anchored_urbs are also introduced with 2.6.28 so i think this is added to the wrong "compat" file
> http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat-wireless-2.6.git;a=commitdiff;h=a2c9d9009ff5692dbb517df97f328fd67940830a
> but this could be misinterpreted by me.
>
> Please check this. Thanks.
Great, thanks, will fix accordingly. Can you try new tarball?
This is a bleeding edge compat-wireless release based on: master-2009-07-10
This is compat-release: master-2009-07-08-11-g899b22b
Luis
^ permalink raw reply
* Re: any controller working in AP mode ?
From: Pavel Roskin @ 2009-07-17 15:19 UTC (permalink / raw)
To: Ram kumar; +Cc: Javier Cardona, andrey, linux-wireless
In-Reply-To: <6306c640907152338k4a5fb474h481d5adba97507b1@mail.gmail.com>
On Thu, 2009-07-16 at 12:08 +0530, Ram kumar wrote:
> hi,
>
> > The thin firmware that allows using the 8383 with mac80211 and
> > implement an AP with hostapd is available here:
> > http://dev.laptop.org/pub/firmware/libertas/thinfirm/
>
> Thanks for the reply.It looks like currently there are only two
> devices support AP mode with USB as an interface.
>
> 1.MARVELL 8388.
> 2.RALINK - RT73USB.
>
> But in the linux wireless website it says RT73USB doesn't support AP
> mode.I am assuming that site is not updated with recent
> information,please correct me if i am wrong.
It's hard to say if it's intentional or not. rt2500usb is listed as
having AP support, and it's closely related to rt73usb.
I did a quick test with rt73usb. hostapd starts sucessfully, and a
client using ath5k can connect and transmit data. A client using ath9k
can connect (wpa_supplicant enters state CONNECTED), but no data goes
through. The same client connects fine to a normal AP (D-Link DIR-615).
I don't have time to debug that issue right now, but you get the idea.
The AP mode can be enabled, but be prepared to some issues.
> It would be very helpful if anyone can guide me,how to get the
> hardware for MARVELL 8388.
5 minute search finds that Zonet ZEW2502 is what you need. There is
only one driver for that device on the Zonet site, and it's clearly for
Marvell.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Is there any wireless catpure tool on Linux such as omnipeek on windows ?
From: Gábor Stefanik @ 2009-07-17 13:37 UTC (permalink / raw)
To: peter meng; +Cc: linux-wireless
In-Reply-To: <520334.88470.qm@web15701.mail.cnb.yahoo.com>
On Fri, Jul 17, 2009 at 2:49 PM, peter meng<mengsanshui@yahoo.com.cn> wrote:
>
> Hi
>
> Is there any wireless catpure tool on Linux such as omnipeek on windows ?
>
> Best Regards.
> Peter Meng
Try these:
Kismet - http://kismetwireless.net/
WiCrawl - http://midnightresearch.com/projects/wicrawl/
Wireshark - http://www.wireshark.org/
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Is there any wireless catpure tool on Linux such as omnipeek on windows ?
From: Larry Finger @ 2009-07-17 13:36 UTC (permalink / raw)
To: peter meng; +Cc: linux-wireless
In-Reply-To: <520334.88470.qm@web15701.mail.cnb.yahoo.com>
peter meng wrote:
> Hi
>
> Is there any wireless catpure tool on Linux such as omnipeek on windows ?
Do you mean like Wireshark or Kismet?
^ permalink raw reply
* Is there any wireless catpure tool on Linux such as omnipeek on windows ?
From: peter meng @ 2009-07-17 12:49 UTC (permalink / raw)
To: linux-wireless
Hi
Is there any wireless catpure tool on Linux such as omnipeek on windows ?
Best Regards.
Peter Meng
^ permalink raw reply
* Re: [RFC/RFT 0/5] mac80211: implement background scan
From: Helmut Schaa @ 2009-07-17 12:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <200907162352.49020.helmut.schaa@gmail.com>
Am Donnerstag, 16. Juli 2009 schrieb Helmut Schaa:
> Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> > On Thu, 2009-07-16 at 11:04 +0200, Helmut Schaa wrote:
> >
> > > So, it would be great if somebody could test the patches on other
> > > hardware as well.
> >
> > If you repost with the stuff we talked about fixed, I'll give them a
> > spin, but for all I can tell they should be good to go in, it's a huge
> > improvement and we can build on that.
>
> Will do that soon. However, I still have an issue that sometimes
> the connection is stuck and I'm still unsure if it is related to the
> bg scan patches or something else :(
Ok, this is also reproducible without the bg scan patches by just using
sw scan together with iwlagn. Sometimes (I still have no clue under which
circumstances) just after a scan the connection is stuck while iwconfig
still shows association and also the signal levels are still updated.
Helmut
^ permalink raw reply
* Re: Using GeoClue to send a Linux wireless regulatory hint
From: Hin-Tak Leung @ 2009-07-17 11:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: GeoClue, linux-wireless, till.kamppeter, desrt, Dan Winship,
Tim Gardner
In-Reply-To: <43e72e890907161810k51e3830bqe3283539f19e2fd2@mail.gmail.com>
I thought the reason for using GeoClue is to cater for frequent
travellers who can cross timezone (and not neccesarily reset their
laptop's computer/clock for it)? So it is orthogonal to one-off static
setup where the computer mostly stay in the same country/location. Is
there an iw/cfg80211 interface/field for regulatory info? AFAIK there
isn't in wext, but that's on its way out and probably not important...
On Fri, Jul 17, 2009 at 2:10 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> The GSoC project to integrate GeoClue to GNOME and eventually send
> regulatory hint information to the kernel [1] will not be completed
> through GSoC. Since I am not sure if the student will be interested in
> following up on this project idea outside the scope of GSoC I'm
> looking for advice to better get an idea of what it is exactly we
> should be looking forward to change to get information to the kernel
> to enhance regulatory support using GeoClue. At the very least I'd
> like to come to some conclusion as to where it is best to put software
> to send information to the kernel to help distributions.
>
> The current best alternative I've seen is to read the current timezone
> information and extract the country from that. That is how John
> implemented it for Fedora. This may be enough but GeoClue should
> provide better accuracy. All we need in the kernel is to determine the
> country you are on. The user can obviously set this themselves during
> a distribution install, but it may make sense to just use GeoClue for
> this. Under the assumption that using GeoClue is the way to go how
> should we do this?
>
> For the GSoC project I was initially suggesting for Network Manager to
> get GeoClue integration and then have Network Manager send the
> regulatory hint once a country was determined through either user
> input or through GeoClue magic. After some discussions with Jouni
> about this he convinced me this may not be the best place for this. So
> if not Network Manager, where? Do we want a GNOME location aware panel
> under System->Administration? Is it as simple as that? If not are
> there any other suggestions?
>
> If you fwd this to another list for discussion please do CC me.
>
> [1] http://wireless.kernel.org/en/developers/GSoC/2009/GeoClue_regulatory
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] cfg80211: don't optimise wext calls too much
From: Kalle Valo @ 2009-07-17 10:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Marcel Holtmann
In-Reply-To: <1247737144.24433.11.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> In the wext code I tried to not reconnect all the time
> when the user wasn't really sure what they were doing,
> like setting the BSSID back to the same value it was.
> However, this optimisation should only be done while
> associated so that setting the BSSID back to the same
> value that it was actually triggers a new association
> if not currently associated. To achieve, that, put the
> relevant code into the !IDLE case instead.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
At least this patch cured my resume problems I reported earlier[1]. It
will take few days to test the dropping from network case, but I'm sure
this patch will help with that problem as well. If not, I'll report
about the issue. Thanks for fixing this.
Tested-by: Kalle Valo <kalle.valo@iki.fi>
[1] http://www.spinics.net/lists/linux-wireless/msg35797.html
--
Kalle Valo
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-17 9:58 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1247775641.6841.16.camel@mj>
Pavel Roskin <proski@gnu.org> writes:
> On Thu, 2009-07-16 at 18:01 +0100, Jon Fairbairn wrote:
>
> I cannot guarantee anything, but I think chances are very high.
OK, fair enough.
>> The distro I'm using (fedora 11) has 2.6.29 -- will the relevant modules
>> build for that, or would I have to build a whole 2.6.31?
>
> You can build compat-wireless, which includes the latest ath5k driver
> backported from the wireless-testing kernel. Alternatively, you can
> build madwifi (be sure to use the trunk snapshot).
Many thanks. I'll go ahead and order one.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-17 9:57 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <43e72e890907161659h320e6d5fpefe7e0881634addd@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@gmail.com>
writes:
> On Thu, Jul 16, 2009 at 4:50 PM, Jouni Malinen<j@w1.fi> wrote:
>> I don't know how the product list ended up being split that way, but the
>> "laptops" page does actually include number of D-Link adapters,
>> including a PCIe desktop adapter (D-Link DWA-556) that seems to match
>> the request. I saw it at Fry's last week and it does indeed look like a
>> PCIe card.
>
> Sorry that was my doing, I forgot there were a few external cards
> available, I've updated the wiki to reflect this and added a new
> external cards page:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k/products/external
Thanks for that it's much clearer. I've gone through the manufacturers
websites and added what detail I could find about card types. I didn't
use the codes on the page as I couldn't be certain of the details...
maybe should be table format, and probably should either add the codes
or remove the code key.
Since the DWA-556 is about four times the price of the Abit Airpace, it
looks like I'll have to go with the bleeding edge version of ath5k
rather than ath9k.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: SDIO Stack and Device Support
From: Jonathan Cameron @ 2009-07-17 9:20 UTC (permalink / raw)
To: Robert Emanuele; +Cc: linux-kernel, linux-wireless
In-Reply-To: <9f53b4330907161718ydbac090k2afc7a749fc9f6f2@mail.gmail.com>
Robert Emanuele wrote:
> Greetings all,
>
> I'm trying to find out more information about the status of an SDIO
> stack and SDIO devices in the kernel. I see under drivers/mmc/ some
> SDIO support.
>
> I'm evaluating the potential of getting a Wireless SDIO card to work
> with the 2.6 kernel. So far all I see in the kernel is support for an
> SDIO UART. There is a patch on sourceforge for an SDIO stack and
> drivers from Atheros but that is for 2.6.18. Is there current support
> for other SDIO wireless devices in the kernel?
>
There is pretty good support for the Marvell chips (sd8686 etc) in the
mainline
kernel. Take a look under drivers/net/wireless/libertas/
I've also copied in the linux-wireless list.
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Johannes Berg @ 2009-07-17 8:18 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Joel Roth, Bob Copeland
In-Reply-To: <200907170806.23728.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Fri, 2009-07-17 at 08:06 +0200, Holger Schurig wrote:
> > 1. kernel and driver setup - use compat-wireless
> >
> > 2. set wireless interface to UP
> >
> > ifconfig <interface> up
> >
> > 3. find available networks using
> >
> > iw dev <interface> scan
> > or
> > iwlist <interface> scan
>
> And maybe here the tools could emit "interface <interface> isn't
> up" as a more specfic error message ?!?
They do.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [KARMIC] review these for rt2x00 (adds rt2800pci)
From: Stefan Bader @ 2009-07-17 8:00 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Luis R. Rodriguez, Manoj Iyer, kernel-team, linux-wireless
In-Reply-To: <a32f33a40907170011n38367961i54a26c50124241c2@mail.gmail.com>
Ivo Van Doorn wrote:
> On Fri, Jul 17, 2009 at 1:15 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Thu, Jul 16, 2009 at 9:56 AM, Stefan Bader<stefan.bader@canonical.com> wrote:
>>> At least this seems to be material for 3 or 4 patches
>>> - adapt the rfkill stuff
>>> - some documentation update
>>> - add the new pci version of the 2800 (with that rt2x00soc lib
>>> which might be another patch)
>>> - and some fixes...
>> Not only that but this driver is not yet merged upstream, there should
>> be a good reason for that.
>>
>> Ivo, what's the status on rt2800pci? Some users have been asking about it.
>
> The status is that it is not functioning correctly, during boot it
> will print out
> tons of errors about the device not being ready, and afterward it cannot scan,
> connect or do anything useful.
>
> And I think those problems can be considered enough reasons for not merging
> the driver upstream yet. ;)
>
> Ivo
I would say so. :) Assuming there is a bit of truth in those claims of that
tarball working better than the current kernel code, we might take away all the
new driver bloat and see what remains (which might be the part Ivo has anyways
in wireless testing...)
Stefan
--
When all other means of communication fail, try words!
^ permalink raw reply
* Re: [KARMIC] review these for rt2x00 (adds rt2800pci)
From: Ivo Van Doorn @ 2009-07-17 7:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Stefan Bader, Manoj Iyer, kernel-team, linux-wireless
In-Reply-To: <43e72e890907161615h507e9c59r421d23d22ff05459@mail.gmail.com>
On Fri, Jul 17, 2009 at 1:15 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Jul 16, 2009 at 9:56 AM, Stefan Bader<stefan.bader@canonical.com> wrote:
>> At least this seems to be material for 3 or 4 patches
>> - adapt the rfkill stuff
>> - some documentation update
>> - add the new pci version of the 2800 (with that rt2x00soc lib
>> which might be another patch)
>> - and some fixes...
>
> Not only that but this driver is not yet merged upstream, there should
> be a good reason for that.
>
> Ivo, what's the status on rt2800pci? Some users have been asking about it.
The status is that it is not functioning correctly, during boot it
will print out
tons of errors about the device not being ready, and afterward it cannot scan,
connect or do anything useful.
And I think those problems can be considered enough reasons for not merging
the driver upstream yet. ;)
Ivo
^ permalink raw reply
* Re: Reading the RSSI from a Kernel Module
From: Tim Schneider @ 2009-07-17 6:37 UTC (permalink / raw)
To: wireless
In-Reply-To: <4A5B211D.3040905@gmail.com>
I did some research on the subject, and it seems that you are right.
The RSSI Value can only be read at the receiving end. This does make a
lot of sense, but I read a paper about the Algorithm I am trying to
implement, and the Author stated it would be possible to read the RSSI-
Value at the senders end. Since the author is a professor at a German
university, I figured he knew what he was talking about. I reworked my
way through the Paper and realized, that there is another thing that
you can't just read at the senders end. He uses the hopcount of the
connection for his calculations. That's an Information that is
actually impossible to get without the support of the routing-layer.
Since I need to modify the routing-layer anyways now, I'll just modify
it in a way, so that I can read the RSSI-Information of the first hop
too.
Thank you for your help.
Tim Schneider
Am 13.07.2009 um 13:57 schrieb Richard Farina:
> Tim Schneider wrote:
>>
>> Am 13.07.2009 um 08:59 schrieb Richard Farina:
>>> I don't mean to make this a flame so please do not take it that
>>> way. How exactly do you expect to get the RECEIVED Signal
>>> Strength indication for a packet which you are SENDING? If you
>>> send it, you don't receive it...
>>>
>>> Just my 0.02
>>>
>>> -Rick Farina
>>
>> Hi Rick,
>>
>> as far, as I understood, the RSSI-Mechanism also displays the
>> signal strength of the just sent package. I figured there was some
>> way the MAC-Layer transported that information, but you're right, I
>> could be mistaken. Anyways, since I'm trying to implement a TCP
>> Algorithm, i definitely have a two-way connection. Assuming, that
>> the route back is going to be the same as it was on the way there
>> (which basically should be true, based on the Routing algorithms
>> we're using in our wireless mesh network), I could just use the
>> RSSI Value of the received ACK.
>>
> Any RSSI on a sent packet will be a calculated number not an
> observed number and as such it will be completely pointless for any
> kind of rate control algorithm. Assuming that the card could
> actually receive the packets it is sending (which it can't) then you
> would be observing a 24dBm signal (for instance) with 0 patch loss
> and your RSSI would be at or above max. Realistically you can
> assume that every packet you sent has a max RSSI on your end because
> you are the one transmitting it. Now, if you want to know what the
> RSSI on the receiver side is that is a completely different
> question, one which you cannot answer at all. When you send a packet
> you do not have the good fortune to know what RSSI the receiver
> got. You can roughly assume based on your RSSI when you get an ACK,
> but honestly that isn't even close to correct because every packet
> has a very unique experience in the air and you cannot assume things
> like the same tx power and rx sensitivity will be the same on both
> ends. There is some 802.11 protocol (the letter eludes me at
> present) which is in draft form which adds information to packets so
> that both ends know each other's RSSI, but I have never seen it
> implemented anywhere yet.
>
> I advise you keep the discussion on list as I am by no means an
> expert and many people much better at this than I may respond.
>
> -Rick Farina
>> Regards,
>>
>> Tim Schneider
>>
>>
>
^ permalink raw reply
* Re: missing piece for starting device on embedded system
From: Kalle Valo @ 2009-07-17 6:25 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-wireless
In-Reply-To: <9e4733910907161915y56bb0682wde4cbcb6b38cce48@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> writes:
> On Thu, Jul 16, 2009 at 9:19 PM, Jon Smirl<jonsmirl@gmail.com> wrote:
>> I must be missing a piece of the necessary environment to get wireless
>> started...
>> This is an embedded environment that has not had wireless previously.
>
> Duh.. the device does not show in ifconfig until I run "ifconfig wlan0 up".
'ifconfig -a' shows all interfaces, even the ones which are down.
--
Kalle Valo
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Holger Schurig @ 2009-07-17 6:06 UTC (permalink / raw)
To: linux-wireless, Joel Roth; +Cc: Johannes Berg, Bob Copeland
In-Reply-To: <20090716100743.GC3867@sprite>
> 1. kernel and driver setup - use compat-wireless
>
> 2. set wireless interface to UP
>
> ifconfig <interface> up
>
> 3. find available networks using
>
> iw dev <interface> scan
> or
> iwlist <interface> scan
And maybe here the tools could emit "interface <interface> isn't
up" as a more specfic error message ?!?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: missing piece for starting device on embedded system
From: Jon Smirl @ 2009-07-17 2:15 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <9e4733910907161819r4202b06fib34027bba1b672d2@mail.gmail.com>
On Thu, Jul 16, 2009 at 9:19 PM, Jon Smirl<jonsmirl@gmail.com> wrote:
> I must be missing a piece of the necessary environment to get wireless
> started...
> This is an embedded environment that has not had wireless previously.
Duh.. the device does not show in ifconfig until I run "ifconfig wlan0 up".
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* missing piece for starting device on embedded system
From: Jon Smirl @ 2009-07-17 1:19 UTC (permalink / raw)
To: linux-wireless
I must be missing a piece of the necessary environment to get wireless
started...
This is an embedded environment that has not had wireless previously.
When I plug my rt73 adapter in:
usb 1-2: USB disconnect, address 6
usb 1-2: new full speed USB device using ppc-of-ohci and address 7
usb 1-2: configuration #1 chosen from 1 choice
phy3 -> rt73usb_validate_eeprom: EEPROM recovery - NIC: 0xffef
phy3 -> rt73usb_validate_eeprom: EEPROM recovery - Led: 0xe000
phy3 -> rt73usb_validate_eeprom: EEPROM recovery - RSSI OFFSET A: 0x0000
phy3 -> rt2x00_set_chip: Info - Chipset detected - rt: 1300, rf: 0002,
rev: 0002573a.
phy3: Selected rate control algorithm 'minstrel'
-----------
UDEV [1247788838.265890] add /class/net/wmaster0 (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/class/net/wmaster0
SUBSYSTEM=net
INTERFACE=wmaster0
IFINDEX=9
SEQNUM=594
UDEV [1247788838.268243] add /class/net/wlan0 (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/class/net/wlan0
SUBSYSTEM=net
INTERFACE=wlan0
IFINDEX=10
SEQNUM=595
MATCHADDR=00:18:f3:2f:0a:de
MATCHIFTYPE=1
COMMENT=USB device 0x:0x (rt73usb)
----------
But I never get a request_firmware event. This seems to be because the
adapter 's start() function is never called.
I'm missing some piece of the system - a kernel module or some part of
user space.
Can someone give me a clue on how to debug this?
I though it was missing crda but adding that didn't fix it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Using GeoClue to send a Linux wireless regulatory hint
From: Luis R. Rodriguez @ 2009-07-17 1:10 UTC (permalink / raw)
To: GeoClue, linux-wireless; +Cc: till.kamppeter, desrt, Dan Winship, Tim Gardner
The GSoC project to integrate GeoClue to GNOME and eventually send
regulatory hint information to the kernel [1] will not be completed
through GSoC. Since I am not sure if the student will be interested in
following up on this project idea outside the scope of GSoC I'm
looking for advice to better get an idea of what it is exactly we
should be looking forward to change to get information to the kernel
to enhance regulatory support using GeoClue. At the very least I'd
like to come to some conclusion as to where it is best to put software
to send information to the kernel to help distributions.
The current best alternative I've seen is to read the current timezone
information and extract the country from that. That is how John
implemented it for Fedora. This may be enough but GeoClue should
provide better accuracy. All we need in the kernel is to determine the
country you are on. The user can obviously set this themselves during
a distribution install, but it may make sense to just use GeoClue for
this. Under the assumption that using GeoClue is the way to go how
should we do this?
For the GSoC project I was initially suggesting for Network Manager to
get GeoClue integration and then have Network Manager send the
regulatory hint once a country was determined through either user
input or through GeoClue magic. After some discussions with Jouni
about this he convinced me this may not be the best place for this. So
if not Network Manager, where? Do we want a GNOME location aware panel
under System->Administration? Is it as simple as that? If not are
there any other suggestions?
If you fwd this to another list for discussion please do CC me.
[1] http://wireless.kernel.org/en/developers/GSoC/2009/GeoClue_regulatory
Luis
^ permalink raw reply
* Re: SDIO Stack and Device Support
From: Bob Copeland @ 2009-07-17 0:47 UTC (permalink / raw)
To: Robert Emanuele; +Cc: linux-wireless
In-Reply-To: <9f53b4330907161718ydbac090k2afc7a749fc9f6f2@mail.gmail.com>
On Thu, Jul 16, 2009 at 8:18 PM, Robert Emanuele<rob@emanuele.us> wrote:
> Greetings all,
Hi! (Added linux-wireless to cc)
> I'm evaluating the potential of getting a Wireless SDIO card to work
> with the 2.6 kernel. So far all I see in the kernel is support for an
> SDIO UART. There is a patch on sourceforge for an SDIO stack and
> drivers from Atheros but that is for 2.6.18. Is there current support
> for other SDIO wireless devices in the kernel?
There is SDIO support for libertas already, and a driver for TI 1251/1271
is in the works. Wireless drivers will be under drivers/net/wireless/
regardless of bus type.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Thomas Backlund @ 2009-07-17 0:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <1247788728.1055.15.camel@johannes.local>
Johannes Berg skrev:
> On Fri, 2009-07-17 at 02:35 +0300, Thomas Backlund wrote:
>
>>> So far so good. Your platform's soft-switch is wired to the card's hard
>>> kill line. Mind trying
>>>
>>> ./rfkill unblock 0
>>>
>>> (or whatever ID the acer-wireless has) at this point to see what
>>> happens? I would hope it goes back to the working state.
>>>
>> Nothing happends...
>>
>> It does not change anything on either acer-wireless or phy0
>
> Humm. Can you try this?
>
> johannes
>
> --- wireless-testing.orig/drivers/platform/x86/acer-wmi.c 2009-07-17 00:19:20.000000000 +0200
> +++ wireless-testing/drivers/platform/x86/acer-wmi.c 2009-07-17 01:58:11.000000000 +0200
> @@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, b
> {
> acpi_status status;
> u32 cap = (unsigned long)data;
> - status = set_u32(!!blocked, cap);
> + status = set_u32(!blocked, cap);
> if (ACPI_FAILURE(status))
> return -ENODEV;
> return 0;
>
Funny how easy the fix was...
Now the rfkill works... ;-)
I can enable/disable it as many times as I want...
So it's:
Tested-by: Thomas Backlund <tmb@mandriva.org>
The difference is that before this patch, bluetooth & wireless were both
disabled at boot...
With this patch the system boots up with bluetooth & wireless is enabled
by default (But it's not a regression as it now behaves just like 2.6.29
& 2.6.30 series kernels)
^ permalink raw reply
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Marcel Holtmann @ 2009-07-17 0:07 UTC (permalink / raw)
To: David Miller
Cc: tomasw, yi.zhu, drzeus-list, netdev, linux-wireless, linux-kernel
In-Reply-To: <20090716.130726.220404456.davem@davemloft.net>
Hi Dave,
> >> > > Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
> >> >
> >> > BTW, subject should be "iwmc3200".
> >>
> >> Thanks. I'll address all comments although I'm not sure how to split
> >> the patch since adding SDIO_VENDOR_ID_INTEL to sdio_ids.h it affects
> >> all the drivers anyhow, so I'm suggesting to route it through netdev.
> >
> > I think it is best that you take the whole patch via net-next-2.6 to
> > avoid breakage during the next merge window.
>
> Fair enough.
after Tomas sent the revised version of course :)
Regards
Marcel
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Luis R. Rodriguez @ 2009-07-16 23:59 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Jon Fairbairn, linux-wireless
In-Reply-To: <20090716235013.GA26789@jm.kir.nu>
On Thu, Jul 16, 2009 at 4:50 PM, Jouni Malinen<j@w1.fi> wrote:
> On Thu, Jul 16, 2009 at 05:39:47PM +0100, Jon Fairbairn wrote:
>> "Luis R. Rodriguez" <mcgrof@gmail.com>
>> writes:
>> > http://wireless.kernel.org/en/users/Drivers/ath9k
>
>> Thanks, but I've seen that page and "products with supported ath9k
>> cards" points to a page that lists "Laptops with ath9k cards" (I'm
>> looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
>> cards". Before I can buy a card, I need to know what it is called in the
>> shops (on-line or otherwise), not what chipset it has.
>
> I don't know how the product list ended up being split that way, but the
> "laptops" page does actually include number of D-Link adapters,
> including a PCIe desktop adapter (D-Link DWA-556) that seems to match
> the request. I saw it at Fry's last week and it does indeed look like a
> PCIe card.
Sorry that was my doing, I forgot there were a few external cards
available, I've updated the wiki to reflect this and added a new
external cards page:
http://wireless.kernel.org/en/users/Drivers/ath9k/products/external
Luis
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Johannes Berg @ 2009-07-16 23:58 UTC (permalink / raw)
To: Thomas Backlund; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FB944.90709@mandriva.org>
On Fri, 2009-07-17 at 02:35 +0300, Thomas Backlund wrote:
> > So far so good. Your platform's soft-switch is wired to the card's hard
> > kill line. Mind trying
> >
> > ./rfkill unblock 0
> >
> > (or whatever ID the acer-wireless has) at this point to see what
> > happens? I would hope it goes back to the working state.
> >
>
> Nothing happends...
>
> It does not change anything on either acer-wireless or phy0
Humm. Can you try this?
johannes
--- wireless-testing.orig/drivers/platform/x86/acer-wmi.c 2009-07-17 00:19:20.000000000 +0200
+++ wireless-testing/drivers/platform/x86/acer-wmi.c 2009-07-17 01:58:11.000000000 +0200
@@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, b
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!!blocked, cap);
+ status = set_u32(!blocked, cap);
if (ACPI_FAILURE(status))
return -ENODEV;
return 0;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox