* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Johannes Berg @ 2010-04-20 6:13 UTC (permalink / raw)
To: Till Kamppeter
Cc: Theodore Ts'o, Greg KH, Arnaldo Carvalho de Melo,
Luis R. Rodriguez, linux-kernel, linux-wireless, Witold Sowa,
Grant Likely
In-Reply-To: <4BCCB176.3060206@gmail.com>
On Mon, 2010-04-19 at 12:39 -0700, Till Kamppeter wrote:
> two students who applied for your projects have applied also for another
> organization's project and they got accepted by us and by the other
> organization.
I'm confused. How do I figure out which ones?
> Until Wednesday Google wants these situation to be resolved until
> Wednesday April 21, 17:00 UTC. Please contact the students and/or the
> organization to agree on one of the project for each student.
>
> In addition, the ranking of the students (to decide who actually gets
> our slots) and the mentor assignments have to be finalized by the same
> date and time.
>
> Duplicates not be resolved until then will be resolved on an IRC meeting
> on Wednesday April 21 at 19:00 UTC. The meeting takes place in the #gsoc
> channel on Freenode.
>
> Please mail me if a mentor needs to be (re)assigned.
Oh wow so I wasn't paying attention much after the initial ranking.
I'm certainly not qualified to mentor the ACL project, would somebody
else do that?
johannes
^ permalink raw reply
* [PATCH v2] mac80211: document IEEE80211_CONF_CHANGE_QOS
From: Stanislaw Gruszka @ 2010-04-20 6:16 UTC (permalink / raw)
To: linux-wireless
Cc: Reinette Chatre, John W. Linville, wey-yi.w.guy, Johannes Berg,
Pavel Roskin
In-Reply-To: <1271692635.9026.17.camel@mj>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index dcf3c5f..97b2222 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -610,6 +610,7 @@ enum ieee80211_conf_flags {
* @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
* @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
* @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
+ * @IEEE80211_CONF_CHANGE_QOS: Quality of service was enabled or disabled
*/
enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_SMPS = BIT(1),
^ permalink raw reply related
* Re: [PATCH] ath9k-htc: speedup disconnect handling
From: Sujith @ 2010-04-20 6:41 UTC (permalink / raw)
To: Ming Lei
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <y2ud82e647a1004192259nec8aad6dy836b76b2211b6a40@mail.gmail.com>
Ming Lei wrote:
> If ATH_DBG_RESET is enabled, you will find the debug messages
> below[1] during disconnecting. From the messages, the short hang should
> be caused by the 'RTC stuck in MAC reset'. Once the patch is applied,
> no such issue will happen.
I take it that you didn't have ATH_DBG_WMI in your debug mask.
A simpler way to fix this issue is to deny all WMI commands once
the target has been unplugged - something like the attached patch.
Can you check if it fixes your issue ?
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index c765ff4..b771e20 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -329,6 +329,7 @@ struct htc_beacon_config {
#define OP_ASSOCIATED BIT(8)
#define OP_ENABLE_BEACON BIT(9)
#define OP_LED_DEINIT BIT(10)
+#define OP_UNPLUGGED BIT(11)
struct ath9k_htc_priv {
struct device *dev;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a861896..701f2ef 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -744,6 +744,9 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
if (ret)
goto err_init;
+ /* The device may have been unplugged earlier. */
+ priv->op_flags &= ~OP_UNPLUGGED;
+
ret = ath9k_init_device(priv, devid);
if (ret)
goto err_init;
@@ -760,6 +763,11 @@ err_free:
void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
{
if (htc_handle->drv_priv) {
+
+ /* Check if the device has been yanked out. */
+ if (hotunplug)
+ htc_handle->drv_priv->op_flags |= OP_UNPLUGGED;
+
ath9k_deinit_device(htc_handle->drv_priv);
ath9k_deinit_wmi(htc_handle->drv_priv);
ieee80211_free_hw(htc_handle->drv_priv->hw);
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index dc6c6fc..c688545 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -276,6 +276,9 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
int time_left, ret = 0;
unsigned long flags;
+ if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
+ return 0;
+
if (!wmi)
return -EINVAL;
^ permalink raw reply related
* mac80211 and asymmetric 802.11n TX/RX
From: Daniel Halperin @ 2010-04-20 7:07 UTC (permalink / raw)
To: linux-wireless
Hi all,
Does anyone know if the 11n standard says that the set of TX rates has to be a subset of the set of RX rates? This seems to be enforced now: when I set up one node to be 2x1, i.e. transmit 2 streams but only able to receive 1, then the mac80211 code only lets it transmit 1 streams (even with a 2-stream-capable receiver at the other end).
A quick diff to net/mac80211/ht.c that fixes this for equal modulation streams is attached; the problem is still there for unequal modulation directly below. Before I send it up I wanted to make sure I'm not crazy.
A second question: my understanding is that if I am a 2x2 node and I associate to a 3x3 AP, the same code will mask out the fact that the AP can receive 3 streams since I can't transmit 3 streams. Is there a way to access this info from the driver if I want it?
Thanks!
Dan
---
From: Daniel Halperin <dhalperi@cs.washington.edu>
Date: Tue, 20 Apr 2010 00:00:29 -0700
Subject: [PATCH] mac80211: support devices with more transmit than receive MCS supported
There is an implicit assumption built into mac80211 that an 11n NIC has a
receive MCS set that contains its TX MCS set, even when
IEEE80211_HT_MCS_TX_RX_DIFF is set. Then, a 2x1 node that can transmit 2
streams but only receive 1 will be unable to transmit 2 streams. Fix this for
equal modulation MCS sets by properly handling the IEEE80211_HT_MCS_TX_RX_DIFF
case.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
---
net/mac80211/ht.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 2ab106a..249805b 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -24,6 +24,7 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
{
u8 ampdu_info, tx_mcs_set_cap;
int i, max_tx_streams;
+ bool use_rx_mask;
BUG_ON(!ht_cap);
@@ -71,12 +72,15 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
return;
/* Counting from 0, therefore +1 */
- if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF)
+ if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF) {
max_tx_streams =
((tx_mcs_set_cap & IEEE80211_HT_MCS_TX_MAX_STREAMS_MASK)
>> IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT) + 1;
- else
+ use_rx_mask = 0;
+ } else {
max_tx_streams = IEEE80211_HT_MCS_TX_MAX_STREAMS;
+ use_rx_mask = 1;
+ }
/*
* 802.11n D5.0 20.3.5 / 20.6 says:
@@ -87,7 +91,8 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
*/
for (i = 0; i < max_tx_streams; i++)
ht_cap->mcs.rx_mask[i] =
- sband->ht_cap.mcs.rx_mask[i] & ht_cap_ie->mcs.rx_mask[i];
+ (use_rx_mask ? sband->ht_cap.mcs.rx_mask[i] : 0xFF) &
+ ht_cap_ie->mcs.rx_mask[i];
if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_UNEQUAL_MODULATION)
for (i = IEEE80211_HT_MCS_UNEQUAL_MODULATION_START_BYTE;
--
1.5.4.3
^ permalink raw reply related
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Till Kamppeter @ 2010-04-20 7:19 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Arnaldo Carvalho de Melo, Luis R. Rodriguez,
linux-kernel, linux-wireless, Witold Sowa, Johannes Berg,
Grant Likely, Alexey Khoroshilov
In-Reply-To: <4BCCDFBC.4020907@gmail.com>
On 04/19/2010 03:57 PM, Till Kamppeter wrote:
> Sorry, here we go:
>
> http://socghop.appspot.com/gsoc/org/list_proposals/google/gsoc2010/lf
>
> Requires login as mentor.
>
> Till
On this page students which are accepted by 2 or more orgs are marked
with "Duplicate" in red. Click on this "Duplicate" to get info to
contact the other org.
Till
^ permalink raw reply
* Re: [PATCH] ath9k-htc: speedup disconnect handling
From: Ming Lei @ 2010-04-20 7:46 UTC (permalink / raw)
To: Sujith
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <19405.19620.199172.233574@gargle.gargle.HOWL>
2010/4/20 Sujith <Sujith.Manoharan@atheros.com>:
> Ming Lei wrote:
>> If ATH_DBG_RESET is enabled, you will find the debug messages
>> below[1] during disconnecting. From the messages, the short hang should
>> be caused by the 'RTC stuck in MAC reset'. Once the patch is applied,
>> no such issue will happen.
>
> I take it that you didn't have ATH_DBG_WMI in your debug mask.
> A simpler way to fix this issue is to deny all WMI commands once
> the target has been unplugged - something like the attached patch.
>
> Can you check if it fixes your issue ?
Yes, the patch does fix the issue.
Thanks,
--
Lei Ming
^ permalink raw reply
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Johannes Berg @ 2010-04-20 8:22 UTC (permalink / raw)
To: Daniel Halperin; +Cc: linux-wireless
In-Reply-To: <48BAD814-F653-4CE3-85E0-A9D82EC31D53@cs.washington.edu>
Hi Dan,
> Does anyone know if the 11n standard says that the set of TX rates has
> to be a subset of the set of RX rates? This seems to be enforced now:
> when I set up one node to be 2x1, i.e. transmit 2 streams but only
> able to receive 1, then the mac80211 code only lets it transmit 1
> streams (even with a 2-stream-capable receiver at the other end).
I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
about the "Rx Highest Supported Data Rate" field. Seems like maybe you
could set the "RX MCS bitmask" to more than is supported, limit it by
the highest supported data rate, and then use the bitmask for TX?
> A quick diff to net/mac80211/ht.c that fixes this for equal modulation
> streams is attached; the problem is still there for unequal modulation
> directly below. Before I send it up I wanted to make sure I'm not
> crazy.
Hmm, ok. I interpreted the standard differently here, but your
interpretation actually makes more sense I guess. Anyone who's more
familiar with the standard?
> A second question: my understanding is that if I am a 2x2 node and I
> associate to a 3x3 AP, the same code will mask out the fact that the
> AP can receive 3 streams since I can't transmit 3 streams. Is there a
> way to access this info from the driver if I want it?
Unfortunately not, at this point. We could keep track of it, what would
you need it for?
johannes
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 8:25 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold, Tor Krill
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Hi again,
On Fri, Apr 16, 2010 at 12:48:50PM +0200, Johan Hovold wrote:
> I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
> mac80211.
[...]
> An example of such a frame is:
>
> 00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
> 00000010: 00 22 02 00 0b 63 20 52 00 00 20 21 21 05 00 20
> 00000020: 8a 39 7b 1f 0f 11 07 9e bd 53 80 33 3b 8c 98 00
> 00000030: ef 5f da 7c 9a d6 3d d7 59 ac e0 21 44 88 63 d7
> 00000040: 21 34 b7 9a 89 8e cf 9e 46 1c ee d6 81 56 25 59
> 00000050: d2 ec ac 33 e6 12 3d c5 02 61 2d 80 8d 30 44 1e
> 00000060: 79 74 79 79 62 25 ba ec 04 4d 54 dc
>
> with associated status
>
> rxstatus8 = 1e989103
>
> Here nothing in the frame status indicates an error; the frame has no error
> flags set, the frame-ok flag is set, and so on. Still the frame is indeed
> corrupt; the last four octets of the CCMP-header (bytes 0x20..0x23) should
> be {00,00,00,00} rather than {8a,39,7b,1f} as the correct PN is 0x0521 (not
> 0x1f7b398a0521).
>
> The corrupt frames all seem to have the upper half of the CCMP-header, data
> and MIC corrupted, whereas the FCS (last four bytes) seem to be correct in the
> sense that they match what I see in the air (and is verified by wireshark).
>
> One explanation for all of this could be that the corrupt packet is what the
> hardware is expected to return should it's processing fail (e.g. due to
> checksum error). Then the problem is merely that the status field sometimes
> get corrupted (some frames with corrupt PN do indeed come with matching
> rxstatus). Comments in the code concerning corrupt status fields also point in
> this direction.
>
> Another explanation could be that the status is actually correct but for some
> reason the returned frame is corrupted. Perhaps it's a combination of both
> corrupt status and frame.
>
> Any ideas about what may be going on here?
I'll answer my own question -- the status field is clearly corrupted.
The bad frames all have status such as
19fdb637
9131f6d7
87b3f0c1
29de5e7b
10c68ff3
4c1a33c7
9abd470b
where it should look something like 00030943. From inspection of
returned frame status, I've come up with at way to catch these; I
discard frames marked ok but with errors flags set or which have any of
the reserved bits 19 through 28 (0x1ff80000) set.
My question is: Is the latter assumption correct? Can I expect bits
19..28 to be zero?
On my AR9820 hardware this seems to be case and I am able to catch all
the corrupt frames and have 802.11n work perfectly. It also works fine
with 802.11g/WEP/TKIP/CCMP.
As a side note, I also seem able to confirm my observation above that
frames returned with non-corrupt status and decrypt error flag set
indeed do have corrupt CCMP header, data and MIC. That is, this seem to
be what hw is expected to return on (such) errors.
I'm responding to this mail with my fix (workaround).
I have also seen non-decrypted frames with decrypt busy flag set but
without decrypt crc err set (frame is marked not ok). I'm not sure
whether this is due to a bug or bit error (decrypt crc somehow got
cleared) but I also propose a change to remedy this.
Thanks,
Johan Hovold
^ permalink raw reply
* [RFC][PATCH 1/2] ath9k: fix corrupt frames being forwarded to mac80211
From: Johan Hovold @ 2010-04-20 8:28 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Frame status frequently gets corrupted in hardware with 802.11n which
can lead to corrupt frames being forwarded to mac80211. This in turn may
trigger countermeasures in reponse to false MIC-errors or cause receive
to stall when frames are dropped after processing a frame with corrupt PN.
Verify frame status by making sure that no error flags are set if frame
is marked ok and that reserved bits 19 through 28 (0x1ff80000) are all
zero, otherwise discarded frame (as ATH9K_PHYERR_HT_CRC_ERROR).
Tested with AR9280 (WEP, TKIP and CCMP).
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/mac.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 4a2060e..2afe72f 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -934,9 +934,22 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
+ } else {
+ if (ads.ds_rxstatus8 & (AR_CRCErr |
+ AR_PHYErr |
+ AR_DecryptCRCErr |
+ AR_MichaelErr |
+ AR_DecryptBusyErr))
+ goto corrupt;
}
+ if (ads.ds_rxstatus8 & 0x1ff80000)
+ goto corrupt;
return 0;
+corrupt:
+ rs->rs_status |= ATH9K_RXERR_PHY;
+ rs->rs_phyerr = ATH9K_PHYERR_HT_CRC_ERROR;
+ return 0;
}
EXPORT_SYMBOL(ath9k_hw_rxprocdesc);
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 2/2] ath9k: use also AR_DecryptBusyErr to determine decrypt errors
From: Johan Hovold @ 2010-04-20 8:28 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Prevent non-decrypted frames with DecryptBusyErr flag set to be marked
decrypted.
Have seen such a frame with status 0x40030bc1 (due to bit error?).
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/mac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 2afe72f..780da87 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -930,7 +930,8 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs->rs_phyerr = phyerr;
- } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
+ } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr ||
+ ads.ds_rxstatus8 & AR_DecryptBusyErr)
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
--
1.7.0.3
^ permalink raw reply related
* Re: [ath9k-devel] [RFC][PATCH 2/6] ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
From: Johan Hovold @ 2010-04-20 8:35 UTC (permalink / raw)
To: Jouni Malinen
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1271417561.8066.4.camel@jm-desktop>
On Fri, Apr 16, 2010 at 02:32:41PM +0300, Jouni Malinen wrote:
> On Fri, 2010-04-16 at 03:52 -0700, Johan Hovold wrote:
> > Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
> > incorrectly be marked decrypted (even if key index in frame is valid).
>
> Have you tested this with static WEP configuration? Or broadcast RX with
> WPA? There must be a reason for that odd looking code being there in the
> first place and I can now only think of it being needed when the default
> keys are used.
You are correct. That piece of code is indeed required for WEP
(KeyIdxValid is not set and sometimes also KeyMiss is set even though
frame has been decrypted).
I just posted a patch which seems to catch the corrupt frames without
messing anything else up. Perhaps you could take a quick look at it?
Thanks,
Johan
^ permalink raw reply
* Re: [RFC][PATCH 1/2] ath9k: fix corrupt frames being forwarded to mac80211
From: Johan Hovold @ 2010-04-20 8:38 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1271752088-13639-1-git-send-email-johan.hovold@lundinova.se>
On Tue, Apr 20, 2010 at 10:28:07AM +0200, Johan Hovold wrote:
> Verify frame status by making sure that no error flags are set if frame
> is marked ok and that reserved bits 19 through 28 (0x1ff80000) are all
> zero, otherwise discarded frame (as ATH9K_PHYERR_HT_CRC_ERROR).
I used ATH9K_PHYERR_HT_CRC_ERROR for now, but perhaps there is better
choice?
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Ranga Rao Ravuri @ 2010-04-20 9:10 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Hi
Can you please tell us more about your test,
what exactly is your test is ?
What kind of traffic are you running
what is your AP ?.
Are you testing with aggregated traffic or non-aggregate legacy
traffic ?
Are you seeing only when CCMP is enabled or in WEP/TKIP also ?
Can you please set register 0x8120 bit 28 to 1 and test this again to
see that helps ?
thanks
Ranga
On Tue, 2010-04-20 at 13:55 +0530, Johan Hovold wrote:
> Hi again,
>
> On Fri, Apr 16, 2010 at 12:48:50PM +0200, Johan Hovold wrote:
> > I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
> > mac80211.
> [...]
> > An example of such a frame is:
> >
> > 00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
> > 00000010: 00 22 02 00 0b 63 20 52 00 00 20 21 21 05 00 20
> > 00000020: 8a 39 7b 1f 0f 11 07 9e bd 53 80 33 3b 8c 98 00
> > 00000030: ef 5f da 7c 9a d6 3d d7 59 ac e0 21 44 88 63 d7
> > 00000040: 21 34 b7 9a 89 8e cf 9e 46 1c ee d6 81 56 25 59
> > 00000050: d2 ec ac 33 e6 12 3d c5 02 61 2d 80 8d 30 44 1e
> > 00000060: 79 74 79 79 62 25 ba ec 04 4d 54 dc
> >
> > with associated status
> >
> > rxstatus8 = 1e989103
> >
> > Here nothing in the frame status indicates an error; the frame has no error
> > flags set, the frame-ok flag is set, and so on. Still the frame is indeed
> > corrupt; the last four octets of the CCMP-header (bytes 0x20..0x23) should
> > be {00,00,00,00} rather than {8a,39,7b,1f} as the correct PN is 0x0521 (not
> > 0x1f7b398a0521).
> >
> > The corrupt frames all seem to have the upper half of the CCMP-header, data
> > and MIC corrupted, whereas the FCS (last four bytes) seem to be correct in the
> > sense that they match what I see in the air (and is verified by wireshark).
> >
> > One explanation for all of this could be that the corrupt packet is what the
> > hardware is expected to return should it's processing fail (e.g. due to
> > checksum error). Then the problem is merely that the status field sometimes
> > get corrupted (some frames with corrupt PN do indeed come with matching
> > rxstatus). Comments in the code concerning corrupt status fields also point in
> > this direction.
> >
> > Another explanation could be that the status is actually correct but for some
> > reason the returned frame is corrupted. Perhaps it's a combination of both
> > corrupt status and frame.
> >
> > Any ideas about what may be going on here?
>
> I'll answer my own question -- the status field is clearly corrupted.
> The bad frames all have status such as
>
> 19fdb637
> 9131f6d7
> 87b3f0c1
> 29de5e7b
> 10c68ff3
> 4c1a33c7
> 9abd470b
>
> where it should look something like 00030943. From inspection of
> returned frame status, I've come up with at way to catch these; I
> discard frames marked ok but with errors flags set or which have any of
> the reserved bits 19 through 28 (0x1ff80000) set.
>
> My question is: Is the latter assumption correct? Can I expect bits
> 19..28 to be zero?
>
> On my AR9820 hardware this seems to be case and I am able to catch all
> the corrupt frames and have 802.11n work perfectly. It also works fine
> with 802.11g/WEP/TKIP/CCMP.
>
> As a side note, I also seem able to confirm my observation above that
> frames returned with non-corrupt status and decrypt error flag set
> indeed do have corrupt CCMP header, data and MIC. That is, this seem to
> be what hw is expected to return on (such) errors.
>
> I'm responding to this mail with my fix (workaround).
>
> I have also seen non-decrypted frames with decrypt busy flag set but
> without decrypt crc err set (frame is marked not ok). I'm not sure
> whether this is due to a bug or bit error (decrypt crc somehow got
> cleared) but I also propose a change to remedy this.
>
> Thanks,
> Johan Hovold
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: p54pci does not work
From: Christian Lamparter @ 2010-04-20 9:32 UTC (permalink / raw)
To: Duarte Nuno Gomes; +Cc: linux-wireless
In-Reply-To: <i2u719bd8781004192319ge1e40479oa17f0f5036a6cee@mail.gmail.com>
On Tuesday 20 April 2010 08:19:11 Duarte Nuno Gomes wrote:
> On Tue, Apr 13, 2010 at 6:48 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Tuesday 13 April 2010 07:47:42 Duarte Nuno Gomes wrote:
> >> it works all ok ... when i visit some websites ( www.rcmadeira.pt.vu is one
> >> of them ), my connection just disconnects and i cannot resume it . i need to
> >> shutdown and re lauch kernel in order to work with wireless again.
> >
> > hrmf, works here no matter how much i try.
> > But let's not get carry away, I guess the problem you are describing
> > has more to do with the amount of data which is transfered.
> > Ideally, you should be able to reproduce this _hang_ with any network
> > benchmarking tools (like iperf / nttcp / netperf (or whatever you prefer)).
> i would if u had a way of having a demon running on some shell and
> know what to check for
> >
> >> here is what dmesg outputs
> >>
> >> No probe response from AP 00:24:17:6c:a5:0e after 500ms, disconnecting.
> >> Phy0 : cannot boot firmware !
> >
> > are you getting these messages in this order? (some timestamps,
> > and maybe p54pci dmesg output while initializing would be jolly nice)
[...]
> >
> > * Wireless setup (Which band (2.4 or 5GHz) ? Do you use WPA/WPA2 with CCMP/TKIP,
> > (you can turn off the hw crypto accelerator by loading p54common with the module
> > parameter nohwcrypt=1 )
>
> 2.4 Ghz with WPA / TKIP
> IT WORKS WITH THAT NOHWCRYPT PARAMETER! ill test a little more !
> just need to figure out now , how to load it with parameter on boot !
> easy task !
echo "options p54common nohwcrypt=1" > /etc/modprobe/p54common.conf,
if you compiled p54common as a module (which I hope you did).
if p54common is built-in, then you'll have to add a p54common.nohwcrypt=1
kernel cmdline parameter.
The (most likely) reason why your AP drops you and does not allow you
to reconnect, is probably due to the "TKIP countermeasures".
What's your Accesspoint/Router and which firmware are you currently using?
Regards,
Chr
^ permalink raw reply
* [PATCH] mac80211: Fix ieee80211_sta_conn_mon_timer with hw connection monitoring
From: Juuso Oikarinen @ 2010-04-20 10:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When IEEE80211_HW_CONNECTION_MONITOR is configured by the driver, starting
of ieee80211_sta_conn_mon_timer should be prevented, as it is then not needed.
This is currently partially the case. As it seems, when a probe-response is
received from the AP the timer is still restarted, thus restarting the host
based connection keep-alive mechanism. These probe-responses happen at least
when scanning while associated.
Fix this by preventing starting of the ieee80211_sta_conn_mon_timer in the
ieee80211_rx_mgmt_probe_resp function.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/mac80211/mlme.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 3133681..425f66c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1333,12 +1333,17 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+
+ if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
+ return;
+
/*
* We've received a probe response, but are not sure whether
* we have or will be receiving any beacons or data, so let's
* schedule the timers again, just in case.
*/
mod_beacon_timer(sdata);
+
mod_timer(&ifmgd->conn_mon_timer,
round_jiffies_up(jiffies +
IEEE80211_CONNECTION_IDLE_TIME));
--
1.6.3.3
^ permalink raw reply related
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 11:06 UTC (permalink / raw)
To: Ranga Rao Ravuri
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1271754651.14253.112.camel@ranga-desktop>
On Tue, Apr 20, 2010 at 02:40:51PM +0530, Ranga Rao Ravuri wrote:
> Can you please tell us more about your test,
> what exactly is your test is ?
> What kind of traffic are you running
> what is your AP ?.
I have a powerpc-based platform running AR9280 in AP mode. My STA is an
Intel 5300 (but I have been able to reproduce it also with an STA using
AR5008).
After connecting I run iperf in client mode on the STA thus sending data
to the STA. After a short while the AP stops receiving any data
(including TCP-acks) and the transfer stalls.
I've verified that frames that look ok in the air can still be corrupt
in ath9k. In particular, the status field is trashed so that frames are
incorrectly forwarded to mac80211 marked as decrypted which can trigger
countermeasures or update CCMP PN incorrectly (thereby dropping later,
correct frames).
Discarding frames which appear to have trashed status makes 802.11n
work.
> Are you testing with aggregated traffic or non-aggregate legacy
> traffic ?
Aggregated.
> Are you seeing only when CCMP is enabled or in WEP/TKIP also ?
Only with 802.11n (CCMP). Everything works perfectly with 802.11g and
WEP/TKIP/CCMP and I never see any corrupt frame status.
> Can you please set register 0x8120 bit 28 to 1 and test this again to
> see that helps ?
I'll try that.
Thanks,
Johan
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 11:35 UTC (permalink / raw)
To: Ranga Rao Ravuri
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20100420110657.GH5288@lundinova.se>
On Tue, Apr 20, 2010 at 01:06:57PM +0200, Johan Hovold wrote:
> On Tue, Apr 20, 2010 at 02:40:51PM +0530, Ranga Rao Ravuri wrote:
> > Can you please set register 0x8120 bit 28 to 1 and test this again to
> > see that helps ?
>
> I'll try that.
I'm afraid it does not seem to have any effect on the corrupt frame
status.
Anything else I can try?
Thanks,
Johan
^ permalink raw reply
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Grant Likely @ 2010-04-20 12:43 UTC (permalink / raw)
To: Till Kamppeter, Rik van Riel
Cc: Theodore Ts'o, Greg KH, Arnaldo Carvalho de Melo,
Luis R. Rodriguez, linux-kernel, linux-wireless, Witold Sowa,
Johannes Berg
In-Reply-To: <4BCCB176.3060206@gmail.com>
On Mon, Apr 19, 2010 at 1:39 PM, Till Kamppeter
<till.kamppeter@gmail.com> wrote:
> Please mail me if a mentor needs to be (re)assigned.
Nitin Gupta has 2 proposals on the table (one pending acceptance, and
one rejection). I'm assigned as mentor on both of them, but I'm
certainly not qualified. Rik van Riel has expressed a willingness to
mentor Nitin. Rik, are you willing to take on a second student, or
can you suggest somebody to mentor Nitin?
Alex Lorca's Locator/ID Separation Protocol project is pending
acceptance, but it has not been reviewed by anyone working in the area
of network routing. Again, I'm not qualified to mentor this project
and I do not know who to suggest.
g.
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Nick Bowler @ 2010-04-20 13:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On 05:15 Tue 20 Apr , Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.33, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
Please list these two similar regressions from 2.6.33 in the r600 DRM:
* r600 CS checker rejects GL_DEPTH_TEST w/o depth buffer:
https://bugs.freedesktop.org/show_bug.cgi?id=27571
* r600 CS checker rejects narrow FBO renderbuffers:
https://bugs.freedesktop.org/show_bug.cgi?id=27609
Thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID now
From: John W. Linville @ 2010-04-20 15:45 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Wiktor Zajas, ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <20100329222008.GA2852@tux>
On Mon, Mar 29, 2010 at 03:20:08PM -0700, Luis R. Rodriguez wrote:
> On Mon, Mar 29, 2010 at 12:40:09PM -0700, Wiktor Zajas wrote:
> > Thanks so much for this driver, it's working flawlessly. Only one minor problem
> > was "Michael MIC failure detected", changing to AES helped.
>
> Not sure if Sujith's patch posted yesterday would fix this.
>
> > I don't know if what I've done is correct, in order to recognize my card
> > (TL-WN422G v2) I've added "ATH9K_FW_USB_DEV(0x1006, "ar9271.fw")," to
> > "ath9k_hif_usb_ids[]", and changed "#define AR9271_USB 0x9271" to
> > "#define AR9271_USB 0x1006", is this the right thing to do ?
>
> Sort of, try this patch:
>
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Subject: [PATCH] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID
>
> Reported-by: Wiktor Zajas <w.zajas@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index fc4f6e8..a7664e4 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -21,6 +21,7 @@
>
> static struct usb_device_id ath9k_hif_usb_ids[] = {
> ATH9K_FW_USB_DEV(0x9271, "ar9271.fw"),
> + ATH9K_FW_USB_DEV(0x1006, "ar9271.fw"), /* TL-WN422G v2 */
> { },
> };
Any feedback on this?
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: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: reinette chatre @ 2010-04-20 16:54 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: wireless, Berg, Johannes
In-Reply-To: <n2g2d0a357f1004170705j6d0750fdkc4784f86aab51c97@mail.gmail.com>
Hi,
On Sat, 2010-04-17 at 07:05 -0700, Sedat Dilek wrote:
> I have already sent an bug-report "iwl3945: Network dropouts w/
> flash-stream in firefox" in [1].
> Unfortunately, the problem still remains, especially when
> fast-forwarding flash movies in firefox-3.6.3.
> It seems the wifi-card is hanging and my system needs a coldstart.
Is this a recent problem? How regularly do you update your kernel?
>
> The kernel I use is a Linux-2.6.34-rc4-git4 with these 3 patches in addition:
Where can I access this kernel's git repo?
> According to Johannes (on IRC) iwl3945 doesn't use internal scans yet
> (see my patch below).
> Thus, I am not sure if this needs to be fixed separately for iwl3945
> and if I ran into a scan race condition here.
Does this patch make any difference for you?
> Hope, this helps.
It does. Thank you. As a sanity check, could you please try this patch?
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index c8cd169..1ad15bd 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -814,7 +814,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata)
changed |= BSS_CHANGED_ASSOC;
sdata->vif.bss_conf.assoc = false;
- ieee80211_set_wmm_default(sdata);
+ /*ieee80211_set_wmm_default(sdata);*/
/* channel(_type) changes are handled by ieee80211_hw_config */
local->oper_channel_type = NL80211_CHAN_NO_HT;
^ permalink raw reply related
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Daniel Halperin @ 2010-04-20 17:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1271751747.8954.3.camel@jlt3.sipsolutions.net>
Hi Johannes,
On Apr 20, 2010, at 1:22 AM, Johannes Berg wrote:
>> Does anyone know if the 11n standard says that the set of TX rates has
>> to be a subset of the set of RX rates? This seems to be enforced now:
>> when I set up one node to be 2x1, i.e. transmit 2 streams but only
>> able to receive 1, then the mac80211 code only lets it transmit 1
>> streams (even with a 2-stream-capable receiver at the other end).
>
> I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
> about the "Rx Highest Supported Data Rate" field. Seems like maybe you
> could set the "RX MCS bitmask" to more than is supported, limit it by
> the highest supported data rate, and then use the bitmask for TX?
First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I assume the section numbers haven't changed). For me that section represents the "Supported MCS Set field".
(An aside: I don't actually *have* 7.3.2.56. I'm using IEEE 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57 and beyond] --- In which document are the missing sections?)
Can you point me at which text in the section you think implies this requirement?
In any case, maybe this discussion is silly: I don't know of any devices with this strange configuration. Typically clients assume downlink-heavy and might support a 1x2 connection but 2x1, i.e. designed for uplink, seems unlikely.
>> A second question: my understanding is that if I am a 2x2 node and I
>> associate to a 3x3 AP, the same code will mask out the fact that the
>> AP can receive 3 streams since I can't transmit 3 streams. Is there a
>> way to access this info from the driver if I want it?
>
> Unfortunately not, at this point. We could keep track of it, what would
> you need it for?
Okay, that's what I figured; I can hack around it locally. I'm working on an alternative rate selection algorithm that at one point tries to take into account how much receive diversity the other endpoint has. The intuition is that how well (e.g.) 2-stream rates work is going to depend not just on the channel, but also on how many excess antennas the receiver has. I would benefit from knowing whether they have 2 or 3 antennas even if I can only send them at most 2 streams.
Thanks,
Dan
^ permalink raw reply
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Till Kamppeter @ 2010-04-20 17:31 UTC (permalink / raw)
To: Grant Likely
Cc: Rik van Riel, Theodore Ts'o, Greg KH,
Arnaldo Carvalho de Melo, Luis R. Rodriguez, linux-kernel,
linux-wireless, Witold Sowa, Johannes Berg
In-Reply-To: <i2wfa686aa41004200543gfbb71c98m9a70120fe1cbc8b9@mail.gmail.com>
On 04/20/2010 05:43 AM, Grant Likely wrote:
> On Mon, Apr 19, 2010 at 1:39 PM, Till Kamppeter
> <till.kamppeter@gmail.com> wrote:
>> Please mail me if a mentor needs to be (re)assigned.
>
> Nitin Gupta has 2 proposals on the table (one pending acceptance, and
> one rejection). I'm assigned as mentor on both of them, but I'm
> certainly not qualified. Rik van Riel has expressed a willingness to
> mentor Nitin. Rik, are you willing to take on a second student, or
> can you suggest somebody to mentor Nitin?
>
Set Rik as mentor for the project pending acceptance.
> Alex Lorca's Locator/ID Separation Protocol project is pending
> acceptance, but it has not been reviewed by anyone working in the area
> of network routing. Again, I'm not qualified to mentor this project
> and I do not know who to suggest.
Seems that we have to reject this student because no one wants to mentor
him.
TIll
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID now
From: Luis R. Rodriguez @ 2010-04-20 17:36 UTC (permalink / raw)
To: John W. Linville, Stephen Chen, Sujith
Cc: Luis Rodriguez, Wiktor Zajas, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20100420154543.GA6472@tuxdriver.com>
On Tue, Apr 20, 2010 at 08:45:44AM -0700, John W. Linville wrote:
> On Mon, Mar 29, 2010 at 03:20:08PM -0700, Luis R. Rodriguez wrote:
> > On Mon, Mar 29, 2010 at 12:40:09PM -0700, Wiktor Zajas wrote:
> > > Thanks so much for this driver, it's working flawlessly. Only one minor problem
> > > was "Michael MIC failure detected", changing to AES helped.
> >
> > Not sure if Sujith's patch posted yesterday would fix this.
> >
> > > I don't know if what I've done is correct, in order to recognize my card
> > > (TL-WN422G v2) I've added "ATH9K_FW_USB_DEV(0x1006, "ar9271.fw")," to
> > > "ath9k_hif_usb_ids[]", and changed "#define AR9271_USB 0x9271" to
> > > "#define AR9271_USB 0x1006", is this the right thing to do ?
> >
> > Sort of, try this patch:
> >
> > From: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Subject: [PATCH] ath9k_htc: add the 0cf3:1006 TL-WN422G v2 device ID
> >
> > Reported-by: Wiktor Zajas <w.zajas@gmail.com>
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> > drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> > index fc4f6e8..a7664e4 100644
> > --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> > @@ -21,6 +21,7 @@
> >
> > static struct usb_device_id ath9k_hif_usb_ids[] = {
> > ATH9K_FW_USB_DEV(0x9271, "ar9271.fw"),
> > + ATH9K_FW_USB_DEV(0x1006, "ar9271.fw"), /* TL-WN422G v2 */
This patch was wrong, Sujith was going to fix it, I think he sent
some followups. If not we'll take care of it.
Luis
^ permalink raw reply
* Problem with AR5001 on eeepc900A after disable with RFKILL switch
From: Larry Finger @ 2010-04-20 18:04 UTC (permalink / raw)
To: wireless; +Cc: Bernhard M. Wiedemann
This problem is reported at
https://bugzilla.novell.com/show_bug.cgi?id=595586.
Although not mentioned in the bug report, the kernel is 2.6.33.
The initial part of the report is as follows:
======================================================================
After disabling WLAN on Asus eeepc 900A using rfkill button (Fn+F2) it
does not get back into a working state without a reboot.
Reproducible: Always
Steps to Reproduce:
1. boot up eeepc900A with WLAN enabled
2. press Fn+F2 (rfkill button) to disable WLAN
3. press Fn+F2 again to enable WLAN
Actual Results:
-----
1. lspci before rfkill
01:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114
Gigabit or Fast Ethernet (rev b0)
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
Network Adapter (rev 01)
-----
2. lspci after rfkill
01:00.0 Ethernet controller: Attansic Technology Corp. Atheros
AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)
02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
Network Adapter (rev ff)
======================================================================
The curious thing is that the lspci output is different for both the
wired and wireless cards.
Any ideas on why setting rfkill should change data in this way?
Thanks,
Larry
^ 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