rt61 and TSF reporting?

rt61 and TSF reporting?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

Hi,

Is there any way to get rt61 to report the receive timestamp? That would
be very useful for monitor mode and good for IBSS.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rt61 and TSF reporting?

[Ivo van Doorn]

Hi,

> Is there any way to get rt61 to report the receive timestamp? That would
> be very useful for monitor mode and good for IBSS.

The specsheets say nothing about TSF timestamps anywhere else then
the registers (which is accessed by the get_tsf() callback function).
To be more exact, the specsheets say _nothing_ about the RXD descriptors at all,
which means they are not helpful for that. ;)

However there are a few RXD fields which are labeled as "reserved" which could
mean the field is present, just not documented.

You could try printing the values of those words to see if they contain valid data,
and to be more exact the TSF data (this can be done in the function rt61pci_fill_rxdone(...))
The undocumented/reserved words are: 6 to 15

Do you want me to come up with a patch for this?

Note that these undocumented fields only are present in rt2500pci and rt61pci.
Neither rt2500usb or rt73usb contain them, which means that they can't report the TSF
based on descriptor information.

Ivo

Re: rt61 and TSF reporting?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Hi,

> The specsheets say nothing about TSF timestamps anywhere else then
> the registers (which is accessed by the get_tsf() callback function).
> To be more exact, the specsheets say _nothing_ about the RXD descriptors at all,
> which means they are not helpful for that. ;)

Heh.

> However there are a few RXD fields which are labeled as "reserved" which could
> mean the field is present, just not documented.
> 
> You could try printing the values of those words to see if they contain valid data,
> and to be more exact the TSF data (this can be done in the function rt61pci_fill_rxdone(...))
> The undocumented/reserved words are: 6 to 15
> 
> Do you want me to come up with a patch for this?
> 
> Note that these undocumented fields only are present in rt2500pci and rt61pci.

Ok cool, I'll play with that, I should be able to make a patch myself,
thanks.

> Neither rt2500usb or rt73usb contain them, which means that they can't report the TSF
> based on descriptor information.

So I guess they just don't transfer those reserved fields on USB.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rt61 and TSF reporting?

[Ivo van Doorn]

On Tuesday 01 July 2008, Johannes Berg wrote:
> Hi,
> 
> > The specsheets say nothing about TSF timestamps anywhere else then
> > the registers (which is accessed by the get_tsf() callback function).
> > To be more exact, the specsheets say _nothing_ about the RXD descriptors at all,
> > which means they are not helpful for that. ;)
> 
> Heh.
> 
> > However there are a few RXD fields which are labeled as "reserved" which could
> > mean the field is present, just not documented.
> > 
> > You could try printing the values of those words to see if they contain valid data,
> > and to be more exact the TSF data (this can be done in the function rt61pci_fill_rxdone(...))
> > The undocumented/reserved words are: 6 to 15
> > 
> > Do you want me to come up with a patch for this?
> > 
> > Note that these undocumented fields only are present in rt2500pci and rt61pci.
> 
> Ok cool, I'll play with that, I should be able to make a patch myself,
> thanks.

Oh wait, just found a reference about those RXD words:

 * The following fields are for DMA block and HOST usage only.
 * Can't be touched by ASIC MAC block.

In other words, they are for driver usage only. :S

> > Neither rt2500usb or rt73usb contain them, which means that they can't report the TSF
> > based on descriptor information.
> 
> So I guess they just don't transfer those reserved fields on USB.

Which means they are pretty much screwed for TSF handling since get_tsf() has been disabled
for USB drivers due to the atomic requirements of that callback function.. :S

Ivo

Re: rt61 and TSF reporting?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]


> > > Note that these undocumented fields only are present in rt2500pci and rt61pci.
> > 
> > Ok cool, I'll play with that, I should be able to make a patch myself,
> > thanks.
> 
> Oh wait, just found a reference about those RXD words:
> 
>  * The following fields are for DMA block and HOST usage only.
>  * Can't be touched by ASIC MAC block.
> 
> In other words, they are for driver usage only. :S

The only ones that are ever non-zero are 0, 1, 4 and 5. Guess not then.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rt61 and TSF reporting?

[Ivo van Doorn]

On Tuesday 01 July 2008, Johannes Berg wrote:
> 
> > > > Note that these undocumented fields only are present in rt2500pci and rt61pci.
> > > 
> > > Ok cool, I'll play with that, I should be able to make a patch myself,
> > > thanks.
> > 
> > Oh wait, just found a reference about those RXD words:
> > 
> >  * The following fields are for DMA block and HOST usage only.
> >  * Can't be touched by ASIC MAC block.
> > 
> > In other words, they are for driver usage only. :S
> 
> The only ones that are ever non-zero are 0, 1, 4 and 5. Guess not then.

4 contains data?
2 and 3 I understand since HW crypto is disabled in wireless-testing,
but that should mean that 4 should also be 0 unless my estimation about
it being the ICV field is wrong...

What data is in there?

Ivo

Re: rt61 and TSF reporting?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On Tue, 2008-07-01 at 13:15 +0200, Ivo van Doorn wrote:
> On Tuesday 01 July 2008, Johannes Berg wrote:
> > 
> > > > > Note that these undocumented fields only are present in rt2500pci and rt61pci.
> > > > 
> > > > Ok cool, I'll play with that, I should be able to make a patch myself,
> > > > thanks.
> > > 
> > > Oh wait, just found a reference about those RXD words:
> > > 
> > >  * The following fields are for DMA block and HOST usage only.
> > >  * Can't be touched by ASIC MAC block.
> > > 
> > > In other words, they are for driver usage only. :S
> > 
> > The only ones that are ever non-zero are 0, 1, 4 and 5. Guess not then.
> 
> 4 contains data?
> 2 and 3 I understand since HW crypto is disabled in wireless-testing,
> but that should mean that 4 should also be 0 unless my estimation about
> it being the ICV field is wrong...
> 
> What data is in there?

Heh. I was connected to an encrypted AP with a different device and
monitoring the traffic no that channel, and got the following:

[139528.433872] rt61pci rx word 4: 0x60483004
[139528.433882] rt61pci rx word 5: 0x012c30a8
[139528.468947] rt61pci rx word 4: 0x60483004
[139528.468956] rt61pci rx word 5: 0x01566138
[139528.571350] rt61pci rx word 4: 0x60483004
[139528.571361] rt61pci rx word 5: 0x1dba1048
[139528.673744] rt61pci rx word 4: 0x60483004
[139528.673753] rt61pci rx word 5: 0x18e02078
[139528.776153] rt61pci rx word 4: 0x60483004
[139528.776165] rt61pci rx word 5: 0x01568018
[139528.878538] rt61pci rx word 4: 0x60483004
[139528.878549] rt61pci rx word 5: 0x072a9048

In fact, through the whole uptime of the card word 4 never changed, so
maybe it's just bogus data from the disabled hwcrypto engine.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rt61 and TSF reporting?

[Ivo van Doorn]

On Tuesday 01 July 2008, Johannes Berg wrote:
> On Tue, 2008-07-01 at 13:15 +0200, Ivo van Doorn wrote:
> > On Tuesday 01 July 2008, Johannes Berg wrote:
> > > 
> > > > > > Note that these undocumented fields only are present in rt2500pci and rt61pci.
> > > > > 
> > > > > Ok cool, I'll play with that, I should be able to make a patch myself,
> > > > > thanks.
> > > > 
> > > > Oh wait, just found a reference about those RXD words:
> > > > 
> > > >  * The following fields are for DMA block and HOST usage only.
> > > >  * Can't be touched by ASIC MAC block.
> > > > 
> > > > In other words, they are for driver usage only. :S
> > > 
> > > The only ones that are ever non-zero are 0, 1, 4 and 5. Guess not then.
> > 
> > 4 contains data?
> > 2 and 3 I understand since HW crypto is disabled in wireless-testing,
> > but that should mean that 4 should also be 0 unless my estimation about
> > it being the ICV field is wrong...
> > 
> > What data is in there?
> 
> Heh. I was connected to an encrypted AP with a different device and
> monitoring the traffic no that channel, and got the following:
> 
> [139528.433872] rt61pci rx word 4: 0x60483004
> [139528.433882] rt61pci rx word 5: 0x012c30a8
> [139528.468947] rt61pci rx word 4: 0x60483004
> [139528.468956] rt61pci rx word 5: 0x01566138
> [139528.571350] rt61pci rx word 4: 0x60483004
> [139528.571361] rt61pci rx word 5: 0x1dba1048
> [139528.673744] rt61pci rx word 4: 0x60483004
> [139528.673753] rt61pci rx word 5: 0x18e02078
> [139528.776153] rt61pci rx word 4: 0x60483004
> [139528.776165] rt61pci rx word 5: 0x01568018
> [139528.878538] rt61pci rx word 4: 0x60483004
> [139528.878549] rt61pci rx word 5: 0x072a9048
> 
> In fact, through the whole uptime of the card word 4 never changed, so
> maybe it's just bogus data from the disabled hwcrypto engine.

Ok, I'll run some experiments with HW crypto enabled and see if the value
is different for each frame in there.

Ivo

Re: rt61 and TSF reporting?

[Ivo van Doorn]

Hi,

> Is there any way to get rt61 to report the receive timestamp? That would
> be very useful for monitor mode and good for IBSS.

I just received an answer from Ralink about this issue,

---
1.       For 11b/g based chips rt2500, rt2570, rt61, rt73 doesn't implement this.

2.       For 11n based chips, there is one MAC register have to enable to have this feature.
	  But, Word 2 of RXWI will put the timestamp and the RSSI will put to Word 3.
	 The original Word 3 SNR will disappear and replace by RSSI.
---

As for the timestamps in 2400 and rt2800, they are both in 32bits, so I am not sure how
reliable they will be for IBSS.

Ivo

Re: rt61 and TSF reporting?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]


> I just received an answer from Ralink about this issue,

Cool.

> 1.       For 11b/g based chips rt2500, rt2570, rt61, rt73 doesn't implement this.

Oh, too bad.

> 2.       For 11n based chips, there is one MAC register have to enable to have this feature.
> 	  But, Word 2 of RXWI will put the timestamp and the RSSI will put to Word 3.
> 	 The original Word 3 SNR will disappear and replace by RSSI.

Nice.

> As for the timestamps in 2400 and rt2800, they are both in 32bits, so I am not sure how
> reliable they will be for IBSS.

Well 32-bits is plenty if you can also read the TSF to extend it to 64,
b43 only gets 16 by the firmware and we just extend it on packet RX.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rt61 and TSF reporting?

[Ivo van Doorn]

On Friday 04 July 2008, Johannes Berg wrote:
> 
> > I just received an answer from Ralink about this issue,
> 
> Cool.
> 
> > 1.       For 11b/g based chips rt2500, rt2570, rt61, rt73 doesn't implement this.
> 
> Oh, too bad.
> 
> > 2.       For 11n based chips, there is one MAC register have to enable to have this feature.
> > 	  But, Word 2 of RXWI will put the timestamp and the RSSI will put to Word 3.
> > 	 The original Word 3 SNR will disappear and replace by RSSI.
> 
> Nice.
> 
> > As for the timestamps in 2400 and rt2800, they are both in 32bits, so I am not sure how
> > reliable they will be for IBSS.
> 
> Well 32-bits is plenty if you can also read the TSF to extend it to 64,
> b43 only gets 16 by the firmware and we just extend it on packet RX.

Ok, I'll update rt2x00 so rt2400pci can already start reporting the timestamp,
I assume the timestamp reporting is more important then reporting the SNR,
because apparenly for rt2800 we can only get one of those. :S

Ivo