Re: [Madwifi-devel] Problem trying to compile Madwifi 0.9.4

[Pavel Roskin <proski@gn...>]

On Thu, 2009-07-30 at 15:56 -0400, Hector Candia wrote:
> Hi list,
> 
> I am trying to install madwifi 0.9.4 and I received the next error:
> /home/Test/madwifi-0.9.4/net80211/ieee80211_power.c: In function
> 'ieee80211_pwrsave':
> /home/Test/madwifi-0.9.4/net80211/ieee80211_power.c:240: error:
> implicit declaration of function '__skb_append'

This will be fixed in version 0.9.4.1.  In the meantime please use the
latest snapshot or the version from Subversion, either trunk or the
0.9.4 branch.

-- 
Regards,
Pavel Roskin

[Madwifi-devel] Problem trying to compile Madwifi 0.9.4

[Hector Candia <hectorcandiabendezu@gm...>]

Hi list,

I am trying to install madwifi 0.9.4 and I received the next error:

[root@... madwifi-0.9.4]# make
Checking requirements... ok.
Checking kernel configuration... ok.
make -C /lib/modules/2.6.27.25-170.2.72.fc10.i686/build
SUBDIRS=/home/Test/madwifi-0.9.4 modules
make[1]: Entering directory `/usr/src/kernels/2.6.27.25-170.2.72.fc10.i686'
  CC [M]  /home/Test/madwifi-0.9.4/ath/if_ath.o
  CC [M]  /home/Test/madwifi-0.9.4/ath/if_ath_pci.o
  LD [M]  /home/Test/madwifi-0.9.4/ath/ath_pci.o
  CC [M]  /home/Test/madwifi-0.9.4/ath_hal/ah_os.o
  HOSTCC  /home/Test/madwifi-0.9.4/ath_hal/uudecode
  UUDECODE /home/Test/madwifi-0.9.4/ath_hal/i386-elf.hal.o
  LD [M]  /home/Test/madwifi-0.9.4/ath_hal/ath_hal.o
  CC [M]  /home/Test/madwifi-0.9.4/ath_rate/amrr/amrr.o
  LD [M]  /home/Test/madwifi-0.9.4/ath_rate/amrr/ath_rate_amrr.o
  CC [M]  /home/Test/madwifi-0.9.4/ath_rate/minstrel/minstrel.o
  LD [M]  /home/Test/madwifi-0.9.4/ath_rate/minstrel/ath_rate_minstrel.o
  CC [M]  /home/Test/madwifi-0.9.4/ath_rate/onoe/onoe.o
  LD [M]  /home/Test/madwifi-0.9.4/ath_rate/onoe/ath_rate_onoe.o
  CC [M]  /home/Test/madwifi-0.9.4/ath_rate/sample/sample.o
  LD [M]  /home/Test/madwifi-0.9.4/ath_rate/sample/ath_rate_sample.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/if_media.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_beacon.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_crypto.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_crypto_none.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_input.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_node.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_output.o
  CC [M]  /home/Test/madwifi-0.9.4/net80211/ieee80211_power.o
/home/Test/madwifi-0.9.4/net80211/ieee80211_power.c: In function
'ieee80211_pwrsave':
/home/Test/madwifi-0.9.4/net80211/ieee80211_power.c:240: error: implicit
declaration of function '__skb_append'
make[3]: *** [/home/Test/madwifi-0.9.4/net80211/ieee80211_power.o] Error 1
make[2]: *** [/home/Test/madwifi-0.9.4/net80211] Error 2
make[1]: *** [_module_/home/Test/madwifi-0.9.4] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.27.25-170.2.72.fc10.i686'
make: *** [modules] Error 2
[root@... madwifi-0.9.4]#

..... I read some web pages, and I found that the solution is to use a
recent madwifi version. I download a recent version from Snapshots, I also
download madwifi-ng-0.9.4 and test them, and both works very well.

But, my question is What madwifi files were modified in order to solve this
problem ?, because I would like to modified those codes and test them for
myself.

I hope your answers,

Thanks,

Hector.

Re: [Madwifi-devel] ref node problem in ieee80211_input()

[Pavel Roskin <proski@gn...>]

On Fri, 2009-04-24 at 17:12 +0100, Matthew Faulkner wrote:
> Hey folks,
> 
> I've just upgraded to the latest ubuntu and come to try compile the
> madwifi drivers, but get the following errors:
> 
> cc1: out of memory allocating 281474976711378 bytes after a total of
> 561152 bytes

Please don't hijack unrelated threads.

There is nothing MadWifi can do to fix compiler bugs.  I suggest that
you report it to the Ubuntu bug tracker for gcc.

-- 
Regards,
Pavel Roskin

Re: [Madwifi-devel] ref node problem in ieee80211_input()

[Pavel Roskin <proski@gn...>]

On Wed, 2009-04-22 at 23:39 -0700, Daniel Wu wrote:
> I think this will be a problem:
> 
> In function ieee80211_input(), net80211/ieee80211_input.c,
> 
> line 215,
> 
> This statement forces the code to got to out, sometimes,
> 
> 	if ((vap->iv_dev->flags & (IFF_RUNNING | IFF_UP)) !=
> 			(IFF_RUNNING | IFF_UP))
> 		goto out;

Yes, that's it.  I have fixed that.  Sorry for delay.  Thank you!

-- 
Regards,
Pavel Roskin

Re: [Madwifi-devel] ieee80211_unref_node on NULL node

[Pavel Roskin <proski@gn...>]

On Tue, 2009-07-21 at 23:49 +0300, Ilya A. Volynets-Evenbakh wrote:
> Under certain conditions, frames are passed to
> ieee80211_input() for VAPs which aren't running.
> 
> Change #3621 introduces a fix for it, but when
> the function is called with ni_or_null == NULL,
> for VAP in IF_DOWN state, the clean-up code tries
> to unref NULL ni pointer.
> 
> Following is a simple patch to fix that problem:

I've applied an equivalent patch.  Thank you for your analysis!

-- 
Regards,
Pavel Roskin

[Madwifi-devel] Question about madwifi monitor mode

[y omar <y_omar_004@ya...>]

Hello all, 

I have been running a rather simple experiment where I generate controlled traffic between two nodes and attempt to monitor it using a third node.

I inserted code in ieee80211_input_monitor() function that writes some data about the captured traffic in a \proc file and then I created a node set to minotor mode (with no other VAPs on the same card ) and nothing was captured. However, when I created two VAPs on the same card (one in managed mode and another in monitor mode, and the first is associated with my network) all the traffic was captured properly by both!

Is there some setting I am missing here? I need to capture all the traffic in my network using a single monitor node.. 

Thanks for your help,
Best,
Yara



      

Re: [Madwifi-devel] Beacons not getting emitted

[Dino Joseph Mycle <dinomycle@ya...>]

Hi,
   attached the log message when athdebug 0x8080(beacon and beacon_proc) enabled

   Regards, 
Dino Joseph Mycle


--- On Tue, 28/7/09, Dino Joseph Mycle <dinomycle@...> wrote:

> From: Dino Joseph Mycle <dinomycle@...>
> Subject: [Madwifi-devel] Beacons not getting emitted
> To: madwifi-devel@...
> Date: Tuesday, 28 July, 2009, 6:32 PM
> Hi ,
>    In trunk r4079 and previous
> versions(openhal) beacons frames(AP mode)
>  are not getting emitted.. If you scan with a PC it will
> show because
>  it uses active scanning(Probe request/response). 
> 
> Using netstumbler you wont be able to see the ssid. 
> 
> My PC config : kernel 2.6.18-92.el5 (CentOS)
> wlan: mac acl policy registered
> PCI: Enabling device 0000:02:02.0 (0210 -> 0212)
> ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 17 (level,
> low) -> IRQ 169
> MadWifi: ath_attach: Switching rfkill capability off.
> wifi0: Atheros AR5413 chip found (MAC 10.4, PHY SChip 6.1,
> Radio 6.3)
> ath_pci: wifi0: Atheros 5413: mem=0x50000000, irq=169
> 
> I tried debugging the athdebug beacon, no printk coming. 
> 
> 
> Regards,
> Dino Joseph Mycle
>


      Looking for local information? Find it on Yahoo! Local http://in.local.yahoo.com/

[Madwifi-devel] Beacons not getting emitted

[Dino Joseph Mycle <dinomycle@ya...>]

Hi ,
   In trunk r4079 and previous versions(openhal) beacons frames(AP mode)
 are not getting emitted. If you scan with a PC it will show because
 it uses active scanning(Probe request/response). 

Using netstumbler you wont be able to see the ssid. 

My PC config : kernel 2.6.18-92.el5 (CentOS)
wlan: mac acl policy registered
PCI: Enabling device 0000:02:02.0 (0210 -> 0212)
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 17 (level, low) -> IRQ 169
MadWifi: ath_attach: Switching rfkill capability off.
wifi0: Atheros AR5413 chip found (MAC 10.4, PHY SChip 6.1, Radio 6.3)
ath_pci: wifi0: Atheros 5413: mem=0x50000000, irq=169

I tried debugging the athdebug beacon, no printk coming. 


Regards,
Dino Joseph Mycle

[Madwifi-devel] OFDM subcarrier

[bin zan <zanbin2046@gm...>]

Hi,
      Anyone knows if it is possible to work on OFDM subcarriers by
modifying the madwifi driver? For example, assign a particular sub-carrier
for data transmitting?  If it is possible, where or which files would be the
best place for me to start?

Thanks,
Bin

[Madwifi-devel] Setting tx Fields SSI, Channel...

[Carlos Chacon <chaconc@gm...>]

Hi,

I am writing a programs that is using libpcap to send packets through the
wireless network, one of the objectives of this programs is to change the
source MAC of the packets to simulate virtual host for a testing
environment. But I have been run into trouble, whenever I send a packet to
the network with a “false” MAC address the following fields are excluded
from the packet (or set to 0) and this will causes communication problems
and no one will reply to the packages. Btw this packets are construct from
scratch, let’s say I write my own code so it will assemble an ARP packet.
These are the fields that are missing or set to 0:

   Radiotap header:
      SSI Signal
      SSI Noise
      SSI Signal 2.
      Channel Type
      Channel Frequency
      Flags
   IEEE 802.11 Data
      Frame check sequence

I have done some research but have hit a brick wall; I know some parameters
are set by HAL Function: ath_hal_setuptxdesc. The solution I was thinking of
is writing a hack into the code of madwifi so before it sets any parameters
it will check for the source MAC and if it is “fake” it will use the
parameters of the real MAC, but keep the Source MAC address untouched.

Is this possible? If so can I have some hints where in the code I can
program this? In advance thank you for any advice you can offer me on this.

Regards,
Carlos

[Madwifi-devel] change channel without loosing the connectivity

[nathan <nitha_2000@ya...>]

Hi,
I'm just wondering is there a way to change the channel of an AP without loosing the connectivity to the associated clients ?
The clients are verified and authorized to connect to the AP. If the AP wants to go to another channel, say less occupied channel, why the clients havo to got re-association process ?

thanks,



      __________________________________________________________________
Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

Re: [Madwifi-devel] XR support in trunk

[Brett Wright <Brett.Wright@el...>]

Probably a combination of both. I do not know of any open source code
with full XR support, but it is interesting to see that there are
differences in, say, openwrt madwifi where it looks like some more
thought has been given to XR (particularly in hal source).

 

Yes, for 5GHz turbo I just followed the wiki.

 

________________________________

From: LAMBA Jaideep [mailto:Jaideep.Lamba@...] 
Sent: Friday, 24 July 2009 10:06 AM
To: madwifi-devel@...
Subject: Re: [Madwifi-devel] XR support in trunk

 

Thanks Brett for the response. 

 

Do you mean porting of the code from somewhere for changes or new code ?

 

 In enabling 5Ghz static turbo channel did you just follow the
instructions on http://madwifi-project.org/wiki/UserDocs/TurboMode.

 

Thanks,

Jaideep 
-------------

I was never able to get XR mode working, it could be possible but there
are a lot of changes required. Sam Leffler has stated that the HAL only
supported XR for STA mode.

Even turbo mode for 2.4GHz in trunk does not really enable 40MHz channel
6 without modifications, in my experience. I think for 5GHz static turbo
channels it is OK though.

 

Brett

Re: [Madwifi-devel] XR support in trunk

[LAMBA Jaideep <Jaideep.Lamba@al...>]

Thanks Brett for the response. 
 
Do you mean porting of the code from somewhere for changes or new code ?

 In enabling 5Ghz static turbo channel did you just follow the
instructions on http://madwifi-project.org/wiki/UserDocs/TurboMode.
 
Thanks,
Jaideep 
-------------

I was never able to get XR mode working, it could be possible but there
are a lot of changes required. Sam Leffler has stated that the HAL only
supported XR for STA mode.

Even turbo mode for 2.4GHz in trunk does not really enable 40MHz channel
6 without modifications, in my experience. I think for 5GHz static turbo
channels it is OK though.

 

Brett

 

Hi,

 

I am trying to run XR and TURBO mode on Ubiquiti XR2 radio using madwifi
trunk. my interfaces are configured in adhoc mode.

 

I see some of the XR code in trunk is currently commented out. 

 

e.g. /* 21 was HAL_CAP_XR */

Is this code no longer needed after open HAL or is it that currently
trunk does not have this capability. Any pointers to get this
functionality is highly appreciated.

 

Thanks,

Jaideep

 

Re: [Madwifi-devel] XR support in trunk

[Brett Wright <Brett.Wright@el...>]

I was never able to get XR mode working, it could be possible but there
are a lot of changes required. Sam Leffler has stated that the HAL only
supported XR for STA mode.

Even turbo mode for 2.4GHz in trunk does not really enable 40MHz channel
6 without modifications, in my experience. I think for 5GHz static turbo
channels it is OK though.

 

Brett

________________________________

From: LAMBA Jaideep [mailto:Jaideep.Lamba@...] 
Sent: Friday, 24 July 2009 9:23 AM
To: madwifi-devel@...
Subject: [Madwifi-devel] XR support in trunk

 

Hi,

 

I am trying to run XR and TURBO mode on Ubiquiti XR2 radio using madwifi
trunk. my interfaces are configured in adhoc mode.

 

I see some of the XR code in trunk is currently commented out. 

 

e.g. /* 21 was HAL_CAP_XR */

Is this code no longer needed after open HAL or is it that currently
trunk does not have this capability. Any pointers to get this
functionality is highly appreciated.

 

Thanks,

Jaideep

 

[Madwifi-devel] XR support in trunk

[LAMBA Jaideep <Jaideep.Lamba@al...>]

Hi,
 
I am trying to run XR and TURBO mode on Ubiquiti XR2 radio using madwifi
trunk. my interfaces are configured in adhoc mode.
 
I see some of the XR code in trunk is currently commented out. 
 
e.g. /* 21 was HAL_CAP_XR */

Is this code no longer needed after open HAL or is it that currently
trunk does not have this capability. Any pointers to get this
functionality is highly appreciated.
 
Thanks,
Jaideep
 

Re: [Madwifi-devel] Accuracy of the timestamp in receive descriptors

[Scott Raynel <scottraynel@gm...>]

Hi Derek,

I haven't really played with Ad-hoc mode at all, mainly because in the  
past it's never worked reliably. I just conjectured that it may be a  
problem given I've never had reliable ad-hoc working and if the  
timestamps were all messed up then it might explain it.

If ad-hoc mode works now then that's brilliant news. I haven't looked  
into the ad-hoc path close enough to see if there needs to be some  
correction done.

Cheers,

On 24/07/2009, at 10:02 AM, Derek Smithies wrote:

> Scott,
> good work on verifying when the timestamp is actually taken.
>
> You mentioned in a previous email that their might be an issue with  
> beacon sync in adhoc mode because of this. To date, I have not seen  
> an issue with adhoc beacon sync. Networks operating
>   * indoors,
>   * outdoors, <100 m long links, no radio noise
>   * outdoors in adverse radio conditions over 700m links
>
> seem to do adhoc beacon sync (including tsf) fine. To use a music  
> analogy, all nodes send beacons in time, so that every 100.24 ms (on  
> average) one beacon is detected on air.
>
> Do you think there is a correction factor that should be introduced  
> somewhere?
>
> Derek.
> On Wed, 22 Jul 2009, Scott Raynel wrote:
>
>> Bit of an update.
>>
>> I've been working on investigating the hypothesis that the  
>> timestamp is taken at the end of each packet. While doing so I  
>> realised I had incorrectly coded my previous experiment when  
>> assuming that the timestamp was for the previous packet.
>>
>> When I fixed that bug and re-ran the experiment it became obvious  
>> that the timestamp was _not_ for the previous packet at all. As a  
>> side note, it turned out that the bug in my code made me treat the  
>> timestamp very similarly to it being the end of the packet :)
>>
>> Continuing under the assumption that the timestamp was for the end  
>> of the current packet I wrote some code to explore the interframe  
>> spacing. If the hypothesis was correct then we should see the SIFS  
>> as a large proportion of the interframe spaces.
>>
>> It turns out that yes, when treating the timestamp as an end  
>> timestamp and working back from there everything works out. To  
>> determine a start timestamp (still focussed only on clause 18 HR/ 
>> DSSS PHYs) we need to calculate the TX time, which is a function of  
>> the MPDU length in octets and the preamble/PLCP length.
>>
>> Determining the MPDU length is easy for clause 18 PHYs. Determining  
>> whether a frame was received with a short or long preamble though  
>> is not possible, as far as I can tell. There is nothing in the  
>> receive descriptors that tells us what PHY type a frame was  
>> received with, e.g. HR/DSSS/short or HR/DSSS/long. This becomes  
>> even more tricky when looking at clause 19 (802.11g) PHYs, but  
>> that's a problem for later.
>>
>> Under controlled conditions (i.e. manually setting the preamble  
>> type and locking mode and rate) I was able to measure the  
>> interframe spacing extremely accurately. I was able to see the  
>> space between DATA and ACK frames at bang on 10 microseconds, which  
>> is great. To the best of my knowledge this is the first time such  
>> accurate measurement has been performed with madwifi.
>>
>> I think at this point we can be pretty confident that the timestamp  
>> is the for the end of the packet. If anybody knows how to determine  
>> the PHY type of a received frame I'd be grateful to hear from you.
>>
>> Some possibly interesting graphs:
>>
>> The following show the cumulative distribution of interframe spaces  
>> within a trace taken of a 1400 byte ICMP ping flood with sender and  
>> receiver locked to 2Mbit HR/DSSS/short. The sender always has  
>> packets queued to send whereas the receiver is only ever replying  
>> with a single packet once as it receives them. The three graphs  
>> show differing zoom levels of the data:
>>
>> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20000usecs.png
>> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.200usecs.png
>> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20usecs.png
>>
>> We can see the SIFS spacing in the last graph very clearly.
>>
>> Cheers all
>>
>> On 21/07/2009, at 7:41 PM, Scott Raynel wrote:
>>
>>> Thanks for the input guys. I will do a more thorough investigation  
>>> of
>>> the timestamp over the next couple of days and get back to you.
>>
>> --
>> Scott Raynel
>> WAND Network Research Group
>> Department of Computer Science
>> University of Waikato
>> New Zealand
>>
>>
>>
>>
>
> -- 
> Derek Smithies Ph.D.
> IndraNet Technologies Ltd.
> ph +64 3 365 6485
> Web: http://www.indranet-technologies.com/
>
> "The only thing IE should be used for is to download Fire Fox"

--
Scott Raynel
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [Madwifi-devel] Accuracy of the timestamp in receive descriptors

[Derek Smithies <derek@in...>]

Scott,
  good work on verifying when the timestamp is actually taken.

You mentioned in a previous email that their might be an issue with beacon 
sync in adhoc mode because of this. To date, I have not seen an issue with 
adhoc beacon sync. Networks operating
    * indoors,
    * outdoors, <100 m long links, no radio noise
    * outdoors in adverse radio conditions over 700m links

seem to do adhoc beacon sync (including tsf) fine. 
To use a music analogy, all nodes send beacons in time, so that every 
100.24 ms (on average) one beacon is detected on air.

Do you think there is a correction factor that should be introduced 
somewhere?

Derek.
On Wed, 22 Jul 2009, Scott Raynel wrote:

> Bit of an update.
>
> I've been working on investigating the hypothesis that the timestamp is taken 
> at the end of each packet. While doing so I realised I had incorrectly coded 
> my previous experiment when assuming that the timestamp was for the previous 
> packet.
>
> When I fixed that bug and re-ran the experiment it became obvious that the 
> timestamp was _not_ for the previous packet at all. As a side note, it turned 
> out that the bug in my code made me treat the timestamp very similarly to it 
> being the end of the packet :)
>
> Continuing under the assumption that the timestamp was for the end of the 
> current packet I wrote some code to explore the interframe spacing. If the 
> hypothesis was correct then we should see the SIFS as a large proportion of 
> the interframe spaces.
>
> It turns out that yes, when treating the timestamp as an end timestamp and 
> working back from there everything works out. To determine a start timestamp 
> (still focussed only on clause 18 HR/DSSS PHYs) we need to calculate the TX 
> time, which is a function of the MPDU length in octets and the preamble/PLCP 
> length.
>
> Determining the MPDU length is easy for clause 18 PHYs. Determining whether a 
> frame was received with a short or long preamble though is not possible, as 
> far as I can tell. There is nothing in the receive descriptors that tells us 
> what PHY type a frame was received with, e.g. HR/DSSS/short or HR/DSSS/long. 
> This becomes even more tricky when looking at clause 19 (802.11g) PHYs, but 
> that's a problem for later.
>
> Under controlled conditions (i.e. manually setting the preamble type and 
> locking mode and rate) I was able to measure the interframe spacing extremely 
> accurately. I was able to see the space between DATA and ACK frames at bang 
> on 10 microseconds, which is great. To the best of my knowledge this is the 
> first time such accurate measurement has been performed with madwifi.
>
> I think at this point we can be pretty confident that the timestamp is the 
> for the end of the packet. If anybody knows how to determine the PHY type of 
> a received frame I'd be grateful to hear from you.
>
> Some possibly interesting graphs:
>
> The following show the cumulative distribution of interframe spaces within a 
> trace taken of a 1400 byte ICMP ping flood with sender and receiver locked to 
> 2Mbit HR/DSSS/short. The sender always has packets queued to send whereas the 
> receiver is only ever replying with a single packet once as it receives them. 
> The three graphs show differing zoom levels of the data:
>
> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20000usecs.png
> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.200usecs.png
> http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20usecs.png
>
> We can see the SIFS spacing in the last graph very clearly.
>
> Cheers all
>
> On 21/07/2009, at 7:41 PM, Scott Raynel wrote:
>
>> Thanks for the input guys. I will do a more thorough investigation of
>> the timestamp over the next couple of days and get back to you.
>> 
>
> --
> Scott Raynel
> WAND Network Research Group
> Department of Computer Science
> University of Waikato
> New Zealand
>
>
>
>

-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

[Madwifi-devel] XR mode in ad-hoc

[LAMBA Jaideep <Jaideep.Lamba@al...>]

Hi,
 
Can I use Atheors XR capability in ad-hoc mode using madwifi. I am using
madwifi trunk "svn r2854".
 
Thanks,
Jaideep 

Re: [Madwifi-devel] Accuracy of the timestamp in receive descriptors

[Scott Raynel <scottraynel@gm...>]

Bit of an update.

I've been working on investigating the hypothesis that the timestamp  
is taken at the end of each packet. While doing so I realised I had  
incorrectly coded my previous experiment when assuming that the  
timestamp was for the previous packet.

When I fixed that bug and re-ran the experiment it became obvious that  
the timestamp was _not_ for the previous packet at all. As a side  
note, it turned out that the bug in my code made me treat the  
timestamp very similarly to it being the end of the packet :)

Continuing under the assumption that the timestamp was for the end of  
the current packet I wrote some code to explore the interframe  
spacing. If the hypothesis was correct then we should see the SIFS as  
a large proportion of the interframe spaces.

It turns out that yes, when treating the timestamp as an end timestamp  
and working back from there everything works out. To determine a start  
timestamp (still focussed only on clause 18 HR/DSSS PHYs) we need to  
calculate the TX time, which is a function of the MPDU length in  
octets and the preamble/PLCP length.

Determining the MPDU length is easy for clause 18 PHYs. Determining  
whether a frame was received with a short or long preamble though is  
not possible, as far as I can tell. There is nothing in the receive  
descriptors that tells us what PHY type a frame was received with,  
e.g. HR/DSSS/short or HR/DSSS/long. This becomes even more tricky when  
looking at clause 19 (802.11g) PHYs, but that's a problem for later.

Under controlled conditions (i.e. manually setting the preamble type  
and locking mode and rate) I was able to measure the interframe  
spacing extremely accurately. I was able to see the space between DATA  
and ACK frames at bang on 10 microseconds, which is great. To the best  
of my knowledge this is the first time such accurate measurement has  
been performed with madwifi.

I think at this point we can be pretty confident that the timestamp is  
the for the end of the packet. If anybody knows how to determine the  
PHY type of a received frame I'd be grateful to hear from you.

Some possibly interesting graphs:

The following show the cumulative distribution of interframe spaces  
within a trace taken of a 1400 byte ICMP ping flood with sender and  
receiver locked to 2Mbit HR/DSSS/short. The sender always has packets  
queued to send whereas the receiver is only ever replying with a  
single packet once as it receives them. The three graphs show  
differing zoom levels of the data:

http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20000usecs.png
http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.200usecs.png
http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20usecs.png

We can see the SIFS spacing in the last graph very clearly.

Cheers all

On 21/07/2009, at 7:41 PM, Scott Raynel wrote:

> Thanks for the input guys. I will do a more thorough investigation of
> the timestamp over the next couple of days and get back to you.
>

--
Scott Raynel
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: [Madwifi-devel] A few questions about TX descriptors

[Derek Smithies <derek@in...>]

On Wed, 22 Jul 2009, Ignacy Gawedzki wrote:
> I was looking at the way the TX descriptor is filled in both drivers in 
> case RTS/CTS or CTS-to-self is used.  It appears that the HAL may put 
> the calculated rtsctsDuration value in some control field of the 
> descriptor, if the chipset supports it.  It also appears there is a flag 
> for asking the chipset to perform the duration calculation itself, but 
> this is never used (HAL_TXDESC_DURENA).  In case the retry chain is 
> used, this flag is set for every alternative rate, I suppose in order 
> for the duration field of subsequent RTS frames to be updated with the 
> correct value for the alternative data rate.  Why is this automatic 
> calculation not requested for the first rate whenever possible?
>
> In ath5k, it seems that automatic calculation is *never* requested, even when
> using the retry chain, which is strange, to say the least.  It also appears to
> me that the calculated duration value is plainly wrong, considering that the
> duration of the data frame is based on the same rate as the CTS frame (which
> is set to the maximum basic rate not faster than the data rate).  In addition,
> if the duration is not to be updated by the firmware, then RTS frames may hold
> a bogus duration field if the subsequent data frame is transmitted with an
> alternative rate.

I don't use cts/rts etc here, so cannot answer.
What about the speed of the cts/rts/ack packet - this is not really added 
into the calculation.

Although - how big an error are we talking about?

Derek.
-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

Re: [Madwifi-devel] A few questions about TX descriptors

[Ignacy Gawedzki <madwifi@qu...>]

On Wed, Jul 22, 2009 at 10:04:14AM +1200, thus spake Derek Smithies:
> Ask your questions, I am happy to answer them. I would prefer that your  
> questions are asked on madwifi list - then my answers are available for  
> others to read.

Sure, as long as the questions are regarding madwifi code.

So here comes the first one, which incidently is related to the ath5k code as
well.  I was looking at the way the TX descriptor is filled in both drivers
in case RTS/CTS or CTS-to-self is used.  It appears that the HAL may put the
calculated rtsctsDuration value in some control field of the descriptor, if
the chipset supports it.  It also appears there is a flag for asking the
chipset to perform the duration calculation itself, but this is never used
(HAL_TXDESC_DURENA).  In case the retry chain is used, this flag is set for
every alternative rate, I suppose in order for the duration field of
subsequent RTS frames to be updated with the correct value for the alternative
data rate.  Why is this automatic calculation not requested for the first rate
whenever possible?

In ath5k, it seems that automatic calculation is *never* requested, even when
using the retry chain, which is strange, to say the least.  It also appears to
me that the calculated duration value is plainly wrong, considering that the
duration of the data frame is based on the same rate as the CTS frame (which
is set to the maximum basic rate not faster than the data rate).  In addition,
if the duration is not to be updated by the firmware, then RTS frames may hold
a bogus duration field if the subsequent data frame is transmitted with an
alternative rate.

-- 
Information wants to be beer, or something like that.

Re: [Madwifi-devel] AR5523 driver - old Atheros USB

[Luis R. Rodriguez <mcgrof@gm...>]

On Tue, Jul 21, 2009 at 2:42 PM, Christoph Hellwig<hch@...> wrote:
> On Tue, Jul 21, 2009 at 02:24:36PM -0700, Luis R. Rodriguez wrote:
>> >> Hey Chris, was curious if you still had lying around the driver you
>> >> had worked on for the old Atheros 802.11 USB device. Dan asked about
>> >> it, seems he bought one. We at least now have specs for it and can
>> >> provide them to interested developers. Since Dan brought this device
>> >> up figured I'd check to see if you still had it to see if you still
>> >> had the code and might be willing to let someone try to give a shot at
>> >> finishing it up for inclusion. Perhaps staging?
>> >
>> > The code has been at http://verein.lst.de/~hch/ar5523.tgz.
>>
>> Sweet. How functional is this? Does it TX/RX?
>
> It's been quite some time.  IIRC it does TX, but can't actually see
> any packets on RX (filter issue or something).

Sorry for the large cross post, just seeing if someone is interested
in working on a wireless driver. The task would be to try to get
AR5523 USB driver up to speed with mac80211 from wireless-testing and
giving it a shot to fix remaining issues?

It seems to have compiled last for 2.6.23.

If you're interested please remove all lists and only leave
linux-wireless on the reply.

  Luis

Re: [Madwifi-devel] A few questions about TX descriptors and the Sample rate control algorithm

[Derek Smithies <derek@in...>]

On Tue, 21 Jul 2009, Ignacy Gawedzki wrote:

> On Tue, Jul 21, 2009 at 04:45:07PM +1200, thus spake Derek Smithies:
>> Scott's comment about parts of sample looking dodgy is correct.
>> There is not enough coffee in this world to help me recover from the
>> trauma of trying to determine why parts of sample are as they are.
>> --The reasons for the way sample processes the results from
>>    transmitting a packet are not clear.
>> --Indeed, vast chunks of code in sample is not clear.
>
> So I assume you haven't contacted John Bicket...
Correct.
  I have not seen a post from John on the madwifi list for a while now, so 
I assume he has moved on to other projects.

>
> Are you also involved in the minstrel code of the linux-wireless kernel in
> which ath5k is developed?
I have no involvement in this - there has been no need of any input from 
me.


> I'm actually looking at both codebases and it seems that minstrel in
> linux-wireless has been rewritten to fit into the mac80211 framework.
Felix Fietkau did the rework of Minstrel to fit into mac80211. He did a 
good job. There were some things, like coping with cards that don't have a 
retry chain in hardware that I am not sure about. However, the basic 
process of Minstrel is still the same.

> Nevertheless, there remain bits of code that are not very clear to me, but my
> questions regarding it certainly belong to the ath5k-devel mailing-list.
Ask your questions, I am happy to answer them. I would prefer that your 
questions are asked on madwifi list - then my answers are available for 
others to read.

Derek.
-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

[Madwifi-devel] ieee80211_unref_node on NULL node

[Ilya A. Volynets-Evenbakh <ilya@to...>]

Under certain conditions, frames are passed to
ieee80211_input() for VAPs which aren't running.

Change #3621 introduces a fix for it, but when
the function is called with ni_or_null == NULL,
for VAP in IF_DOWN state, the clean-up code tries
to unref NULL ni pointer.

Following is a simple patch to fix that problem:
Index: net80211/ieee80211_input.c
===================================================================
--- net80211/ieee80211_input.c  (revision 4072)
+++ net80211/ieee80211_input.c  (working copy)
@@ -214,7 +214,7 @@

        if ((vap->iv_dev->flags & (IFF_RUNNING | IFF_UP)) !=
                        (IFF_RUNNING | IFF_UP))
-               goto out;
+               goto out2;

        /* Initialize ni as in the previous API. */
        if (ni_or_null == NULL) {
@@ -837,9 +839,11 @@
 err:
        vap->iv_devstats.rx_errors++;
 out:
+       if (ni_or_null == NULL) {
+               ieee80211_unref_node(&ni);
+       }
+out2:
        ieee80211_dev_kfree_skb(&skb);
-       if (ni_or_null == NULL)
-               ieee80211_unref_node(&ni);
        return type;
 #undef HAS_SEQ
 }


-- 
Ilya A. Volynets-Evenbakh
http://www.total-knowledge.com

Re: [Madwifi-devel] A few questions about TX descriptors and the Sample rate control algorithm

[Ignacy Gawedzki <madwifi@qu...>]

On Tue, Jul 21, 2009 at 04:45:07PM +1200, thus spake Derek Smithies:
> Scott's comment about parts of sample looking dodgy is correct.
> There is not enough coffee in this world to help me recover from the  
> trauma of trying to determine why parts of sample are as they are.
> --The reasons for the way sample processes the results from
>    transmitting a packet are not clear.
> --Indeed, vast chunks of code in sample is not clear.

So I assume you haven't contacted John Bicket...

Are you also involved in the minstrel code of the linux-wireless kernel in
which ath5k is developed?

I'm actually looking at both codebases and it seems that minstrel in
linux-wireless has been rewritten to fit into the mac80211 framework.
Nevertheless, there remain bits of code that are not very clear to me, but my
questions regarding it certainly belong to the ath5k-devel mailing-list.

-- 
Sex on TV doesn't hurt....unless you fall off.