* A file to print the release of loaded compat-wireless stuff
From: Luis R. Rodriguez @ 2010-05-04 20:44 UTC (permalink / raw)
To: linux-wireless
It seems there is a reasonable need to find out what version of
compat-wireless you have running. This will be a dated thing when
based on linux-next but more importantly it will contain the 2.6.3x.y
release the release was based on for the stable releases. Any ideas of
what filesystem API to use for this, I was thinking maybe a simple
sysfs entry for the compat module. Thoughts, preferences?
Luis
^ permalink raw reply
* Re: mac80211/ath9k: HT rates in Mesh
From: Luis R. Rodriguez @ 2010-05-04 20:20 UTC (permalink / raw)
To: Johannes Berg, Javier Cardona
Cc: Luis Rodriguez, Mathieu Olivari, linux-wireless
In-Reply-To: <1273004047.3673.26.camel@jlt3.sipsolutions.net>
Adding Javier.
On Tue, May 04, 2010 at 01:14:07PM -0700, Johannes Berg wrote:
> On Tue, 2010-05-04 at 12:52 -0700, Luis R. Rodriguez wrote:
> > Cc'ing linux-wireless.
> >
> > On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> > > BTW, do you know if HT is supported in Mesh ?
> >
> > This would involve doing the same as for IBSS that Benoit
> > is doing, someone with good will would have to do it. It should
> > be fairly easy to review the patches implemented by Benoit to
> > port to Mesh but there may be some unresolved things I may be
> > overlooking.
>
> Last I heard mesh wasn't supporting HT at all due to whatever issues?
> Maybe protection or something?
Oh .. yeah... it was aggregation that was not allowed. So the only
other change you'd have to do is to disable aggregation IIRC unless
something else has changed on the latest 11s drafts.
Luis
^ permalink raw reply
* Re: mac80211/ath9k: HT rates in Mesh
From: Johannes Berg @ 2010-05-04 20:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Mathieu Olivari, Luis Rodriguez, linux-wireless
In-Reply-To: <20100504195211.GG2624@tux>
On Tue, 2010-05-04 at 12:52 -0700, Luis R. Rodriguez wrote:
> Cc'ing linux-wireless.
>
> On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> > BTW, do you know if HT is supported in Mesh ?
>
> This would involve doing the same as for IBSS that Benoit
> is doing, someone with good will would have to do it. It should
> be fairly easy to review the patches implemented by Benoit to
> port to Mesh but there may be some unresolved things I may be
> overlooking.
Last I heard mesh wasn't supporting HT at all due to whatever issues?
Maybe protection or something?
johannes
^ permalink raw reply
* [PATCH] rtl8187: use SET_IEEE80211_PERM_ADDR
From: John W. Linville @ 2010-05-04 19:53 UTC (permalink / raw)
To: linux-wireless; +Cc: herton, htl10, Larry.Finger, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 0fb850e..ef66a5e 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1332,6 +1332,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
u16 txpwr, reg;
u16 product_id = le16_to_cpu(udev->descriptor.idProduct);
int err, i;
+ u8 mac_addr[ETH_ALEN];
dev = ieee80211_alloc_hw(sizeof(*priv), &rtl8187_ops);
if (!dev) {
@@ -1389,12 +1390,13 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
udelay(10);
eeprom_93cx6_multiread(&eeprom, RTL8187_EEPROM_MAC_ADDR,
- (__le16 __force *)dev->wiphy->perm_addr, 3);
- if (!is_valid_ether_addr(dev->wiphy->perm_addr)) {
+ (__le16 __force *)mac_addr, 3);
+ if (!is_valid_ether_addr(mac_addr)) {
printk(KERN_WARNING "rtl8187: Invalid hwaddr! Using randomly "
"generated MAC address\n");
- random_ether_addr(dev->wiphy->perm_addr);
+ random_ether_addr(mac_addr);
}
+ SET_IEEE80211_PERM_ADDR(dev, mac_addr);
channel = priv->channels;
for (i = 0; i < 3; i++) {
@@ -1525,7 +1527,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
skb_queue_head_init(&priv->b_tx_status.queue);
printk(KERN_INFO "%s: hwaddr %pM, %s V%d + %s, rfkill mask %d\n",
- wiphy_name(dev->wiphy), dev->wiphy->perm_addr,
+ wiphy_name(dev->wiphy), mac_addr,
chip_name, priv->asic_rev, priv->rf->name, priv->rfkill_mask);
#ifdef CONFIG_RTL8187_LEDS
--
1.6.6.1
^ permalink raw reply related
* [PATCH] rtl8180: use SET_IEEE80211_PERM_ADDR
From: John W. Linville @ 2010-05-04 19:53 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 4907fef..093b93d 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -827,6 +827,7 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
const char *chip_name, *rf_name = NULL;
u32 reg;
u16 eeprom_val;
+ u8 mac_addr[ETH_ALEN];
err = pci_enable_device(pdev);
if (err) {
@@ -987,12 +988,13 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
eeprom_93cx6_read(&eeprom, 0x19, &priv->rfparam);
}
- eeprom_93cx6_multiread(&eeprom, 0x7, (__le16 *)dev->wiphy->perm_addr, 3);
- if (!is_valid_ether_addr(dev->wiphy->perm_addr)) {
+ eeprom_93cx6_multiread(&eeprom, 0x7, (__le16 *)mac_addr, 3);
+ if (!is_valid_ether_addr(mac_addr)) {
printk(KERN_WARNING "%s (rtl8180): Invalid hwaddr! Using"
" randomly generated MAC addr\n", pci_name(pdev));
- random_ether_addr(dev->wiphy->perm_addr);
+ random_ether_addr(mac_addr);
}
+ SET_IEEE80211_PERM_ADDR(dev, mac_addr);
/* CCK TX power */
for (i = 0; i < 14; i += 2) {
@@ -1024,7 +1026,7 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
}
printk(KERN_INFO "%s: hwaddr %pM, %s + %s\n",
- wiphy_name(dev->wiphy), dev->wiphy->perm_addr,
+ wiphy_name(dev->wiphy), mac_addr,
chip_name, priv->rf->name);
return 0;
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 19:55 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Luis Rodriguez, linux-wireless, John W. Linville
In-Reply-To: <4BE0773A.8090009@openwrt.org>
On Tue, May 04, 2010 at 12:36:26PM -0700, Felix Fietkau wrote:
> On 2010-05-04 8:09 PM, Luis R. Rodriguez wrote:
> > On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> >> Atheros hardware supports receiving frames that span multiple
> >> descriptors and buffers. In this case, the rx status of every
> >> descriptor except for the last one is invalid and may contain random
> >> data. Because the driver does not support this, it needs to drop such
> >> frames.
> >>
> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> >> ---
> >> --- a/drivers/net/wireless/ath/ath9k/common.c
> >> +++ b/drivers/net/wireless/ath/ath9k/common.c
> >> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> >> * rs_more indicates chained descriptors which can be used
> >> * to link buffers together for a sort of scatter-gather
> >> * operation.
> >> - *
> >> + * reject the frame, we don't support scatter-gather yet and
> >> + * the frame is probably corrupt anyway
> >> + */
> >> + if (rx_stats->rs_more)
> >> + return false;
> >
> > Actually this is required by ath9k_htc, it does process these, but
> > ath9k doesn't so this could be done within ath9k itself.
> I don't see any place in ath9k_htc that processes rs_more.
Odd, when I worked on it, I had to use this, let me check with today's
code and get back to this thread.
> And even if
> it did, processing the rx status of a frame that has more descriptors
> chained after it would be wrong, since the rx status is only valid for
> the last frame of the descriptor chain.
This is true.
> I think my patch would work fine for ath9k_htc as well.
We should test just to be sure. Would hate to request for a revert
for something we could have just prevented with proper testing/review.
I can test this in a bit I think.
Luis
^ permalink raw reply
* Re: mac80211/ath9k: HT rates in Mesh
From: Luis R. Rodriguez @ 2010-05-04 19:52 UTC (permalink / raw)
To: Mathieu Olivari; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <93781E992CBA7843962D8B0E7D683F3C1116C465EA@SC1EXMB-MBCL.global.atheros.com>
Cc'ing linux-wireless.
On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> BTW, do you know if HT is supported in Mesh ?
This would involve doing the same as for IBSS that Benoit
is doing, someone with good will would have to do it. It should
be fairly easy to review the patches implemented by Benoit to
port to Mesh but there may be some unresolved things I may be
overlooking.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 19:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Luis Rodriguez, Felix Fietkau, linux-wireless
In-Reply-To: <20100504183613.GC21043@tuxdriver.com>
On Tue, May 04, 2010 at 11:36:13AM -0700, John W. Linville wrote:
> On Tue, May 04, 2010 at 11:09:32AM -0700, Luis R. Rodriguez wrote:
> > On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> > > Atheros hardware supports receiving frames that span multiple
> > > descriptors and buffers. In this case, the rx status of every
> > > descriptor except for the last one is invalid and may contain random
> > > data. Because the driver does not support this, it needs to drop such
> > > frames.
> > >
> > > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > > ---
> > > --- a/drivers/net/wireless/ath/ath9k/common.c
> > > +++ b/drivers/net/wireless/ath/ath9k/common.c
> > > @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> > > * rs_more indicates chained descriptors which can be used
> > > * to link buffers together for a sort of scatter-gather
> > > * operation.
> > > - *
> > > + * reject the frame, we don't support scatter-gather yet and
> > > + * the frame is probably corrupt anyway
> > > + */
> > > + if (rx_stats->rs_more)
> > > + return false;
> >
> > Actually this is required by ath9k_htc, it does process these, but
> > ath9k doesn't so this could be done within ath9k itself.
>
> I'm sorry, that is a bit unclear to me. Are you NAKing the patch?
Yes, I am NAK'ing it, I should have been clearer about that, sorry.
The reason is that ath9k_htc *depends* on rs_more stuff because the
USB frames it receives *are* split up and to RX them we decouple
them. With this patch you'd break ath9k_htc considerably.
> Or saying that the patch is fine but another patch is needed on top?
My suggestion is that this change can be made but only on the
ath9k RX path, instead of the comon path so a separate patch would
be needed.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Felix Fietkau @ 2010-05-04 19:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, John W. Linville
In-Reply-To: <u2q43e72e891005041109i5106ba24ma7345c4f4c4fde21@mail.gmail.com>
On 2010-05-04 8:09 PM, Luis R. Rodriguez wrote:
> On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Atheros hardware supports receiving frames that span multiple
>> descriptors and buffers. In this case, the rx status of every
>> descriptor except for the last one is invalid and may contain random
>> data. Because the driver does not support this, it needs to drop such
>> frames.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> ---
>> --- a/drivers/net/wireless/ath/ath9k/common.c
>> +++ b/drivers/net/wireless/ath/ath9k/common.c
>> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
>> * rs_more indicates chained descriptors which can be used
>> * to link buffers together for a sort of scatter-gather
>> * operation.
>> - *
>> + * reject the frame, we don't support scatter-gather yet and
>> + * the frame is probably corrupt anyway
>> + */
>> + if (rx_stats->rs_more)
>> + return false;
>
> Actually this is required by ath9k_htc, it does process these, but
> ath9k doesn't so this could be done within ath9k itself.
I don't see any place in ath9k_htc that processes rs_more. And even if
it did, processing the rx status of a frame that has more descriptors
chained after it would be wrong, since the rx status is only valid for
the last frame of the descriptor chain.
I think my patch would work fine for ath9k_htc as well.
- Felix
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-04 19:13 UTC (permalink / raw)
To: Walter Goldens
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users,
Luis R. Rodriguez
In-Reply-To: <282593.4376.qm@web56802.mail.re3.yahoo.com>
On 05/04/10 21:09, Walter Goldens wrote:
>
>> Now that RT30xx support is at the
>> same level as RT28xx support we can enable
>> these devices by default.
>
> Shouldn't support for RT30xx be enabled by default for compat-wireless as well?
>
compat-wireless will be updated automatically once wireless-next-2.6 gets merged
into linux-next. Just have a bit of patience.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Walter Goldens @ 2010-05-04 19:09 UTC (permalink / raw)
To: John W. Linville, Gertjan van Wingerde
Cc: Ivo van Doorn, linux-wireless, users, Luis R. Rodriguez
In-Reply-To: <1272919385-18004-3-git-send-email-gwingerde@gmail.com>
> Now that RT30xx support is at the
> same level as RT28xx support we can enable
> these devices by default.
Shouldn't support for RT30xx be enabled by default for compat-wireless as well?
Walter.
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: John W. Linville @ 2010-05-04 18:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <u2q43e72e891005041109i5106ba24ma7345c4f4c4fde21@mail.gmail.com>
On Tue, May 04, 2010 at 11:09:32AM -0700, Luis R. Rodriguez wrote:
> On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> > Atheros hardware supports receiving frames that span multiple
> > descriptors and buffers. In this case, the rx status of every
> > descriptor except for the last one is invalid and may contain random
> > data. Because the driver does not support this, it needs to drop such
> > frames.
> >
> > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > ---
> > --- a/drivers/net/wireless/ath/ath9k/common.c
> > +++ b/drivers/net/wireless/ath/ath9k/common.c
> > @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> > * rs_more indicates chained descriptors which can be used
> > * to link buffers together for a sort of scatter-gather
> > * operation.
> > - *
> > + * reject the frame, we don't support scatter-gather yet and
> > + * the frame is probably corrupt anyway
> > + */
> > + if (rx_stats->rs_more)
> > + return false;
>
> Actually this is required by ath9k_htc, it does process these, but
> ath9k doesn't so this could be done within ath9k itself.
I'm sorry, that is a bit unclear to me. Are you NAKing the patch?
Or saying that the patch is fine but another patch is needed on top?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Kalle Valo @ 2010-05-04 18:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <w2q43e72e891005031610uf6b912aduf271b0a97933d68a@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
> Can you enable ATH_DBG_XMIT on the box and see if this comes up?
>
> ATH_DBG_XMIT = 0x00000080,
>
> So just modprobe ath9k debug=0x80. I'll send an RFT patch soon.
I'm travelling right now and the AP is at home. I can test it
when I get back home, hopefully in two weeks.
/me prays for the volcano gods
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] compat-wireless, unload rt2800usb
From: Luis R. Rodriguez @ 2010-05-04 18:23 UTC (permalink / raw)
To: Walter Goldens; +Cc: linux-wireless, users
In-Reply-To: <829828.92087.qm@web56808.mail.re3.yahoo.com>
On Tue, May 4, 2010 at 7:30 AM, Walter Goldens <goldenstranger@yahoo.com> wrote:
>
> Signed-off-by: Walter Goldens <goldenstranger@yahoo,com>
Applied, thanks!
Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-04 18:22 UTC (permalink / raw)
To: John W. Linville
Cc: Pavel Roskin, Stefan Lippers-Hollmann, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <20100504171720.GA21043@tuxdriver.com>
On 05/04/10 19:17, John W. Linville wrote:
> On Tue, May 04, 2010 at 05:31:09AM +0200, Gertjan van Wingerde wrote:
>
>> To be honest, at the moment I would just change the default from 'n' to 'y'
>> for one kernel cycle, and then remove the entire option in the next kernel
>> release.
>> This is just to make it easier to revert back if for some reasons problems
>> arise with the rt30xx support.
>> The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
>> symbols, but that can only happen if the devices denoted by these symbols
>> are properly supported.
>>
>> John, I leave it up to you, but for me my original patch should be merged, and
>> I'll send an equivalent patch for Stefan's one for the next kernel release.
>
> Since the options are already inside "if RT2800PCI" and "if RT2800USB"
> blocks, I don't see why anyone should object to the boolean defaulting
> to 'y'. It's not as if you are enabling a new driver.
>
> I think Gertjan's proposal seems reasonable -- just don't forget! :-)
> I would suggest a feature-removal-schedlue.txt patch, but I don't
> know that it is worth the trouble.
>
Don't worry. I won't forget. I introduced these configuration items simply to
be able to disable non-functional devices from the driver. Once all devices are
working properly I will remove all of these Kconfig variables.
Feature-removal-schedule.txt seems like a lot of overkill, as we are not actually
removing features, we are simply unconditionally enabling code.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] cfg80211: Check for channel HT capabilities in an IBSS
From: Luis R. Rodriguez @ 2010-05-04 18:14 UTC (permalink / raw)
To: Benoit Papillault; +Cc: johannes, linux-wireless
In-Reply-To: <1272955622-6987-2-git-send-email-benoit.papillault@free.fr>
On Mon, May 3, 2010 at 11:47 PM, Benoit Papillault
<benoit.papillault@free.fr> wrote:
> When configuring an HT IBSS, we need to check if the specified channel
> is capable of ht40+, ht40- or ht20.
>
> Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
> ---
> net/wireless/nl80211.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 8da9823..0a82623 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -3858,11 +3858,11 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
> ibss.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
> }
>
> - ibss.channel = ieee80211_get_channel(wiphy,
> - nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
> + ibss.channel = rdev_freq_to_chan(rdev,
> + nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]),
> + channel_type);
> if (!ibss.channel ||
> - ibss.channel->flags & IEEE80211_CHAN_NO_IBSS ||
> - ibss.channel->flags & IEEE80211_CHAN_DISABLED) {
> + ibss.channel->flags & IEEE80211_CHAN_NO_IBSS) {
> err = -EINVAL;
Why is the disabled channel check being removed here?
Luis
^ permalink raw reply
* Re: Philosophical question about channel selection
From: Luis R. Rodriguez @ 2010-05-04 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4BE05F6B.3060705@lwfinger.net>
On Tue, May 4, 2010 at 10:54 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> A question has been posed on the openSUSE wireless forum that I do not
> know how to answer.
>
> In a given neighborhood, there are 802.11g APs at roughly the same
> strength on channels 1 and 10 (yes - 10). As this configuration ensures
> that there are no clear channels, what would be the best choice? As I
> see it, the options are ch 1 with interference across the full channel
> width, ch 6 with interference only at the upper end, or ch 11. Which
> would get the best throughput?
Depends on how busy those APs are :) I'd use a minstrel type algorithm
to test :P
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 18:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville
In-Reply-To: <4BDFD3C1.4000209@openwrt.org>
On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> Atheros hardware supports receiving frames that span multiple
> descriptors and buffers. In this case, the rx status of every
> descriptor except for the last one is invalid and may contain random
> data. Because the driver does not support this, it needs to drop such
> frames.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> --- a/drivers/net/wireless/ath/ath9k/common.c
> +++ b/drivers/net/wireless/ath/ath9k/common.c
> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> * rs_more indicates chained descriptors which can be used
> * to link buffers together for a sort of scatter-gather
> * operation.
> - *
> + * reject the frame, we don't support scatter-gather yet and
> + * the frame is probably corrupt anyway
> + */
> + if (rx_stats->rs_more)
> + return false;
Actually this is required by ath9k_htc, it does process these, but
ath9k doesn't so this could be done within ath9k itself.
Luis
^ permalink raw reply
* Philosophical question about channel selection
From: Larry Finger @ 2010-05-04 17:54 UTC (permalink / raw)
To: wireless
A question has been posed on the openSUSE wireless forum that I do not
know how to answer.
In a given neighborhood, there are 802.11g APs at roughly the same
strength on channels 1 and 10 (yes - 10). As this configuration ensures
that there are no clear channels, what would be the best choice? As I
see it, the options are ch 1 with interference across the full channel
width, ch 6 with interference only at the upper end, or ch 11. Which
would get the best throughput?
Thanks,
Larry
^ permalink raw reply
* Re: [Fwd: USB AP card and/or rt2870 issue]
From: GNUtoo @ 2010-05-04 17:33 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: linux-wireless
In-Reply-To: <q2na32f33a41005040832n7d50a934q4ff0a6a4dde53f28@mail.gmail.com>
On Tue, 2010-05-04 at 17:32 +0200, Ivo Van Doorn wrote:
> On Tue, May 4, 2010 at 5:28 PM, GNUtoo <GNUtoo@no-log.org> wrote:
> > hi, I sent the following mail(attached) to the hostapd mailing list,but
> > Now I think It's a driver issue.
> > Is it possible to make an access point with a rt2870 card.
> > Does the driver support it?
> > I don't have much hope for now as it is a staging driver...and it
> > displayed a warning about that in dmesg...
>
> You could try compat-wireless and the rt2800usb driver.
> That one actually does have Master mode support, but doesn't work
> on all cards yet. rt2800usb is also found in the main kernel tree, but
> using compat-wireless will give you the most recent version with
> _many_ fixes applied to it. :)
I tried that,
hostapd put the card in master mode
unfortunately once in master mode,impossible to find the essid when
scanning.
Denis.
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: John W. Linville @ 2010-05-04 17:17 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Pavel Roskin, Stefan Lippers-Hollmann, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <4BDF94FD.7050606@gmail.com>
On Tue, May 04, 2010 at 05:31:09AM +0200, Gertjan van Wingerde wrote:
> To be honest, at the moment I would just change the default from 'n' to 'y'
> for one kernel cycle, and then remove the entire option in the next kernel
> release.
> This is just to make it easier to revert back if for some reasons problems
> arise with the rt30xx support.
> The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
> symbols, but that can only happen if the devices denoted by these symbols
> are properly supported.
>
> John, I leave it up to you, but for me my original patch should be merged, and
> I'll send an equivalent patch for Stefan's one for the next kernel release.
Since the options are already inside "if RT2800PCI" and "if RT2800USB"
blocks, I don't see why anyone should object to the boolean defaulting
to 'y'. It's not as if you are enabling a new driver.
I think Gertjan's proposal seems reasonable -- just don't forget! :-)
I would suggest a feature-removal-schedlue.txt patch, but I don't
know that it is worth the trouble.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: wl1251_sdio PSM
From: Grazvydas Ignotas @ 2010-05-04 16:19 UTC (permalink / raw)
To: gnutoo; +Cc: linux-wireless
In-Reply-To: <1272986655.2486.42.camel@gnutoo-desktop>
On Tue, May 4, 2010 at 6:24 PM, gnutoo <GNUtoo@no-log.org> wrote:
>
>> You need a few more patches for PS to work (on top of current compat-wireless):
>> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
>> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
>>
>> I'm working on mainline mergeable versions of those..
> 2 things:
> *I rebased the patches against lastest compat wireless but I don't know
> where to send them...
> Basically or they apply or they are already in compat-wireless(verified)
> here are the one which applies:
> 0007-wl1251-read-default-MAC-address-from-EEPROM-when-ava.patch
> 0008-wl1251-register-platform_device-to-pass-board-data.patch
> 0009-wl1251-add-support-for-dedicated-IRQ-line.patch
> 0010-wl1251-use-sdio_readb_ext-for-ELP-to-work.patch
> 0011-wl1251-add-reset-handling.patch
> 0013-wl1251-prevent-scan-when-connected.patch
>
> against compat-wireless-2010-04-26
>From your list 0007-0009 are on their way to mainline, 0010-0013 are
not mainline friendly (0010 needs a new function in MMC subsystem
which I sent for review, 0011 depends on some code from Android tree,
0013 is a hack).
> By the way we can't make ad-hoc work,Is ad-hoc supported by the driver?
AFAIK it is not.
Grazvydas
^ permalink raw reply
* Re: [Fwd: USB AP card and/or rt2870 issue]
From: Ivo Van Doorn @ 2010-05-04 15:32 UTC (permalink / raw)
To: GNUtoo; +Cc: linux-wireless
In-Reply-To: <1272986923.2486.45.camel@gnutoo-desktop>
On Tue, May 4, 2010 at 5:28 PM, GNUtoo <GNUtoo@no-log.org> wrote:
> hi, I sent the following mail(attached) to the hostapd mailing list,but
> Now I think It's a driver issue.
> Is it possible to make an access point with a rt2870 card.
> Does the driver support it?
> I don't have much hope for now as it is a staging driver...and it
> displayed a warning about that in dmesg...
You could try compat-wireless and the rt2800usb driver.
That one actually does have Master mode support, but doesn't work
on all cards yet. rt2800usb is also found in the main kernel tree, but
using compat-wireless will give you the most recent version with
_many_ fixes applied to it. :)
Ivo
^ permalink raw reply
* [Fwd: USB AP card and/or rt2870 issue]
From: GNUtoo @ 2010-05-04 15:28 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
hi, I sent the following mail(attached) to the hostapd mailing list,but
Now I think It's a driver issue.
Is it possible to make an access point with a rt2870 card.
Does the driver support it?
I don't have much hope for now as it is a staging driver...and it
displayed a warning about that in dmesg...
Denis.
[-- Attachment #2: Forwarded message - USB AP card and/or rt2870 issue --]
[-- Type: message/rfc822, Size: 6814 bytes --]
From: GNUtoo <GNUtoo@no-log.org>
To: hostap@lists.shmoo.com
Subject: USB AP card and/or rt2870 issue
Date: Sat, 24 Apr 2010 17:51:41 +0200
Message-ID: <1272124301.2536.18.camel@gnutoo-desktop>
hi,I'm thinking about replacing my pentium III 500 router with something
like a sheevaplug.
The sheevaplug-like hardware do not have a pci slot or a wireless card
supported that can do access point(if they have one(depend on the
versions)).
So I'm looking for an usb card that can do AP
Someone wanted the exact same thing than me,but for other kind of
embedded devices.he tested a rt8070 and hostap displayed a line with the
ESSID,but the access point essid didn't appear when another computer
scanned it,association was also impossible.
I bought a card with the same chipset.
with my distribution(based on ubuntu hardy) I had the same results.
But...
I wanted and planed to try wireless-compat,libnl2,and hostapd from git:
(that's why I bought it,I was thinking that I could make it work)
here are the results:
With a card that does not support AP mode:
root@gnutoo-desktop:/usr/local/bin# LD_LIBRARY_PATH=/usr/local/lib/
hostapd -ddd /usr/local/etc/hostapd.conf
Configuration file: /usr/local/etc/hostapd.conf
nl80211: Add own interface ifindex 11
nl80211: Failed to set interface 11 to mode 3: -95 (Operation not
supported)
nl80211: Failed to set interface 11 to mode 3: -95 (Operation not
supported)
nl80211: Interface mode change to 3 from 0 failed
nl80211: Failed to set interface wlan2 into AP mode
nl80211 driver initialization failed.
ELOOP: remaining socket: sock=4 eloop_data=0x8c26718 user_data=0x8c26bf8
handler=0x8072580
ELOOP: remaining socket: sock=6 eloop_data=0x8c286e8 user_data=(nil)
handler=0x807be40
With the rt2870 card:
root@gnutoo-desktop:/usr/local/bin# LD_LIBRARY_PATH=/usr/local/lib/
hostapd -ddd /usr/local/etc/hostapd.conf
Configuration file: /usr/local/etc/hostapd.conf
nl80211: Register Action command failed: ret=-19 (No such device)
nl80211: Register Action match - hexdump(len=1): 06
nl80211: Failed to register Action frame processing - ignore for now
nl80211: Add own interface ifindex 10
nl80211: Failed to set interface 10 to mode 3: -19 (No such device)
nl80211: Failed to set interface 10 to mode 3: -19 (No such device)
nl80211: Interface mode change to 3 from 0 failed
nl80211: Failed to set interface wlan0 into AP mode
nl80211 driver initialization failed.
ELOOP: remaining socket: sock=4 eloop_data=0x9fca718 user_data=0x9fcabf8
handler=0x8072580
ELOOP: remaining socket: sock=6 eloop_data=0x9fcc6e8 user_data=(nil)
handler=0x807be40
here's the configuration(interface was changed between the 2 cards)
interface=wlan0
driver=nl80211
ssid=ralink
channel=2
hw_mode=g
here are the version used:
hostapd: 0b86f67a2970403d1b1b6d34ce49f5485ef5dbb3
libnl2: d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
compat-wireless: compat-wireless-2010-04-23.tar.bz2
here is the config of hostapd compilation:
root@gnutoo-desktop:~/wireless/hostap/hostapd# cat .config | sed
's/#.*//' | sed '/^$/d'
CONFIG_DRIVER_NL80211=y
LIBNL=/usr/local
CFLAGS += -I$(LIBNL)/include
LIBS += -L$(LIBNL)/lib
CONFIG_LIBNL20=y
CONFIG_IAPP=y
CONFIG_RSN_PREAUTH=y
CONFIG_PEERKEY=y
CONFIG_EAP=y
CONFIG_EAP_MD5=y
CONFIG_EAP_TLS=y
CONFIG_EAP_MSCHAPV2=y
CONFIG_EAP_PEAP=y
CONFIG_EAP_GTC=y
CONFIG_EAP_TTLS=y
CONFIG_PKCS12=y
CONFIG_IPV6=y
I started to post here because I'm not shure if it's an hostap,a libnl2
or a wireless-dev problem.
I hope the problem can be fixed(or that after time(and effort of the
developers) it would be fixed,so I would only have to wait,I hope not
too long),else I would need to search for another card.
Denis.
_______________________________________________
HostAP mailing list
HostAP@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
^ permalink raw reply
* Re: wl1251_sdio PSM
From: gnutoo @ 2010-05-04 15:24 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <loom.20100427T143119-272@post.gmane.org>
> You need a few more patches for PS to work (on top of current compat-wireless):
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
>
> I'm working on mainline mergeable versions of those..
2 things:
*I rebased the patches against lastest compat wireless but I don't know
where to send them...
Basically or they apply or they are already in compat-wireless(verified)
here are the one which applies:
0007-wl1251-read-default-MAC-address-from-EEPROM-when-ava.patch
0008-wl1251-register-platform_device-to-pass-board-data.patch
0009-wl1251-add-support-for-dedicated-IRQ-line.patch
0010-wl1251-use-sdio_readb_ext-for-ELP-to-work.patch
0011-wl1251-add-reset-handling.patch
0013-wl1251-prevent-scan-when-connected.patch
against compat-wireless-2010-04-26
By the way we can't make ad-hoc work,Is ad-hoc supported by the driver?
Denis.
^ 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