Having has no luck with an old rc6 version (basically all plink
packets were getting lost), I upgraded to the newest git (rc8) however
now when I run iw dev mesh0 station sump I don't see a single other
mesh point. This would imply that presumably beaconing is broken?
Does anyone know a revision for which ath5k is properly working? I am
yet to find one that works on my system.
Cheers
Keir
Hi Keir. What type of Atheros-based card are you using? How many
antennas do you have connected? If I understand things correctly, the
PCU code regression (with respect to mesh and maybe AP and IBSS) has
to do with having one antenna hooked up when your hardware also has an
AUX antenna connector. If you have only one antenna, can you please
plug in a second one and try again (before and after the commit in
question)? I will try to do the same test here. More details from
Nick were posted here:
http://marc.info/?l=linux-wireless&m=122771338021489&w=2
On Tue, Dec 16, 2008 at 8:07 AM, Keir <[email protected]> wrote:
> I've been working on the commit previous to the PCU code breakage
> (8485b7f773a8e9883e0165273940f16a086eba2b), but I'm still having
> problems (beaconing is working, but links are rarely established, most
> of the time to packets get through).
>
> Cheers
>
> Keir
>
> 2008/12/16 Steve Brown <[email protected]>:
>> Keir wrote:
>>>
>>> Having has no luck with an old rc6 version (basically all plink
>>> packets were getting lost), I upgraded to the newest git (rc8) however
>>> now when I run iw dev mesh0 station sump I don't see a single other
>>> mesh point. This would imply that presumably beaconing is broken?
>>>
>>> Does anyone know a revision for which ath5k is properly working? I am
>>> yet to find one that works on my system.
>>>
>>> Cheers
>>>
>>> Keir
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Beaconing seems broken by Update PCU code
>> dd1c9abd167de9bb9457a57694a1ab5e5801a0c1. After this patch, beacon debug
>> says beacons sent, but sniffer sees none.
>>
>> A snapshot of ath5k prior to this and git 12/10
>> (b6d06c9669f27db31a0317fc98fedc8ff1ba4822) works for me with hostapd/wpa.
>> It's been running for the past few days.
>>
>> Mesh beaconing also works. I didn't test two nodes; I only sniffed the
>> beacons.
>>
>> I had to comment out 5GHz in caps.c because of too many channels. It's a
>> nl80211 buffer size problem that's been discussed.
>>
>> Steve
>>
>>
>>
>
--
Andrey Yurovsky
cozybit Inc.
On Thu, Dec 18, 2008 at 9:00 AM, Steve Brown <[email protected]> wrote:
> I did a binary chop on the pcu patch. Reverting this part of the patch
> restores ap and mesh beaconing. I've no idea why.
>
> 77: + else
> 78: + AR5K_REG_ENABLE_BITS(ah, AR5K_CFG,
> AR5K_CFG_ADHOC);
Hmm, that looks exactly backwards, shouldn't it be DISABLE_BITS
(and ENABLE_BITS in the adhoc case?)
I think it's supposed to be 0 for AP/STA and 1 for IBSS.
--
Bob Copeland %% http://www.bobcopeland.com
On Fri, Dec 19, 2008 at 3:18 PM, Steve Brown <[email protected]> wrote:
> If I revert this part of the pcu patch, the "queue 7" messages go away.
> Beacons remain.
>
> - ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
> + /* When in AP mode zero timer0 to start TSF */
> + if (ah->ah_op_mode == NL80211_IFTYPE_AP)
> + ath5k_hw_reg_write(ah, 0, AR5K_TIMER0);
> + else
> + ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
So you're talking about AP mode and not mesh right (otherwise above code
wouldn't make a difference)? As in the HAL we do want to write 0 there.
There's probably some other issue with setup of beacon timers.
--
Bob Copeland %% http://www.bobcopeland.com
On Mon, Dec 22, 2008 at 5:29 PM, Steve Brown <[email protected]> wrote:
> Should I submit a patch for the AR5K_CFG_ADHOC enable/disable bug? With it
> fixed, at least the ap and mesh problems are exposed. Maybe somebody can see
> what's wrong.
Yeah, if you don't mind putting together a patch for that part, that'd be
great. I doubt anyone would disagree with it.
--
Bob Copeland %% http://www.bobcopeland.com
I've been working on the commit previous to the PCU code breakage
(8485b7f773a8e9883e0165273940f16a086eba2b), but I'm still having
problems (beaconing is working, but links are rarely established, most
of the time to packets get through).
Cheers
Keir
2008/12/16 Steve Brown <[email protected]>:
> Keir wrote:
>>
>> Having has no luck with an old rc6 version (basically all plink
>> packets were getting lost), I upgraded to the newest git (rc8) however
>> now when I run iw dev mesh0 station sump I don't see a single other
>> mesh point. This would imply that presumably beaconing is broken?
>>
>> Does anyone know a revision for which ath5k is properly working? I am
>> yet to find one that works on my system.
>>
>> Cheers
>>
>> Keir
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Beaconing seems broken by Update PCU code
> dd1c9abd167de9bb9457a57694a1ab5e5801a0c1. After this patch, beacon debug
> says beacons sent, but sniffer sees none.
>
> A snapshot of ath5k prior to this and git 12/10
> (b6d06c9669f27db31a0317fc98fedc8ff1ba4822) works for me with hostapd/wpa.
> It's been running for the past few days.
>
> Mesh beaconing also works. I didn't test two nodes; I only sniffed the
> beacons.
>
> I had to comment out 5GHz in caps.c because of too many channels. It's a
> nl80211 buffer size problem that's been discussed.
>
> Steve
>
>
>
On Thu, Dec 18, 2008 at 4:02 PM, Steve Brown <[email protected]> wrote:
> Lots of these however:
> Dec 18 15:53:20 fl-ws kernel: ath5k phy23: beacon queue 7 didn't stop?
Can you change the if statement that prints that in ath5k_beacon_send() in
base.c to capture the return value? i.e.:
int err;
...
err = ath5k_hw_stop_tx_dma(ah, sc->bhalq);
if (unlikely(err)) {
ATH5K_WARN(... "...didn't stop? %d\n", sc->bhalq, err);
}
> If I make the same change to the current git, still no beacons. But, the
> "queue 7" msgs persist.
Not sure, I was about to blame ath5k_configure_filter() but I see it does
turn on the beacons for mesh.
--
Bob Copeland %% http://www.bobcopeland.com
Keir wrote:
> Tried this, and I'm getting slightly odd results. The two nodes
> running with these lines commented out can see the node whose code is
> previous to the PCU patch, but they cant see each other. Also the
> other node can see both of them... very strange.
>
> Cheers
>
> Keir
>
> 2008/12/17 Nick Kossifidis <[email protected]>:
>
>> 2008/12/16 Andrey Yurovsky <[email protected]>:
>>
>>> Hi Keir. What type of Atheros-based card are you using? How many
>>> antennas do you have connected? If I understand things correctly, the
>>> PCU code regression (with respect to mesh and maybe AP and IBSS) has
>>> to do with having one antenna hooked up when your hardware also has an
>>> AUX antenna connector. If you have only one antenna, can you please
>>> plug in a second one and try again (before and after the commit in
>>> question)? I will try to do the same test here. More details from
>>> Nick were posted here:
>>> http://marc.info/?l=linux-wireless&m=122771338021489&w=2
>>>
>>>
>> To summarize, the following code on base.c is the problem...
>>
>> 1955 /*
>> 1956 * Switch antenna every 4 beacons if txantenna is not set
>> 1957 * XXX assumes two antennas
>> 1958 */
>> 1959 if (antenna == 0)
>> 1960 antenna = sc->bsent & 4 ? 2 : 1;
>>
>> ...we should always set 0 on tx descriptor for the default scenario to
>> work. Can you please comment this out and see if it works ?
>>
>> --
>> GPG ID: 0xD21DB2DB
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>>
>>
I did a binary chop on the pcu patch. Reverting this part of the patch
restores ap and mesh beaconing. I've no idea why.
77: + else
78: + AR5K_REG_ENABLE_BITS(ah, AR5K_CFG,
AR5K_CFG_ADHOC);
Steve
Bob Copeland wrote:
> On Fri, Dec 19, 2008 at 3:18 PM, Steve Brown <[email protected]> wrote:
>
>> If I revert this part of the pcu patch, the "queue 7" messages go away.
>> Beacons remain.
>>
>> - ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
>> + /* When in AP mode zero timer0 to start TSF */
>> + if (ah->ah_op_mode == NL80211_IFTYPE_AP)
>> + ath5k_hw_reg_write(ah, 0, AR5K_TIMER0);
>> + else
>> + ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
>>
>
> So you're talking about AP mode and not mesh right (otherwise above code
> wouldn't make a difference)? As in the HAL we do want to write 0 there.
> There's probably some other issue with setup of beacon timers.
>
>
Yes, this was with AP mode. I agree that the current code conforms to
the HAL. I'll keep looking.
I have also run some tests w/ mesh. After running (pings in both
directions) for a half hour or so, I get a warning on one of the nodes.
Most of the time, everything on that node freezes. When it doesn't, it
is not possible to unload the ath5k driver on either node, even the one
without the warning.
kernel:unregister_netdevice: waiting for mesh to become free. Usage
count = 11
Should I submit a patch for the AR5K_CFG_ADHOC enable/disable bug? With
it fixed, at least the ap and mesh problems are exposed. Maybe somebody
can see what's wrong.
Steve
------------------------
Dec 19 15:56:07 ubuntu kernel: [10169.157843] ------------[ cut here
]------------
Dec 19 15:56:07 ubuntu kernel: [10169.157848] WARNING: at
net/mac80211/tx.c:569 invoke_tx_handlers+0xd77/0xde0 [mac80211]()
Dec 19 15:56:07 ubuntu kernel: [10169.157851] Modules linked in: ath5k
af_packet i915 drm ppdev speedstep_lib cpufreq_conservative
cpufreq_powersave cpufreq_userspace cpufreq_ondemand cpufreq_stats
freq_table sco bridge rfcomm stp bnep l2cap bluetooth binfmt_misc ipv6
battery sbs sbshc wmi video output container pci_slot snd_intel8x0
snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy
snd_seq_oss snd_seq_midi arc4 ecb snd_rawmidi psmouse snd_seq_midi_event
snd_seq serio_raw snd_timer snd_seq_device snd pcspkr soundcore
snd_page_alloc iTCO_wdt iTCO_vendor_support rt73usb crc_itu_t rt2500usb
rt2x00usb rt2x00lib rfkill evdev shpchp pci_hotplug led_class mac80211
cfg80211 button intel_agp agpgart parport_pc lp parport ac
iptable_filter ip_tables x_tables ext3 jbd mbcache sd_mod crc_t10dif
usbhid hid sr_mod cdrom sg ata_piix pata_acpi ata_generic libata e100
mii ehci_hcd scsi_mod uhci_hcd usbcore thermal processor fan fuse [last
unloaded: ath5k]
Dec 19 15:56:07 ubuntu kernel: [10169.157995] Pid: 0, comm: swapper Not
tainted 2.6.28-rc8-wl #9
Dec 19 15:56:07 ubuntu kernel: [10169.157998] Call Trace:
Dec 19 15:56:07 ubuntu kernel: [10169.158007] [<c0377f35>] ?
printk+0x18/0x1b
Dec 19 15:56:07 ubuntu kernel: [10169.158014] [<c0133084>]
warn_on_slowpath+0x54/0x80
Dec 19 15:56:07 ubuntu kernel: [10169.158038] [<f8150249>] ?
ieee80211_duration+0x189/0x220 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158061] [<f814a4ed>] ?
rate_control_get_rate+0xbd/0xd0 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158083] [<f8151e77>]
invoke_tx_handlers+0xd77/0xde0 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158089] [<c02e7678>] ?
skb_release_data+0x68/0xa0
Dec 19 15:56:07 ubuntu kernel: [10169.158108] [<f814fe4b>] ?
__ieee80211_tx_prepare+0x17b/0x2f0 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158127] [<f81525d3>]
ieee80211_master_start_xmit+0x1e3/0x4a0 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158133] [<c02ef83b>]
dev_hard_start_xmit+0x23b/0x2d0
Dec 19 15:56:07 ubuntu kernel: [10169.158138] [<c0301905>]
__qdisc_run+0x1b5/0x220
Dec 19 15:56:07 ubuntu kernel: [10169.158153] [<c02f1677>]
dev_queue_xmit+0x337/0x570
Dec 19 15:56:07 ubuntu kernel: [10169.158172] [<f8150cb6>]
ieee80211_subif_start_xmit+0x366/0x7b0 [mac80211]
Dec 19 15:56:07 ubuntu kernel: [10169.158185] [<f7d83376>] ?
qh_urb_transaction+0xd6/0x3a0 [ehci_hcd]
Dec 19 15:56:07 ubuntu kernel: [10169.158190] [<c02ef83b>]
dev_hard_start_xmit+0x23b/0x2d0
Dec 19 15:56:07 ubuntu kernel: [10169.158194] [<c0301905>]
__qdisc_run+0x1b5/0x220
Dec 19 15:56:07 ubuntu kernel: [10169.158198] [<c02f1677>]
dev_queue_xmit+0x337/0x570
Dec 19 15:56:07 ubuntu kernel: [10169.158204] [<c03173d5>]
ip_finish_output+0x185/0x280
Dec 19 15:56:07 ubuntu kernel: [10169.158208] [<c0314c90>] ?
dst_output+0x0/0x10
Dec 19 15:56:07 ubuntu kernel: [10169.158212] [<c0317520>]
ip_output+0x50/0xa0
Dec 19 15:56:07 ubuntu kernel: [10169.158216] [<c0314c90>] ?
dst_output+0x0/0x10
Dec 19 15:56:07 ubuntu kernel: [10169.158220] [<c03164e8>]
ip_local_out+0x18/0x30
Dec 19 15:56:07 ubuntu kernel: [10169.158224] [<c0316775>]
ip_push_pending_frames+0x275/0x390
Dec 19 15:56:07 ubuntu kernel: [10169.158229] [<c0338084>]
icmp_push_reply+0x104/0x120
Dec 19 15:56:07 ubuntu kernel: [10169.158233] [<c0338df6>]
icmp_reply+0x116/0x1c0
Dec 19 15:56:07 ubuntu kernel: [10169.158237] [<c0338fce>]
icmp_echo+0x4e/0x50
Dec 19 15:56:07 ubuntu kernel: [10169.158242] [<c02ea4eb>] ?
__skb_checksum_complete_head+0x1b/0x70
Dec 19 15:56:07 ubuntu kernel: [10169.158246] [<c02ea54b>] ?
__skb_checksum_complete+0xb/0x10
Dec 19 15:56:07 ubuntu kernel: [10169.158250] [<c03388cc>]
icmp_rcv+0x21c/0x2a0
Dec 19 15:56:07 ubuntu kernel: [10169.158255] [<c0312805>]
ip_local_deliver_finish+0xa5/0x1c0
Dec 19 15:56:07 ubuntu kernel: [10169.158259] [<c03129af>]
ip_local_deliver+0x8f/0xa0
Dec 19 15:56:07 ubuntu kernel: [10169.158263] [<c0312760>] ?
ip_local_deliver_finish+0x0/0x1c0
Dec 19 15:56:07 ubuntu kernel: [10169.158267] [<c03121ee>]
ip_rcv_finish+0x14e/0x330
Dec 19 15:56:07 ubuntu kernel: [10169.158271] [<c030c1af>] ?
nf_hook_slow+0x9f/0xe0
Dec 19 15:56:07 ubuntu kernel: [10169.158275] [<c03120a0>] ?
ip_rcv_finish+0x0/0x330
Dec 19 15:56:07 ubuntu kernel: [10169.158279] [<c0312607>]
ip_rcv+0x237/0x280
Dec 19 15:56:07 ubuntu kernel: [10169.158283] [<c03120a0>] ?
ip_rcv_finish+0x0/0x330
Dec 19 15:56:07 ubuntu kernel: [10169.158287] [<c02f0f94>]
netif_receive_skb+0x284/0x550
Dec 19 15:56:07 ubuntu kernel: [10169.158291] [<c02f12cb>]
process_backlog+0x6b/0xe0
Dec 19 15:56:07 ubuntu kernel: [10169.158295] [<c02f0a7d>]
net_rx_action+0xed/0x220
Dec 19 15:56:07 ubuntu kernel: [10169.158300] [<c01385b7>]
__do_softirq+0x97/0x170
Dec 19 15:56:07 ubuntu kernel: [10169.158305] [<c0115faf>] ?
ack_apic_level+0x6f/0x290
Dec 19 15:56:07 ubuntu kernel: [10169.158309] [<c01386ed>]
do_softirq+0x5d/0x60
Dec 19 15:56:07 ubuntu kernel: [10169.158312] [<c0138865>]
irq_exit+0x55/0x90
Dec 19 15:56:07 ubuntu kernel: [10169.158318] [<c0106703>] do_IRQ+0x83/0xa0
Dec 19 15:56:07 ubuntu kernel: [10169.158323] [<c014bdfa>] ?
hrtimer_start+0x1a/0x20
Dec 19 15:56:07 ubuntu kernel: [10169.158328] [<c0105173>]
common_interrupt+0x23/0x30
Dec 19 15:56:07 ubuntu kernel: [10169.158334] [<c011be85>] ?
native_safe_halt+0x5/0x10
Dec 19 15:56:07 ubuntu kernel: [10169.158339] [<c010ac0d>]
default_idle+0x5d/0x60
Dec 19 15:56:07 ubuntu kernel: [10169.158343] [<c010285d>]
cpu_idle+0x6d/0xd0
Dec 19 15:56:07 ubuntu kernel: [10169.158347] [<c0369bde>]
rest_init+0x4e/0x60
Dec 19 15:56:07 ubuntu kernel: [10169.158351] ---[ end trace
16bfa1182f3e9a67 ]---
Bob Copeland wrote:
> On Thu, Dec 18, 2008 at 4:02 PM, Steve Brown <[email protected]> wrote:
>
>> Lots of these however:
>> Dec 18 15:53:20 fl-ws kernel: ath5k phy23: beacon queue 7 didn't stop?
>>
>
> Can you change the if statement that prints that in ath5k_beacon_send() in
> base.c to capture the return value? i.e.:
>
> int err;
> ...
>
> err = ath5k_hw_stop_tx_dma(ah, sc->bhalq);
> if (unlikely(err)) {
> ATH5K_WARN(... "...didn't stop? %d\n", sc->bhalq, err);
> }
>
>
>> If I make the same change to the current git, still no beacons. But, the
>> "queue 7" msgs persist.
>>
>
> Not sure, I was about to blame ath5k_configure_filter() but I see it does
> turn on the beacons for mesh.
>
>
If I revert this part of the pcu patch, the "queue 7" messages go away.
Beacons remain.
- ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
+ /* When in AP mode zero timer0 to start TSF */
+ if (ah->ah_op_mode == NL80211_IFTYPE_AP)
+ ath5k_hw_reg_write(ah, 0, AR5K_TIMER0);
+ else
+ ath5k_hw_reg_write(ah, next_beacon, AR5K_TIMER0);
The corresponding snippet of hal code seems to be:
case HAL_M_HOSTAP:
if (AH_PRIVATE(ah)->ah_opmode == HAL_M_HOSTAP)
OS_REG_WRITE(ah, AR_TIMER0, 0);
else
OS_REG_WRITE(ah, AR_TIMER0, next_beacon);
No idea what's going on.
Steve
Bob Copeland wrote:
> On Thu, Dec 18, 2008 at 9:00 AM, Steve Brown <[email protected]> wrote:
>
>> I did a binary chop on the pcu patch. Reverting this part of the patch
>> restores ap and mesh beaconing. I've no idea why.
>>
>> 77: + else
>> 78: + AR5K_REG_ENABLE_BITS(ah, AR5K_CFG,
>> AR5K_CFG_ADHOC);
>>
>
> Hmm, that looks exactly backwards, shouldn't it be DISABLE_BITS
> (and ENABLE_BITS in the adhoc case?)
>
> I think it's supposed to be 0 for AP/STA and 1 for IBSS.
>
>
Your interpretation matches the recently released hal source. I switched
them around in the pcu patch and ap/mesh beacons return.
Lots of these however:
Dec 18 15:53:20 fl-ws kernel: ath5k phy23: beacon queue 7 didn't stop?
If I make the same change to the current git, still no beacons. But, the
"queue 7" msgs persist.
Anyway, it's not antenna related.
Steve
Hi.
Keir wrote:
> I'm using Netgear WG311TGE PCI cards,
Those models I know of this card are just PCI-to-MiniPCI carrier cards,
with a MiniPCI card sitting inside the metal shield. Very likely Netgear
just attached a single pigtail (which then allows to attach an antenna
from the outside of the PC case) to one of the antenna connectors on that
MiniPCI card and left the other(s) empty.
Bye, Mike
Bob Copeland wrote:
> On Thu, Dec 18, 2008 at 4:02 PM, Steve Brown <[email protected]> wrote:
>
>> Lots of these however:
>> Dec 18 15:53:20 fl-ws kernel: ath5k phy23: beacon queue 7 didn't stop?
>>
>
> Can you change the if statement that prints that in ath5k_beacon_send() in
> base.c to capture the return value? i.e.:
>
> int err;
> ...
>
> err = ath5k_hw_stop_tx_dma(ah, sc->bhalq);
> if (unlikely(err)) {
> ATH5K_WARN(... "...didn't stop? %d\n", sc->bhalq, err);
> }
>
>
>> If I make the same change to the current git, still no beacons. But, the
>> "queue 7" msgs persist.
>>
>
> Not sure, I was about to blame ath5k_configure_filter() but I see it does
> turn on the beacons for mesh.
>
>
Dec 18 18:04:26 fl-ws kernel: ath5k phy24: beacon queue 7 didn't stop? -16
Dec 18 18:04:26 fl-ws kernel: ath5k phy24: beacon queue 7 didn't stop? -16
BUSY?
I'm using a:
03:0a.0 Ethernet controller: Atheros Communications Inc. AR5413
802.11abg NIC (rev 01)
Subsystem: Atheros Communications Inc. EnGenius EMP-8602 (400mw) or
Compex WLM54AG
Flags: medium devsel, IRQ 22
Memory at feab0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Kernel modules: ath5k
Steve
Keir wrote:
> Having has no luck with an old rc6 version (basically all plink
> packets were getting lost), I upgraded to the newest git (rc8) however
> now when I run iw dev mesh0 station sump I don't see a single other
> mesh point. This would imply that presumably beaconing is broken?
>
> Does anyone know a revision for which ath5k is properly working? I am
> yet to find one that works on my system.
>
> Cheers
>
> Keir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Beaconing seems broken by Update PCU code
dd1c9abd167de9bb9457a57694a1ab5e5801a0c1. After this patch, beacon debug
says beacons sent, but sniffer sees none.
A snapshot of ath5k prior to this and git 12/10
(b6d06c9669f27db31a0317fc98fedc8ff1ba4822) works for me with
hostapd/wpa. It's been running for the past few days.
Mesh beaconing also works. I didn't test two nodes; I only sniffed the
beacons.
I had to comment out 5GHz in caps.c because of too many channels. It's a
nl80211 buffer size problem that's been discussed.
Steve
I am getting good results with revision
5b6a96d870aea85ae5ef3f775a8403a9f40f8747 however after pinging a few
times my system completely locks up :-(
I'm getting frustratingly close to having this working!
Cheers
Keir
2008/12/17 Keir <[email protected]>:
> Hu Andrey,
>
> I'm using Netgear WG311TGE PCI cards, lspci says:
>
> Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband
> processor (rev 01)
>
> There is only one bit to plug in an antenna, so I've only had one
> plugged in, there isnt a place to plug in a second. After the commit
> in question I get no beaconing, before I get beaconing, but the PLINK
> state keeps flipping between OPEN_SNT and LISTEN, implying that for
> some reason it isnt receiving any PLINK packets.
>
> That said, I havent tried directly after the PCU commit, so I will try
> that now... but as I dont have an aux connector surely it shouldnt
> effect me?
>
> Cheers
>
> Keir
>
> 2008/12/16 Andrey Yurovsky <[email protected]>:
>> Hi Keir. What type of Atheros-based card are you using? How many
>> antennas do you have connected? If I understand things correctly, the
>> PCU code regression (with respect to mesh and maybe AP and IBSS) has
>> to do with having one antenna hooked up when your hardware also has an
>> AUX antenna connector. If you have only one antenna, can you please
>> plug in a second one and try again (before and after the commit in
>> question)? I will try to do the same test here. More details from
>> Nick were posted here:
>> http://marc.info/?l=linux-wireless&m=122771338021489&w=2
>>
>> On Tue, Dec 16, 2008 at 8:07 AM, Keir <[email protected]> wrote:
>>> I've been working on the commit previous to the PCU code breakage
>>> (8485b7f773a8e9883e0165273940f16a086eba2b), but I'm still having
>>> problems (beaconing is working, but links are rarely established, most
>>> of the time to packets get through).
>>>
>>> Cheers
>>>
>>> Keir
>>>
>>> 2008/12/16 Steve Brown <[email protected]>:
>>>> Keir wrote:
>>>>>
>>>>> Having has no luck with an old rc6 version (basically all plink
>>>>> packets were getting lost), I upgraded to the newest git (rc8) however
>>>>> now when I run iw dev mesh0 station sump I don't see a single other
>>>>> mesh point. This would imply that presumably beaconing is broken?
>>>>>
>>>>> Does anyone know a revision for which ath5k is properly working? I am
>>>>> yet to find one that works on my system.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Keir
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>>>> in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>> Beaconing seems broken by Update PCU code
>>>> dd1c9abd167de9bb9457a57694a1ab5e5801a0c1. After this patch, beacon debug
>>>> says beacons sent, but sniffer sees none.
>>>>
>>>> A snapshot of ath5k prior to this and git 12/10
>>>> (b6d06c9669f27db31a0317fc98fedc8ff1ba4822) works for me with hostapd/wpa.
>>>> It's been running for the past few days.
>>>>
>>>> Mesh beaconing also works. I didn't test two nodes; I only sniffed the
>>>> beacons.
>>>>
>>>> I had to comment out 5GHz in caps.c because of too many channels. It's a
>>>> nl80211 buffer size problem that's been discussed.
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Andrey Yurovsky
>> cozybit Inc.
>>
>
2008/12/16 Andrey Yurovsky <[email protected]>:
> Hi Keir. What type of Atheros-based card are you using? How many
> antennas do you have connected? If I understand things correctly, the
> PCU code regression (with respect to mesh and maybe AP and IBSS) has
> to do with having one antenna hooked up when your hardware also has an
> AUX antenna connector. If you have only one antenna, can you please
> plug in a second one and try again (before and after the commit in
> question)? I will try to do the same test here. More details from
> Nick were posted here:
> http://marc.info/?l=linux-wireless&m=122771338021489&w=2
>
To summarize, the following code on base.c is the problem...
1955 /*
1956 * Switch antenna every 4 beacons if txantenna is not set
1957 * XXX assumes two antennas
1958 */
1959 if (antenna == 0)
1960 antenna = sc->bsent & 4 ? 2 : 1;
...we should always set 0 on tx descriptor for the default scenario to
work. Can you please comment this out and see if it works ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
Hu Andrey,
I'm using Netgear WG311TGE PCI cards, lspci says:
Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband
processor (rev 01)
There is only one bit to plug in an antenna, so I've only had one
plugged in, there isnt a place to plug in a second. After the commit
in question I get no beaconing, before I get beaconing, but the PLINK
state keeps flipping between OPEN_SNT and LISTEN, implying that for
some reason it isnt receiving any PLINK packets.
That said, I havent tried directly after the PCU commit, so I will try
that now... but as I dont have an aux connector surely it shouldnt
effect me?
Cheers
Keir
2008/12/16 Andrey Yurovsky <[email protected]>:
> Hi Keir. What type of Atheros-based card are you using? How many
> antennas do you have connected? If I understand things correctly, the
> PCU code regression (with respect to mesh and maybe AP and IBSS) has
> to do with having one antenna hooked up when your hardware also has an
> AUX antenna connector. If you have only one antenna, can you please
> plug in a second one and try again (before and after the commit in
> question)? I will try to do the same test here. More details from
> Nick were posted here:
> http://marc.info/?l=linux-wireless&m=122771338021489&w=2
>
> On Tue, Dec 16, 2008 at 8:07 AM, Keir <[email protected]> wrote:
>> I've been working on the commit previous to the PCU code breakage
>> (8485b7f773a8e9883e0165273940f16a086eba2b), but I'm still having
>> problems (beaconing is working, but links are rarely established, most
>> of the time to packets get through).
>>
>> Cheers
>>
>> Keir
>>
>> 2008/12/16 Steve Brown <[email protected]>:
>>> Keir wrote:
>>>>
>>>> Having has no luck with an old rc6 version (basically all plink
>>>> packets were getting lost), I upgraded to the newest git (rc8) however
>>>> now when I run iw dev mesh0 station sump I don't see a single other
>>>> mesh point. This would imply that presumably beaconing is broken?
>>>>
>>>> Does anyone know a revision for which ath5k is properly working? I am
>>>> yet to find one that works on my system.
>>>>
>>>> Cheers
>>>>
>>>> Keir
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>>> in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> Beaconing seems broken by Update PCU code
>>> dd1c9abd167de9bb9457a57694a1ab5e5801a0c1. After this patch, beacon debug
>>> says beacons sent, but sniffer sees none.
>>>
>>> A snapshot of ath5k prior to this and git 12/10
>>> (b6d06c9669f27db31a0317fc98fedc8ff1ba4822) works for me with hostapd/wpa.
>>> It's been running for the past few days.
>>>
>>> Mesh beaconing also works. I didn't test two nodes; I only sniffed the
>>> beacons.
>>>
>>> I had to comment out 5GHz in caps.c because of too many channels. It's a
>>> nl80211 buffer size problem that's been discussed.
>>>
>>> Steve
>>>
>>>
>>>
>>
>
>
>
> --
> Andrey Yurovsky
> cozybit Inc.
>
Tried this, and I'm getting slightly odd results. The two nodes
running with these lines commented out can see the node whose code is
previous to the PCU patch, but they cant see each other. Also the
other node can see both of them... very strange.
Cheers
Keir
2008/12/17 Nick Kossifidis <[email protected]>:
> 2008/12/16 Andrey Yurovsky <[email protected]>:
>> Hi Keir. What type of Atheros-based card are you using? How many
>> antennas do you have connected? If I understand things correctly, the
>> PCU code regression (with respect to mesh and maybe AP and IBSS) has
>> to do with having one antenna hooked up when your hardware also has an
>> AUX antenna connector. If you have only one antenna, can you please
>> plug in a second one and try again (before and after the commit in
>> question)? I will try to do the same test here. More details from
>> Nick were posted here:
>> http://marc.info/?l=linux-wireless&m=122771338021489&w=2
>>
>
> To summarize, the following code on base.c is the problem...
>
> 1955 /*
> 1956 * Switch antenna every 4 beacons if txantenna is not set
> 1957 * XXX assumes two antennas
> 1958 */
> 1959 if (antenna == 0)
> 1960 antenna = sc->bsent & 4 ? 2 : 1;
>
> ...we should always set 0 on tx descriptor for the default scenario to
> work. Can you please comment this out and see if it works ?
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>