Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled

2012-02-29 Thread Adrian Chadd
.. and you'll be able to sense ACKs how? :-)


Adrian

On 29 February 2012 14:25, srinivas prasad  wrote:
> I thought that it will enable me to transmit without sensing the carrier. I
> am a bit new to this so maybe I interpreted it wrong. My aim is to induce
> overlaps as many overlaps as possible in our network in our experiments. I
> thought by physical carrier sense, i would be able to transmit without
> sensing the carrier.
>
> Thank you
> Srinivas
>
> On Wed, Feb 29, 2012 at 4:02 PM, Nick Kossifidis 
> wrote:
>>
>> 2012/2/29 srinivas prasad :
>> > Thanks for the reply. Just to make it clear, So are you saying that the
>> > patch is buggy?  I thought it is supposed to disable carrier sensing
>> > (physical and virtual) by turning on and off some flags.
>> >
>>
>> Define buggy. This patch disables carrier sensing on PHY by forcing
>> the RX_CLEAR signal to always be high (that means the PHY always
>> reports the channel as idle, e.g. allowing you to transmit all the way
>> ignoring any other users -some people use that for DoS
>> attacks/testing/research etc-) and virtual carrier sensing on MAC by
>> telling the PCU to ignore it. It does what's supposed to and as Felix
>> told you it effectively kills RX (until you switch them back on).
>>
>> What did you expect from such a patch/approach ?
>>
>> --
>> GPG ID: 0xEE878588
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>
>
>
> ___
> ath5k-devel mailing list
> ath5k-devel@lists.ath5k.org
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel


Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled

2012-02-29 Thread Nick Kossifidis
2012/2/29 srinivas prasad :
> Thanks for the reply. Just to make it clear, So are you saying that the
> patch is buggy?  I thought it is supposed to disable carrier sensing
> (physical and virtual) by turning on and off some flags.
>

Define buggy. This patch disables carrier sensing on PHY by forcing
the RX_CLEAR signal to always be high (that means the PHY always
reports the channel as idle, e.g. allowing you to transmit all the way
ignoring any other users -some people use that for DoS
attacks/testing/research etc-) and virtual carrier sensing on MAC by
telling the PCU to ignore it. It does what's supposed to and as Felix
told you it effectively kills RX (until you switch them back on).

What did you expect from such a patch/approach ?

-- 
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel


Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled

2012-02-29 Thread srinivas prasad
I thought that it will enable me to transmit without sensing the carrier. I
am a bit new to this so maybe I interpreted it wrong. My aim is to induce
overlaps as many overlaps as possible in our network in our experiments. I
thought by physical carrier sense, i would be able to transmit without
sensing the carrier.

Thank you
Srinivas

On Wed, Feb 29, 2012 at 4:02 PM, Nick Kossifidis wrote:

> 2012/2/29 srinivas prasad :
> > Thanks for the reply. Just to make it clear, So are you saying that the
> > patch is buggy?  I thought it is supposed to disable carrier sensing
> > (physical and virtual) by turning on and off some flags.
> >
>
> Define buggy. This patch disables carrier sensing on PHY by forcing
> the RX_CLEAR signal to always be high (that means the PHY always
> reports the channel as idle, e.g. allowing you to transmit all the way
> ignoring any other users -some people use that for DoS
> attacks/testing/research etc-) and virtual carrier sensing on MAC by
> telling the PCU to ignore it. It does what's supposed to and as Felix
> told you it effectively kills RX (until you switch them back on).
>
> What did you expect from such a patch/approach ?
>
> --
> GPG ID: 0xEE878588
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel


Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled

2012-02-29 Thread Adrian Chadd
On 29 February 2012 09:19, srinivas prasad  wrote:
> Thanks for the reply. Just to make it clear, So are you saying that the
> patch is buggy?  I thought it is supposed to disable carrier sensing
> (physical and virtual) by turning on and off some flags.

I don't think that patch does what you think it does, at least not
guaranteed on all chips.

In fact, I wonder how early those misc mode bits do go back..


Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel


Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled

2012-02-29 Thread srinivas prasad
Thanks for the reply. Just to make it clear, So are you saying that the
patch is buggy?  I thought it is supposed to disable carrier sensing
(physical and virtual) by turning on and off some flags.

On Tue, Feb 28, 2012 at 7:22 AM, Felix Fietkau  wrote:

> On 2012-02-28 3:01 AM, srinivas prasad wrote:
> > hi,
> > I am using voyage linux(3.0.0-voyage kernel) for my work. All my
> > wireless cards are atheros cards(Atheros Communications Inc. Atheros
> > AR5001X+ Wireless Network Adapter (rev 01)) and I am using ath5k driver.
> > I incorporated the following change to create the interface for enabling
> > and disabling carrier
> > sensing
> https://www.pentoo.ch/svn/portage/trunk/net-wireless/compat-wireless/files/super_secret_patch.diff
> .
> > Whenever i disable physical carrier sense to induce maximum overlap of
> > packets at the AP, the client disassociates from it and is unable to
> > reconnect in any successive attempt. I get the following error message
> > at the client
> I'm pretty sure you're effectively killing Rx. With an essential part of
> the card's functionality disabled, of course it's going to assume that
> the AP is dead and it'll disconnect - not sure why you'd expect it to
> behave differently.
>
> - Felix
>
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel