Jeon | 20 Jun 20:57 2016
Picon

Is there a way to get a gain value of AGC?

Dear developers,
Is there a way to get a gain value of AGC?

To get nearly-correct RSSI, or CSI magnitude values, I think I need to know how much gain is obtained from AGC.

Intel 5300 NIC (iwlwifi) can get a such AGC value with this tool. (http://dhalperi.github.io/linux-80211n-csitool/) However, its Atheros version (http://pdcc.ntu.edu.sg/wands/Atheros/), doesn't have a such functionality.

I wonder whether the author did not implement it, or it can't be implemented in aht9k.
It says that it is impossible because AGC is implemented with CMOS technology.
Since it's a quite old thread and time passed, I'd like to check if there is any updates to get AGC, or correct RSSI, CSI magnitude.

Regards,
Jeon.
_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Jeon | 17 Jun 09:08 2016
Picon

unknown phase offset added to CSI measurement at 2.4 GHz?

It is not directly related with ath9k, but with Intel 5300 NIC.


dhalperi says:

> On 2.4 GHz bands, it appears that each antenna experiences an unknown phase shift by a multiple of π/2 (or 90 degrees). This is probably what you're seeing?
> If I recall correctly, this effect does not show up at 5 GHz(*). So if you do your experiments in that band, you may not have this problem.
> (*) Manikanta Kotaru from Stanford pointed out that this effect disappears on 5 GHz, and pointed at Section 3 in Jon Gjengset, Graeme McPhillips, and Kyle Jamieson's ArrayPhaser ( <at> jonhoo's) paper as evidence.

I wonder whether it applies to all 2.4 GHz devices, which means it is not a manufacturer-specific problem. Or, is it a manufacturer(Intel)-specific problem, so thus ath9k does not suffer such problem? Or even worse, will ath9k suffer such  problem at both 2.4 GHz and 5 GHz?

Regards,
Jeon.
_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Jeon | 17 Jun 09:08 2016
Picon

Re: linearity of ath9k CSI phase

Dear Joe Ayers

Thanks for your response again.
I started studying and investigating on antennas theories.

Regards,
Jeon.

2016-06-14 14:19 GMT+09:00 Joe Ayers <joe <at> ayerscasa.com>:
This increased spacing looks to impact the detection angle before aliasing occurs with grating lobes.   Google around, but looks like 1/2 wave length spacing gives full +/-90 deg.  Going up to 1 wave length spacing reduces the detection angle to +/-30 deg before aliasing.



On Mon, Jun 13, 2016 at 8:39 PM, Jeon <sjeon87+ath9k <at> gmail.com> wrote:
Dear Joe Ayers,
Thank you for response.

I don't have a sort of RF anechoic chamber. So, I've captured CSI in a quite realistic and practical environemnt with possible interference and multipath components. There are other WLAN APs, Bluetooth devices. Also, there exist desks, chairs and walls as reflectors.

Yet, I don't think it does matter to capture CSI and estimate true phase. My attempts are based on a couple of papers which have done estimating true phase and AoA of a signal with uniform linear antenna array (ULA) in a realistic and practical living environment [1, 2, 3]. Which means, those papers claim that they can identify directpath component and multipath components with MUSIC algorithm [4].

One suspicious thing is, I think distance between antennas of ULA is misconfigured. I placed them 6.5 cm apart from each other. With calculation, a half of wavelength at 2.4 GHz band is less than 6.25 cm. Does it matter a lot?

Regards,
Jeon.

[1]: K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8.
[2]: J. Xiong and K. Jamieson, “ArrayTrack: A Fine-Grained Indoor Location System,” in Presented as part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13), Lombard, IL, 2013, pp. 71–84.
[3]: M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015.
[4]: R. Schmidt, “Multiple emitter location and signal parameter estimation,” IEEE Transactions on Antennas and Propagation, vol. 34, no. 3, pp. 276–280, Mar. 1986.

2016-06-14 3:28 GMT+09:00 Joe Ayers <joe <at> ayerscasa.com>:
Jeon,

"only constant offset across subcarrier seems to be effective".    Could this be because there's not just one signal being received anymore, rather with microwaves, particularly with lots of nearby reflection surfaces, there's now ~10 signals bouncing in to the receive antenna at 10 AoA's--some with 2x the distance-delay traveled--and resonance/nulls occurring?  How perfect is your test environment?

Joe AE6XE

On Mon, Jun 13, 2016 at 10:00 AM, Jeon <sjeon87+ath9k <at> gmail.com> wrote:
Dear ath9k developers,

I am currently working with Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier.

- Background

[2], [3] and many other papers claim that phase information from extracted CSI contains two components: true phase and unwanted phase offset due to subcarrier and time delay.
i.e., measured_phase = true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_mismatch
This equation can be visualized as below:

http://i.imgur.com/rk9Hh1M.png

(Please note that this figure is based on CSI tool for Intel 5300 NIC.)

It contains unwanted linear phase offset and constant phase offset. Since the true phase is relatively small, it seems that phase is monotonically increasing or decreasing in macro view due to the unwanted phase offsets. We cannot see a tiny true phase currently.

To remove phase offset due to subcarrier, the mentioned papers are attempting to remove it with linear fitting ax + b,
where a = slope of the figure, b = average of measured phase, and x = subcarrier index.

After removing unwanted phase offset components, the true phase is estimated.
This estimated true phase seems steady and consistent across a time duration shorter than < 100 - 1000 ms:

http://i.imgur.com/AO89vYV.png

Note that Y-axis scale is reduece from [-50, 10] to [5, -3]

- My question

I want to extract and manipulate CSI phase WITH ATH9K NIC.

After extracting CSI from my ath9k NIC (AR9580 <at> 2.4 GHz) with Atheros CSI extraction tool,
I've tried various fitting methods to eliminate unwanted components and stacked results from nearly 100 packets:

http://i.imgur.com/5r9eYwO.png

From the result, in short, removing only constant offset across subcarrier seems to be effective. But I'm not sure.
And sometimes, some phase measurement show large dispalcement along y-axis even they are captured within very short duration.

Hence the question is,
Is ath9k reports CSI with those unwanted linear phase offset removed?
If it is not, should I look into Atheros CSI tool? As I look into it, it just captures CSI from the kernel and does not modify it.
Or, Is CSI of Atheros different form that of Intel? I don't think so...

The final goal of extracting true phase from CSI of ath9k is to determine angle of arrival (AoA) of signal.

Regards,
Jeon.

[1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool"
[2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8.
[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015.
[4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI Tool"

_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel




_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel



_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Jeon | 14 Jun 05:39 2016
Picon

Re: linearity of ath9k CSI phase

Dear Joe Ayers,
Thank you for response.

I don't have a sort of RF anechoic chamber. So, I've captured CSI in a quite realistic and practical environemnt with possible interference and multipath components. There are other WLAN APs, Bluetooth devices. Also, there exist desks, chairs and walls as reflectors.

Yet, I don't think it does matter to capture CSI and estimate true phase. My attempts are based on a couple of papers which have done estimating true phase and AoA of a signal with uniform linear antenna array (ULA) in a realistic and practical living environment [1, 2, 3]. Which means, those papers claim that they can identify directpath component and multipath components with MUSIC algorithm [4].

One suspicious thing is, I think distance between antennas of ULA is misconfigured. I placed them 6.5 cm apart from each other. With calculation, a half of wavelength at 2.4 GHz band is less than 6.25 cm. Does it matter a lot?

Regards,
Jeon.

[1]: K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8.
[2]: J. Xiong and K. Jamieson, “ArrayTrack: A Fine-Grained Indoor Location System,” in Presented as part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13), Lombard, IL, 2013, pp. 71–84.
[3]: M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015.
[4]: R. Schmidt, “Multiple emitter location and signal parameter estimation,” IEEE Transactions on Antennas and Propagation, vol. 34, no. 3, pp. 276–280, Mar. 1986.

2016-06-14 3:28 GMT+09:00 Joe Ayers <joe <at> ayerscasa.com>:
Jeon,

"only constant offset across subcarrier seems to be effective".    Could this be because there's not just one signal being received anymore, rather with microwaves, particularly with lots of nearby reflection surfaces, there's now ~10 signals bouncing in to the receive antenna at 10 AoA's--some with 2x the distance-delay traveled--and resonance/nulls occurring?  How perfect is your test environment?

Joe AE6XE

On Mon, Jun 13, 2016 at 10:00 AM, Jeon <sjeon87+ath9k <at> gmail.com> wrote:
Dear ath9k developers,

I am currently working with Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier.

- Background

[2], [3] and many other papers claim that phase information from extracted CSI contains two components: true phase and unwanted phase offset due to subcarrier and time delay.
i.e., measured_phase = true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_mismatch
This equation can be visualized as below:

http://i.imgur.com/rk9Hh1M.png

(Please note that this figure is based on CSI tool for Intel 5300 NIC.)

It contains unwanted linear phase offset and constant phase offset. Since the true phase is relatively small, it seems that phase is monotonically increasing or decreasing in macro view due to the unwanted phase offsets. We cannot see a tiny true phase currently.

To remove phase offset due to subcarrier, the mentioned papers are attempting to remove it with linear fitting ax + b,
where a = slope of the figure, b = average of measured phase, and x = subcarrier index.

After removing unwanted phase offset components, the true phase is estimated.
This estimated true phase seems steady and consistent across a time duration shorter than < 100 - 1000 ms:

http://i.imgur.com/AO89vYV.png

Note that Y-axis scale is reduece from [-50, 10] to [5, -3]

- My question

I want to extract and manipulate CSI phase WITH ATH9K NIC.

After extracting CSI from my ath9k NIC (AR9580 <at> 2.4 GHz) with Atheros CSI extraction tool,
I've tried various fitting methods to eliminate unwanted components and stacked results from nearly 100 packets:

http://i.imgur.com/5r9eYwO.png

From the result, in short, removing only constant offset across subcarrier seems to be effective. But I'm not sure.
And sometimes, some phase measurement show large dispalcement along y-axis even they are captured within very short duration.

Hence the question is,
Is ath9k reports CSI with those unwanted linear phase offset removed?
If it is not, should I look into Atheros CSI tool? As I look into it, it just captures CSI from the kernel and does not modify it.
Or, Is CSI of Atheros different form that of Intel? I don't think so...

The final goal of extracting true phase from CSI of ath9k is to determine angle of arrival (AoA) of signal.

Regards,
Jeon.

[1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool"
[2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8.
[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015.
[4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI Tool"

_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel



_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Jeon | 13 Jun 19:00 2016
Picon

linearity of ath9k CSI phase

Dear ath9k developers,

I am currently working with Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier.

- Background

[2], [3] and many other papers claim that phase information from extracted CSI contains two components: true phase and unwanted phase offset due to subcarrier and time delay.
i.e., measured_phase = true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_mismatch
This equation can be visualized as below:

http://i.imgur.com/rk9Hh1M.png

(Please note that this figure is based on CSI tool for Intel 5300 NIC.)

It contains unwanted linear phase offset and constant phase offset. Since the true phase is relatively small, it seems that phase is monotonically increasing or decreasing in macro view due to the unwanted phase offsets. We cannot see a tiny true phase currently.

To remove phase offset due to subcarrier, the mentioned papers are attempting to remove it with linear fitting ax + b,
where a = slope of the figure, b = average of measured phase, and x = subcarrier index.

After removing unwanted phase offset components, the true phase is estimated.
This estimated true phase seems steady and consistent across a time duration shorter than < 100 - 1000 ms:

http://i.imgur.com/AO89vYV.png

Note that Y-axis scale is reduece from [-50, 10] to [5, -3]

- My question

I want to extract and manipulate CSI phase WITH ATH9K NIC.

After extracting CSI from my ath9k NIC (AR9580 <at> 2.4 GHz) with Atheros CSI extraction tool,
I've tried various fitting methods to eliminate unwanted components and stacked results from nearly 100 packets:

http://i.imgur.com/5r9eYwO.png

From the result, in short, removing only constant offset across subcarrier seems to be effective. But I'm not sure.
And sometimes, some phase measurement show large dispalcement along y-axis even they are captured within very short duration.

Hence the question is,
Is ath9k reports CSI with those unwanted linear phase offset removed?
If it is not, should I look into Atheros CSI tool? As I look into it, it just captures CSI from the kernel and does not modify it.
Or, Is CSI of Atheros different form that of Intel? I don't think so...

The final goal of extracting true phase from CSI of ath9k is to determine angle of arrival (AoA) of signal.

Regards,
Jeon.

[1]: http://pdcc.ntu.edu.sg/wands/Atheros/ "Atheros CSI Extraction Tool"
[2] K. Qian, C. Wu, Z. Yang, Y. Liu, and Z. Zhou, “PADS: Passive detection of moving targets with dynamic speed using PHY layer information,” in 2014 20th IEEE International Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1–8.
[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, “SpotFi: Decimeter Level Localization Using WiFi,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 4, pp. 269–282, Aug. 2015.
[4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI Tool"
_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Kamran Nishat | 11 Jun 22:59 2016
Picon

Spectral Scan on extended channel

Hi,
In 20/40 mode if there is a transmission on extended channel while
primary channel is idle. Using only the data given in the struct of
spectral scan. How can we determine it.

Regards,
Kamran
Adrian Chadd | 10 Jun 04:56 2016
Picon
Gravatar

ath9k EDMA behaviour with TXOP?

hi,

I've noticed something reasonably quirky with the AR9380 and later
EDMA engine and I'd like to see if anyone else has seen it with ath9k.

It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is
gated by a TX FIFO entry. Ie, if you queue 8 separate TX FIFO entries,
each with a single MPDU, then you end up only getting one frame per
burst window.

For TDMA it shows up as frames only going out every time I push new
frames into the FIFO. It's very .. odd.

Now, if I try /really hard/ to keep pushing groups of frames into the
FIFO (ie, a list of frames per TX FIFO slot) and I don't push a single
frame here and there in, I get reasonably consistent 30mbit
performance each way, which is what I'm expecting without A-MPDU or
A-MSDU aggregation.

But if I schedule say, 5 groups of 32 frames and then one frame, the
PCU/QCU doesn't seem to grant that queue any more airtime until I push
/another/ frame into the TX FIFO. Merely just hitting TXE for that
queue doesn't work - I have to push in more frames to keep it
immediately going rather than waiting for the next TXOP/gating time.

So, I have some local hacks that only push groups of X (where X is 16
atm) frames into TX FIFO slots to keep the engine happy and will only
push a shorter amount of frames into the TX FIFO if the FIFO itself is
empty. That gets the performance on part with TDMA on AR5416/AR9280,
which was the initial goal.

Ok, so with all of the above - has anyone seen this kind of behaviour
with ath9k? eg, doing lots of non-aggregate frames to some WMM burst
queue, like voice or video?

Thanks,

-adrian
gregkh | 4 Jun 21:30 2016
Gravatar

Patch "ath9k: Add a module parameter to invert LED polarity." has been added to the 4.6-stable tree


This is a note to let you know that I've just added the patch titled

    ath9k: Add a module parameter to invert LED polarity.

to the 4.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     ath9k-add-a-module-parameter-to-invert-led-polarity.patch
and it can be found in the queue-4.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable <at> vger.kernel.org> know about it.

From cd84042ce9040ad038e958bc67a46fcfc015c736 Mon Sep 17 00:00:00 2001
From: "Vittorio Gambaletta (VittGam)" <linux-wireless <at> vittgam.net>
Date: Mon, 11 Apr 2016 04:48:54 +0200
Subject: ath9k: Add a module parameter to invert LED polarity.

From: Vittorio Gambaletta (VittGam) <linux-wireless <at> vittgam.net>

commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: <linux-wireless <at> vger.kernel.org>
Cc: <ath9k-devel <at> qca.qualcomm.com>
Cc: <ath9k-devel <at> lists.ath9k.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs <at> vittgam.net>
Signed-off-by: Kalle Valo <kvalo <at> qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>

---
 drivers/net/wireless/ath/ath9k/init.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
 <at>  <at>  -49,6 +49,10  <at>  <at>  int ath9k_led_blink;
 module_param_named(blink, ath9k_led_blink, int, 0444);
 MODULE_PARM_DESC(blink, "Enable LED blink on activity");

+static int ath9k_led_active_high = -1;
+module_param_named(led_active_high, ath9k_led_active_high, int, 0444);
+MODULE_PARM_DESC(led_active_high, "Invert LED polarity");
+
 static int ath9k_btcoex_enable;
 module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
 MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
 <at>  <at>  -600,6 +604,9  <at>  <at>  static int ath9k_init_softc(u16 devid, s
 	if (ret)
 		return ret;

+	if (ath9k_led_active_high != -1)
+		ah->config.led_active_high = ath9k_led_active_high == 1;
+
 	/*
 	 * Enable WLAN/BT RX Antenna diversity only when:
 	 *

Patches currently in stable-queue which might be from linux-wireless <at> vittgam.net are

queue-4.6/ath9k-add-a-module-parameter-to-invert-led-polarity.patch
queue-4.6/ath9k-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch
bruce m beach | 3 Jun 19:59 2016
Picon

ath9k_htc firmware

Hello All

 I am still working on cleaning up ath9k_htc firmware build tree for about 6
months now ( and looks like I'll be doing this for all eternity**2 ) and am
not clear myself what I'm looking for right now.

I'm looking for some kind of simple request in the ath9k_htc driver, through
the usb ep0, like a memory read on the card, where a urb is sent with
the resulting chain of events. The simpler the better. The simplest.

Bruce
Adrian Chadd | 29 May 20:14 2016
Picon
Gravatar

MCI howto?

hiya!

I'm trying to bring up MCI bluetooth coexistence on the QCA9565 on
FreeBSD. I'm having no end of trouble - it seems that no matter what I
do, the bluetooth always wins and the wifi side disconnects when the
bt does an active scan (HCI "inquiry".)

Does anyone remember the deep and amusing details about MCI support
and how to debug this? I'm sure it's something stupid, but my time at
QCA involved 2-wire and 3-wire coex (which you can debug with a
scope), not MCI :(

Thanks!

-adrian
Robert Smith | 24 May 15:39 2016

Adaptivity issues

Hi,

 

We’ve recently tried to compliance test our Atheros AR9344 based product against EN300 328 & EN301 893.

We are running OpenWRT Chaos Calmer stable version which uses ath9k included within compat-wireless-2016-01-10, we are only using the on SoC radio.

 

It fails both EN300 328 and EN301 893 adaptivity testing. It doesn’t appear to back off transmissions when other interferers are introduced.

We’ve also tried running a version of Barrier Breaker and have seen similar results.

 

Does anyone have any guidance or suggestions on how to pass this compliance testing using ath9k ?

 

Thanks in advance

Robert Smith

Eseye Limited - 8 Frederick Sanger Road - Surrey Research Park - Guildford - Surrey - GU2 7YD Call for direct access to our sales and support teams: • +44 1483 802501 (International and UK sales) • +44 1483 802503 (International and UK Technical Support) • +33 9 87 67 53 37 (France) • +1 484-935-3130 (US) • +61 8 9551 5200 (Australia) ISO27001:2013 Certified
_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Gmane