* Re: [PATCH 1/2] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Kalle Valo @ 2016-10-03 7:25 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <1475178055-16924-2-git-send-email-Jes.Sorensen@redhat.com>
Jes.Sorensen@redhat.com writes:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> A device running without RX package aggregation could return more data
> in the USB packet than the actual network packet. In this case the
> could would clone the skb but then determine that that there was no
> packet to handle and exit without freeing the cloned skb first.
s/case the/case we/? I can edit that before applying the patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix big-endian problem reporting mactime
From: Kalle Valo @ 2016-10-03 7:26 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <1475178055-16924-3-git-send-email-Jes.Sorensen@redhat.com>
Jes.Sorensen@redhat.com writes:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The full RX descriptor is converted so converting tsfl again would
> return it to it's original endian value.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
I'll add:
Cc: stable@vger.kernel.org # 4.8+
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Kalle Valo @ 2016-10-03 7:29 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Greg KH, linux-wireless, Larry.Finger, stable
In-Reply-To: <wrfjshsg5k21.fsf@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> writes:
> Greg KH <greg@kroah.com> writes:
>> On Fri, Sep 30, 2016 at 07:35:17PM -0400, Jes.Sorensen@redhat.com wrote:
>>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>>
>>> The generic disable_rf() function clears bits 22 and 23 in
>>> REG_RX_WAIT_CCA, however we did not re-enable them again in
>>> rtl8723b_enable_rf()
>>>
>>> This resolves the problem for me with 8723bu devices not working again
>>> after reloading the driver.
>>>
>>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>>> ---
>>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>
>> <formletter>
>>
>> This is not the correct way to submit patches for inclusion in the
>> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
>> for how to do this properly.
>>
>> </formletter>
>
> DOH Kalle told me to CC stable I took it for granted that you meant CC
> in the email sense. Guess I get to blame my self for looking like a
> fool in public.
Yes, I meant adding it to the commit log. This part of the stable
process is a bit confusing, I should have been more clear how this
works.
> I'll send you an email directly with the SHA once it hits Linus' tree
> instead.
No need, I'll add this to the commit log and the stable team will get
the commit automatically once the commit is in Linus' tree:
Cc: stable@vger.kernel.org # 4.7+
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix rtl8192eu driver reload issue
From: Kalle Valo @ 2016-10-03 7:30 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <1475278518-18527-3-git-send-email-Jes.Sorensen@redhat.com>
Jes.Sorensen@redhat.com writes:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The 8192eu suffered from two issues when reloading the driver.
>
> The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
> 23 didn't get set in rtl8192e_enable_rf().
>
> In addition it also seems prone to issues when setting REG_RF_CTRL to
> 0 intead of just disabling the RF_ENABLE bit. Similar to what was
> causing issues with the 8188eu.
>
> With this patch I can successfully reload the driver and reassociate
> to an APi with an 8192eu dongle.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
I'll add:
Cc: stable@vger.kernel.org # 4.8+
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: add platform regulatory domain support
From: Bartosz Markowski @ 2016-10-03 7:43 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <871t0nhsdu.fsf@kamboji.qca.qualcomm.com>
On 14 September 2016 at 09:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
> > On 12 September 2016 at 17:35, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> >
> >> > +#ifdef CONFIG_ACPI
> >> > +#define WRD_METHOD "WRDD"
> >> > +#define WRDD_WIFI (0x07)
> >> > +
> >> > +static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_object *wrdd)
> >> > +{
> >>
> >> I don't think the ifdef is really necessary, acpi.h should handle that
> >> (hopefully). Also I changed the error handling to use standard error
> >> values and changed the info messages to dbg, they are too spammy in my
> >> opinion. Please check carefully my changes in the pending branch:
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=fe91745381ec3999d8de6dedb07b396c82539717
> >
> > I'm OK with the changes, I have not tried that though, except of
> > reviewing and compiling it (do not have access to the chromebook for
> > next few days). If you want to wait with it until I test it, it's fine
> > too.
>
> Ok, I'll wait for few days in case you have time to test it.
Sorry, it took so long. I've final check this and can confirm the patch.
Bartosz
^ permalink raw reply
* Re: [PATCH] ath10k: cache calibration data when the core is stopped.
From: Valo, Kalle @ 2016-10-03 7:46 UTC (permalink / raw)
To: Marty Faltesek; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <1473801118-103112-1-git-send-email-mfaltesek@google.com>
Marty Faltesek <mfaltesek@google.com> writes:
> Caching calibration data allows it to be accessed when the
> device is not active.
>
> Signed-off-by: Marty Faltesek <mfaltesek@google.com>
No comma in the title, please.
What tree did you use as the baseline? This doesn't seem to apply to
ath.git:
Applying: ath10k: cache calibration data when the core is stopped.
fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath=
10k/core.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 ath10k: cache calibration data when the core is stoppe=
d.
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1227,6 +1227,42 @@ success:
> return 0;
> }
> =20
> +int
> +ath10k_cal_data_alloc(struct ath10k *ar, void **buf)
> +{
> + u32 hi_addr;
> + __le32 addr;
> + int ret;
I think this function should be in debug.c. That way the code is not
wasting memory if DEBUGFS is disabled.=20
> + vfree(*buf);
> + *buf =3D vmalloc(QCA988X_CAL_DATA_LEN);
> + if (!*buf) {
> + return -EAGAIN;
> + }
Is it really necessary to allocate memory every time? What if allocate
it only once when module is loaded, just like with
ar->debug.fw_crash_data?
Also please note that this patch (which I'm queuing to 4.9) touches the
same area:
ath10k: fix debug cal data file
https://patchwork.kernel.org/patch/9340953/
> + hi_addr =3D host_interest_item_address(HI_ITEM(hi_board_data));
> +
> + ret =3D ath10k_hif_diag_read(ar, hi_addr, &addr, sizeof(addr));
> +
> + if (ret) {
> + ath10k_warn(ar, "failed to read hi_board_data address: %d\n", ret);
> + } else {
> + ret =3D ath10k_hif_diag_read(ar, le32_to_cpu(addr), *buf,
> + QCA988X_CAL_DATA_LEN);
> + if (ret) {
> + ath10k_warn(ar, "failed to read calibration data: %d\n", ret);
> + }
> + }
We try to avoid using else branches so that only error handling is
indented and the main code flow is not.
> + /*
> + * We are up now, so no need to cache calibration data.
> + */
> + vfree(ar->cal_data);
> + ar->cal_data =3D NULL;
Indentation looks wrongs here.
> @@ -1757,6 +1799,11 @@ void ath10k_core_stop(struct ath10k *ar)
> lockdep_assert_held(&ar->conf_mutex);
> ath10k_debug_stop(ar);
> =20
> + /*
> + * Cache caclibration data while stopped.
> + */
> + ath10k_cal_data_alloc(ar, &ar->cal_data);
I like the idea that the calibration data is copied during stop(), but
can you do this from debug.c? For example, add ath10k_debug_stop() and
call it from there? I don't think any of this should be in core.c.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] ath10k: cache calibration data when the core is stopped.
From: Valo, Kalle @ 2016-10-03 7:51 UTC (permalink / raw)
To: Marty Faltesek; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <1473801118-103112-1-git-send-email-mfaltesek@google.com>
Marty Faltesek <mfaltesek@google.com> writes:
> Caching calibration data allows it to be accessed when the
> device is not active.
>
> Signed-off-by: Marty Faltesek <mfaltesek@google.com>
[...]
> +int
> +ath10k_cal_data_alloc(struct ath10k *ar, void **buf)
> +{
[...]
> + ath10k_cal_data_alloc(ar, &ar->cal_data);
[...]
> + ret =3D ath10k_cal_data_alloc(ar, &file->private_data);
Pointer to pointer parameters can be a source of problems and if we
could use one shared buffer for both of these cases when it would
simplify the code and we would need the buf parameter at all.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: add platform regulatory domain support
From: Valo, Kalle @ 2016-10-03 7:52 UTC (permalink / raw)
To: bartosz.markowski@tieto.com
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CACKGw+GDbiCLsE7VVas7ATDE0aBZOkbBperXQP0c7XASJgXQ=Q@mail.gmail.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> On 14 September 2016 at 09:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote=
:
>>
>> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>>
>> > On 12 September 2016 at 17:35, Valo, Kalle <kvalo@qca.qualcomm.com> wr=
ote:
>> >
>> >> > +#ifdef CONFIG_ACPI
>> >> > +#define WRD_METHOD "WRDD"
>> >> > +#define WRDD_WIFI (0x07)
>> >> > +
>> >> > +static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_o=
bject *wrdd)
>> >> > +{
>> >>
>> >> I don't think the ifdef is really necessary, acpi.h should handle tha=
t
>> >> (hopefully). Also I changed the error handling to use standard error
>> >> values and changed the info messages to dbg, they are too spammy in m=
y
>> >> opinion. Please check carefully my changes in the pending branch:
>> >>
>> >> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=
=3Dpending&id=3Dfe91745381ec3999d8de6dedb07b396c82539717
>> >
>> > I'm OK with the changes, I have not tried that though, except of
>> > reviewing and compiling it (do not have access to the chromebook for
>> > next few days). If you want to wait with it until I test it, it's fine
>> > too.
>>
>> Ok, I'll wait for few days in case you have time to test it.
>
>
> Sorry, it took so long. I've final check this and can confirm the patch.
Thanks, I'll apply the patch soon. Do note that I changed more of the
warnings messages to debug level.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] ath10k: cache calibration data when the core is stopped.
From: Michal Kazior @ 2016-10-03 8:02 UTC (permalink / raw)
To: Marty Faltesek; +Cc: ath10k@lists.infradead.org, linux-wireless
In-Reply-To: <1473801118-103112-1-git-send-email-mfaltesek@google.com>
On 13 September 2016 at 23:11, Marty Faltesek <mfaltesek@google.com> wrote:
[...]
> +int
> +ath10k_cal_data_alloc(struct ath10k *ar, void **buf)
> +{
> + u32 hi_addr;
> + __le32 addr;
> + int ret;
> +
> + vfree(*buf);
> + *buf =3D vmalloc(QCA988X_CAL_DATA_LEN);
Shouldn't you use ar->hw_params to get hw-specific caldata length?
[...]
> @@ -1714,6 +1750,12 @@ int ath10k_core_start(struct ath10k *ar, enum ath1=
0k_firmware_mode mode)
>
> INIT_LIST_HEAD(&ar->arvifs);
>
> + /*
> + * We are up now, so no need to cache calibration data.
> + */
The comment style is:
/* comment */
If it's multi-line it should be:
/* comment
* comment
*/
Ditto for other instances.
[...]
> @@ -1757,6 +1799,11 @@ void ath10k_core_stop(struct ath10k *ar)
> lockdep_assert_held(&ar->conf_mutex);
> ath10k_debug_stop(ar);
>
> + /*
> + * Cache caclibration data while stopped.
typo. "calibration"
Micha=C5=82
^ permalink raw reply
* [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-03 10:00 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
If generic entries are positioned above specific ones, then the
former will be matched first and used instead of the latter.
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@lists.ath9k.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
---
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -26,7 +26,6 @@
{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
- { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
#ifdef CONFIG_ATH9K_PCOEM
/* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
@@ -37,7 +36,7 @@
.driver_data = ATH9K_PCI_LED_ACT_HI },
#endif
- { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
#ifdef CONFIG_ATH9K_PCOEM
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
@@ -85,7 +84,11 @@
0x10CF, /* Fujitsu */
0x1536),
.driver_data = ATH9K_PCI_D3_L1_WAR },
+#endif
+ { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+
+#ifdef CONFIG_ATH9K_PCOEM
/* AR9285 card for Asus */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
0x002B,
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-09-30
From: Johannes Berg @ 2016-10-03 10:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <20161003.015401.1915647209236695770.davem@davemloft.net>
On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote:
>
> Could you please look into this and send me a new pull request with
> the conflicts resolved?
>
Sure, will do (tomorrow, we have a holiday today).
Would you prefer I send you the merge resolution for your tree, or just
pull in net for a new pull request?
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 10:44 UTC (permalink / raw)
To: Johannes Berg
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475229714.17481.18.camel@sipsolutions.net>
Am 30.09.2016 um 12:01 schrieb Johannes Berg:
> A few more things:
>
> First of all - there's nothing specific to "AP interfaces", which you
> say in the subject, as far as I can tell? That should be removed?
>> if (unlikely(ta &&
>>+ (iftype == NL80211_IFTYPE_AP ||
>>+ iftype == NL80211_IFTYPE_AP_VLAN) &&
>>+ !ether_addr_equal(ta, eth.h_source)
>>+ ))
>>+ goto purge;
So the A-MSDU packets are only dropped if received by an interface in AP
or AP_VLAN mode, not on client side, as my original issue was about
arp/ip filters being circumvented on AP side.
>> IEEE 802.11-2012 mandates that the outer source mac address should
>> match the inner source address (section 8.3.2.2). For the
>> destination mac address, matching is not required (section 10.23.15).
>
> I think this is wrong. As we do not support DMS (yet), we should adhere
> to 8.3.2.2 and only accept matching TA/SA and DA/RA.
IEEE 802.11-2012 8.3.2.2 contains the note "NOTE—It is possible to have
different DA and SA parameter values in A-MSDU subframe headers of the
same A-MSDU as long as they all map to the same Address 1 and Address 2
parameter values."
I conclude that embedding multicast in unicast A-MSDU frames is
generally allowed, because "mapping" does not mean "be identical".
Regards,
M. Braun
^ permalink raw reply
* Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN
From: M. Braun @ 2016-10-03 11:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1475235707.17481.44.camel@sipsolutions.net>
Am 30.09.2016 um 13:41 schrieb Johannes Berg:
>> - sta = sta_info_get(sdata, mgmt->da);
>> + if (ieee80211_vif_is_mesh(&sdata->vif))
>> + sta = sta_info_get(sdata, mgmt->da);
>> + else
>> + sta = sta_info_get_bss(sdata, mgmt->da);
>>
> I don't see why you need to distinguish between mesh and non-mesh
> here?
> get_bss() will ignore the BSS pointer if it's NULL, and that will
> always be the case when the type is mesh, so ... why?
because the in ieee80211_mgmt_tx the
> case NL80211_IFTYPE_AP:
> case NL80211_IFTYPE_AP_VLAN:
> case NL80211_IFTYPE_P2P_GO:
> ...
> rcu_read_lock();
> if (ieee80211_vif_is_mesh(&sdata->vif))
> sta = sta_info_get(sdata, mgmt->da);
> else
> sta = sta_info_get_bss(sdata, mgmt->da);
> rcu_read_unlock();
>
does it the same way and I wanted to go safe and not change the mesh path.
michael
^ permalink raw reply
* [PATCHv2 1/3] mac80211: fix CMD_FRAME for AP_VLAN
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd needs to
send out a frame using CMD_FRAME for a station assigned to an AP_VLAN
interface.
Right now, the userspace needs to give the exact AP_VLAN interface index
for CMD_FRAME; hostapd does not do this. Additionally, userspace cannot
use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION finds
stations assigned to AP_VLAN even if the AP iface is queried, it does not
return AP_VLAN ifidx (it returns the queried one).
This breaks IEEE 802.11r over_ds with vlans, as the reply frame does not
get out. This patch fixes this by using get_sta_bss for CMD_FRAME.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
---
net/mac80211/offchannel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index 55a9c5b..688744c 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -819,7 +819,7 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
mgmt->u.action.category == WLAN_CATEGORY_SPECTRUM_MGMT)
break;
rcu_read_lock();
- sta = sta_info_get(sdata, mgmt->da);
+ sta = sta_info_get_bss(sdata, mgmt->da);
rcu_read_unlock();
if (!sta)
return -ENOLINK;
--
2.1.4
^ permalink raw reply related
* [PATCHv3 2/3] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes
Cc: Michael Braun, linux-wireless, projekt-wlan, kvalo, akarwar,
nishants, Larry.Finger, Jes.Sorensen
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
When using WPA security, the station and thus the required key is
identified by its mac address when packets are received. So a
station usually cannot spoof its source mac address.
But when a station sends an A-MSDU frame, port control and crypto
is done using the outer mac address, while the packets delivered
and forwarded use the inner mac address.
This might affect ARP/IP filtering on the AccessPoint.
IEEE 802.11-2012 mandates that the outer source mac address should
match the inner source address (section 8.3.2.2). For the destination
mac address, matching is not required, as a wifi client may send all
its traffic to the AP in order to have it forwarded.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
Cc: kvalo@codeaurora.org
Cc: akarwar@marvell.com
Cc: nishants@marvell.com
Cc: Larry.Finger@lwfinger.net
Cc: Jes.Sorensen@redhat.com
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 3 ++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +-
drivers/staging/rtl8723au/core/rtw_recv.c | 2 +-
include/net/cfg80211.h | 9 ++++----
net/mac80211/rx.c | 11 +++++++--
net/wireless/util.c | 26 ++++++++--------------
6 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 4fdc3da..05dcaef 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1436,7 +1436,8 @@ static void iwl_mvm_report_wakeup_reasons(struct iwl_mvm *mvm,
memcpy(skb_put(pkt, pktsize), pktdata, pktsize);
- if (ieee80211_data_to_8023(pkt, vif->addr, vif->type))
+ if (ieee80211_data_to_8023(pkt, NULL, vif->addr,
+ vif->type))
goto report;
wakeup.packet = pkt->data;
wakeup.packet_present_len = pkt->len;
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index a74cc43..49d0efe 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -45,7 +45,7 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
skb_trim(skb, le16_to_cpu(local_rx_pd->rx_pkt_length));
ieee80211_amsdu_to_8023s(skb, &list, priv->curr_addr,
- priv->wdev.iftype, 0, false);
+ priv->wdev.iftype, 0, NULL);
while (!skb_queue_empty(&list)) {
struct rx_packet_hdr *rx_hdr;
diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c b/drivers/staging/rtl8723au/core/rtw_recv.c
index 150dabc..caa0e7c 100644
--- a/drivers/staging/rtl8723au/core/rtw_recv.c
+++ b/drivers/staging/rtl8723au/core/rtw_recv.c
@@ -1687,7 +1687,7 @@ int amsdu_to_msdu(struct rtw_adapter *padapter, struct recv_frame *prframe)
skb_pull(skb, prframe->attrib.hdrlen);
__skb_queue_head_init(&skb_list);
- ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, false);
+ ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, NULL);
while (!skb_queue_empty(&skb_list)) {
sub_skb = __skb_dequeue(&skb_list);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index beb7610..d768fcd 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3905,12 +3905,13 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr);
/**
* ieee80211_data_to_8023 - convert an 802.11 data frame to 802.3
* @skb: the 802.11 data frame
+ * @ehdr: (out) buffer for source/destination address (optional)
* @addr: the device MAC address
* @iftype: the virtual interface type
* Return: 0 on success. Non-zero on error.
*/
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype);
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype);
/**
* ieee80211_data_from_8023 - convert an 802.3 frame to 802.11
@@ -3938,12 +3939,12 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
* @addr: The device MAC address.
* @iftype: The device interface type.
* @extra_headroom: The hardware extra headroom for SKBs in the @list.
- * @has_80211_header: Set it true if SKB is with IEEE 802.11 header.
+ * @ta: transmitter address (or NULL)
*/
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header);
+ const u8 *ta);
/**
* cfg80211_classify8021d - determine the 802.1p/1d tag for a data frame
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9dce3b1..fbf99b8 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2090,7 +2090,8 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, bool *port_control)
sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta)
return -1;
- ret = ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
+ ret = ieee80211_data_to_8023(rx->skb, NULL, sdata->vif.addr,
+ sdata->vif.type);
if (ret < 0)
return ret;
@@ -2243,6 +2244,7 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
__le16 fc = hdr->frame_control;
struct sk_buff_head frame_list;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
+ struct ethhdr eth_80211;
if (unlikely(!ieee80211_is_data(fc)))
return RX_CONTINUE;
@@ -2268,9 +2270,14 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
skb->dev = dev;
__skb_queue_head_init(&frame_list);
+ if (ieee80211_data_to_8023(skb, ð_80211, dev->dev_addr,
+ rx->sdata->vif.type) < 0)
+ return RX_DROP_UNUSABLE;
+
ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,
rx->sdata->vif.type,
- rx->local->hw.extra_tx_headroom, true);
+ rx->local->hw.extra_tx_headroom,
+ eth_80211.h_source);
while (!skb_queue_empty(&frame_list)) {
rx->skb = __skb_dequeue(&frame_list);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b7d1592..efa4f5f 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -414,8 +414,8 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr)
}
EXPORT_SYMBOL(ieee80211_get_mesh_hdrlen);
-static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
- const u8 *addr, enum nl80211_iftype iftype)
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct {
@@ -519,12 +519,6 @@ static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
return 0;
}
-
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype)
-{
- return __ieee80211_data_to_8023(skb, NULL, addr, iftype);
-}
EXPORT_SYMBOL(ieee80211_data_to_8023);
int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
@@ -740,24 +734,18 @@ __ieee80211_amsdu_copy(struct sk_buff *skb, unsigned int hlen,
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header)
+ const u8 *ta)
{
unsigned int hlen = ALIGN(extra_headroom, 4);
struct sk_buff *frame = NULL;
u16 ethertype;
u8 *payload;
- int offset = 0, remaining, err;
+ int offset = 0, remaining;
struct ethhdr eth;
bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb);
bool reuse_skb = false;
bool last = false;
- if (has_80211_header) {
- err = __ieee80211_data_to_8023(skb, ð, addr, iftype);
- if (err)
- goto out;
- }
-
while (!last) {
unsigned int subframe_len;
int len;
@@ -768,6 +756,11 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
subframe_len = sizeof(struct ethhdr) + len;
padding = (4 - subframe_len) & 0x3;
+ if (unlikely(ta && !ether_addr_equal(ta, eth.h_source) &&
+ (iftype == NL80211_IFTYPE_AP ||
+ iftype == NL80211_IFTYPE_AP_VLAN)))
+ goto purge;
+
/* the last MSDU has no padding */
remaining = skb->len - offset;
if (subframe_len > remaining)
@@ -813,7 +806,6 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
purge:
__skb_queue_purge(list);
- out:
dev_kfree_skb(skb);
}
EXPORT_SYMBOL(ieee80211_amsdu_to_8023s);
--
2.1.4
^ permalink raw reply related
* [PATCHv3 3/3] mwifiex: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-10-03 11:14 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan, akarwar, nishants
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
When using WPA security, the station and thus the required key is
identified by its mac address when packets are received. So a
station usually cannot spoof its source mac address.
But when a station sends an A-MSDU frame, port control and crypto
is done using the outer mac address, while the packets delivered
and forwarded use the inner mac address.
This might affect ARP/IP filtering on the AccessPoint.
IEEE 802.11-2012 mandates that the outer source mac address should
match the inner source address (section 8.3.2.2). For the destination
mac address, matching is not required, as a wifi client may send all
its traffic to the AP in order to have it forwarded.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org
Cc: projekt-wlan@fem.tu-ilmenau.de
Cc: akarwar@marvell.com
Cc: nishants@marvell.com
---
drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 49d0efe..f4469d7 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -30,7 +30,8 @@
* layer.
*/
static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ const u8 *ta)
{
struct rxpd *local_rx_pd = (struct rxpd *)(skb->data);
int ret;
@@ -45,7 +46,7 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
skb_trim(skb, le16_to_cpu(local_rx_pd->rx_pkt_length));
ieee80211_amsdu_to_8023s(skb, &list, priv->curr_addr,
- priv->wdev.iftype, 0, NULL);
+ priv->wdev.iftype, 0, ta);
while (!skb_queue_empty(&list)) {
struct rx_packet_hdr *rx_hdr;
@@ -76,9 +77,10 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
/* This function will process the rx packet and forward it to kernel/upper
* layer.
*/
-static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
+static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload,
+ const u8 *ta)
{
- int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
+ int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload, ta);
if (!ret)
return 0;
@@ -119,7 +121,7 @@ mwifiex_11n_dispatch_pkt_until_start_win(struct mwifiex_private *priv,
}
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
if (rx_tmp_ptr)
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -161,7 +163,7 @@ mwifiex_11n_scan_and_dispatch(struct mwifiex_private *priv,
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -568,12 +570,12 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
if (!tbl) {
if (pkt_type != PKT_TYPE_BAR)
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
if ((pkt_type == PKT_TYPE_AMSDU) && !tbl->amsdu) {
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] mac80211: fix CMD_FRAME for AP_VLAN
From: M. Braun @ 2016-10-03 11:31 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1474786035-15410-1-git-send-email-michael-dev@fami-braun.de>
Am 03.10.2016 um 13:03 schrieb M. Braun:
> because the in ieee80211_mgmt_tx the
ups, that was the patch itself.
I think I carried it over from ieee80211_add_key, that does
>
> if (mac_addr) {
> if (ieee80211_vif_is_mesh(&sdata->vif))
> sta = sta_info_get(sdata, mac_addr);
> else
> sta = sta_info_get_bss(sdata, mac_addr);
>
Regards,
M. Braun
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Jes Sorensen @ 2016-10-03 12:21 UTC (permalink / raw)
To: Franc[e]sco; +Cc: linux-wireless
In-Reply-To: <ec3a2db3-1e52-e2f1-1a3a-52bdfed3c803@waifu.club>
"Franc[e]sco" <lolisamurai@waifu.club> writes:
> Thanks for the patch, just tested the rtl8xxxu-devel branch and it seems
> to have the same exact issue with the same dmesg output with the
> addition of "rtl8192eu_active_to_emu: Disabling MAC timed out" when I
> disconnect the dongle.
>
> I checked out and compiled the whole kernel from the branch because the
> 4.7.4 sources seemed to be missing the rtl8192eu_active_to_emu function.
There are other patches related to the 8192eu in the wireless tree which
fix some issues with the dongle if you reload the driver. Alternatively
pull my git tree and build that.
Jes
^ permalink raw reply
* Re: [PATCH 1/2] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Jes Sorensen @ 2016-10-03 12:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <87wphpsxky.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes.Sorensen@redhat.com writes:
>
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> A device running without RX package aggregation could return more data
>> in the USB packet than the actual network packet. In this case the
>> could would clone the skb but then determine that that there was no
>> packet to handle and exit without freeing the cloned skb first.
>
> s/case the/case we/? I can edit that before applying the patch.
Sounds good - thanks!
Jes
^ permalink raw reply
* Re: [PATCH 2/2] rtl8xxxu: Fix big-endian problem reporting mactime
From: Jes Sorensen @ 2016-10-03 12:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Larry.Finger, stable
In-Reply-To: <87shsdsxj9.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes.Sorensen@redhat.com writes:
>
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> The full RX descriptor is converted so converting tsfl again would
>> return it to it's original endian value.
>>
>> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> I'll add:
>
> Cc: stable@vger.kernel.org # 4.8+
Appreciate it!
Jes
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-10-03 13:04 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <1475027104-17423-1-git-send-email-rajatja@google.com>
Rajat Jain <rajatja@google.com> wrote:
> Enable notifying wakeup source to the PM core in case of
> a wake on wireless LAN event.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
The commit log doesn't give any background info. Does this fix a bug or
why is it needed?
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9353051/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Kalle Valo @ 2016-10-03 13:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Felix Fietkau, linux-wireless, devicetree
In-Reply-To: <201609301658.35039.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> On Friday 30 September 2016, Felix Fietkau wrote:
>> >> >> >> + device_type = "pci";
>> >> >> >> + mediatek,mtd-eeprom = <&factory 0x8000>;
>> >> >> >> + mediatek,2ghz = <0>;
>> >> >
>> >> > It's not clear what the possible values for the 2ghz property are,
>> >> > can you be more verbose in the description? How is <0> different
>> >> > from no property?
>> >> 0 means disabled, no property means unchanged (compared to EEPROM).
>> >
>> > Maybe have a boolean property instead then to say "mediatek,2ghz-disabled" ?
>> >
>> > If zero is the only possible value, there is no need to put a number in there.
>> 1 is also possible, which will force-enable the capability.
>
> Ok, then both those values should be documented in the binding.
Related to this, Martin sent patches which add generic bindings for
enabling 2 Ghz and 5 Ghz bands.
[RFC,1/3] Documentation: dt-bindings: add IEEE 802.11 binding documentation
https://patchwork.kernel.org/patch/9359833/
[RFC,2/3] of: add IEEE 802.11 device configuration support code
https://patchwork.kernel.org/patch/9359837/
--
Kalle Valo
^ permalink raw reply
* Final 4.8 w-t build is wt-2016-10-03
From: Bob Copeland @ 2016-10-03 13:45 UTC (permalink / raw)
To: linux-wireless
Per the subject, Linus released 4.8 yesterday so, unless I broke something
in recent conflict resolutions, wireless-testing is on pause until the
merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: Final 4.8 w-t build is wt-2016-10-03
From: Christian Lamparter @ 2016-10-03 14:42 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Kalle Valo
In-Reply-To: <20161003134507.GA9911@localhost>
Hello,
On Monday, October 3, 2016 9:45:07 AM CEST Bob Copeland wrote:
> Per the subject, Linus released 4.8 yesterday so, unless I broke something
> in recent conflict resolutions, wireless-testing is on pause until the
> merge window closes in two weeks. Have a happy (Canadian) thanksgiving!
>
> https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
Thanks for the timely update.
I have a request: can you please pull Linus' kernel tags?
Currently the last tag from Linus' is v4.4-rc4 [0] and
everything between v4.4-rc5 and v4.8 is missing?!
Regards,
Christian
[0] <https://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git/refs/tags>
^ permalink raw reply
* Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands
From: Rob Herring @ 2016-10-03 15:22 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Mark Rutland, Frank Rowand, devicetree@vger.kernel.org,
Felix Fietkau, linux-wireless, ath9k-devel, ath9k-devel,
Kalle Valo
In-Reply-To: <20161002225059.16757-1-martin.blumenstingl@googlemail.com>
On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> There are at least two drivers (ath9k and mt76) out there, where
> devicetree authors need to override the enabled bands.
>
> For ath9k there is only one use-case: disabling a band which has been
> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
> possible because the calibration data would be missing in the EEPROM).
> The mt76 driver (currently pending for review) however allows enabling
> and disabling the 2.4GHz and 5GHz band, see [0].
>
> Based on the discussion of (earlier versions of) my ath9k devicetree
> patch it was suggested [1] that we use enable- and disable- properties.
> The current patch implements:
> - bands can be enabled or disabled with the corresponding property
> - if both (disable and enable) properties are given and a driver asks
> whether the band is enabled then the logic will return false (= not
> enabled, preferring the disabled flag)
> - if both (disable and enable) properties are given and a driver asks
> whether the band is disabled then the logic will return true (again,
> preferring the disabled flag over the enabled flag)
>
> We can still change the logic to do what the mt76 driver does (I am
> fine with both solutions):
> - property not available: driver decides which bands to enable
> - property set to 0: disable the band
> - property set to 1: enable the band
I prefer this way. Really, I'd prefer just a boolean disable property.
I'm not sure why you need the enable. We usually have these tri-state
properties when you want not present to mean use the bootloader or
default setting. Try to make not present the most common case.
> The new code has been integrated into ath9k to demonstrate how to use
> it (with the benefit that the disable_2ghz and disable_5ghz settings
> from the ath9k_platform_data can now also be configured via .dts).
>
> open questions/decisions needed:
> - where to place this new code? I put it into drivers/of/of_ieee80211
> because that's where most other functions live.
> However, I found that this makes backporting the code harder (using
> wireless-backports from the driver-backports project [2])
We are generally moving subsystem specific code like this out of
drivers/of/, so please do that here. Maybe someone will get motivated
to move the other networking code out too.
> - we need a decision whether we want to go with two flags for each
> band (enable-ieee80211-band and disable-ieee80211-band) or if we
> prefer the solution from the mt76 driver (which means that the
> property for a band is absent for auto-detection, or
> ieee80211-band-enabled = <0/1> is specified. we could also move
> the 0 and 1 to a header file of course to make it easer to read,
> such as IEEE80211_BAND_ENABLED and IEEE80211_BAND_DISABLED)
Please don't add defines for this. 0/1 meaning false/true is clear enough IMO.
Rob
^ 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