* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
80 /* Enable radar pulse detection if on a DFS channel. Spectral
81 * scanning and radar detection can not be used concurrently.
82 */
83 if (hw->conf.radar_enabled) {
84 u32 rxfilter;
85
86 rxfilter = ath9k_hw_getrxfilter(ah);
87 rxfilter |= ATH9K_RX_FILTER_PHYRADAR |
88 ATH9K_RX_FILTER_PHYERR;
89 ath9k_hw_setrxfilter(ah, rxfilter);
90 ath_dbg(common, DFS, "DFS enabled at freq %d\n",
91 chan->center_freq);
92 } else {
93 /* perform spectral scan if requested. */
94 if (test_bit(ATH_OP_SCANNING, &common->op_flags) &&
95 sc->spec_priv.spectral_mode == SPECTRAL_CHANSCAN)
96 ath9k_cmn_spectral_scan_trigger(common, &sc->spec_priv);
97 }
it seems that spectral can't ever be activated while operating on a DFS channel.
If you need to catch the opposite case, i.e. prevent feeding pseudo-radar pulses
into the pattern detector, you just need to ensure that they depend on
hw->conf.radar_enabled. A patch like the attached one should be enough.
Cheers,
Zefir
--------------81DB7B8680E9662AC7B071A0
Content-Type: text/x-patch;
name="0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-ath9k-feed-DFS-detector-only-if-operating-on-radar-c.pa";
filename*1="tch"
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
behaviour. The biggest problem seems to be that the
ath9k_hw_set_sta_beacon_timers function is never called, so once the
hardware enters the PS mode there is no hardware trigger to wake up
the hardware. However, there is a mac80211 beacon loss software timer
is the one that wakes up the hardware after 7 lost beacon.
Could you provide me more details about the link between Power Save
Mode and the hardware triggers/sleep registers from
ath9k_hw_set_sta_beacon_timers?
The ath9k_hw_set_sta_beacon_timers should be called every time a
beacon is received, right?
[1] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.3#L2269
[2] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/main.c#L486
[3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c?v=2.6.35#L639
> BR
> Janusz
>
>> Thanks,
>> Doru
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable to
> measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a hardware
> RNG that per default and without being able to change it at runtime injects
> data into the input_pool where the noise source cannot be audited. Note, even
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent that it
> does not cause /dev/random to unblock. The reason is that your noise source
> starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts to
> spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng
framework. Interrupt timings were never designed to be a source of entropy
either. We need to grab it where ever we can find it, especially on
embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of
sources under char/hw_random/. I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about
sound cards?
thx,
Jason.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-11-19 18:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-11-19 18:31 UTC (permalink / raw)
To: ath9k-devel
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind=
it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?=20
> >=20
> > Otherwise, your patch will cause high CPU load, as continuously=20
> > read ADC data if entropy bits under write_wakeup_threshold.
>=20
> The issue is that although you may have analyzed it, others are unable=20
> to measure the quality of the RNG and assess the design as well as the=20
> implementation of the RNG. This RNG is the only implementation of a=20
> hardware RNG that per default and without being able to change it at=20
> runtime injects data into the input_pool where the noise source cannot=20
> be audited. Note, even other respected RNG noise sources like the=20
> Intel RDRAND will not feed into / dev/random per default in a way that do=
minates all other noise sources.
>=20
> I would like to be able to deactivate that noise source to the extent=20
> that it does not cause /dev/random to unblock. The reason is that your=20
> noise source starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM =3D y || HW_RANDOM =3D ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card (HW_RAN=
DOM =3D y and ATH9K !=3D n), you get the behavior Stephan is pointing out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts=20
> to spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng framew=
ork. Interrupt timings were never designed to be a source of entropy eithe=
r. We need to grab it where ever we can find it, especially on embedded sy=
stems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be bog=
us (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of sources u=
nder char/hw_random/. I think the only thing we would be concerned about, =
other than the already addressed entropy estimation, would be constraining =
the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about sou=
nd cards?
thx,
Jason.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-06-13 6:24 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-06-13 6:24 UTC (permalink / raw)
To: ath9k-devel
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, =E2=80=9CPADS: Passive de=
tection
of moving targets with dynamic speed using PHY layer information,=E2=80=9D =
in 2014
20th IEEE International Conference on Parallel and Distributed Systems
(ICPADS), 2014, pp. 1=E2=80=938.
[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, =E2=80=9CSpotFi: Decime=
ter
Level Localization Using WiFi,=E2=80=9D SIGCOMM Comput. Commun. Rev., vol. =
45, no.
4, pp. 269=E2=80=93282, Aug. 2015.
[4] http://dhalperi.github.io/linux-80211n-csitool/ "Linux 802.11n CSI
Tool"
--001a113ff17008949005352bd33e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Dear ath9k developers,<br><br>I am currently working with =
Atheros CSI Extraction Tool [1] to get a true phase of each subcarrier.<br>=
<br>- Background<br><br>[2], [3] and many other papers claim that phase inf=
ormation from extracted CSI contains two components: true phase and unwante=
d phase offset due to subcarrier and time delay.<br>i.e., measured_phase =
=3D true_phase + time_delay * subcarrier_index + phase_offset_due_to_txrx_m=
ismatch<br>This equation can be visualized as below:<br><br><a href=3D"http=
://i.imgur.com/rk9Hh1M.png">http://i.imgur.com/rk9Hh1M.png</a><br><br>(Plea=
se note that this figure is based on CSI tool for Intel 5300 NIC.)<br><br>I=
t contains unwanted linear phase offset and constant phase offset. Since th=
e true phase is relatively small, it seems that phase is monotonically incr=
easing or decreasing in macro view due to the unwanted phase offsets. We ca=
nnot see a tiny true phase currently.<div><div><br>To remove phase offset d=
ue to subcarrier, the mentioned papers are attempting to remove it with lin=
ear fitting ax + b,<br>where a =3D slope of the figure, b =3D average of me=
asured phase, and x =3D subcarrier index.<br><br>After removing unwanted ph=
ase offset components, the true phase is estimated.<br>This estimated true =
phase seems steady and consistent across a time duration shorter than < =
100 - 1000 ms:<br><br><a href=3D"http://i.imgur.com/AO89vYV.png">http://i.i=
mgur.com/AO89vYV.png</a><br><br>Note that Y-axis scale is reduece from [-50=
, 10] to [5, -3]<br><br>- My question<br><br>I want to extract and manipula=
te CSI phase WITH ATH9K NIC.<br><br>After extracting CSI from my ath9k NIC =
(AR9580 @ 2.4 GHz) with Atheros CSI extraction tool,<br>I've tried vari=
ous fitting methods to eliminate unwanted components and stacked results fr=
om nearly 100 packets:<br><br><a href=3D"http://i.imgur.com/5r9eYwO.png">ht=
tp://i.imgur.com/5r9eYwO.png</a><br><br>From the result, in short, removing=
only constant offset across subcarrier seems to be effective. But I'm =
not sure.</div><div>And sometimes, some phase measurement show large dispal=
cement along y-axis even they are captured within very short duration.<br><=
br>Hence the question is,</div><div>Is ath9k reports CSI with those unwante=
d linear phase offset removed?</div><div>If it is not, should I look into A=
theros CSI tool? As I look into it, it just captures CSI from the kernel an=
d does not modify it.</div><div>Or, Is CSI of Atheros different form that o=
f Intel? I don't think so...</div><div><br></div><div>The final goal of=
extracting true phase from CSI of ath9k is to determine angle of arrival (=
AoA) of signal.<br><br>Regards,<br>Jeon.<br><br>[1]: <a href=3D"http://pdcc=
.ntu.edu.sg/wands/Atheros/">http://pdcc.ntu.edu.sg/wands/Atheros/</a> "=
;Atheros CSI Extraction Tool"<br>[2] K. Qian, C. Wu, Z. Yang, Y. Liu, =
and Z. Zhou, =E2=80=9CPADS: Passive detection of moving targets with dynami=
c speed using PHY layer information,=E2=80=9D in 2014 20th IEEE Internation=
al Conference on Parallel and Distributed Systems (ICPADS), 2014, pp. 1=E2=
=80=938.<br>[3] M. Kotaru, K. Joshi, D. Bharadia, and S. Katti, =E2=80=9CSp=
otFi: Decimeter Level Localization Using WiFi,=E2=80=9D SIGCOMM Comput. Com=
mun. Rev., vol. 45, no. 4, pp. 269=E2=80=93282, Aug. 2015.<br>[4] <a href=
=3D"http://dhalperi.github.io/linux-80211n-csitool/">http://dhalperi.github=
.io/linux-80211n-csitool/</a> "Linux 802.11n CSI Tool"
</div></div></div>
--001a113ff17008949005352bd33e--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-06-13 6:24 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-06-13 6:24 UTC (permalink / raw)
To: ath9k-devel
assumed the frequencies and numbers were correct, which is why I
picked it up.
> Is this trying to add 4.9 GHz channels in general for multiple different
> use cases? And if so, what are those use cases? Or is this only for some
> public safety cases? And if so, for which regulatory domains?
I believe he has a client that requires this support in a Linux kernel.
> To be frank, I really don't see how this would be even close to a state
> that should be accepted into the upstream tree.
Fair enough I'm dropping this.
Kalle, I've marked this as rejected and archived on Patchwork.
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2016-02-09 7:29 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2016-02-09 7:29 UTC (permalink / raw)
To: ath9k-devel
CSI Tool->
- Gives 56 complex numbers which represent the mag and phase
of the ofdm subcarriers.
- The CSI tool is listening for HT20/HT40 packets with channel sounding
bit (or bits) set so is per packet and needs a transmitter node also
- CSI is also available on some intel (sorry to mention the dirty word) chips
but you need to have specialised firmware which the kernel
and userland CSI code accesses.
SpectralScan->
- Is easier to use
- give you the phase and mag (summed) in one figure.
- don't need specialised transmitters.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2015-11-16 16:13 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2015-11-16 16:13 UTC (permalink / raw)
To: ath9k-devel
anything over that is cause for great concern.
Is there any other metric that you would suggest we track that would
show some issues due to wifi interference?
Is there anyway to get AR9341 datasheet?
Cheers,
Valent.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2015-10-12 17:26 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2015-10-12 17:26 UTC (permalink / raw)
To: ath9k-devel
div>Let me know if something is not clear.<br><br></div></div></blockquote>=
<div>I am interested if you reintroduce bug that Sujith already fix in comm=
it:</div><div>ath9k: Enable HW queue control only for MCC<br></div><div><br=
></div><div>While as I understand correctly this patch disable hw queues fo=
r non-mcc (also clear IEEE80211_HW_QUEUE_CONTROL) and your</div><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())</span><b=
r></div><div><span style=3D"font-size:12.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D fi->txq;</span><br style=3D"font-size:1=
2.8px"><span style=3D"font-size:12.8px">+=C2=A0 =C2=A0 =C2=A0 =C2=A0else</s=
pan><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">+=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_queue;</=
span><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
<span style=3D"font-size:12.8px">Use again hw_queue for standard non-mcc op=
eration.</span></div><div><span style=3D"font-size:12.8px"><br></span></div=
><div><span style=3D"font-size:12.8px">Please check this, I am sure while d=
id only simple check :)</span></div><div><span style=3D"font-size:12.8px"><=
br></span></div><div><span style=3D"font-size:12.8px">BR<br>Janusz</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div></div>Regards,<br></div><div class=
=3D"gmail_extra"><br clear=3D"all"><div><div><div dir=3D"ltr"><table cellsp=
acing=3D"0" cellpadding=3D"0" border=3D"0" style=3D"font-family:'Times =
New Roman'"><tbody><tr><td style=3D"width:60px;height:37px"><a href=3D"=
http://www.fon.com/" target=3D"_blank"><img src=3D"http://corp.fon.com/site=
s/default/files/filelibrary/firmafon.png" width=3D"60" height=3D"37" title=
=3D"Fon" alt=3D"Fon" border=3D"0" style=3D"border: 0px none;"></a></td></tr=
><tr><td style=3D"border-bottom-width:1px;border-bottom-style:dotted;min-wi=
dth:100px;font-family:Arial;font-size:10pt;color:rgb(51,51,51);font-weight:=
bold;padding:15px 0px 3px">Borja Salazar</td></tr><tr><td style=3D"padding:=
5px 0px 1px;font-family:Arial;font-size:7.5pt;color:rgb(102,102,102)">Firmw=
are team</td></tr><tr><td style=3D"padding:1px 0px;font-family:Arial;font-s=
ize:7.5pt;color:rgb(102,102,102)"></td></tr><tr><td style=3D"padding:1px 0p=
x;font-family:Arial;font-size:7.5pt;color:rgb(102,102,102)"></td></tr><tr><=
td style=3D"padding:1px 0px;font-family:Arial;font-size:7.5pt;color:rgb(102=
,102,102)">All information in this email is=C2=A0<a href=3D"http://corp.fon=
.com/legal/email-disclaimer" style=3D"color:rgb(102,102,102)" target=3D"_bl=
ank">confidential</a></td></tr></tbody></table></div></div></div><div><div =
class=3D"h5">
<br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 at 11:33 AM, Borja Sala=
zar <span dir=3D"ltr"><<a href=3D"mailto:borja.salazar@fon.com" target=
=3D"_blank">borja.salazar at fon.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span>When channel context is enabled, we could be<br>
stopping/awakening an incorrect queue.<br>
<br>
</span>Signed-off-by: Borja Salazar <<a href=3D"mailto:borja.salazar@fon=
.com" target=3D"_blank">borja.salazar at fon.com</a>><br>
<div><div>---<br>
=C2=A0drivers/net/wireless/ath/ath9k/xmit.c | 22 ++++++++++++----------<br>
=C2=A01 file changed, 12 insertions(+), 10 deletions(-)<br>
<br>
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/a=
th/ath9k/xmit.c<br>
index 3e3dac3..9b17a59 100644<br>
--- a/drivers/net/wireless/ath/ath9k/xmit.c<br>
+++ b/drivers/net/wireless/ath/ath9k/xmit.c<br>
@@ -147,7 +147,12 @@ static void ath_txq_skb_done(struct ath_softc *sc, str=
uct ath_txq *txq,<br>
=C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct ieee80211_tx_info *info =3D IEEE80211_SK=
B_CB(skb);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct ath_frame_info *fi =3D get_frame_info(sk=
b);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0int q =3D fi->txq;<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0int q;<br>
+<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D fi->txq;<b=
r>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_q=
ueue;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (q < 0)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;<br>
@@ -158,10 +163,7 @@ static void ath_txq_skb_done(struct ath_softc *sc, str=
uct ath_txq *txq,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txq->stopped &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 txq->pending_frames < sc-&g=
t;tx.txq_max_pending[q]) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanct=
x_enabled())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_wake_queue(sc->hw, info->hw_queue);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_wake_queue(sc->hw, q);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_wake_queu=
e(sc->hw, q);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 txq->stopped =3D=
false;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0}<br>
@@ -2299,17 +2301,17 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk=
_buff *skb,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* info are no longer valid (overwritten b=
y the ath_frame_info data.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/<br>
<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D skb_get_queue_mapping(skb);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D skb_get_queue=
_mapping(skb);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q =3D info->hw_q=
ueue;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ath_txq_lock(sc, txq);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txq =3D=3D sc->tx.txq_map[q]) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fi->txq =3D q;<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (++txq->pendi=
ng_frames > sc->tx.txq_max_pending[q] &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !txq-=
>stopped) {<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0if (ath9k_is_chanctx_enabled())<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_stop_queue(sc->hw, info-=
>hw_queue);<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0else<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ieee80211_stop_queue(sc->hw, q);<b=
r>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0ieee80211_stop_queue(sc->hw, q);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 txq->stopped =3D true;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
--<br>
2.3.6<br>
<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>
--001a11444ce011feae05246a36f0--
^ permalink raw reply related [flat|nested] 96+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
apply patches to the ath.git tree as before and handle the patches from
there.
For ath9k and wil6210 the change is that I will be commiting the patches
instead of John and I will apply them to my wireless-drivers trees:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/
For ath10k and ath6kl related work I will continue to use my QCA email
address but for wireless-drivers maintainer duties I will use CAF
address.
Please let me know if there any questions. Me and John try to make this
transition as smooth as possible.
Kalle
"John W. Linville" <linville@tuxdriver.com> writes:
> Greetings,
>
> Almost 9 years ago, Jeff Garzik wrote a message on LKML detailing
> the sad state of wireless LANs in the Linux world. The point of his
> message was "So... there it is. We suck. There's hope. No Luke
> Skywalker in sight.":
>
> https://lkml.org/lkml/2006/1/5/671
>
> Shortly thereafter, I became the maintainer for wireless LANs in the
> Linux kernel:
>
> https://lkml.org/lkml/2006/1/18/377
>
> Since then, we have had a number of wireless summit meetings all around
> the world. Items were discussed, patches were merged, and friendships
> were made. Over time, we garnered support from a large range of
> wireless networking vendors. Eventually even other technologies
> were sending their patches through my trees, and I was consistently
> ranked amongst the top 10 "gate keepers" for getting changes into the
> Linux kernel. In fact, a couple of years ago I even gave a talk on
> how Linux wireless got better. It has been quite a ride!
>
> https://events.linuxfoundation.org/images/stories/pdf/lfcs2012_linville.pdf
>
> Nevertheless, I think it is time for some changes. I have been
> the wireless maintainer for a long time, and I personally would
> like to develop in a different direction. Plus, I think that Linux
> will benefit from having some fresh blood involved in more of the
> maintenance duties. I will be stepping aside to let that happen.
>
> The mac80211, bluetooth, and nfc trees have fed through me for some
> time. I am now asking these trees to send pull request directly to
> David Miller. Since these trees are managed through git, my hope is
> that they will not place any significant burden on Dave.
>
> As for the wireless driver patches, I have asked Kalle Valo
> to handle patch review and merge duties for everything under the
> drivers/net/wireless directory. This will now include not only the ath
> patches he already manages, but other drivers that don't have trees
> such as mwifiex, rt2x00, rtlwifi, and others. For consistency, the
> iwlwifi tree will also be merged through Kalle's new tree. I expect
> that Kalle will announce any relevant details in a follow-up message.
>
> The wireless-testing tree is a resource that some people value.
> I will continue to provide a wireless-testing tree. Now that tree
> will feed from the various wireless trees managed by others, probably
> with some sort of regularly scheduled pulls. Details are still to be
> determined, but the tree will still exist and will be substantially
> similar to how it has been so far.
>
> I also receive notices of new bug reports for wireless LANs on
> bugzilla.kernel.org. For now I will continue to triage those reports,
> so don't ignore me!! :-)
>
> Some may ask what I will do now -- I wish I had a specific answer.
> Immediate plans are to enjoy the coming holidays and my traditional
> year-end time away from work. After that...well, I'm sure I will
> find something to do. If you have any suggestions for good uses of
> my talents, feel free to contact me -- I'm not hard to find!
>
> In closing, I hope everyone will support Kalle and the other wireless
> maintainers at least as much as you have supported me for the past
> several years. These are good, hard working folks. You are in
> good hands!
>
> Regards,
>
> John
>
> P.S. Bonus points for anyone that finds a way for me to become a
> professional retro-computing hobbyist... :-)
--
Kalle Valo
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
phyXtpt to blink like what it does.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Hong<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature">Met vriendelijk groeten,<br>Melroy van den Berg</div>
</div>
--001a113801d2d4fad5050c853d75--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
It doesn't appear to be present in the kernel and I don't think
ath3k would be loaded.
I have a patch to add this ID to ath3k, can you apply it in
backports-20141221 and check ?
http://msujith.org/dir/patches/wl/Jan-14-2015/0013-ath3k-Add-new-AR3012-device.patch
Inside backports:
patch -p1 < 0013-ath3k-Add-new-AR3012-device.patch
And then, do a "make menuconfig" to select ath9k/ath3k
and install.
Sujith
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
I think WOW-enabled cards require hardware changes from the
base reference design (in your case WB222/AR9462), to receive
power when suspended.
Sujith
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2014-09-13 19:40 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2014-09-13 19:40 UTC (permalink / raw)
To: ath9k-devel
but how does the device decide to wake up? Is it based on local TSF and
beacon interval being programmed in somewhere? Or do you give it an arbitrary
TSF wake-up time somehow as in the previous devices? I noticed that in ath9k
the various generic timer aliases (e.g. TIM_TIMER) aren't even supported in
ar9003_mac.c.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
selection is just a few days away) -- but June would be better anyway.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
generated acks.
Enabling hw acks results in duplicate, identical acks being sent by the
access point on successful frame receipt.
The difference is just in timings: while hw acks is usually received in
less then 10 or 20 microseconds from a successful frame receipt, sw
generated acks arrive in 2-300 microseconds.
We suppose the problem is in Clear Channel Assessment: the hardware waits
the right (CSMA compliant) time to send the frame while we would like it to
send the ack frame ASAP (i.e. wait SIFS instead of AIFS).
Tried a few flags with no success (tested with or without such flags and no
apparent change happened).
Flags are:
AR_DIAG_FORCE_RX_CLEAR
AR_DIAG_FORCE_CH_IDLE_HIGH
AR_DIAG_IGNORE_VIRT_CS
AR_D_GBL_IFS_MISC_IGNORE_BACKOFF
Possible "next steps":
- choose the correct hw queue (now using queue skb->queue_mapping=3 and
skb->priority=7)
- find out the correct register values for disabling the virtual and
physical carrier sense (AR_DIAG_SW) for ath9k.
- find out if such values are "honored" in our card or if should be better
to simply change the atheros chipset family or card manufacturer
- disabling back-off setting the cwmin and cwmax to zero on the choosen
queue And also setting AIFS=1 (or zero?)
- disabling any debug code possibly inserted during coding phase (according
to
http://adrianchadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html
)
Any suggestion?
Is anyone interested in collaborating in softMAC development? Right now we
are thinking about standard ack mechanism (i.e. a/g) but it could be
extended to blockAck (802.11e or "n" versions of a/g)?
Any feedback welcome...
Thnkz in advance!!!
Alex
--047d7b15ad979ce54c04edbbc6dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everybody!<br>I's my first time writing to the l=
ist, while I'm following it with interest for some time.<br><br>We'=
re developing some MAC functions in software for testing purposes.<br><br>
The most challenging part seems to be generating Acks in software.<br><br>T=
hree main tasks:<br>1. Disabling Link Layer Acks in hardware<br>2. Generati=
ng Acks as "low" as possible in driver stack<br>3. sending such a=
cks as quickly as possible<br>
<br>Now, task 1 and 2 are done in ath9k: task 1 setting the appropriate fla=
g in the register and task 2 coding link layer ack generation in ath9k_rx t=
asklet.<br><br>We have a problem in task 3.<br>It seems that the ack frame =
is sent like regular frames, respecting CCA, while we would need the ack fr=
ames to be sent immediately, as soon as they've been put in the tx queu=
e.<br>
<br>Test environment<br>Access Point <br>Hardware: Alix 2d2 board, Compex W=
LM200NX MiniPCI network adapter (should be Chipset AR9220 according to vend=
or datasheet - kernel Dmesg says "ieee80211 phy0: Atheros AR9280 Rev:2=
mem=3D0xd0ca0000, irq=3D9") <br>
Software: OpenWRT REVISION r37112<br><br>Client<br>any WiFi compliant clien=
t such as smartphones and laptop<br><br>Sniffer<br>wireshark on a laptop wi=
th a mon interface<br><br><br>Results<br>From a sniffer perspective you can=
not distinguish between hw and sw generated acks.<br>
Enabling hw acks results in duplicate, identical acks being sent by the acc=
ess point on successful frame receipt.<br>The difference is just in timings=
: while hw acks is usually received in less then 10 or 20 microseconds from=
a successful frame receipt, sw generated acks arrive in 2-300 microseconds=
.<br>
<br>We suppose the problem is in Clear Channel Assessment: the hardware wai=
ts the right (CSMA compliant) time to send the frame while we would like it=
to send the ack frame ASAP (i.e. wait SIFS instead of AIFS).<br><br>Tried =
a few flags with no success (tested with or without such flags and no appar=
ent change happened).<br>
Flags are:<br><br>AR_DIAG_FORCE_RX_CLEAR<br>AR_DIAG_FORCE_CH_IDLE_HIGH<br>A=
R_DIAG_IGNORE_VIRT_CS<br>AR_D_GBL_IFS_MISC_IGNORE_BACKOFF<br><br><br>Possib=
le "next steps":<br><br>- choose the correct hw queue =A0(now usi=
ng queue skb->queue_mapping=3D3 and skb->priority=3D7)<br>
- find out the correct register values for disabling the virtual and physic=
al carrier sense (AR_DIAG_SW) for ath9k.<br>- find out if such values are &=
quot;honored" in our card or if should be better to simply change the =
atheros chipset family or card manufacturer<br>
- disabling back-off setting the cwmin and cwmax to zero on the choosen que=
ue And also setting AIFS=3D1 (or zero?)<br>- disabling any debug code possi=
bly inserted during coding phase (according to <a href=3D"http://adrianchad=
d.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html">http://adrian=
chadd.blogspot.it/2012/11/be-careful-of-adding-debugging-as.html</a>)<br>
<br><br>Any suggestion?<br>Is anyone interested in collaborating in softMAC=
development? Right now we are thinking about standard ack mechanism (i.e. =
a/g) but it could be extended to blockAck (802.11e or "n" version=
s of a/g)?<div>
<br></div><div><br>Any feedback welcome...<br>Thnkz in advance!!!</div><div=
><br></div><div>Alex</div><div><br></div><div><br></div></div>
--047d7b15ad979ce54c04edbbc6dc--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-09-15 9:49 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-09-15 9:49 UTC (permalink / raw)
To: ath9k-devel
timestamp.
The question is, how accurated this timestamp is? The precision is in
nanoseconds, but what accuracy i can expect?
My main need is the implement a good precision TDOA algorithm.
I don't know jack about driver development, but is something that interests
me. If the accuracy is low, can i improve it in driver or firmware?
If its possible, i can even trade reception packet speed for a better
accuracy in timestamp.
The other question is, what is the difference between the ath9k_htc and
carl9170 drivers? Both support the AR9287 (from the debian wiki).
Thanks for all
Links:
Wireshark community:
http://ask.wireshark.org/questions/28683/recommended-wireless-adapter-usb-with-linux-wireshark-that-reports-mactime-in-radiotap-header
Debian Wiki ath9k_htc: https://wiki.debian.org/ath9k_htc
Debian Wiki carl9170: https://wiki.debian.org/carl9170
--001a11335f40ad0de604f2af55f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>I have one question about hardware =
timestamp in Atheros chipsets.</div><div>From a post in Wireshark community=
, the chipset AR9287 can do hardware timestamp.</div><div><br></div><div>Th=
e question is, how accurated this timestamp is? The precision is in nanosec=
onds, but what accuracy i can expect?</div>
<div><br></div><div>My main need is the implement a good precision TDOA alg=
orithm.=A0</div><div><br></div><div>I don't know jack about driver deve=
lopment, but is something that=A0interests me. If the accuracy is low, can =
i improve it in driver or firmware?=A0</div>
<div>If its possible, i can even trade reception packet speed for a better =
accuracy in timestamp.</div><div><br></div><div>The other question is, what=
is the difference between the ath9k_htc and carl9170 drivers? Both support=
the AR9287 (from the debian wiki).</div>
<div><br></div><div>Thanks for all</div><div><br></div><div>Links:</div><di=
v><br></div><div>Wireshark community: <a href=3D"http://ask.wireshark.org/q=
uestions/28683/recommended-wireless-adapter-usb-with-linux-wireshark-that-r=
eports-mactime-in-radiotap-header">http://ask.wireshark.org/questions/28683=
/recommended-wireless-adapter-usb-with-linux-wireshark-that-reports-mactime=
-in-radiotap-header</a></div>
<div><br></div><div>Debian Wiki ath9k_htc:=A0<a href=3D"https://wiki.debian=
.org/ath9k_htc">https://wiki.debian.org/ath9k_htc</a></div><div><br></div><=
div>Debian Wiki carl9170:=A0<a href=3D"https://wiki.debian.org/carl9170">ht=
tps://wiki.debian.org/carl9170</a></div>
</div>
--001a11335f40ad0de604f2af55f8--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
monitor mode (non promiscuous) are corrupted. They
have the QoS Control stripped, with LLC header
finding itself in the QoS Control. Wireshark shows
such packets as A-MSDU corrupted frames. I tried
restoring the QoS Control but it didn't fix that.
I think we'll need to make a copy of skb, work on
that copy and keep the original skbuff pointer as
a "cookie" to use with mac80211 functions
(tx_status, free_txskb). I'm hoping this won't
degrade tx performance (well, we already do a
memmove()).
Yuck. Any comments?
Michal Kazior (2):
ath10k: make more space in ath10k_skb_cb
ath10k: copy skb during tx
drivers/net/wireless/ath/ath10k/core.h | 32 ++++++++++++++++++++------------
drivers/net/wireless/ath/ath10k/mac.c | 21 +++++++++++++++++++--
drivers/net/wireless/ath/ath10k/txrx.c | 8 +++++---
3 files changed, 44 insertions(+), 17 deletions(-)
--
1.7.9.5
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
priority feature. For me most important is to support the real monitor
mode (iw wlan0 set type monitor), anything else is just nice to have.
I haven't even looked at your patches, but I'm worried that if a very
low priority feature jeopardizes normal functionality. What if we just
don't support the monitor mode while associated feature? Can we do that?
Disclaimer: I haven't looked at your patches
--
Kalle Valo
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
Bartosz
On 9 May 2013 12:33, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
> > Kalle, could you please submit/review these?
>
> I will not commit any patches which have either RFC or RFT tag. And I
> also review them in lower priority.
>
> So if you want me to commit something I recommend to use only PATCH.
>
> --
> Kalle Valo
>
--f46d04388e55778a4404dc43abee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Michal, could you please address Kalle's comments.</div>
<div>=A0</div>
<div>From me ACK for the series (tested OK)</div>
<div>=A0</div>
<div>Bartosz<br><br></div>
<div class=3D"gmail_quote">On 9 May 2013 12:33, Kalle Valo <span dir=3D"ltr=
"><<a href=3D"mailto:kvalo@qca.qualcomm.com" target=3D"_blank">kvalo at qca=
.qualcomm.com</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div class=3D"im">Bartosz Markowski <<a href=3D"mailto:bartosz.markowski=
@tieto.com">bartosz.markowski at tieto.com</a>> writes:<br><br>> Kalle, =
could you please submit/review these?<br><br></div>I will not commit any pa=
tches which have either RFC or RFT tag. And I<br>
also review them in lower priority.<br><br>So if you want me to commit some=
thing I recommend to use only PATCH.<br><span class=3D"HOEnZb"><font color=
=3D"#888888"><br>--<br>Kalle Valo<br></font></span></blockquote></div><br>
--f46d04388e55778a4404dc43abee--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-04-03 10:31 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-04-03 10:31 UTC (permalink / raw)
To: ath9k-devel
supposed to be prepared for reception of the firmware code from the driver.
This normally happens when the device boots up and passes the first stage of
the bootloader. I suppose (I'm really totally guessing) that the driver
somehow doesn't do something to prepare the device for firmware upload if the
device is already past stage 2.
I would love to have the UART pins connected to some terminal, but I don't
have the soldering tools for such small-scale work...
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-01-16 21:46 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-01-16 21:46 UTC (permalink / raw)
To: ath9k-devel
driver isn't doing something stupid like running multiple copies of
the reset / setup path on different CPUs/threads, it should be
reliable.
HTH,
Adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2013-01-16 21:46 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2013-01-16 21:46 UTC (permalink / raw)
To: ath9k-devel
limitation in that it must not be reset more than once. That seems
like not so reliable PCIe IP, as long as the issue really is well
understood, but I'm not sure?
I would really like to hear the exact details about what the hardware
requires.
//Peter
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-11-08 9:33 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-11-08 9:33 UTC (permalink / raw)
To: ath9k-devel
timestamp (first frame?).
Thomas
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-05-25 15:26 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-05-25 15:26 UTC (permalink / raw)
To: ath9k-devel
"enabled" in the device driver. I will scour the ath9k source code for
this config.
=20
Thank you for your input.
=20
Hasan R.
=20
=20
From: adrian.chadd@gmail.com [mailto:adrian.chadd at gmail.com] On Behalf
Of Adrian Chadd
Sent: Sunday, May 27, 2012 7:18 PM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Atheros AR9382 W_DISABLE_L PIN 20 Mini-PCIe
=20
Hi,
=20
So the 30 second version of rfkill is this:
=20
* it can be software driven (ie, the driver implements rfkill by
stopping TX/RX and baseband activity, possibly shutting down the NIC)
* it can be hardware driven (ie, there's an RFKill line to the NIC via=
a
GPIO pin)
=20
The pin itself can be controlled by:
=20
* hardware - ie, a physical switch to the rfkill pin;
* software - ie, some ACPI controlled function maps to the rfkill pin.
=20
What you have above seems to be (2) and (1) respectively - ie, that pin
is mapped to GPIO7 on the NIC, and now you need to program GPIO7 to be
an RFkill pin. There's code in ath9k somewhere to configure the GPIO pin
correctly to implement hardware rfkill.
=20
Good luck!
=20
=20
Adrian
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in
error, please immediately notify the sender by telephone or by electroni=
c mail.
------_=_NextPart_001_01CD3DB5.D3C19EF1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-m=
icrosoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:=
word" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=
=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Ty=
pe content=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator cont=
ent=3D"Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue=
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
From your email I gather I have a RFKILL switch but it needs to be R=
20;enabled” in the device driver. I will scour the ath9k sou=
rce code for this config.<o:p></o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank=
you for your input.<o:p></o:p></span></p><p class=3DMsoNormal><span sty=
le=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><=
o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size=
:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Hasan R.<o:p></o=
:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-=
family:"Arial","sans-serif";color:#1F497D'> <o:p></o:p></span></p><=
p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial",=
"sans-serif";color:#1F497D'> </span><span style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p=
><p class=3DMsoNormal style=3D'margin-left:.5in'><b><span style=3D'font-=
size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span sty=
le=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> adrian.chadd@=
gmail.com [mailto:adrian.chadd at gmail.com] <b>On Behalf Of </b>Adrian Cha=
dd<br><b>Sent:</b> Sunday, May 27, 2012 7:18 PM<br><b>To:</b> Hasan Rash=
id<br><b>Cc:</b> ath9k-devel at lists.ath9k.org<br><b>Subject:</b> Re: [ath=
9k-devel] Atheros AR9382 W_DISABLE_L PIN 20 Mini-PCIe<o:p></o:p></span><=
/p><p class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p>=
<p class=3DMsoNormal style=3D'margin-left:.5in'>Hi,<o:p></o:p></p><div><=
p class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p></di=
v><div><p class=3DMsoNormal style=3D'margin-left:.5in'>So the 30 second=
version of rfkill is this:<o:p></o:p></p></div><div><p class=3DMsoNorma=
l style=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3D=
MsoNormal style=3D'margin-left:.5in'>* it can be software driven (ie,=
the driver implements rfkill by stopping TX/RX and baseband activity,=
possibly shutting down the NIC)<o:p></o:p></p></div><div><p class=3DMso=
Normal style=3D'margin-left:.5in'>* it can be hardware driven (ie, there=
's an RFKill line to the NIC via a GPIO pin)<o:p></o:p></p></div><div><p=
class=3DMsoNormal style=3D'margin-left:.5in'><o:p> </o:p></p></div=
><div><p class=3DMsoNormal style=3D'margin-left:.5in'>The pin itself can=
be controlled by:<o:p></o:p></p></div><div><p class=3DMsoNormal style=
=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNorm=
al style=3D'margin-left:.5in'>* hardware - ie, a physical switch to the=
rfkill pin;<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'marg=
in-left:.5in'>* software - ie, some ACPI controlled function maps to the=
rfkill pin.<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'marg=
in-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNormal style=
=3D'margin-left:.5in'>What you have above seems to be (2) and (1) respec=
tively - ie, that pin is mapped to GPIO7 on the NIC, and now you need=
to program GPIO7 to be an RFkill pin. There's code in ath9k somewhere=
to configure the GPIO pin correctly to implement hardware rfkill.<o:p><=
/o:p></p></div><div><p class=3DMsoNormal style=3D'margin-left:.5in'><o:p=
> </o:p></p></div><div><p class=3DMsoNormal style=3D'margin-left:.5=
in'>Good luck!<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'ma=
rgin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNormal sty=
le=3D'margin-left:.5in'><o:p> </o:p></p></div><div><p class=3DMsoNo=
rmal style=3D'margin-left:.5in'>Adrian<o:p></o:p></p></div></div>
<!-- Begin Ninja Disclaimer ID 06d1f63c-a7f2-4bdd-9832-359e6e93159e -->
<P>This communication contains information that may be confidential or=
privileged. The information is solely intended for the use of the addre=
ssee. If you are not the intended recipient, be advised that any disclos=
ure, copy, distribution, or use of the contents of this communication=
is prohibited. If you have received this communication in<BR>error, ple=
ase immediately notify the sender by telephone or by electronic mail.</P>
<P>Export Notice: This email may contain technical data controlled under=
the International Traffic in Arms Regulations (ITAR) by the U.S.=
Department of State (22 CFR 120-130) or under the U.S Export Administra=
tion Regulations (EAR) by the Department of Commerce (15 CFR 730-744).&n=
bsp; Violations of these export laws are subject to severe criminal pena=
lties. <BR></P>
</body></html>
------_=_NextPart_001_01CD3DB5.D3C19EF1--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-05-25 15:26 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-05-25 15:26 UTC (permalink / raw)
To: ath9k-devel
it being NULL along the way"
I guess you refer to the comment in mac80211.h, struct tx_info that I
removed:
- * The TX control's sta pointer is only valid during the ->tx call,
- * it may be NULL.
I am not sure what you want me to keep here as comment. As the sta
pointer is moved into the new struct tx_control and the remaining
pointers in the tx_info->control structure (vif, hw_key) are ALL only
valid during the ->tx call and may be NULL. So I could think of adding a
comment to tx_control about the sta been NULL, but anything more ?
>> The tx-path of all affected drivers is restructured to respect the
chaneged
>> layout of struct ieee80211_tx_info. List of modified drivers:
>> ath9k
>
> Please also remove the driver list. git can tell you the modified files
> very easily.
Will do so in v2.
Greetings Thomas
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-04-05 7:54 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-04-05 7:54 UTC (permalink / raw)
To: ath9k-devel
relative to noise floor in dB."
Adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-04-05 7:54 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-04-05 7:54 UTC (permalink / raw)
To: ath9k-devel
relative to noise floor in dB."<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Adrian<br>
</font></span></blockquote></div><br></div>
--bcaec52be6d10f215404c0d1b26d--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
actually useful for narrowing down the source of this issue...
- Felix
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
The lower you go on the level of abstraction, the more data any kind of
debugging approach generates, meaning way more effort to analyze the
data and make sense of it.
I don't typically start with the part that's hardest to analyze. High
level states are easier to look into and make sense of, so they're also
easier to rule out.
Code review is also a very good starting point. I actually found and
fixed more user visible bugs through code review than any other
debugging method.
>> > but hardware development information in the community is not
>> > really available.
>>
>> I found that people that have shown enough interest in improving ath9k
>> and have proven to be experienced in working on such drivers tend to get
>> access to documentation.
>
> Well, let's say that in my experience the threshold for "approval"
> was set too high. As I said, and as you may remember, I was
> repeatedly shot down or ignored, offering to try to get to the bottom
> of the issues. I understand now that it may not really be legally
> possible for Atheros to provide the information that is actually
> required to get to the bottom of the issues, but that makes working
> on the driver too inefficient.
Most issues can be fixed with a good understanding of the code alone,
detailed hardware knowledge is often not as important.
This isn't unique to ath9k. I've fixed bugs in other drivers as well
without having any form of hardware documentation, because I'm able to
read and understand code and my brain can handle a bit of complexity.
>> > Being told to try to reverse engineer the hardware using the
>> > driver source code or any other source code does not qualify.
>>
>> Your definition of 'reverse engineering' is quite funny.
>
> There's not just one type of reverse engineering.
>
> Suggesting hardware reverse engineering in an open source driver
> development effort is, well, not what I expect.
>
>
>> To me it looks somewhat ridiculous that you claim to know better what's
>> required to debug this issue than people working with the hardware on a
>> daily basis (Adrian, Mohammed, me).
>
> I've developed both hardware and software for more than 20 years, and
> neither problems nor solutions have changed much, so I think I still
> have a clue.
OK, so let me get this straight: You can't imagine how the test result
from disabling PS could be useful for tracking down the problem, so you
automatically assume that it *must* be a lame workaround suggestion?
That seems rather narrow-minded of you.
Of course I can see multiple ways in which this information would be
useful, but I guess that may not matter to you.
- Felix
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-02-27 5:00 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-02-27 5:00 UTC (permalink / raw)
To: ath9k-devel
;f=3Dhostapd/hostapd.conf), I
cannot find what wme_enabled is.
=20
- What does wme_enabled do ? Is it needed in conjunction with =
ht_capab ?
Another question, I live in CH, a reboot shows=20
[ 9.201363] ath: Country alpha2 being used: AU
And changed it to CH.=20
=20
- Which limitation can I expect, for not being a European Card, =
as it propagates AU ?
=20
Below I added lspci, iw list, hostapd.conf, dmesg output.
http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#spec
=20
Thanks for your help
Angela
=20
# lspci -vvd 168c:
02:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless =
LAN adaptor (rev 01)
Subsystem: Atheros Communications Inc. Device 3112
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- =
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- =
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fbe00000 (64-bit, non-prefetchable) =
[size=3D128K]
Expansion ROM at fbe20000 [disabled] [size=3D64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA =
PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 =
PME-
Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s =
<1us, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- =
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- =
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, =
Latency L0 <2us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- =
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ =
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- =
SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, =
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- =
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- =
ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=3DFixed
Status: InProgress-
VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 =
RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- =
WRR256-
Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed =
TC/VC=3D01
Status: NegoPending- InProgress-
Capabilities: [300 v1] Device Serial Number =
00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
=20
=20
# iw list
Wiphy phy0
Band 1:
Capabilities: 0x11ef
RX LDCP
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Capabilities: 0x11ef
RX LDCP
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no =
IBSS, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* mesh point
* Unknown mode (8)
* Unknown mode (9)
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* Unknown command (68)
* Unknown command (55)
* Unknown command (57)
* Unknown command (59)
* Unknown command (67)
* set_wiphy_netns
* Unknown command (65)
* Unknown command (66)
* Unknown command (82)
* Unknown command (81)
* Unknown command (84)
* Unknown command (87)
* Unknown command (85)
* testmode
* connect
* disconnect
=20
=20
# cat /etc/hostapd.conf
# Schnittstelle und Treiber
interface=3Dwlan0
driver=3Dnl80211
=20
# WLAN-Konfiguration
ssid=3Dxxxx
channel=3D6
=20
# ESSID sichtbar
ignore_broadcast_ssid=3D0
=20
# L=E4ndereinstellungen
country_code=3DCH
ieee80211d=3D1
=20
# =DCbertragungsmodus
hw_mode=3Dg
# Optionale Einstellungen
# supported_rates=3D10 20 55 110 60 90 120 180 240 360 480 540
=20
# Draft-N Modus aktivieren / optional nur f=FCr entsprechende Karten
# ieee80211n=3D1
ieee80211n=3D1
=20
# Beacons
beacon_int=3D100
dtim_period=3D2
=20
# MAC-Authentifizierung
macaddr_acl=3D0
=20
# max. Anzahl der Clients
max_num_sta=3D255
=20
# Gr=F6=DFe der Datenpakete/Begrenzung
rts_threshold=3D2347
fragm_threshold=3D2346
=20
# hostapd Log Einstellungen
logger_syslog=3D-1
logger_syslog_level=3D2
logger_stdout=3D-1
logger_stdout_level=3D2
=20
# tempor=E4re Konfigurationsdateien
dump_file=3D/tmp/hostapd.dump
ctrl_interface=3D/var/run/hostapd
ctrl_interface_group=3D0
=20
# Authentifizierungsoptionen
auth_algs=3D1
=20
# wmm-Funktionalit=E4t
wmm_enabled=3D0
=20
# Verschl=FCsselung / hier rein WPA2
macaddr_acl=3D0
wpa=3D2
rsn_preauth=3D1
rsn_preauth_interfaces=3Dwlan0
wpa_key_mgmt=3DWPA-PSK
wpa_pairwise=3DTKIP
rsn_pairwise=3DCCMP
=20
# Schl=FCsselintervalle / Standardkonfiguration
wpa_group_rekey=3D600
wpa_ptk_rekey=3D600
wpa_gmk_rekey=3D86400
=20
# Zugangsschl=FCssel (PSK) / hier in Klartext (ASCII)
wpa_passphrase=3Dxxxx
=20
=20
[ 0.000000] Linux version 3.3.0-rc2-1+ (root@linux) (gcc version =
4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #1 SMP Tue Feb 14
13:17:34 CET 2012
[ 0.000000] Command line: BOOT_IMAGE=3D/vmlinuz-3.3.0-rc2-1+ =
root=3DUUID=3Dcfc15d9c-2cd1-4bad-9e9d-f2fa1ded76e2 ro
[ 9.201360] ath: EEPROM regdomain: 0x21
[ 9.201362] ath: EEPROM indicates we should expect a direct regpair =
map
[ 9.201363] ath: Country alpha2 being used: AU
[ 9.201364] ath: Regpair used: 0x21
[ 9.531824] ieee80211 phy0: Selected rate control algorithm =
'ath9k_rate_control'
[ 9.532132] Registered led device: ath9k-phy0
[ 7.594696] cfg80211: Calling CRDA to update world regulatory domain
[ 8.966680] cfg80211: World regulatory domain updated:
[ 8.966682] cfg80211: (start_freq - end_freq @ bandwidth), =
(max_antenna_gain, max_eirp)
[ 8.966684] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966686] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966687] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966688] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 8.966689] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.201366] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201368] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201369] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201370] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201371] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201373] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201374] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201375] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201376] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201378] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201379] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201380] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201381] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201383] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201384] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201385] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201386] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201388] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201389] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201390] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201391] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201393] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.201394] cfg80211: Disabling freq 2467 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201395] cfg80211: Disabling freq 2472 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201396] cfg80211: Disabling freq 2484 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201398] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201399] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201400] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201402] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201403] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201404] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201405] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201407] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201408] cfg80211: Updating information on frequency 5260 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201409] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201410] cfg80211: Updating information on frequency 5280 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201412] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201413] cfg80211: Updating information on frequency 5300 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201414] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201415] cfg80211: Updating information on frequency 5320 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201417] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201418] cfg80211: Disabling freq 5500 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201419] cfg80211: Disabling freq 5520 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201420] cfg80211: Disabling freq 5540 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201422] cfg80211: Disabling freq 5560 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201423] cfg80211: Disabling freq 5580 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201424] cfg80211: Disabling freq 5600 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201425] cfg80211: Disabling freq 5620 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201426] cfg80211: Disabling freq 5640 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201428] cfg80211: Disabling freq 5660 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201429] cfg80211: Disabling freq 5680 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201430] cfg80211: Disabling freq 5700 MHz as custom regd has no =
rule that fits a 20 MHz wide channel
[ 9.201431] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201433] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201434] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201435] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201436] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201438] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201439] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201440] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.201441] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.201443] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A =
mBi, 3000 mBm)
[ 9.202827] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202829] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202830] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202831] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202833] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202834] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202845] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202847] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202848] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202849] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202851] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202852] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202853] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202855] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202856] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202857] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202859] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202860] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202861] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202863] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202864] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202865] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202867] cfg80211: Updating information on frequency 2467 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202868] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202869] cfg80211: Updating information on frequency 2472 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202871] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202872] cfg80211: Updating information on frequency 2484 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202874] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202875] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202877] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202878] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202879] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202881] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202882] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202884] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202885] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202887] cfg80211: Disabling freq 5260 MHz
[ 9.202897] cfg80211: Disabling freq 5280 MHz
[ 9.202898] cfg80211: Disabling freq 5300 MHz
[ 9.202899] cfg80211: Disabling freq 5320 MHz
[ 9.202900] cfg80211: Disabling freq 5500 MHz
[ 9.202901] cfg80211: Disabling freq 5520 MHz
[ 9.202901] cfg80211: Disabling freq 5540 MHz
[ 9.202902] cfg80211: Disabling freq 5560 MHz
[ 9.202903] cfg80211: Disabling freq 5580 MHz
[ 9.202904] cfg80211: Disabling freq 5600 MHz
[ 9.202905] cfg80211: Disabling freq 5620 MHz
[ 9.202905] cfg80211: Disabling freq 5640 MHz
[ 9.202916] cfg80211: Disabling freq 5660 MHz
[ 9.202917] cfg80211: Disabling freq 5680 MHz
[ 9.202918] cfg80211: Disabling freq 5700 MHz
[ 9.202919] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202920] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202921] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202923] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202924] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202925] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202926] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202928] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.202929] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.202930] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 2000 mBm)
[ 9.532113] cfg80211: Calling CRDA for country: AU
[ 9.533522] cfg80211: Updating information on frequency 2412 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533524] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533525] cfg80211: Updating information on frequency 2417 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533527] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533528] cfg80211: Updating information on frequency 2422 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533530] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533531] cfg80211: Updating information on frequency 2427 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533533] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533534] cfg80211: Updating information on frequency 2432 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533535] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533537] cfg80211: Updating information on frequency 2437 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533538] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533539] cfg80211: Updating information on frequency 2442 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533541] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533542] cfg80211: Updating information on frequency 2447 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533544] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533545] cfg80211: Updating information on frequency 2452 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533546] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533547] cfg80211: Updating information on frequency 2457 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533549] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533550] cfg80211: Updating information on frequency 2462 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533552] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533553] cfg80211: Updating information on frequency 2467 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533554] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533556] cfg80211: Updating information on frequency 2472 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533557] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)
[ 9.533558] cfg80211: Disabling freq 2484 MHz
[ 9.533559] cfg80211: Updating information on frequency 5180 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533561] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533562] cfg80211: Updating information on frequency 5200 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533564] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533565] cfg80211: Updating information on frequency 5220 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533566] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533568] cfg80211: Updating information on frequency 5240 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533569] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533570] cfg80211: Updating information on frequency 5260 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533572] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533573] cfg80211: Updating information on frequency 5280 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533575] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533576] cfg80211: Updating information on frequency 5300 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533577] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533579] cfg80211: Updating information on frequency 5320 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533580] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533581] cfg80211: Disabling freq 5500 MHz
[ 9.533582] cfg80211: Disabling freq 5520 MHz
[ 9.533583] cfg80211: Disabling freq 5540 MHz
[ 9.533584] cfg80211: Disabling freq 5560 MHz
[ 9.533585] cfg80211: Disabling freq 5580 MHz
[ 9.533585] cfg80211: Disabling freq 5600 MHz
[ 9.533586] cfg80211: Disabling freq 5620 MHz
[ 9.533587] cfg80211: Disabling freq 5640 MHz
[ 9.533588] cfg80211: Disabling freq 5660 MHz
[ 9.533589] cfg80211: Disabling freq 5680 MHz
[ 9.533590] cfg80211: Disabling freq 5700 MHz
[ 9.533591] cfg80211: Updating information on frequency 5745 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533592] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533593] cfg80211: Updating information on frequency 5765 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533595] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533596] cfg80211: Updating information on frequency 5785 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533597] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533599] cfg80211: Updating information on frequency 5805 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533600] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533601] cfg80211: Updating information on frequency 5825 MHz for =
a 20 MHz width channel with regulatory rule:
[ 9.533603] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
[ 9.533606] cfg80211: Regulatory domain changed to country: AU
[ 9.533607] cfg80211: (start_freq - end_freq @ bandwidth), =
(max_antenna_gain, max_eirp)
[ 9.533608] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), =
(N/A, 2000 mBm)
[ 9.533609] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533611] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 =
mBi, 2300 mBm)
[ 9.533612] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 =
mBi, 3000 mBm)
------=_NextPart_000_0CFF_01CD01BB.A7359070
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Microsoft Word =
12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1667975767;
mso-list-type:hybrid;
mso-list-template-ids:1557444888 -1730749342 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:2012;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoNormal>Hello<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I have a TP =
Link WDN4800 (ar9380). A Windows 802.11n client showed 72Mb connection, =
150Mb should be possible. inSSIDer showed 195Mb. I want to have it =
optimized for 2.4Ghz. <o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>iw =
list:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT20 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT40 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I =
haven’t found a complete guide (<a =
href=3D"http://linuxwireless.org/en/users/Documentation/hostapd">http://l=
inuxwireless.org/en/users/Documentation/hostapd</a>) for the ht_capab =
settings or some guidance to map them from iw list. Iw list shows HT20, =
what should/can be used, HT20, or HT20- or HT20+, with or without HT40*. =
Mapping to much seems also not to good.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>What are the most optimized settings for =
ht_capab ?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>From the guide and hostapd.conf (<a =
href=3D"http://hostap.epitest.fi/gitweb/gitweb.cgi?p=3Dhostap.git;a=3Dblo=
b_plain;f=3Dhostapd/hostapd.conf">http://hostap.epitest.fi/gitweb/gitweb.=
cgi?p=3Dhostap.git;a=3Dblob_plain;f=3Dhostapd/hostapd.conf</a>), =A0I =
cannot find what wme_enabled is.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>What does wme_enabled do ? Is it needed in =
conjunction with ht_capab ?<o:p></o:p></p><p class=3DMsoNormal> =
<o:p></o:p></p><p class=3DMsoNormal>Another question, I live in CH, a =
reboot shows <o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201363] =
ath: Country alpha2 being used: AU<o:p></o:p></p><p =
class=3DMsoNormal>And changed it to CH. <o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>-<span =
style=3D'font:7.0pt "Times New =
Roman"'> =
</span></span><![endif]>Which limitation can I expect, for not being a =
European Card, as it propagates AU ?<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Below I =
added lspci, iw list, hostapd.conf, dmesg output.<o:p></o:p></p><p =
class=3DMsoNormal><a =
href=3D"http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#sp=
ec">http://www.tp-link.com/en/products/details/?model=3DTL-WDN4800#spec</=
a><o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>Thanks for your help<o:p></o:p></p><p =
class=3DMsoNormal>Angela<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># lspci -vvd =
168c:<o:p></o:p></p><p class=3DMsoNormal>02:00.0 Network controller: =
Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev =
01)<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Subsystem: =
Atheros Communications Inc. Device 3112<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Control: I/O+ Mem+ BusMaster+ =
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- =
DisINTx-<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 <span =
lang=3DDE-CH>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast =
>TAbort- <TAbort- <MAbort- >SERR- <PERR- =
INTx-<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0 </span>Latency: 0, Cache Line Size: =
64 bytes<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 =
Interrupt: pin A routed to IRQ 17<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Region 0: Memory at fbe00000 =
(64-bit, non-prefetchable) [size=3D128K]<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Expansion ROM at fbe20000 =
[disabled] [size=3D64K]<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [40] Power =
Management version 3<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Flags: =
PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA =
PME(D0+,D1+,D2-,D3hot+,D3cold-)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Status: =
D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [50] MSI: Enable- =
Count=3D1/4 Maskable+ 64bit+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Address: =
0000000000000000=A0 Data: 0000<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Masking: =
00000000=A0 Pending: 00000000<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [70] Express (v2) =
Endpoint, MSI 00<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCap: =
MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 =
<8us<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 <span lang=3DDE-CH>ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ =
FLReset-<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span>DevCtl: Report errors: Correctable- Non-Fatal- Fatal- =
Unsupported-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RlxdOrd- ExtTag- PhantFunc- AuxPwr- =
NoSnoop-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 MaxPayload 128 bytes, MaxReadReq 512 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevSta: =
CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- =
TransPend-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCap: =
Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <2us, L1 =
<64us<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 ClockPM- Surprise- LLActRep- BwNot-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCtl: =
ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 ExtSynch- ClockPM- AutWidDis- BWInt- =
AutBWInt-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkSta: =
Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- =
ABWMgmt-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCap2: =
Completion Timeout: Not Supported, TimeoutDis+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DevCtl2: =
Completion Timeout: 50us to 50ms, TimeoutDis-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkCtl2: =
Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable =
De-emphasis: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Transmit Margin: Normal Operating Range, =
EnterModifiedCompliance- ComplianceSOS-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Compliance De-emphasis: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LnkSta2: =
Current De-emphasis Level: -6dB<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [100 v1] Advanced =
Error Reporting<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
UESta:=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- =
MalfTLP- ECRC- UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0UEMsk:=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- =
MalfTLP- ECRC- UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UESvrt: =
DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- =
UnsupReq- ACSViol-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
CESta:=A0 RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
CEMsk:=A0 RxErr- BadTLP- BadDLLP- Rollover- Timeout- =
NonFatalErr+<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AERCap: =
First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [140 v1] Virtual =
Channel<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0Caps:=A0=A0 LPEVC=3D0 RefClk=3D100ns =
PATEntryBits=3D1<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Arb:=A0=A0=A0 Fixed- WRR32- WRR64- WRR128-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Ctrl:=A0=A0 ArbSelect=3DFixed<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Status: =
InProgress-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
VC0:=A0=A0=A0 Caps:=A0=A0 PATOffset=3D00 MaxTimeSlots=3D1 =
RejSnoopTrans-<o:p></o:p></p><p class=3DMsoNormal> =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Arb:=
=A0=A0=A0 Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Ctrl:=A0=A0 Enable+ ID=3D0 ArbSelect=3DFixed =
TC/VC=3D01<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Status: NegoPending- InProgress-<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Capabilities: [300 v1] Device =
Serial Number 00-00-00-00-00-00-00-00<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Kernel driver in use: =
ath9k<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Kernel =
modules: ath9k<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># iw =
list<o:p></o:p></p><p class=3DMsoNormal>Wiphy phy0<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Band 1:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Capabilities: 0x11ef<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT20 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX HT40 SGI<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maximum =
RX AMPDU length 65535 bytes (exponent: 0x003)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Minimum =
RX AMPDU time spacing: 8 usec (0x06)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HT TX/RX =
MCS rate indexes supported: 0-23<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Frequencies:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2412 MHz [1] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2417 MHz [2] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2422 MHz [3] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2427 MHz [4] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2432 MHz [5] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2437 MHz [6] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2442 MHz [7] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2447 MHz [8] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2452 MHz [9] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2457 MHz [10] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2462 MHz [11] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2467 MHz [12] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* 2472 =
MHz [13] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2484 MHz [14] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bitrates =
(non-HT):<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 1.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 2.0 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5.5 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 11.0 Mbps (short preamble supported)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 6.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 9.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 12.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 18.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 24.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 36.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 48.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 54.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Band 2:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Capabilities: 0x11ef<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX LDCP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0HT20/HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 SM Power Save disabled<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 <span lang=3DDE-CH>RX HT20 SGI<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 RX HT40 SGI<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 </span>TX STBC<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 RX STBC 1-stream<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Max AMSDU length: 7935 bytes<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 DSSS/CCK HT40<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maximum =
RX AMPDU length 65535 bytes (exponent: 0x003)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Minimum =
RX AMPDU time spacing: 8 usec (0x06)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 HT TX/RX =
MCS rate indexes supported: 0-23<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Frequencies:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5180 MHz [36] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5200 MHz [40] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5220 MHz [44] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5240 MHz [48] (20.0 dBm)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, =
radar detection)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5500 MHz [100] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5520 MHz [104] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5540 MHz [108] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5560 MHz [112] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5580 MHz [116] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5600 MHz [120] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5620 MHz [124] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0* 5640 MHz [128] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5660 MHz [132] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5680 MHz [136] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5700 MHz [140] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5745 MHz [149] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0* 5765 MHz [153] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5785 MHz [157] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5805 MHz [161] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 5825 MHz [165] (disabled)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bitrates =
(non-HT):<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 6.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 9.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 12.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 18.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 24.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 36.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 48.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 * 54.0 Mbps<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 max # scan SSIDs: =
4<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Supported =
interface modes:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
IBSS<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
managed<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
AP<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
AP/VLAN<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
WDS<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
monitor<o:p></o:p></p><p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0* mesh point<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown mode (8)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown mode (9)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0 Supported =
commands:<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_interface<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_interface<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_key<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_beacon<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0* =
new_station<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
new_mpath<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_mesh_params<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_bss<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
authenticate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
associate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
deauthenticate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
disassociate<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
join_ibss<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (68)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (55)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (57)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (59)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (67)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
set_wiphy_netns<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (65)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (66)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (82)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (81)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (84)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
Unknown command (87)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0* =
Unknown command (85)<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
testmode<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
connect<o:p></o:p></p><p =
class=3DMsoNormal>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * =
disconnect<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># cat /etc/hostapd.conf<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Schnittstelle und =
Treiber<o:p></o:p></span></p><p =
class=3DMsoNormal>interface=3Dwlan0<o:p></o:p></p><p =
class=3DMsoNormal>driver=3Dnl80211<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
WLAN-Konfiguration<o:p></o:p></p><p =
class=3DMsoNormal>ssid=3Dxxxx<o:p></o:p></p><p =
class=3DMsoNormal>channel=3D6<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># ESSID =
sichtbar<o:p></o:p></p><p =
class=3DMsoNormal>ignore_broadcast_ssid=3D0<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># L=E4ndereinstellungen<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>country_code=3DCH<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>ieee80211d=3D1<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
=DCbertragungsmodus<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>hw_mode=3Dg<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH># Optionale Einstellungen<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># supported_rates=3D10 20 55 110 60 =
90 120 180 240 360 480 540<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Draft-N Modus aktivieren / =
optional nur f=FCr entsprechende Karten<o:p></o:p></span></p><p =
class=3DMsoNormal># ieee80211n=3D1<o:p></o:p></p><p =
class=3DMsoNormal>ieee80211n=3D1<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
Beacons<o:p></o:p></p><p =
class=3DMsoNormal>beacon_int=3D100<o:p></o:p></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>dtim_period=3D2<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
MAC-Authentifizierung<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>macaddr_acl=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># max. Anzahl der =
Clients<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>max_num_sta=3D255<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Gr=F6=DFe der =
Datenpakete/Begrenzung<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>rts_threshold=3D2347<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>fragm_threshold=3D2346<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># hostapd Log =
Einstellungen<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>logger_syslog=3D-1<o:p></o:p></span></p><p =
class=3DMsoNormal>logger_syslog_level=3D2<o:p></o:p></p><p =
class=3DMsoNormal>logger_stdout=3D-1<o:p></o:p></p><p =
class=3DMsoNormal>logger_stdout_level=3D2<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
tempor=E4re Konfigurationsdateien<o:p></o:p></p><p =
class=3DMsoNormal>dump_file=3D/tmp/hostapd.dump<o:p></o:p></p><p =
class=3DMsoNormal>ctrl_interface=3D/var/run/hostapd<o:p></o:p></p><p =
class=3DMsoNormal>ctrl_interface_group=3D0<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
lang=3DDE-CH># Authentifizierungsoptionen<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>auth_algs=3D1<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># =
wmm-Funktionalit=E4t<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>wmm_enabled=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Verschl=FCsselung / hier rein =
WPA2<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DDE-CH>macaddr_acl=3D0<o:p></o:p></span></p><p =
class=3DMsoNormal>wpa=3D2<o:p></o:p></p><p =
class=3DMsoNormal>rsn_preauth=3D1<o:p></o:p></p><p =
class=3DMsoNormal>rsn_preauth_interfaces=3Dwlan0<o:p></o:p></p><p =
class=3DMsoNormal>wpa_key_mgmt=3DWPA-PSK<o:p></o:p></p><p =
class=3DMsoNormal>wpa_pairwise=3DTKIP<o:p></o:p></p><p =
class=3DMsoNormal>rsn_pairwise=3DCCMP<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal># =
Schl=FCsselintervalle / Standardkonfiguration<o:p></o:p></p><p =
class=3DMsoNormal>wpa_group_rekey=3D600<o:p></o:p></p><p =
class=3DMsoNormal>wpa_ptk_rekey=3D600<o:p></o:p></p><p =
class=3DMsoNormal><span =
lang=3DDE-CH>wpa_gmk_rekey=3D86400<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DDE-CH># Zugangsschl=FCssel (PSK) / hier =
in Klartext (ASCII)<o:p></o:p></span></p><p =
class=3DMsoNormal>wpa_passphrase=3Dxxxx<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
0.000000] Linux version 3.3.0-rc2-1+ (root at linux) (gcc version 4.6.1 =
(Ubuntu/Linaro 4.6.1-9ubuntu3) ) #1 SMP Tue Feb 14 13:17:34 CET =
2012<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 0.000000] Command =
line: BOOT_IMAGE=3D/vmlinuz-3.3.0-rc2-1+ =
root=3DUUID=3Dcfc15d9c-2cd1-4bad-9e9d-f2fa1ded76e2 ro<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201360] ath: EEPROM regdomain: =
0x21<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201362] ath: EEPROM =
indicates we should expect a direct regpair map<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201363] ath: Country alpha2 being used: =
AU<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201364] ath: Regpair =
used: 0x21<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.531824] =
ieee80211 phy0: Selected rate control algorithm =
'ath9k_rate_control'<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.532132] Registered led device: ath9k-phy0<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 7.594696] cfg80211: Calling CRDA to update =
world regulatory domain<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
8.966680] cfg80211: World regulatory domain updated:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966682] cfg80211:=A0=A0 (start_freq - =
end_freq @ bandwidth), (max_antenna_gain, max_eirp)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966684] cfg80211:=A0=A0 (2402000 KHz - =
2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966686] cfg80211:=A0=A0 (2457000 KHz - =
2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966687] cfg80211:=A0=A0 (2474000 KHz - =
2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966688] cfg80211:=A0=A0 (5170000 KHz - =
5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 8.966689] cfg80211:=A0=A0 (5735000 KHz - =
5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201366] cfg80211: Updating information on =
frequency 2412 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201368] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201369] cfg80211: =
Updating information on frequency 2417 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201370] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201371] =
cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201373] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201374] cfg80211: Updating information on =
frequency 2427 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201375] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201376] cfg80211: =
Updating information on frequency 2432 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0 =
=A0=A09.201378] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A =
mBi, 2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201379] =
cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201380] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201381] cfg80211: Updating information on =
frequency 2442 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201383] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201384] cfg80211: =
Updating information on frequency 2447 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201385] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201386] =
cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201388] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201389] cfg80211: Updating information on =
frequency 2457 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201390] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201391] cfg80211: =
Updating information on frequency 2462 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201393] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201394] =
cfg80211: Disabling freq 2467 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201395] cfg80211: Disabling freq 2472 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201396] cfg80211: Disabling freq 2484 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201398] =
cfg80211: Updating information on frequency 5180 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201399] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201400] cfg80211: Updating information on =
frequency 5200 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201402] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201403] cfg80211: =
Updating information on frequency 5220 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201404] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201405] =
cfg80211: Updating information on frequency 5240 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201407] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201408] cfg80211: Updating information on =
frequency 5260 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201409] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201410] cfg80211: =
Updating information on frequency 5280 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201412] cfg80211: 5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201413] =
cfg80211: Updating information on frequency 5300 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201414] cfg80211: 5140000 KHz - 5360000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201415] cfg80211: Updating information on =
frequency 5320 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201417] cfg80211: =
5140000 KHz - 5360000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201418] cfg80211: =
Disabling freq 5500 MHz as custom regd has no rule that fits a 20 MHz =
wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201419] =
cfg80211: Disabling freq 5520 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201420] cfg80211: Disabling freq 5540 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201422] cfg80211: Disabling freq 5560 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201423] =
cfg80211: Disabling freq 5580 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201424] cfg80211: Disabling freq 5600 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201425] cfg80211: Disabling freq 5620 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201426] =
cfg80211: Disabling freq 5640 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201428] cfg80211: Disabling freq 5660 MHz as custom regd has no rule =
that fits a 20 MHz wide channel<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201429] cfg80211: Disabling freq 5680 MHz =
as custom regd has no rule that fits a 20 MHz wide =
channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201430] =
cfg80211: Disabling freq 5700 MHz as custom regd has no rule that fits a =
20 MHz wide channel<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201431] cfg80211: Updating information on frequency 5745 MHz for a 20 =
MHz width channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201433] cfg80211: 5715000 KHz - 5860000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201434] cfg80211: Updating information on =
frequency 5765 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201435] cfg80211: =
5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201436] cfg80211: =
Updating information on frequency 5785 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.201438] cfg80211: 5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201439] =
cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201440] cfg80211: 5715000 KHz - 5860000 =
KHz @ 40000 KHz), (N/A mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.201441] cfg80211: Updating information on =
frequency 5825 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.201443] cfg80211: =
5715000 KHz - 5860000 KHz @ 40000 KHz), (N/A mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202827] cfg80211: =
Updating information on frequency 2412 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202829] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202830] =
cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202831] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202833] cfg80211: Updating information on =
frequency 2422 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202834] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202845] cfg80211: =
Updating information on frequency 2427 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202847] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202848] =
cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202849] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202851] cfg80211: Updating information on =
frequency 2437 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202852] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202853] cfg80211: =
Updating information on frequency 2442 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202855] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202856] =
cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202857] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202859] cfg80211: Updating information on =
frequency 2452 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202860] cfg80211: =
2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202861] cfg80211: =
Updating information on frequency 2457 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202863] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202864] =
cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202865] cfg80211: 2402000 KHz - 2472000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202867] cfg80211: Updating information on =
frequency 2467 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202868] cfg80211: =
2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202869] cfg80211: =
Updating information on frequency 2472 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202871] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202872] =
cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202874] cfg80211: 2474000 KHz - 2494000 =
KHz @ 20000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202875] cfg80211: Updating information on =
frequency 5180 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202877] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202878] cfg80211: =
Updating information on frequency 5200 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202879] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202881] =
cfg80211: Updating information on frequency 5220 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202882] cfg80211: 5170000 KHz - 5250000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202884] cfg80211: Updating information on =
frequency 5240 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202885] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202887] cfg80211: =
Disabling freq 5260 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202897] cfg80211: Disabling freq 5280 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202898] cfg80211: Disabling freq 5300 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202899] cfg80211: =
Disabling freq 5320 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202900] cfg80211: Disabling freq 5500 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202901] cfg80211: Disabling freq 5520 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202901] cfg80211: =
Disabling freq 5540 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202902] cfg80211: Disabling freq 5560 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202903] cfg80211: Disabling freq 5580 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202904] cfg80211: =
Disabling freq 5600 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202905] cfg80211: Disabling freq 5620 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202905] cfg80211: Disabling freq 5640 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202916] cfg80211: =
Disabling freq 5660 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202917] cfg80211: Disabling freq 5680 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202918] cfg80211: Disabling freq 5700 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202919] cfg80211: =
Updating information on frequency 5745 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202920] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202921] =
cfg80211: Updating information on frequency 5765 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202923] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202924] cfg80211: Updating information on =
frequency 5785 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202925] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202926] cfg80211: =
Updating information on frequency 5805 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.202928] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.202929] =
cfg80211: Updating information on frequency 5825 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.202930] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.532113] cfg80211: Calling CRDA for =
country: AU<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533522] =
cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533524] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533525] cfg80211: Updating information on =
frequency 2417 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533527] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533528] cfg80211: =
Updating information on frequency 2422 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533530] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533531] =
cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533533] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533534] cfg80211: Updating information on =
frequency 2432 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533535] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533537] cfg80211: =
Updating information on frequency 2437 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533538] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533539] =
cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533541] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533542] cfg80211: Updating information on =
frequency 2447 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533544] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533545] cfg80211: =
Updating information on frequency 2452 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533546] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533547] =
cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533549] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533550] cfg80211: Updating information on =
frequency 2462 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533552] cfg80211: =
2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533553] cfg80211: =
Updating information on frequency 2467 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533554] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, =
2000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533556] =
cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533557] cfg80211: 2402000 KHz - 2482000 =
KHz @ 40000 KHz), (N/A mBi, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533558] cfg80211: Disabling freq 2484 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533559] cfg80211: =
Updating information on frequency 5180 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533561] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533562] =
cfg80211: Updating information on frequency 5200 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533564] cfg80211: 5170000 KHz - 5250000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533565] cfg80211: Updating information on =
frequency 5220 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533566] cfg80211: =
5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2300 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533568] cfg80211: =
Updating information on frequency 5240 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533569] cfg80211: 5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533570] =
cfg80211: Updating information on frequency 5260 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533572] cfg80211: 5250000 KHz - 5330000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533573] cfg80211: Updating information on =
frequency 5280 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533575] cfg80211: =
5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2300 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533576] cfg80211: =
Updating information on frequency 5300 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533577] cfg80211: 5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, =
2300 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533579] =
cfg80211: Updating information on frequency 5320 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533580] cfg80211: 5250000 KHz - 5330000 =
KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[ =A0=A0=A09.533581] cfg80211: Disabling freq 5500 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533582] cfg80211: =
Disabling freq 5520 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533583] cfg80211: Disabling freq 5540 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533584] cfg80211: Disabling freq 5560 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533585] cfg80211: =
Disabling freq 5580 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533585] cfg80211: Disabling freq 5600 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533586] cfg80211: Disabling freq 5620 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533587] cfg80211: =
Disabling freq 5640 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533588] cfg80211: Disabling freq 5660 MHz<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533589] cfg80211: Disabling freq 5680 =
MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533590] cfg80211: =
Disabling freq 5700 MHz<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533591] cfg80211: Updating information on frequency 5745 MHz for a 20 =
MHz width channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533592] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533593] cfg80211: Updating information on =
frequency 5765 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533595] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533596] cfg80211: =
Updating information on frequency 5785 MHz for a 20 MHz width channel =
with regulatory rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 =
9.533597] cfg80211: 5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, =
3000 mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533599] =
cfg80211: Updating information on frequency 5805 MHz for a 20 MHz width =
channel with regulatory rule:<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533600] cfg80211: 5735000 KHz - 5835000 =
KHz @ 40000 KHz), (300 mBi, 3000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533601] cfg80211: Updating information on =
frequency 5825 MHz for a 20 MHz width channel with regulatory =
rule:<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533603] cfg80211: =
5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p><p class=3DMsoNormal>[=A0=A0=A0 9.533606] cfg80211: =
Regulatory domain changed to country: AU<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533607] cfg80211:=A0=A0 (start_freq - =
end_freq @ bandwidth), (max_antenna_gain, max_eirp)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533608] cfg80211:=A0=A0 (2402000 KHz - =
2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533609] cfg80211:=A0=A0 (5170000 KHz - =
5250000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533611] cfg80211:=A0=A0 (5250000 KHz - =
5330000 KHz @ 40000 KHz), (300 mBi, 2300 mBm)<o:p></o:p></p><p =
class=3DMsoNormal>[=A0=A0=A0 9.533612] cfg80211:=A0=A0 (5735000 KHz - =
5835000 KHz @ 40000 KHz), (300 mBi, 3000 =
mBm)<o:p></o:p></p></div></body></html>
------=_NextPart_000_0CFF_01CD01BB.A7359070--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2012-01-15 8:24 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2012-01-15 8:24 UTC (permalink / raw)
To: ath9k-devel
=A0=A0=A0 /* Only use status info from the last fragment */
=A0=A0=A0 if (rx_stats->rs_more)
=A0=A0=A0 =A0=A0=A0 return 0=3B
rs_more is set from the receive descriptor in ath9k_hw_rxprocdesc=2C so if =
"fragment" is an A-MPDU subframe=2C each subframe gets its own descriptor. =
This looks promising.
=
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-11-12 14:39 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-11-12 14:39 UTC (permalink / raw)
To: ath9k-devel
and/or experimental. Am I right?
Either way I would be more than happy to help with debugging this and
maybe get this chipset working
sometime soon! The only problem us that my expertise only stretches so
far. Even though I know C
I've never done any kernel or driver work.
So what can I do? I'll see if I can get my hands on one (or two) of
those usb-to-serial adapters and see what happens, but I live on a
very tight budget so I can't hope for too much.
// Kim
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-11-12 14:39 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-11-12 14:39 UTC (permalink / raw)
To: ath9k-devel
masked out and then unmasked. So I bet ath_rx_tasklet() is actually
running somehow and not doing anything useful.
Kim - can you please add a debug statement inside ath_rx_tasklet() -
at the beginning, then at the end of the function where it's
re-enabling RXEOL. Just to confirm that it _is_ running and causing
the RXEOL bit to be re-enabled.
Thanks,
Adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
users on debugging issues like this, even if end users happen to be
competent. The prefered modus operandi is to attempt to reproduce
issues internally, and if that is successful then some time later
there usually comes a patch into wireless-testing.git. This is of
course useless for corner case problems.
This mailing list is a lot like first-line support. You usually don't
get quality engineer time from Atheros here. I can understand that,
because remote debugging is a tremendous pain. But it's also the only
way to resolve odd problems.
I would recommend that you try to reproduce using FreeBSD. I'm unsure
if the driver there supports AR9287, but if it does I think you will
be able to get good help thanks to Adrian, the main fbsd driver
developer, who is also active on this list, but he's obviously not
working on the Linux driver. :)
//Peter
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
1. ASPM is disabled on my machine wherever possible (in fact I think
my mainboard doesn't even support it and this is detected correctly,
at least there I couldn't find any related setting in bios)
2. My wireless card is PCI not PCIe, and if I don't confuse something
here, ASPM is a feature of PCIe and PCIe only.
Power-saving I might check by disabling all the related options, I'll
let you know if it changes anything.
Thanks,
Philipp
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
that'd occur with the NIC awake or having something being written to
it) the NIC shouldn't be generating interrupts if:
* sync/async cause are 0;
* ier is 0;
* imr is 0.
Now maybe some part of ath9k is still trying to write to the NIC when
it's asleep, but it would set some bits in sync_cause/async_cause.
At this point I'd really suggest whacking other devices into the slot
to see if they generate the same kind of behaviour.
Adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
explained in the wireshark documentation.
Cheers,
Julien
--
.''`. Julien Valroff ~ <julien@kirya.net> ~ <julien@debian.org>
: :' : Debian Developer & Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-08-05 3:08 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-08-05 3:08 UTC (permalink / raw)
To: ath9k-devel
so the user should only be allowed to change the value to anything else than
what is stored in the eeprom if we know it's a valid setting.
As far as I understand the EEPROM only stores a single value for the
antenna-switch setting, i.e. if there multiple valid values these must come from
somewhere else.
I don't know the exact electronic details of the implementation, so I'd go with
a list of known-to-be-good values (passed to the driver via platform-data)
instead of a causal check (e.g. don't allow to set the TX and RX to the same
antenna or whatever you imagine to possibly be an invalid setting).
Cheers
Daniel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-06-04 23:16 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-06-04 23:16 UTC (permalink / raw)
To: ath9k-devel
"Evidently, some BIOSes have their ASPM support misconfigured and thus
problems can arise if the PCI-E link power mode is dropped on an
unsupported device. There are a few mentions of hangs and other issues
under Linux associated with this power management feature. It's not
really a surprise though that the BIOSes would be misconfigured given
all of the other BIOS-related problems under Linux and the once very
poor suspend-and-resume support due to all of the workarounds and
hacks that BIOS/hardware vendors have done to cater towards Microsoft
Windows power management. In this case, it seems a large number of
mobile systems are supporting ASPM but not properly advertising the
support via the standard BIOS ACPI FADT (Fixed ACPI Description
Table). Some Linux drivers even forcibly disable ASPM on Linux (e.g.
this kernel patch)."
Would someone please take charge of testing an unmodified ath9k (ie,
without my APSM disable fix) and try reverting this kernel patch?
Thanks,
Adrian
On 25 February 2011 04:02, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (just cc-ing some people listed in MAINTAINERS)
> Hi,
>
> Tony Houghton wrote:
>
>> With 2.6.37 I can not use suspend on my Compaq/HP 311c (Intel Atom
>> N270/NVidia Ion LE). Originally the machine just kept locking up without
>> even blanking the display when I tried to suspend (using the GNOME menu
>> or by shutting the lid). I upgraded upower and gnome-power-manager etc
>> to experimental and after that the machine suspended OK but could not
>> resume. The backlight came on but the screen stayed blank and I could
>> not get to a console or anything with Alt+Fn.
> [...]
>> I tried replacing network-manager with wicd but that crashed the system
>> when it connected instead of when disconnected.
> [...]
>> While testing different kernels I found it would crash at different
>> times, usually before the screen turned off for suspending, but
>> sometimes it would crash on resuming and occasionally it locked up while
>> booting, but it's always a complete lock-up ie the keyboard is
>> completely responsive, including caps lock, the mouse won't move if the
>> display is still on, and the only way out is to hold down the power
>> button.
> [...]
>> I haven't tried looking in logs because the crashes are so severe I
>> don't think they'd be able to record anything useful. But using git
>> bisect I think I have tracked down the change that started causing this
>> problem:
>>
>> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f is the first bad commit
>> commit 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
>> Author: Vivek Natarajan <vnatarajan@atheros.com>
>> Date: =A0 Mon Apr 5 14:48:04 2010 +0530
>>
>> =A0 =A0 ath9k: Add support for newer AR9285 chipsets.
>>
>> =A0 =A0 This patch adds support for a modified newer version of AR9285
>> =A0 =A0 chipsets.
>>
>> =A0 =A0 Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>> =A0 =A0 Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> The adaptor is an AR9285[1].
>
> That commit is based against v2.6.33 and was merged in v2.6.35-rc1
>
> $ git describe 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> v2.6.33-3523-g53bc7aa
> $ git name-rev --tags 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
> 53bc7aa08b48e5cd745f986731cc7dc24eef2a9f tags/v2.6.35-rc1~473^2~167^2~346
>
> Any ideas for tracking this down?
>
> Thanks,
> Jonathan
>
> [1]
>> 84: udi =3D '/org/freedesktop/Hal/devices/pci_168c_2b'
>> =A0 pci.device_protocol =3D 0 =A0(0x0) =A0(int)
>> =A0 pci.vendor =3D 'Atheros Communications Inc.' =A0(string)
>> =A0 info.vendor =3D 'Atheros Communications Inc.' =A0(string)
>> =A0 pci.product =3D 'AR9285 Wireless Network Adapter
>> (PCI-Express)' =A0(string) linux.sysfs_path =3D
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' =A0(strin g)
>> =A0 info.parent =3D '/org/freedesktop/Hal/devices/pci_10de_ac6' =A0(stri=
ng)
>> =A0 info.linux.driver =3D 'ath9k' =A0(string)
>> =A0 pci.subsys_vendor =3D 'Hewlett-Packard Company' =A0(string)
>> =A0 linux.hotplug_type =3D 2 =A0(0x2) =A0(int)
>> =A0 linux.subsystem =3D 'pci' =A0(string)
>> =A0 info.subsystem =3D 'pci' =A0(string)
>> =A0 info.product =3D 'AR9285 Wireless Network Adapter
>> (PCI-Express)' =A0(string) info.udi =3D
>> '/org/freedesktop/Hal/devices/pci_168c_2b' =A0(string)
>> pci.linux.sysfs_path =3D
>> '/sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0' =A0(string)
>> pci.product_id =3D 43 =A0(0x2b) =A0(int) pci.vendor_id =3D 5772 =A0(0x16=
8c)
>> (int) pci.subsys_product_id =3D 12352 =A0(0x3040) =A0(int)
>> pci.subsys_vendor_id =3D 4156 =A0(0x103c) =A0(int) pci.device_class =3D =
2
>> (0x2) =A0(int) pci.device_subclass =3D 128 =A0(0x80) =A0(int)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"=
in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-06-04 23:16 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-06-04 23:16 UTC (permalink / raw)
To: ath9k-devel
not even used an AR9300 yet, let alone tinkered with the TPC stuff) it
looks all very straightforward. Unless some other chip functionality
is required that hasn't been ported to ath9k, it "should just work".
Sorry, I can't be more helpful than that.
(Also, it'd be nice if someone contributed per-packet TPC support -
proper support at that! - to ath9k. :)
adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
the silicon itself at power-on. 'abcd' sounds a bit too convenient to be
what's in EEPROM/OTP; so maybe it's a default value in the silicon?
(All just conjecture here at this point.)
Adrian
On 10 April 2011 23:17, Mohammed Shafi <shafi.ath9k@gmail.com> wrote:
> On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge <peter@stuge.se> wrote:
> > Mohammed Shafi wrote:
> >> > Is this a serious proposal from Atheros, or just your attempt at
> >> > a quick fix?
> >>
> >> No! its purely a personal idea (am completely responsible for the
> >> mistake),and I will take a look at it carefully to fix this.
> >
> > Sorry, I didn't mean that you made a mistake, just that the
> > suggestion probably would not get us closer to the actual issue.
> >
> > Bus level issues are indeed difficult. :\
>
> thanks, i did not know that. thought simple as adding another device id.
> >
> >
> >> > A device having an unexpected PCI id means that something is really
> >> > wrong in the device or on the bus, and the solution is rarely to
> >> > pretend that it didn't happen.]
> >>
> >> Yeah I can see that, hoping that I may get a correct Device ID from
> >> the reporter. I dont think 'abcd' is a proper vendor id.
> >
> > Yes, it's easy to spot. The question is how we can find out *why*
> > this happened, so that this error case can be prevented.
>
> Yes sure.
> >
> >
> >> > Since this card should work fine in principle, maybe it's some issue
> >> > with missing, or wrong, firmware stored on the Linux system.
> >>
> >> AR9382 does not seems to have firmware
> >
> > Aha! That's only for the USB devices maybe. I don't know much detail
> > for these latest devices.
> >
> currently only ath9k_htc needs firmware.
>
> >
> >> and you have any idea what might went wrong.
> >
> > Sorry, I don't understand what you mean here.
>
> Your suggestions about what might have went wrong, as you had already
> told it might be a bus level issue.
>
> >
> >
> >> Also why its detected as Ethernet Controller rather than
> >> Network controller.
> >
> > This string comes from the pciutils package and could easily have
> > changed. Better look at the numerical device class code, which is
> > what is read from hardware.
>
> thanks, I will look into that.
>
> >
> > But I expect that when one thing in config space (device id) is bogus
> > then the rest of config space is also quite possibly bogus, for the
> > same reason, whatever it is.
> >
> >
> > //Peter
> > _______________________________________________
> > 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
>
--20cf300256ecb39f7b04a09232d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Incorrect or misplaced EEPROM/OTP data, perhaps?<div><br></div><div>From wh=
at I gather, the PCI ID on earlier devices is loaded out of EEPROM by the s=
ilicon itself at power-on. 'abcd' sounds a bit too convenient to be=
what's in EEPROM/OTP; so maybe it's a default value in the silicon=
?</div>
<div><br></div><div>(All just conjecture here at this point.)</div><div><br=
></div><div><br></div><div>Adrian</div><div><br><div class=3D"gmail_quote">=
On 10 April 2011 23:17, Mohammed Shafi <span dir=3D"ltr"><<a href=3D"mai=
lto:shafi.ath9k@gmail.com">shafi.ath9k at gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Sun, Apr 10, 2011 at 8=
:41 PM, Peter Stuge <<a href=3D"mailto:peter@stuge.se">peter at stuge.se</a=
>> wrote:<br>
> Mohammed Shafi wrote:<br>
>> > Is this a serious proposal from Atheros, or just your attempt=
at<br>
>> > a quick fix?<br>
>><br>
>> No! its purely a personal idea (am completely responsible for the<=
br>
>> mistake),and I will take a look at it carefully to fix this.<br>
><br>
> Sorry, I didn't mean that you made a mistake, just that the<br>
> suggestion probably would not get us closer to the actual issue.<br>
><br>
> Bus level issues are indeed difficult. :\<br>
<br>
</div>thanks, i did not know that. thought simple as adding another device =
id.<br>
<div class=3D"im">><br>
><br>
>> > A device having an unexpected PCI id means that something is =
really<br>
>> > wrong in the device or on the bus, and the solution is rarely=
to<br>
>> > pretend that it didn't happen.]<br>
>><br>
>> Yeah I can see that, hoping that I may get a correct Device ID fro=
m<br>
>> the reporter. I dont think 'abcd' is a proper vendor id.<b=
r>
><br>
> Yes, it's easy to spot. The question is how we can find out *why*<=
br>
> this happened, so that this error case can be prevented.<br>
<br>
</div>Yes sure.<br>
<div class=3D"im">><br>
><br>
>> > Since this card should work fine in principle, maybe it's=
some issue<br>
>> > with missing, or wrong, firmware stored on the Linux system.<=
br>
>><br>
>> AR9382 does not seems to have firmware<br>
><br>
> Aha! That's only for the USB devices maybe. I don't know much =
detail<br>
> for these latest devices.<br>
><br>
</div>currently only =A0ath9k_htc needs firmware.<br>
<div class=3D"im"><br>
><br>
>> and you have any idea what might went wrong.<br>
><br>
> Sorry, I don't understand what you mean here.<br>
<br>
</div>Your suggestions about what might have went wrong, as you had already=
<br>
told it might be a bus level issue.<br>
<div class=3D"im"><br>
><br>
><br>
>> Also why its detected as Ethernet Controller rather than<br>
>> Network controller.<br>
><br>
> This string comes from the pciutils package and could easily have<br>
> changed. Better look at the numerical device class code, which is<br>
> what is read from hardware.<br>
<br>
</div>thanks, I will look into that.<br>
<div><div></div><div class=3D"h5"><br>
><br>
> But I expect that when one thing in config space (device id) is bogus<=
br>
> then the rest of config space is also quite possibly bogus, for the<br=
>
> same reason, whatever it is.<br>
><br>
><br>
> //Peter<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k=
.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
</div></div></blockquote></div><br></div>
--20cf300256ecb39f7b04a09232d4--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
ATTITUDE ADJUSTMENT (bleeding edge, r26358) ----------
root at jv-2400-ap1:~# uptime
16:57:14 up 3 days, 14:15, load average: 0.00, 0.01, 0.04
root at jv-2400-ap1:~# iw wlan0 station dump | grep -i failed
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 0
tx failed: 7
tx failed: 0
tx failed: 0
root at jv-2400-ap1:~#
--
Larry Vaden, CoFounder
Internet Texoma, Inc.
Serving Rural Texomaland Since 1995
We Care About Your Connection!
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------
Device Instance Id:
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&0&00E2
Hardware Ids:
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C
PCI\VEN_168C&DEV_0030&CC_028000
PCI\VEN_168C&DEV_0030&CC_0280
Compatible Ids:
PCI\VEN_168C&DEV_0030&REV_01
PCI\VEN_168C&DEV_0030
PCI\VEN_168C&CC_028000
PCI\VEN_168C&CC_0280
PCI\VEN_168C
PCI\CC_028000
PCI\CC_0280
Matching Device Id:
pci\ven_168c&dev_0030&subsys_3116168c
Here is the interesting bit, when I first hooked this card I booted my=
machine in Ubuntu I saw the same 168c:ABCD. After using it under Window=
s, I booted in to Linux today and found that it is reporting the expecte=
d IDs. Now ath9k works right out of the box, no Vendor ID hacking requir=
ed. I am using it as station right now. The other card is in a different=
machine. I will try to swap the cards to verify my theory. I am thinkin=
g the Windows driver applied a firmware update to the card. Or, the othe=
r card skipped quality checks and has bogus EEPROM data. Any thoughts?
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)
lspci -vvvnn returns
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)
Subsystem: Atheros Communications Inc. Device [168c:3116]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste=
pping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbor=
t- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=3D128K]
[virtual] Expansion ROM@f2000000 [disabled] [size=3D64K]
Capabilities: <access denied>
Kernel driver in use: ath9k
Kernel modules: ath9k
Hasan R.
-----Original Message-----
From: Mohammed Shafi [mailto:shafi.ath9k at gmail.com]=20
Sent: Tuesday, April 12, 2011 7:47 AM
To: Hasan Rashid
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad@avionica.com>=
wrote:
>
> I have attached the driver load output in dmesg.
>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you=20
> list the major requirements?
because the hardware code(HAL) will be present from that kernel version=
only.
>
> Hasan R.
>
> -----Original Message-----
> From: ath9k-devel-bounces at lists.ath9k.org
> [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Peter Stuge
> Sent: Monday, April 11, 2011 12:20 PM
> To: ath9k-devel at lists.ath9k.org
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
>
> Mohammed Shafi wrote:
>> to make sure that HT is configured in driver please do this
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c
>> b/drivers/net/wireless/ath/ath9k/hw.c
>> index 1b5bd13..720a866 100644
>> --- a/drivers/net/wireless/ath/ath9k/hw.c
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
>> =A0 =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9K_HW_CAP_HT;
>>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CAP_HT;
>> +
>
> The indentation is off, or do you mean to include the added line only=20
> within the else block? If so, remember to add braces.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
> This communication contains information that may be confidential or=20
> privileged. The information is solely intended for the use of the addr=
essee. If you are not the intended recipient, be advised that any disclo=
sure, copy, distribution, or use of the contents of this communication=
is prohibited. If you have received this communication in error, please=
immediately notify the sender by telephone or by electronic mail.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in
error, please immediately notify the sender by telephone or by electroni=
c mail.
------_=_NextPart_001_01CBF922.E6EB9838
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-88=
59-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7654.=
12">
<TITLE>RE: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>I put another Sparklan card in a Windows XP machine=
and following are the device ids reported by the Atheros driver on Wind=
ows. It seems it is reporting the correct 0x168c, and 0x0030.<BR>
<BR>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------<BR>
Device Instance Id:<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&a=
mp;0&00E2<BR>
<BR>
Hardware Ids:<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01<BR>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C<BR>
PCI\VEN_168C&DEV_0030&CC_028000<BR>
PCI\VEN_168C&DEV_0030&CC_0280<BR>
<BR>
Compatible Ids:<BR>
PCI\VEN_168C&DEV_0030&REV_01<BR>
PCI\VEN_168C&DEV_0030<BR>
PCI\VEN_168C&CC_028000<BR>
PCI\VEN_168C&CC_0280<BR>
PCI\VEN_168C<BR>
PCI\CC_028000<BR>
PCI\CC_0280<BR>
<BR>
Matching Device Id:<BR>
pci\ven_168c&dev_0030&subsys_3116168c<BR>
<BR>
<BR>
Here is the interesting bit, when I first hooked this card I booted my=
machine in Ubuntu I saw the same 168c:ABCD. After using it under Window=
s, I booted in to Linux today and found that it is reporting the expecte=
d IDs. Now ath9k works right out of the box, no Vendor ID hacking requir=
ed. I am using it as station right now. The other card is in a different=
machine. I will try to swap the cards to verify my theory. I am thinkin=
g the Windows driver applied a firmware update to the card. Or, the othe=
r card skipped quality checks and has bogus EEPROM data. Any thoughts?<B=
R>
<BR>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)<BR>
<BR>
lspci -vvvnn returns<BR>
<BR>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300=
Wireless LAN adaptor [168c:0030] (rev 01)<BR>
Subsystem: Atheros Communicat=
ions Inc. Device [168c:3116]<BR>
Control: I/O+ Mem+ BusMaster+=
SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-=
<BR>
Status: Cap+ 66MHz- UDF- Fast=
B2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- <MAbort- >SERR-=
<PERR- INTx-<BR>
Latency: 0, Cache Line Size:=
64 bytes<BR>
Interrupt: pin A routed to=
IRQ 18<BR>
Region 0: Memory at fa000000=
(64-bit, non-prefetchable) [size=3D128K]<BR>
[virtual] Expansion ROM at=
f2000000 [disabled] [size=3D64K]<BR>
Capabilities: <access deni=
ed><BR>
Kernel driver in use: ath9k<B=
R>
Kernel modules: ath9k<BR>
<BR>
<BR>
Hasan R.<BR>
<BR>
-----Original Message-----<BR>
From: Mohammed Shafi [<A HREF=3D"mailto:shafi.ath9k@gmail.com">mailto:sh=
afi.ath9k at gmail.com</A>]<BR>
Sent: Tuesday, April 12, 2011 7:47 AM<BR>
To: Hasan Rashid<BR>
Cc: ath9k-devel at lists.ath9k.org<BR>
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<BR>
<BR>
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <hrashad at avionica.com&=
gt; wrote:<BR>
><BR>
> I have attached the driver load output in dmesg.<BR>
><BR>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you=
<BR>
> list the major requirements?<BR>
<BR>
because the hardware code(HAL) will be present from that kernel version=
only.<BR>
><BR>
> Hasan R.<BR>
><BR>
> -----Original Message-----<BR>
> From: ath9k-devel-bounces at lists.ath9k.org<BR>
> [<A HREF=3D"mailto:ath9k-devel-bounces@lists.ath9k.org">mailto:ath9=
k-devel-bounces at lists.ath9k.org</A>] On Behalf Of Peter Stuge<BR>
> Sent: Monday, April 11, 2011 12:20 PM<BR>
> To: ath9k-devel at lists.ath9k.org<BR>
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<BR>
><BR>
> Mohammed Shafi wrote:<BR>
>> to make sure that HT is configured in driver please do this<BR>
>><BR>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> b/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> index 1b5bd13..720a866 100644<BR>
>> --- a/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c<BR>
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw=
*ah)<BR>
>> =A0 =A0 =A0 =A0 else<BR>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9=
K_HW_CAP_HT;<BR>
>><BR>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CA=
P_HT;<BR>
>> +<BR>
><BR>
> The indentation is off, or do you mean to include the added line=
only<BR>
> within the else block? If so, remember to add braces.<BR>
><BR>
><BR>
> //Peter<BR>
> _______________________________________________<BR>
> ath9k-devel mailing list<BR>
> ath9k-devel at lists.ath9k.org<BR>
> <A HREF=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel">ht=
tps://lists.ath9k.org/mailman/listinfo/ath9k-devel</A><BR>
><BR>
> This communication contains information that may be confidential=
or<BR>
> privileged. The information is solely intended for the use of the=
addressee. If you are not the intended recipient, be advised that any=
disclosure, copy, distribution, or use of the contents of this communic=
ation is prohibited. If you have received this communication in error,=
please immediately notify the sender by telephone or by electronic mail=
.<BR>
> _______________________________________________<BR>
> ath9k-devel mailing list<BR>
> ath9k-devel at lists.ath9k.org<BR>
> <A HREF=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel">ht=
tps://lists.ath9k.org/mailman/listinfo/ath9k-devel</A><BR>
><BR>
><BR>
<BR>
</FONT>
</P>
<!-- Begin Ninja Disclaimer ID 06d1f63c-a7f2-4bdd-9832-359e6e93159e -->
This communication contains information that may be confidential or priv=
ileged. The information is solely intended for the use of the addressee.=
If you are not the intended recipient, be advised that any disclosure,=
copy, distribution, or use of the contents of this communication is pro=
hibited. If you have received this communication in<BR>error, please imm=
ediately notify the sender by telephone or by electronic mail.
</BODY>
</HTML>
------_=_NextPart_001_01CBF922.E6EB9838--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2011-04-07 5:55 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2011-04-07 5:55 UTC (permalink / raw)
To: ath9k-devel
-------------------------------<br>
Device Instance Id:<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01\4&492937F&=
0&00E2<br>
<br>
Hardware Ids:<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C&REV_01<br>
PCI\VEN_168C&DEV_0030&SUBSYS_3116168C<br>
PCI\VEN_168C&DEV_0030&CC_028000<br>
PCI\VEN_168C&DEV_0030&CC_0280<br>
<br>
Compatible Ids:<br>
PCI\VEN_168C&DEV_0030&REV_01<br>
PCI\VEN_168C&DEV_0030<br>
PCI\VEN_168C&CC_028000<br>
PCI\VEN_168C&CC_0280<br>
PCI\VEN_168C<br>
PCI\CC_028000<br>
PCI\CC_0280<br>
<br>
Matching Device Id:<br>
pci\ven_168c&dev_0030&subsys_3116168c<br>
<br>
<br>
Here is the interesting bit, when I first hooked this card I booted my mach=
ine in Ubuntu I saw the same 168c:ABCD. After using it under Windows, I boo=
ted in to Linux today and found that it is reporting the expected IDs. Now =
ath9k works right out of the box, no Vendor ID hacking required. I am using=
it as station right now. The other card is in a different machine. I will =
try to swap the cards to verify my theory. I am thinking the Windows driver=
applied a firmware update to the card. Or, the other card skipped quality =
checks and has bogus EEPROM data. Any thoughts?<br>
<br>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wirel=
ess LAN adaptor [168c:0030] (rev 01)<br>
<br>
lspci -vvvnn returns<br>
<br>
0e:00.0 Network controller [0280]: Atheros Communications Inc. AR9300 Wirel=
ess LAN adaptor [168c:0030] (rev 01)<br>
=A0=A0=A0=A0=A0=A0=A0 Subsystem: Atheros Communications Inc. Device [168c:3=
116]</font></p><div class=3D"im"><font size=3D"2"><br>
=A0=A0=A0=A0=A0=A0=A0 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGA=
Snoop- ParErr- Stepping- SERR- FastB2B- DisINTx-<br>
=A0=A0=A0=A0=A0=A0=A0 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfa=
st >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-<br></font>=
</div><font size=3D"2">
=A0=A0=A0=A0=A0=A0=A0 Latency: 0, Cache Line Size: 64 bytes<br>
=A0=A0=A0=A0=A0=A0=A0 Interrupt: pin A routed to IRQ 18<br>
=A0=A0=A0=A0=A0=A0=A0 Region 0: Memory at fa000000 (64-bit, non-prefetchabl=
e) [size=3D128K]<br>
=A0=A0=A0=A0=A0=A0=A0 [virtual] Expansion ROM at f2000000 [disabled] [size=
=3D64K]<br>
=A0=A0=A0=A0=A0=A0=A0 Capabilities: <access denied><br>
=A0=A0=A0=A0=A0=A0=A0 Kernel driver in use: ath9k<br>
=A0=A0=A0=A0=A0=A0=A0 Kernel modules: ath9k<br>
<br>
<br>
Hasan R.<div class=3D"im"><br>
<br>
-----Original Message-----<br>
From: Mohammed Shafi [<a href=3D"mailto:shafi.ath9k@gmail.com" target=3D"_b=
lank">mailto:shafi.ath9k at gmail.com</a>]<br></div><div class=3D"im">
Sent: Tuesday, April 12, 2011 7:47 AM<br>
To: Hasan Rashid<br></div><div><div></div><div class=3D"h5">
Cc: <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k-=
devel at lists.ath9k.org</a><br>
Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<br>
<br>
On Mon, Apr 11, 2011 at 11:24 PM, Hasan Rashid <<a href=3D"mailto:hrasha=
d@avionica.com" target=3D"_blank">hrashad at avionica.com</a>> wrote:<br>
><br>
> I have attached the driver load output in dmesg.<br>
><br>
> By the way why does AR9382 require Kernel 2.6.36 or higher? Can you<br=
>
> list the major requirements?<br>
<br>
because the hardware code(HAL) will be present from that kernel version onl=
y.<br>
><br>
> Hasan R.<br>
><br>
> -----Original Message-----<br>
> From: <a href=3D"mailto:ath9k-devel-bounces@lists.ath9k.org" target=3D=
"_blank">ath9k-devel-bounces at lists.ath9k.org</a><br>
> [<a href=3D"mailto:ath9k-devel-bounces@lists.ath9k.org" target=3D"_bla=
nk">mailto:ath9k-devel-bounces at lists.ath9k.org</a>] On Behalf Of Peter Stug=
e<br>
> Sent: Monday, April 11, 2011 12:20 PM<br>
> To: <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">a=
th9k-devel at lists.ath9k.org</a><br>
> Subject: Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd<br>
><br>
> Mohammed Shafi wrote:<br>
>> to make sure that HT is configured in driver please do this<br>
>><br>
>> diff --git a/drivers/net/wireless/ath/ath9k/hw.c<br>
>> b/drivers/net/wireless/ath/ath9k/hw.c<br>
>> index 1b5bd13..720a866 100644<br>
>> --- a/drivers/net/wireless/ath/ath9k/hw.c<br>
>> +++ b/drivers/net/wireless/ath/ath9k/hw.c<br>
>> @@ -1855,6 +1855,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah=
)<br>
>> =A0 =A0 =A0 =A0 else<br>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps &=3D ~ATH9K_H=
W_CAP_HT;<br>
>><br>
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pCap->hw_caps |=3D ATH9K_HW_CAP_H=
T;<br>
>> +<br>
><br>
> The indentation is off, or do you mean to include the added line only<=
br>
> within the else block? If so, remember to add braces.<br>
><br>
><br>
> //Peter<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
> This communication contains information that may be confidential or<br=
>
> privileged. The information is solely intended for the use of the addr=
essee. If you are not the intended recipient, be advised that any disclosur=
e, copy, distribution, or use of the contents of this communication is proh=
ibited. If you have received this communication in error, please immediatel=
y notify the sender by telephone or by electronic mail.<br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
<br>
</div></div></font>
<p></p><div><div></div><div class=3D"h5">
This communication contains information that may be confidential or privile=
ged. The information is solely intended for the use of the addressee. If yo=
u are not the intended recipient, be advised that any disclosure, copy, dis=
tribution, or use of the contents of this communication is prohibited. If y=
ou have received this communication in<br>
error, please immediately notify the sender by telephone or by electronic m=
ail.
</div></div></div>
<br>_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
<br></blockquote></div><br>
--002215b031060bfd5704a0c0a00c--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
chip haven't been woken up.
The AR9280 support works (for values of "work") in FreeBSD, so I'm
thinking the local code is missing a couple of relevant register
settings to enable the thing.
Does anyone know off-hand what I may need to glimpse at to make it
work? What's different between the AR9280 and AR9220 initialisation
sequences? I couldn't see anything AR9220 specific in ath9k.
Thanks,
Adrian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
* If your RX chainmask has >1 radio enabled, you'll always be doing
receive-side "diversity" (which is really "combining" (MRC) if I
understand the technology correctly on multi-radio atheros 11n cards);
* If your TX chainmask has >1 radio enabled and the TX descriptor has
the relevant chainmask bits set, you should be transmitting on both
antennas regardless of the rate. I honestly haven't verified it (I've
only verified that behaviour for transmitting legacy rates out of the
11n chips);
* For rates < MCS8 (and legacy rates) there's further TX-side trickery
that can be going on which I'm not too up-to-date on. For example,
some (all?) of the 11n chips allow you to optionally transmit MCS0-7
using STBC. But iirc, STBC is only enabled for 1-stream TX.
In short, if you've got all the radios enabled for RX and ath9k is
enabling both/all radio chains when TX'ing, I think the answer is
"yes" for you. :)
Adrian
On 16 February 2011 22:47, Baldomero Coll <baldo.ath9k@gmail.com> wrote:
> I'm not sure, but I've read somewhere that by default the two antennas are
> used.
> It is true that I'm not interested in selecting the number of antennas, what
> I really want is that the MIMO capability is exploited if I'm using 802.11n
> HT IBSS operation mode.
> Can someone confirm that by default the two antennas (spatial diversity) are
> being used when we create the HT IBSS network?
>
> 2011/2/16 Mohammed Shafi <shafi.ath9k@gmail.com>
>>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <baldo.ath9k@gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Can you please tell me how do you select one o two antennas?
>>
>> I don't know why you should do that. I guess changing the tx/rx
>> chainmask will do after it was read from eeprom.
>>
>> >
>> > I'm using a similar setting than you:
>> > Linux kernel: 2.6.32-28-generic-pae.
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch
>> > suggested by
>> > Alex.
>> > Radio card: Ubiquiti SR71x
>> >
>> > Thanks in advance,
>> > Baldomero
>> >>
>> >> Hi all,
>> >>
>> >> I would like to confirm my findings. My test platform configurations
>> >> are
>> >> follow.
>> >> Board: pcengine alix3d2
>> >> Linux kernel: 2.6.35 from linux-wireless git
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the patch
>> >> suggested by Alex.
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered load
>> >>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (two or three
>> >> antennas).
>> >
>> >
>> > _______________________________________________
>> > 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
>
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
<br>
* If your RX chainmask has >1 radio enabled, you'll always be doing<=
br>
receive-side "diversity" (which is really "combining" (=
MRC) if I<br>
understand the technology correctly on multi-radio atheros 11n cards);<br>
* If your TX chainmask has >1 radio enabled and the TX descriptor has<br=
>
the relevant chainmask bits set, you should be transmitting on both<br>
antennas regardless of the rate. I honestly haven't verified it (I'=
ve<br>
only verified that behaviour for transmitting legacy rates out of the<br>
11n chips);<br>
<br>
* For rates < MCS8 (and legacy rates) there's further TX-side tricke=
ry<br>
that can be going on which I'm not too up-to-date on. For example,<br>
some (all?) of the 11n chips allow you to optionally transmit MCS0-7<br>
using STBC. But iirc, STBC is only enabled for 1-stream TX.<br>
<br>
In short, if you've got all the radios enabled =C2=A0for RX and ath9k i=
s<br>
enabling both/all radio chains when TX'ing, I think the answer is<br>
"yes" for you. :)<br>
<br>
Adrian<br>
<br>
On 16 February 2011 22:47, Baldomero Coll <<a href=3D"mailto:baldo.ath9k=
@gmail.com">baldo.ath9k at gmail.com</a>> wrote:<br>
> I'm not sure, but I've read somewhere that by default the two =
antennas are<br>
> used.<br>
> It is true that I'm not interested in selecting the number of ante=
nnas, what<br>
> I really want is that the MIMO capability is exploited if I'm usin=
g 802.11n<br>
> HT IBSS operation mode.<br>
> Can someone confirm that by default the two antennas (spatial diversit=
y) are<br>
> being used when we create the HT IBSS network?<br>
><br>
> 2011/2/16 Mohammed Shafi <<a href=3D"mailto:shafi.ath9k@gmail.com">=
shafi.ath9k at gmail.com</a>><br>
>><br>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <<a href=3D"mai=
lto:baldo.ath9k@gmail.com">baldo.ath9k at gmail.com</a>><br>
>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > Can you please tell me how do you select one o two antennas?<=
br>
>><br>
>> I don't know why you should do that. I guess changing the tx/r=
x<br>
>> chainmask will do after it was read from eeprom.<br>
>><br>
>> ><br>
>> > I'm using a similar setting than you:<br>
>> > Linux kernel: 2.6.32-28-generic-pae.<br>
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the pat=
ch<br>
>> > suggested by<br>
>> > Alex.<br>
>> > Radio card: Ubiquiti SR71x<br>
>> ><br>
>> > Thanks in advance,<br>
>> > Baldomero<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> I would like to confirm my findings. My test platform con=
figurations<br>
>> >> are<br>
>> >> follow.<br>
>> >> Board: pcengine alix3d2<br>
>> >> Linux kernel: 2.6.35 from linux-wireless git<br>
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the=
patch<br>
>> >> suggested by Alex.<br>
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+<br>
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered =
load<br>
>> >><br>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (t=
wo or three<br>
>> >> antennas).<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > ath9k-devel mailing list<br>
>> > <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at li=
sts.ath9k.org</a><br>
>> > <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-dev=
el" target=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel<=
/a><br>
>> ><br>
>> ><br>
><br>
><br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k=
.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
</blockquote></div><br>
--002215048f672c1ad2049c7703f8--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
<br>
* If your RX chainmask has >1 radio enabled, you'll always be doing<=
br>
receive-side "diversity" (which is really "combining" (=
MRC) if I<br>
understand the technology correctly on multi-radio atheros 11n cards);<br>
* If your TX chainmask has >1 radio enabled and the TX descriptor has<br=
>
the relevant chainmask bits set, you should be transmitting on both<br>
antennas regardless of the rate. I honestly haven't verified it (I'=
ve<br>
only verified that behaviour for transmitting legacy rates out of the<br>
11n chips);<br>
<br>
* For rates < MCS8 (and legacy rates) there's further TX-side tricke=
ry<br>
that can be going on which I'm not too up-to-date on. For example,<br>
some (all?) of the 11n chips allow you to optionally transmit MCS0-7<br>
using STBC. But iirc, STBC is only enabled for 1-stream TX.<br>
<br>
In short, if you've got all the radios enabled =A0for RX and ath9k is<b=
r>
enabling both/all radio chains when TX'ing, I think the answer is<br>
"yes" for you. :)<br>
<br>
Adrian<br>
<br>
On 16 February 2011 22:47, Baldomero Coll <<a href=3D"mailto:baldo.ath9k=
@gmail.com" target=3D"_blank">baldo.ath9k at gmail.com</a>> wrote:<br>
> I'm not sure, but I've read somewhere that by default the two =
antennas are<br>
> used.<br>
> It is true that I'm not interested in selecting the number of ante=
nnas, what<br>
> I really want is that the MIMO capability is exploited if I'm usin=
g 802.11n<br>
> HT IBSS operation mode.<br>
> Can someone confirm that by default the two antennas (spatial diversit=
y) are<br>
> being used when we create the HT IBSS network?<br>
><br>
> 2011/2/16 Mohammed Shafi <<a href=3D"mailto:shafi.ath9k@gmail.com" =
target=3D"_blank">shafi.ath9k at gmail.com</a>><br>
>><br>
>> On Tue, Feb 15, 2011 at 2:35 PM, Baldomero Coll <<a href=3D"mai=
lto:baldo.ath9k@gmail.com" target=3D"_blank">baldo.ath9k at gmail.com</a>><=
br>
>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > Can you please tell me how do you select one o two antennas?<=
br>
>><br>
>> I don't know why you should do that. I guess changing the tx/r=
x<br>
>> chainmask will do after it was read from eeprom.<br>
>><br>
>> ><br>
>> > I'm using a similar setting than you:<br>
>> > Linux kernel: 2.6.32-28-generic-pae.<br>
>> > Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the pat=
ch<br>
>> > suggested by<br>
>> > Alex.<br>
>> > Radio card: Ubiquiti SR71x<br>
>> ><br>
>> > Thanks in advance,<br>
>> > Baldomero<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> I would like to confirm my findings. My test platform con=
figurations<br>
>> >> are<br>
>> >> follow.<br>
>> >> Board: pcengine alix3d2<br>
>> >> Linux kernel: 2.6.35 from linux-wireless git<br>
>> >> Driver: compat-wireless-2011-01-17 and iw-0.9.21 with the=
patch<br>
>> >> suggested by Alex.<br>
>> >> Radio card: Ubiqiti SR71a on channel 36 with HT40+<br>
>> >> Measurement tool and settings: Iperf, UDP, 100Mb offered =
load<br>
>> >><br>
>> >> Recored throughput: 50-54Mbps (one antenna); 78-80Mbps (t=
wo or three<br>
>> >> antennas).<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > ath9k-devel mailing list<br>
>> > <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_bla=
nk">ath9k-devel at lists.ath9k.org</a><br>
>> > <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-dev=
el" target=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel<=
/a><br>
>> ><br>
>> ><br>
><br>
><br>
> _______________________________________________<br>
> ath9k-devel mailing list<br>
> <a href=3D"mailto:ath9k-devel@lists.ath9k.org" target=3D"_blank">ath9k=
-devel at lists.ath9k.org</a><br>
> <a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" targe=
t=3D"_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
><br>
><br>
</blockquote></div></div></div><br>
</blockquote></div><br></div>
--0016362847b84c7571049c7ca7bc--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
interrupt earlier. For example, I send 1st frame with rate MCS 1 and 2nd
frame with MCS 2, but some time I can get hw tx interrupt for second frame
ealier than the first. I think this may relate to the aggregation. So I have
tried set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in
ath_tx_start_dma, and I find that disorder issue doesn't happen again. Also,
I find that
in the disorder case, it looks like that transmitter triggers
ath_tx_txqaddbuf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf
is triggered again and for 2nd first, and 1st. But from tx_info.status, I
find that both 1st and 2nd frame is transmitted once and successfully
received.
Moreover, the transmitter may send 1st aggregation frame with sequence from
0-31, and send 2nd aggregation frame with sequence 32-63 immediately, and
then based on the tx_info.status, transmitter send the un-acked frame in the
later frame. In this case, I mean, transmitter can send the 2nd aggregation
frame without knowing the result for the first one, is this right?
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
when the transmitter receive the hw tx interrupt, is there anything wrong or
missing? Actually, I don't quite understand how aggregation works in ath9k,
could you give some information?
Thank you for your time on this.
Best regards,
Jerry Zhao
--0016e649cdb2575291049ce47042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Dear all,<br>Good day.<br>I have got a question about disorder of hw tx int=
erupt. I am looking for your helps. Thanks in advance.<br>I am using D-link=
652 and ubuntu 10.04 as my platform.<br>I am running some tests, I set fra=
mes with an cyclic increasing rate from MCS 0 - MCS 15, it's done per f=
rame. After the transmitter sends the frame, it gets a hw tx interrupt afte=
r successful transmission or no ack.<br>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
--0016e649cdb2575291049ce47042--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
<br>_______________________________________________<br>
ath9k-devel mailing list<br>
<a href=3D"mailto:ath9k-devel@lists.ath9k.org">ath9k-devel at lists.ath9k.org<=
/a><br>
<a href=3D"https://lists.ath9k.org/mailman/listinfo/ath9k-devel" target=3D"=
_blank">https://lists.ath9k.org/mailman/listinfo/ath9k-devel</a><br>
<br></blockquote></div><br></div></div>
--bcaec53f8e215e2cfc049ce55219--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
rupt earlier. For example, I send 1st frame=A0 with rate MCS 1 and 2nd fram=
e with MCS 2, but some time I can get hw tx interrupt for second frame eali=
er than the first. I think this may relate to the aggregation. So I have tr=
ied set ATH_AMPDU_SUBFRAME_DEFAULT to 1, but that doesn't help. Then I =
tried substitute ath_tx_send_ampdu with ath_tx_send_normal in ath_tx_start_=
dma, and I find that disorder issue doesn't happen again. Also, I find =
that <br>
in the disorder case, it looks like that transmitter triggers ath_tx_txqadd=
buf for 1st then for 2nd, however, immediately ath_tx_txqaddbuf is triggere=
d again and for 2nd first, and 1st. But from tx_info.status, I find that bo=
th 1st and 2nd frame is transmitted once and successfully received.<br>
<br>Moreover, the transmitter may send 1st aggregation frame with sequence =
from 0-31, and send 2nd aggregation frame with sequence 32-63 immediately, =
and then based on the tx_info.status, transmitter send the un-acked frame i=
n the later frame. In this case, I mean, transmitter can send the 2nd aggre=
gation frame without knowing the result for the first one, is this right?<b=
r>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
hen the transmitter receive the hw tx interrupt, is there anything wrong or=
missing? Actually, I don't quite understand how aggregation works in a=
th9k, could you give some information? <br>
<br>Thank you for your time on this.<br><br>Best regards,<br>Jerry Zhao<br>
</blockquote></div><br>
--0016e659f780473917049cfe2f87--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
discarded. But for ping packet __ieee80211_parse_tx_radiotap function
returns false. Surprisingly radtap_hdr_len is getting printed to be 65535,
which I assumed will be 0 at this point.
So in function ieee80211_monitor_start_xmit(), i tried following
approaches:
1) pulling radio tap header from skb and disabling RADIOTAP flag and send
rest of skb as it is.
2) allocate a new skb of size ieee80211_hdr and assigning first 2 bytes of
skb->data to 0x08 and 0x02 and pass this skb to the called functions.
However i could not see any activity over the air. :(.
I am not using packetspammer like utlity to send packets to driver, but just
ping packets.
Any suggestion over this will be appreciated.
Thanks
-Sagar
--20cf3079bdf4c2e5cd049d932c1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, <br>For my research, I want to send the packet at a specified time. I g=
uess monitor mode is suitable for this. <br>From code it looks like in moni=
tor mode the radiotap header is parsed and discarded. But for ping packet _=
_ieee80211_parse_tx_radiotap function returns false. Surprisingly radtap_hd=
r_len is getting printed to be 65535, which I assumed will be 0 at this poi=
nt.<br>
<br>So in function=A0 ieee80211_monitor_start_xmit(), i tried following app=
roaches:<br>1) pulling radio tap header from skb and disabling RADIOTAP fla=
g and send rest of skb as it is. <br>2) allocate a new skb of size=A0 ieee8=
0211_hdr and assigning=A0 first 2 bytes of skb->data to=A0 0x08 and 0x02=
and pass this skb to the called functions.<br>
However i could not see any activity over the air. :(. <br>I am not using p=
acketspammer like utlity to send packets to driver, but just ping packets.<=
br>Any suggestion over this will be appreciated. <br><br>Thanks<br>-Sagar<b=
r>
--20cf3079bdf4c2e5cd049d932c1c--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-12-19 23:59 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-12-19 23:59 UTC (permalink / raw)
To: ath9k-devel
MIMO, but with only two spatial streams, so it should handle MCS0
through MCS15. Check the output of "iw list" for a line like the
following:
HT TX/RX MCS rate indexes supported: 0-15
It is possible for a card to support multiple spatial streams without
having support for space-time block coding.
-Brian
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
possible with the driver at this point.
As a side note, no, iwconfig should not be used for anything anymore.
//Peter
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
when ath_draintxq() is called. From ath_draintxq() point of view that
looks like a bad idea (race between CPU and DMA).
Also, that looking around "cabq_depth =3D cabq->axq_depth;" looks very
peculiar. I believe it's correct (because nobody else puts anything
into this queue and we don't care if it's shorter later on when we
drain it) but I think it would be nice with a comment.
Any thoughts? I can whip up and test a patch if there are no objections.
/Bj=F6rn
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
Like you said, it is low because both interfaces share the medium but if I don??t change the rate using iwconfig, this values or at least the first one goes down until 1,5 MBits. That??s way I wonder if there is something that keeps the rate low by the time a virtual interface is created.
Thanks for your response
Best regards
Lorna
-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 09:00:45 -0800
> Von: Ben Greear <greearb@candelatech.com>
> An: "Lorna Gonz??lez" <lorna.glez@gmx.net>
> CC: Jouni Malinen <jouni.malinen@atheros.com>, ath9k-devel at venema.h4ckr.net
> Betreff: Re: [ath9k-devel] ath9k: Virtual interface as AP
> On 11/11/2010 07:06 AM, "Lorna Gonz??lez" wrote:
> >
> > Hello
> >
> > I finally got a station an a virtual AP working on the same channel
> using the setup below. I made some test sending TCP through iperf between the
> AP and the station and the VAP to a station associated with it.
> > Using an AP operating with Ieee802.11n, an atheros AR928X and without
> virtual interfaces I get a max throughput of 50 MBits/s.
> > As soon as I start using my desired setup, the thoughput of the station
> is about 15 MBits/s... I actually need to make the rate fixed using
> iwconfig to get this max. Otherwise the traffic is sent at 1 MBit/s.
> >
> > Can someone please tell me how is the behaviour of the rate control in
> case of virtual interfaces on mac80211?
>
> Can you give a more detailed description/diagram of your virtual AP setup
> and
> network throughput test? It sounds like you are using the same radio as
> AP
> and STA? If so, then of course you are going to get less bandwidth on the
> VIFS because they have to share the radio.
>
> I'm not sure it should drop all the way to 15Mbps, though. We haven't
> done a lot of throughput
> testing yet, but if we use two STA vifs on the ath9k box connected to an
> 80211n AP (trendnet),
> then we can set a max of about 9Mbps tx + rx across each STA (the STAs are
> sending to each other).
> That is around 40Mbps total tx + rx across the radio.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
Like you said, it is low because both interfaces share the medium but if I don??t change the rate using iwconfig, this values or at least the first one goes down until 1,5 MBits. That??s way I wonder if there is something that keeps the rate low by the time a virtual interface is created.
Thanks for your response
Best regards
Lorna
-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 09:00:45 -0800
> Von: Ben Greear <greearb@candelatech.com>
> An: "Lorna Gonz??lez" <lorna.glez@gmx.net>
> CC: Jouni Malinen <jouni.malinen@atheros.com>, ath9k-devel at venema.h4ckr.net
> Betreff: Re: [ath9k-devel] ath9k: Virtual interface as AP
> On 11/11/2010 07:06 AM, "Lorna Gonz??lez" wrote:
> >
> > Hello
> >
> > I finally got a station an a virtual AP working on the same channel
> using the setup below. I made some test sending TCP through iperf between the
> AP and the station and the VAP to a station associated with it.
> > Using an AP operating with Ieee802.11n, an atheros AR928X and without
> virtual interfaces I get a max throughput of 50 MBits/s.
> > As soon as I start using my desired setup, the thoughput of the station
> is about 15 MBits/s... I actually need to make the rate fixed using
> iwconfig to get this max. Otherwise the traffic is sent at 1 MBit/s.
> >
> > Can someone please tell me how is the behaviour of the rate control in
> case of virtual interfaces on mac80211?
>
> Can you give a more detailed description/diagram of your virtual AP setup
> and
> network throughput test? It sounds like you are using the same radio as
> AP
> and STA? If so, then of course you are going to get less bandwidth on the
> VIFS because they have to share the radio.
>
> I'm not sure it should drop all the way to 15Mbps, though. We haven't
> done a lot of throughput
> testing yet, but if we use two STA vifs on the ath9k box connected to an
> 80211n AP (trendnet),
> then we can set a max of about 9Mbps tx + rx across each STA (the STAs are
> sending to each other).
> That is around 40Mbps total tx + rx across the radio.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-09-24 14:53 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-09-24 14:53 UTC (permalink / raw)
To: ath9k-devel
ath9k, I read.
The mac filtering has not implemented at ath9k or not?
I would like to know how it is about the status.
Any comments will be very appreciated of..
-
mason
--0016e68e92891791f80497724c8a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>From the openwrt site, mac address filtering has not implemented yet a=
t ath9k, I read.</div>
<div>The mac filtering has not implemented at ath9k or not? </div>
<div>=A0</div>
<div>I would like to know how it is about the status.</div>
<div>=A0</div>
<div>Any comments will be very appreciated of..</div>
<div>-</div>
<div>mason</div>
<div><br clear=3D"all"><br>=A0</div>
--0016e68e92891791f80497724c8a--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-07-23 10:05 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-07-23 10:05 UTC (permalink / raw)
To: ath9k-devel
mesh point. We have not yet figured out why the mesh interface is removed a=
nd reset to an interface of type NL80211_IFTYPE_STATION.
Regards
Abhijeet
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof at gmail.com]
Sent: Wednesday, July 28, 2010 9:23 PM
To: Abhijeet Chandran
Cc: ath9k-devel at lists.ath9k.org
Subject: Re: [ath9k-devel] ath9k mesh point not emitting beacons
On Wed, Jul 28, 2010 at 7:19 AM, Abhijeet Chandran <Abhijeet.Chandran@arice=
nt.com> wrote:
> Hi
> We have a problem that we have configured a mesh point for the first
> time and it does not seem to start emitting beacons as soon as it comes=
up.
> The card we are using is ath 9220
> We brought mesh point up , ex:
> # iw phy phy0 interface add mesh type mp mesh_id mymesh # ifconfig
> mesh up
>
> Through tracing in the kernel module mac80211 it appears that a
> callback function ieee80211_open is called with type mesh point as
> soon as the above commands are executed.
> However it is immediately followed by the callback function
> ieee80211_stop (usually called when the mesh point is brought down) ,
> following which the meshpoint related sdata is flushed .
> Another question that we have is that do we need to enable scanning
> for the mesh point to emit beacons/probes?
>
> We have used the simulator mac80211_hwsim before in which beacons are
> emitted as soon as the mesh point comes up.In the simulator don't need
> to start scanning on the mesh point.
> We'd really appreciate if somone can help us out here.
Known issue no one has yet looked into:
https://bugzilla.kernel.org/show_bug.cgi?id=3D14187
It should start beaconing if you issue a scan.
Luis
"DISCLAIMER: This message is proprietary to Aricent and is intended solely =
for the use of the individual to whom it is addressed. It may contain privi=
leged or confidential information and should not be circulated or used for =
any purpose other than for what it is intended. If you have received this m=
essage in error, please notify the originator immediately. If you are not t=
he intended recipient, you are notified that you are strictly prohibited fr=
om using, copying, altering, or disclosing the contents of this message. Ar=
icent accepts no responsibility for loss or damage arising from the use of =
the information transmitted by this email including damage from virus."
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-03-25 17:02 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-03-25 17:02 UTC (permalink / raw)
To: ath9k-devel
the production level yet, although my chipset is AR9160.
One issue is after a long time running the traffic maybe stopped
occasionally. Another one is it seems have some compatibility issue
with Intel chipset. They have troubled me a lot.
-Daniel
2010/5/6 Alan <lameventanas@gmail.com>:
> Can anybody give me a status report on the current state of ath9k?
> I know the one shipped with kernel 2.6.33.2 is working without major
> issues with 802.11g because I'm using it.
> But what is the status of 802.11n?
> What is the status of multiple ssids? Can I configure more than one in
> master mode?
>
> I'm asking because I'm about to set up an AP to be considered
> production level, and having 802.11n and two ssids (one open for
> guests, one encrypted for intended users) would be great.
> Should I stick to the version provided with the current kernel or
> should I use compat-wireless?
> Should I wait for the next kernel to be released with a major
> breakthrough in ath9k? (judging by the mailing list activity, it seems
> so).
> Hardware is AR5008 (dual band, 3 antennas).
>
> Thanks a lot!
>
> Alan
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2010-03-25 17:02 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2010-03-25 17:02 UTC (permalink / raw)
To: ath9k-devel
different behaviour and if the ls and error message were done on the same
machine the file is actually there.
I have not read the code, so I am more speculating, but could some other error
in the firmware loading be falsely evaluated as fw not found?
-Stefan
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
wlan0: STA 00:23:4d:b7:98:e8 IEEE 802.11: authenticated
MGMT
mgmt::assoc_req
association request: STA=00:23:4d:b7:98:e8 capab_info=0x431 listen_interval=10
handle_assoc STA 00:23:4d:b7:98:e8 - no HT, num of non-HT stations 1
hostapd_ht_operation_update current operation mode=0x0
hostapd_ht_operation_update new operation mode=0x13 changes=2
new AID 1
wlan0: STA 00:23:4d:b7:98:e8 IEEE 802.11: association OK (aid 1)
This is weird, since it chooses non-HT mode for the STA.
Am not sure why this is happening. Are you running the latest git
code for all 3 cases ?
* hostapd
* ath9k - AP side
* ath9k - STA side
Also, can you paste your hostapd.conf and wpa_supplicant's configuration file here ?
Sujith
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
required. You can think of my previous phrase as possible feature
request, or a question of "how to?" type. I know that borh SLI nvidia
cards are sharing IRQ 16 as well as atheros based dlink wireless card.
(if it's not difficult, please look into my previous emails, they will
have dmesg and lspci -vv details, otherwise just ask me for more
details, i shall provide them)
>> Obviously, there is not much point of asking Nvidia to do it, since
>> those behemoth's won't do anything for sure, since their current driver
>> (i dont use it for that matter)release is pretty banged up...
>>
>
> If you do most of the work finding how to work around the problem, and
> it turns out that something could be improved in free software, then
> maybe your patch will be applied.
>
> If you expect others to question you about the symptoms, then suggest
> patches and push them to the kernel, that's not going to happen.
>
Symptoms are simple with nvidia module and ath9k loaded at the same time
connection degrades over short period of time and after several minutes
disappears all together. I suspect it could be IRQ sharing or other I/O
or similar hardware conflict, since both of them work pretty well while
other devices driver is not loaded. no unusual messages in dmesg.
Machine may hang and even if in terminal(not in X), machine hangs
completely without providing a bit of information, not even oops message.
>
>> Another question, my Access Point and PCI wifi card are from same
>> manufacturer. AP is set to B,G,N auto mode, but my card only connects to
>> it using G mode, which is not why i bought it in the first place. Why is
>> this happening? i am pretty much only user to network myself 99% of
>> time. i tried to force it to use N mode, it could detect it, but it
>> couldn't connect.
>>
>
> I suggest that you actually show what commands you run and what they
> return, not just your interpretation.
>
> In case you are hitting the stuck scan bug, try setting the channel with
> iwconfig instead of loading and unloading modules.
>
>
Commands are simple as well.
ip link set wlan0 up
iwconfig wlan0 essid dlink
they don't give any errors and don't show any unusual messages in dmesg
thats pretty much it. (no wireless security used at all)
N.B.
What i really don't want is any kind of aggression towards to me.
Coding something for a community, even advanced one requires certain
amount of tolerance, as ANY normal communication.
I am not perfect tester(i just attempt to become better one), i
understand that, but i am not coming after difficult day, working with
difficult people to submit difficult issues(which other people may
prefer to ignore all together or for those reasons abandon Linux and go
to MS products, i have seeing enough of those). I am not going to become
more enthusiastic by being referred to "RTFM noob" like documents, who
nearly imply my stupidity.
So far I was very happy in this list, and even my lack of technical
knowledge did not spoil my attitude towards this list. I want it to stay
that way. Ignoring problems of people who lack technical knowledge on
matter is path to nowhere. I seriously, don't want to start flame wars,
i am not naive and I don't ask for apologies. I just ask one thing,
please be tolerant, everyone can have a shi*** day, that includes you
and me!
Dmitri
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
rev. 2.1 now), a single function device may _only_ provide an interrupt
request on pin A and no others. Pins B-D only have meaning for multi-
function devices.
> > There seems to be some kind of race. If I have both the AR5416 and
> > HPT371N, loaded, and after the board has booted(everything is
> > configured), the "IRQ X Nobody cared" never occurs. If i remove
> > AR5416 mini-pci, I also never get the "IRQ X Nobody cared".
>
> You would have to investigate a) which chip generates the bogus IRQ,
> and b) how to clear it. Then you can clear the IRQ in the platform code,
> or using a PCI quirk code if it's not related to the platform.
It sounds to me like the driver is prodding the chip, and it's generating
an interrupt but the driver hasn't yet registered its handler. If so,
that's really a driver bug needing to be fixed.
Normally you get a backtrace when a "nobody cared" message is issued -
this should tell you which driver is probably the cause.
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
(usually link quality warries between 60-70)
Machine started to suffer with disconnects.
Below is fuller log.
1249488753.366831: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249488753.366985: wlan0 (phy #0): disconnected (local request)
1249488848.660029: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249488848.668387: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249488848.668489: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249488918.365949: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249488918.365996: wlan0 (phy #0): disconnected (local request)
1249489968.542997: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249489968.551472: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249489968.551576: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249489985.366774: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249489985.366850: wlan0 (phy #0): disconnected (local request)
1249490017.023313: wlan0 (phy #0): auth 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249490017.031578: wlan0 (phy #0): assoc 00:1e:58:b4:f6:83 ->
00:22:b0:bc:1e:1e status: 0: Successful
1249490017.031616: wlan0 (phy #0): connected to 00:1e:58:b4:f6:83
1249490039.365052: wlan0 (phy #0): deauth 00:22:b0:bc:1e:1e ->
00:1e:58:b4:f6:83 reason 4: Disassociated due to inactivity
1249490039.365096: wlan0 (phy #0): disconnected (local request)
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
// ?? nice pointer arithmetic... should use PTR_ALIGN here?
off = ((unsigned long) skb->data) % sc->cachelsz;
if (off != 0)
skb_reserve(skb, sc->cachelsz);
in other words, when we allocate, round up to the next cache line
greater than IEEE80211_MAX_LEN, then add an extra cache_line-1
bytes so we can map starting from it.
dev_alloc_skb already does some padding and alignment, and it's
configurable on a per-arch basis (though looks like only powerpc
sets it to L1 cache size, everywhere else it's 32 bytes.)
I guess if someone is bored some benchmarking would be useful.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
is=20
yet, but I wonder if anyone else has solved this with a vendor extension?
--=20
Tim Smith <Tim.Smith@csr.com>
Member of the CSR plc group of companies. CSR plc registered in England and=
Wales, registered number 4187346, registered office Churchill House, Cambr=
idge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-27 19:01 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-27 19:01 UTC (permalink / raw)
To: ath9k-devel
should be automagically functional on the kernel I'm on, assuming the
hardware is compatible?
So that's where I stand now. I'm probably not asking the right
questions or providing enough information - please let me know any
tests you'd like me to run or further information I can give.
Thanks!
Andrew
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-02-15 8:49 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-02-15 8:49 UTC (permalink / raw)
To: ath9k-devel
am not sure if this is related to AP mode in ath9k.
Sujith
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-01-04 17:33 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-01-04 17:33 UTC (permalink / raw)
To: ath9k-devel
---------------------------------------------------------------------------=
------------------------
Reason Meaning
0 Reserved
1 Unspecified reason
2 Previous authentication no longer valid
3 Deauthenticated because sending STA is leaving (or has left) IBSS or ESS
4 Disassociated due to inactivity
5 Disassociated because AP is unable to handle all currently associated STA=
s
6 Class 2 frame received from nonauthenticated STA
7 Class 3 frame received from nonassociated STA
8 Disassociated because sending STA is leaving (or has left) BSS
9 STA requesting (re)association is not authenticated with responding STA
10 Disassociated because the information in the Power Capability element is=
unacceptable
11 Disassociated because the information in the Supported Channels element =
is unacceptable
12 Reserved
13 Invalid information element, i.e., an information element defined in thi=
s standard for
which the content does not meet the specifications in Clause 7
14 Message integrity code (MIC) failure
15 4-Way Handshake timeout
16 Group Key Handshake timeout
17 Information element in 4-Way Handshake different from (Re)Association Re=
quest/Probe
Response/Beacon frame
18 Invalid group cipher
19 Invalid pairwise cipher
20 Invalid AKMP
21 Unsupported RSN information element version
22 Invalid RSN information element capabilities
23 IEEE 802.1X authentication failed
24 Cipher suite rejected because of the security policy
25=E2=80=9331 Reserved
32 Disassociated for unspecified, QoS-related reason
33 Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA
34 Disassociated because excessive number of frames need to be acknowledged=
, but are not
acknowledged due to AP transmissions and/or poor channel conditions
35 Disassociated because STA is transmitting outside the limits of its TXOP=
s
36 Requested from peer STA as the STA is leaving the BSS (or resetting)
37 Requested from peer STA as it does not want to use the mechanism
38 Requested from peer STA as the STA received frames using the mechanism f=
or which a
setup is required
39 Requested from peer STA due to timeout
45 Peer STA does not support the requested cipher suite
46=E2=80=9365 Reserved
535 Reserved
---------------------------------------------------------------------------=
------------------------
> Jan 30 23:31:37 ws1 dhcpcd[23630]: wlan0: carrier lost
> Jan 30 23:31:37 ws1 wpa_cli: interface wlan0 DISCONNECTED
> Jan 30 23:31:38 ws1 [ 9444.502016] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:38 ws1 dhcpcd[23630]: wlan0: received SIGTERM, stopping
> Jan 30 23:31:38 ws1 [ 9444.703019] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:38 ws1 [ 9444.902015] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:39 ws1 [ 9445.102013] wlan0: association with AP f51a5ea8 ti=
med out
> Jan 30 23:31:40 ws1 [ 9445.990865] wlan0: authenticate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9445.998616] wlan0: authenticate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9446.000416] wlan0: authenticated
> Jan 30 23:31:40 ws1 [ 9446.000421] wlan0: associate with AP f51a5ea8
> Jan 30 23:31:40 ws1 [ 9446.003209] wlan0: RX AssocResp from f029002a (cap=
ab=3D0x411 status=3D0 aid=3D2)
> Jan 30 23:31:40 ws1 [ 9446.003214] wlan0: associated
> Jan 30 23:31:40 ws1 wpa_cli: interface wlan0 CONNECTED
> Jan 30 23:31:41 ws1 dhcpcd[24556]: wlan0: dhcpcd 4.0.7 starting
> Jan 30 23:31:41 ws1 dhcpcd[24556]: wlan0: broadcasting for a lease
> Jan 30 23:31:42 ws1 dhcpcd[24556]: wlan0: offered 192.168.1.100 from 192.=
168.1.1
> Jan 30 23:31:42 ws1 dhcpcd[24556]: wlan0: checking 192.168.1.100 is avail=
able on attached networks
> Jan 30 23:31:47 ws1 dhcpcd[24556]: wlan0: acknowledged 192.168.1.100 from=
192.168.1.1
Yeap everything looks good except your AP doesn't seem to like you to be id=
le
for more than 8 minutes, that is if no traffic was going on in between your
dhcp negotiation and your disassoc.
> Used Hardware :
> My Router: Linksys WRT 160v2 Standard: 80211N. maybe a broadcom Chip
> My Wlan Card: Linksys WMP 300N v2 Standard: 80211N. AR5416 Chip
>=20
> But at all it works. Today i have set the router that he only uses the 80=
211N Standard and it works with my Wireless Card.
I don't see any issues above. Please see:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
> !!!!!!!!!!!!!!Big Thanks for your great drivers and packages!!!!!!!!!!!!!=
!
>=20
> Well night
>=20
> kind regards
>=20
> Alexander Bartha
Luis
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2009-01-04 17:33 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2009-01-04 17:33 UTC (permalink / raw)
To: ath9k-devel
802.11n chips. Is any one has ath9k or similar driver for linux 2.6.21? I
saw the ath9k driver in 2.6.28. It is higly dependent on linux 2.6.28
kernel. Anyone has PCI/PCIe driver supporting any 802.11n chips for 2.6.21?
any sugestions welcome!!
thanks,
MB.
--000e0cd15718164b2c0462176409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hi All,</div>
<div> </div>
<div>From Linux 2.6.28 onwards ath9k driver is part of the linux and suppor=
ts 802.11n chips. Is any one has ath9k or similar driver for linux 2.6.21? =
I saw the ath9k driver in 2.6.28. It is higly dependent on linux 2.6.28 ker=
nel. Anyone has PCI/PCIe driver supporting any 802.11n chips for 2.6.21?</d=
iv>
<div> </div>
<div>any sugestions welcome!!</div>
<div> </div>
<div>thanks,</div>
<div>MB.</div>
--000e0cd15718164b2c0462176409--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
how can i else monitor the problem?
On Mon, 13 Oct 2008 15:14:37 -0700
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> On Sat, Oct 11, 2008 at 6:46 AM, Alexander Petukhov <al_petukhov@mail.ru> wrote:
> > Hello,
> >
> > first of all - many thanks to you guys for developing this driver!
> > i'm owning D-Link DWA-547 card (Atheros Communications Inc. AR5416 802.11abgn Wireless PCI Adapter (rev 01)), and i'm on Debian Lenny\Sid.
> > My current kernel is 2.6.27 released not long ago, and i have one problem - connection periodicly losts, i.e. i can't even ping router i'm associated with. After some time (5-40 seconds) all becomes fine again. This happents one time for an hour or so on. Interface is not down when this problem occures, gnome applet shows it is up and have a normal(~90%) signal strength. Now i'm using wpa on router and wpasupplicant package on debian box(without any network-managers), but this still happents even without any encryption used.
> > Would be glad to help in testing.
>
> Can you do this:
>
> sudo dmesg -c > /dev/null
>
> Then connect to the AP, every now and then do this:
>
> sudo dmesg -c | tee log
>
> Keep doing this routinely, it'll keep overwriting the data from the
> kernel ring buffer to the log but you will also be able to see it on
> the screen. Once you see the strange disconnect issue appear please
> play more careful attention to what comes up and send us the log. To
> be safe you can just use 'tee -a' to append to the log all the
> information.
>
> Anyway please send us the log.
>
> Luis
>
--
Best regards,
Alexander Petukhov <al_petukhov@mail.ru>
--Multipart=_Wed__15_Oct_2008_01_31_40_+0400_4IyuS81Mmz9KfB9=
Content-Type: application/octet-stream;
name="log"
Content-Disposition: attachment;
filename="log"
Content-Transfer-Encoding: base64
WzEzNzIxLjMxNjg1Ml0gd2xhbjA6IGF1dGhlbnRpY2F0ZSB3aXRoIEFQIDAwOjIxOjkxOjA5OmY5
OjNiClsxMzcyMS4zMTgyODJdIHdsYW4wOiBhdXRoZW50aWNhdGVkClsxMzcyMS4zMTgzMjJdIHds
YW4wOiBhc3NvY2lhdGUgd2l0aCBBUCAwMDoyMTo5MTowOTpmOTozYgpbMTM3MjEuMzIxODU5XSB3
bGFuMDogUlggQXNzb2NSZXNwIGZyb20gMDA6MjE6OTE6MDk6Zjk6M2IgKGNhcGFiPTB4NDMxIHN0
YXR1cz0wIGFpZD0xKQpbMTM3MjEuMzIxODk3XSB3bGFuMDogYXNzb2NpYXRlZApbMTM3MjEuMzIy
MDgzXSB3bGFuMCAoV0UpIDogV2lyZWxlc3MgRXZlbnQgdG9vIGJpZyAoMzIwKQpbMTk0MjQuNDc3
OTU5XSBzZCA0OjA6MDowOiBbc2RhXSAxMDAzNTIwIDUxMi1ieXRlIGhhcmR3YXJlIHNlY3RvcnMg
KDUxNCBNQikKWzE5NDI0LjQ3ODgzMV0gc2QgNDowOjA6MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBp
cyBvZmYKWzE5NDI0LjQ3ODgzNF0gc2QgNDowOjA6MDogW3NkYV0gTW9kZSBTZW5zZTogMDMgMDAg
MDAgMDAKWzE5NDI0LjQ3ODgzNV0gc2QgNDowOjA6MDogW3NkYV0gQXNzdW1pbmcgZHJpdmUgY2Fj
aGU6IHdyaXRlIHRocm91Z2gKWzE5NDI0LjQ3OTcwMF0gc2QgNDowOjA6MDogW3NkYV0gMTAwMzUy
MCA1MTItYnl0ZSBoYXJkd2FyZSBzZWN0b3JzICg1MTQgTUIpClsxOTQyNC40ODA3MDBdIHNkIDQ6
MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsxOTQyNC40ODA3MDJdIHNkIDQ6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAzIDAwIDAwIDAwClsxOTQyNC40ODA3MDRdIHNkIDQ6MDow
OjA6IFtzZGFdIEFzc3VtaW5nIGRyaXZlIGNhY2hlOiB3cml0ZSB0aHJvdWdoClsxOTQyNC40ODA3
MDVdICBzZGE6IHNkYTEKWzE5NDI0Ljg1Njc4Nl0gRkFUOiB1dGY4IGlzIG5vdCBhIHJlY29tbWVu
ZGVkIElPIGNoYXJzZXQgZm9yIEZBVCBmaWxlc3lzdGVtcywgZmlsZXN5c3RlbSB3aWxsIGJlIGNh
c2Ugc2Vuc2l0aXZlIQpbMTk1MjguMDE4MDczXSBCdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBz
ZGExLCBsb2dpY2FsIGJsb2NrIDUyMwpbMTk1MjguMDE4MDc3XSBsb3N0IHBhZ2Ugd3JpdGUgZHVl
IHRvIEkvTyBlcnJvciBvbiBzZGExClsxOTUyOC4wMTgwNzldIEJ1ZmZlciBJL08gZXJyb3Igb24g
ZGV2aWNlIHNkYTEsIGxvZ2ljYWwgYmxvY2sgNTI0ClsxOTUyOC4wMTgwODBdIGxvc3QgcGFnZSB3
cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIHNkYTEKWzE5NTI4LjAxODA4Ml0gQnVmZmVyIEkvTyBl
cnJvciBvbiBkZXZpY2Ugc2RhMSwgbG9naWNhbCBibG9jayA1MjUKWzE5NTI4LjAxODA4M10gbG9z
dCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3Igb24gc2RhMQpbMTk1MjguMDE4MDg0XSBCdWZm
ZXIgSS9PIGVycm9yIG9uIGRldmljZSBzZGExLCBsb2dpY2FsIGJsb2NrIDUyNgpbMTk1MjguMDE4
MDg2XSBsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBlcnJvciBvbiBzZGExClsxOTUyOC4wMTgw
ODddIEJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIHNkYTEsIGxvZ2ljYWwgYmxvY2sgNTI3Clsx
OTUyOC4wMTgwODhdIGxvc3QgcGFnZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIHNkYTEKWzE5
NTI4LjAxODA5MV0gQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2Ugc2RhMSwgbG9naWNhbCBibG9j
ayA1MjgKWzE5NTI4LjAxODA5Ml0gbG9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3Igb24g
c2RhMQpbMTk1MjguMDE4MDk0XSBCdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBzZGExLCBsb2dp
Y2FsIGJsb2NrIDUyOQpbMTk1MjguMDE4MDk1XSBsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBl
cnJvciBvbiBzZGExClsxOTUyOC4wMTgwOTZdIEJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIHNk
YTEsIGxvZ2ljYWwgYmxvY2sgNTMwClsxOTUyOC4wMTgwOTddIGxvc3QgcGFnZSB3cml0ZSBkdWUg
dG8gSS9PIGVycm9yIG9uIHNkYTEK
--Multipart=_Wed__15_Oct_2008_01_31_40_+0400_4IyuS81Mmz9KfB9=--
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-10-14 11:50 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-10-14 11:50 UTC (permalink / raw)
To: ath9k-devel
computer) I get a stable stream at >4MBps.
Eirik
^ permalink raw reply [flat|nested] 96+ messages in thread
* No subject
@ 2008-07-28 4:41 bogus
0 siblings, 0 replies; 96+ messages in thread
From: bogus @ 2008-07-28 4:41 UTC (permalink / raw)
To: ath9k-devel
Connectivtiy is lost after Group rekeying is done. The keytype
maintained by ath9k is reset when group key is updated. Though
sc_keytype can be reset only for broadcast key the proper fix
would be to use mac80211 provided key type from txinfo during
xmit and get rid of sc_keytype from ath9k ath_softc.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
---
drivers/net/wireless/ath9k/core.h | 1 -
drivers/net/wireless/ath9k/main.c | 3 ---
drivers/net/wireless/ath9k/xmit.c | 6 +++---
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath9k/core.h b/drivers/net/wireless/ath9k=
/core.h
index b66de29..e8ccbe4 100644
--- a/drivers/net/wireless/ath9k/core.h
+++ b/drivers/net/wireless/ath9k/core.h
@@ -976,7 +976,6 @@ struct ath_softc {
u32 sc_keymax; /* size of key cache */
DECLARE_BITMAP(sc_keymap, ATH_KEYMAX); /* key use bit map */
u8 sc_splitmic; /* split TKIP MIC keys */
- int sc_keytype;
/* RX */
struct list_head sc_rxbuf;
diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k=
/main.c
index 1ba1800..aca893a 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -204,8 +204,6 @@ static int ath_key_config(struct ath_softc *sc,
if (!ret)
return -EIO;
- if (mac)
- sc->sc_keytype =3D hk.kv_type;
return 0;
}
@@ -1507,7 +1505,6 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
case DISABLE_KEY:
ath_key_delete(sc, key);
clear_bit(key->keyidx, sc->sc_keymap);
- sc->sc_keytype =3D ATH9K_CIPHER_CLR;
break;
default:
ret =3D -EINVAL;
diff --git a/drivers/net/wireless/ath9k/xmit.c b/drivers/net/wireless/ath9k=
/xmit.c
index 3fc6641..2592905 100644
--- a/drivers/net/wireless/ath9k/xmit.c
+++ b/drivers/net/wireless/ath9k/xmit.c
@@ -239,11 +239,11 @@ static int ath_tx_prepare(struct ath_softc *sc,
txctl->keyix =3D tx_info->control.hw_key->hw_key_idx;
txctl->frmlen +=3D tx_info->control.icv_len;
- if (sc->sc_keytype =3D=3D ATH9K_CIPHER_WEP)
+ if (tx_info->control.hw_key->alg =3D=3D ALG_WEP)
txctl->keytype =3D ATH9K_KEY_TYPE_WEP;
- else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_TKIP)
+ else if (tx_info->control.hw_key->alg =3D=3D ALG_TKIP)
txctl->keytype =3D ATH9K_KEY_TYPE_TKIP;
- else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_AES_CCM)
+ else if (tx_info->control.hw_key->alg =3D=3D ALG_CCMP)
txctl->keytype =3D ATH9K_KEY_TYPE_AES;
}
--
1.5.5
--opJtzjQTFsWo+cga
Content-Type: text/x-diff; charset="us-ascii"
Content-Disposition: attachment; filename="connectivity.patch"
^ permalink raw reply related [flat|nested] 96+ messages in thread
end of thread, other threads:[~2016-11-19 18:31 UTC | newest]
Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-19 18:31 No subject bogus
-- strict thread matches above, loose matches on Subject: below --
2016-11-19 18:31 bogus
2016-11-19 18:31 bogus
2016-11-19 18:31 bogus
2016-06-13 6:24 bogus
2016-06-13 6:24 bogus
2016-02-09 7:29 bogus
2015-11-16 16:13 bogus
2015-10-12 17:26 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2014-09-13 19:40 bogus
2013-09-15 9:49 bogus
2013-09-15 9:49 bogus
2013-09-15 9:49 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-04-03 10:31 bogus
2013-01-16 21:46 bogus
2013-01-16 21:46 bogus
2012-11-08 9:33 bogus
2012-05-25 15:26 bogus
2012-05-25 15:26 bogus
2012-04-05 7:54 bogus
2012-04-05 7:54 bogus
2012-02-27 5:00 bogus
2012-02-27 5:00 bogus
2012-02-27 5:00 bogus
2012-01-15 8:24 bogus
2011-11-12 14:39 bogus
2011-11-12 14:39 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-08-05 3:08 bogus
2011-06-04 23:16 bogus
2011-06-04 23:16 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2011-04-07 5:55 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-12-19 23:59 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-09-24 14:53 bogus
2010-07-23 10:05 bogus
2010-03-25 17:02 bogus
2010-03-25 17:02 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-27 19:01 bogus
2009-02-15 8:49 bogus
2009-01-04 17:33 bogus
2009-01-04 17:33 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-10-14 11:50 bogus
2008-07-28 4:41 bogus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).