Thread: [Madwifi-devel] Specific questions on HAL/Atheros MAC behavior in hardware
Status: Beta
Brought to you by:
otaku
From: David B. <dbe...@ze...> - 2004-08-19 01:40:22
|
Hi, Just pulled down the merged WPA version of the driver. As some more specific questions in addition to looking for a technical spec.: 1: Can anybody describe under what circumstances the receiving HAL/Atheros chipset will not transmit an ACK for received data? I assume it won't transmit an ACK to a multicast or broadcast packet. Similarly not for a beacon, and for management frames. Are there any others? 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set for AP mode does that mean that PIFS is used before transmitting, or only when transmitting a beacon frame? Under what circumstances will the HAL/chips use a PIFS or SIFS for a queued tx packet descriptor? 3: Does anybody have an estimate of the delay in processing from the time a packet is received in the phy to the time a transmit interrupt is generated? 4: The latest driver looks like it honors the beacon cfp duration field by setting the most recently received value into the HAL. That is, NAV management appears to be under software control. However there is a comment in the source that tends to make me believe that NAV management is in the hardware. Something to the effect that the hardware honors PCF with respect to cfp duration in station mode. Is this under software control and not honored in AP mode? Thinking about possible DoS situations. Any help is appreciated. Thanks, David Beberman |
From: Mathieu L. <Mat...@so...> - 2004-08-19 08:55:19
|
On Thu, 2004-08-19 at 03:12, David Beberman wrote: > Just pulled down the merged WPA version of the driver. > As some more specific questions in addition to looking for a technical spec.: > > 1: Can anybody describe under what circumstances the receiving HAL/Atheros > chipset will not transmit an ACK for received data? I assume it won't transmit > an ACK to a multicast or broadcast packet. Similarly not for a beacon, and for yes. > management frames. Are there any others? I don't think there are others. Generally, the hardware is 802.11-compliant which means it should closely follow what the 802.11 spec requires and the examples you gave above are clearly specified by the spec. > > 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set for AP > mode does that mean that PIFS is used before transmitting, or only when > transmitting a beacon frame? Under what circumstances will the HAL/chips use a > PIFS or SIFS for a queued tx packet descriptor? > > 3: Does anybody have an estimate of the delay in processing from the time a > packet is received in the phy to the time a transmit interrupt is generated? what does "transmit interrupt is generated" means ? I assume you are interested in the delay between the time the last bit of a packet is received and the time the reception interrupt handler of the driver runs ? If so, this is obviously really hard to quantify since the biggest culprit here is the linux kernel, which, as far as I can tell, is not a hard real-time OS which means it can not offer such fixed-delay guarantees. > > 4: The latest driver looks like it honors the beacon cfp duration field by > setting the most recently received value into the HAL. That is, NAV management > appears to be under software control. However there is a comment in the source > that tends to make me believe that NAV management is in the hardware. Something > to the effect that the hardware honors PCF with respect to cfp duration in > station mode. Hardware handles NAV management. ie: it updates the NAV counter for each frame received and uses this counter when contending for the medium. Mathieu -- Mathieu Lacage <mat...@so...> |
From: David B. <dbe...@ze...> - 2004-08-19 17:57:15
|
Mathieu Lacage wrote: >On Thu, 2004-08-19 at 03:12, David Beberman wrote: > > > >>Just pulled down the merged WPA version of the driver. >>As some more specific questions in addition to looking for a technical spec.: >> >>1: Can anybody describe under what circumstances the receiving HAL/Atheros >>chipset will not transmit an ACK for received data? I assume it won't transmit >>an ACK to a multicast or broadcast packet. Similarly not for a beacon, and for >> >> > >yes. > > > >>management frames. Are there any others? >> >> > >I don't think there are others. Generally, the hardware is >802.11-compliant which means it should closely follow what the 802.11 >spec requires and the examples you gave above are clearly specified by >the spec. > > Thanks for the response. > > >>2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set for AP >>mode does that mean that PIFS is used before transmitting, or only when >>transmitting a beacon frame? Under what circumstances will the HAL/chips use a >>PIFS or SIFS for a queued tx packet descriptor? >> >>3: Does anybody have an estimate of the delay in processing from the time a >>packet is received in the phy to the time a transmit interrupt is generated? >> >> > >what does "transmit interrupt is generated" means ? I assume you are >interested in the delay between the time the last bit of a packet is >received and the time the reception interrupt handler of the driver runs >? If so, this is obviously really hard to quantify since the biggest >culprit here is the linux kernel, which, as far as I can tell, is not a >hard real-time OS which means it can not offer such fixed-delay >guarantees. > > Agreed that the kernel controls the interrupt handler latency. I was interested in the time until a hardware interrupt is generated. I goofed on the question. I meant the time until the receiving side generates an rx interrupt with a full descriptor buffer after the packet has been received in the phy. > > >>4: The latest driver looks like it honors the beacon cfp duration field by >>setting the most recently received value into the HAL. That is, NAV management >>appears to be under software control. However there is a comment in the source >>that tends to make me believe that NAV management is in the hardware. Something >>to the effect that the hardware honors PCF with respect to cfp duration in >>station mode. >> >> > >Hardware handles NAV management. ie: it updates the NAV counter for each >frame received and uses this counter when contending for the medium. > > Thanks for the response. >Mathieu > > |
From: Sam L. <sa...@er...> - 2004-08-19 17:54:36
|
On Aug 18, 2004, at 6:12 PM, David Beberman wrote: > Hi, > > Just pulled down the merged WPA version of the driver. > As some more specific questions in addition to looking for a technical > spec.: > > 1: Can anybody describe under what circumstances the receiving > HAL/Atheros > chipset will not transmit an ACK for received data? I assume it won't > transmit > an ACK to a multicast or broadcast packet. Similarly not for a > beacon, and for > management frames. Are there any others? The chip follows 802.11 in acking frames. > > 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set > for AP > mode does that mean that PIFS is used before transmitting, or only when > transmitting a beacon frame? Under what circumstances will the > HAL/chips use a > PIFS or SIFS for a queued tx packet descriptor? Again it follows the spec. There are mechanisms for altering the IFS parameters on a per h/w tx-q basis but the existing mechanism (setTxQParameters) has some problems that will be addressed soon as part of wme/wsm work. > > 3: Does anybody have an estimate of the delay in processing from the > time a > packet is received in the phy to the time a transmit interrupt is > generated? Huh? rx -> tx interrupt? Understand also that there are many different parts and a question like this is likely chip+bus+software dependent. > > > 4: The latest driver looks like it honors the beacon cfp duration > field by > setting the most recently received value into the HAL. That is, NAV > management > appears to be under software control. However there is a comment in > the source > that tends to make me believe that NAV management is in the hardware. > Something > to the effect that the hardware honors PCF with respect to cfp > duration in > station mode. All parts will honor CFP if the hardware is programmed properly. I don't believe the current code does this. The comment refers to the fact that the part will not transmit during CFP but to do this right it needs some parameters programmed into the hardware from the CFParameters element in the received beacon. > > Is this under software control and not honored in AP mode? > Thinking about possible DoS situations. Is what under software control? In AP operation CFP is specified by the AP so your question doesn't make a lot of sense (unless you''re thinking of overlapping BSS's using CFP in which case you should read the 802.11 spec). Sam |
From: David B. <dbe...@ze...> - 2004-08-19 19:18:06
|
Sam Leffler wrote: > On Aug 18, 2004, at 6:12 PM, David Beberman wrote: > >> Hi, >> >> Just pulled down the merged WPA version of the driver. >> As some more specific questions in addition to looking for a >> technical spec.: >> >> 1: Can anybody describe under what circumstances the receiving >> HAL/Atheros >> chipset will not transmit an ACK for received data? I assume it won't >> transmit >> an ACK to a multicast or broadcast packet. Similarly not for a >> beacon, and for >> management frames. Are there any others? > > > The chip follows 802.11 in acking frames. I assume that is the 802.11 1999 MAC? > >> >> 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set >> for AP >> mode does that mean that PIFS is used before transmitting, or only when >> transmitting a beacon frame? Under what circumstances will the >> HAL/chips use a >> PIFS or SIFS for a queued tx packet descriptor? > > > Again it follows the spec. There are mechanisms for altering the IFS > parameters on a per h/w tx-q basis but the existing mechanism > (setTxQParameters) has some problems that will be addressed soon as > part of wme/wsm work. In ah.h I can find setTxQueueProps. Assuming you are referring to that. Looking forward to those changes. > >> >> 3: Does anybody have an estimate of the delay in processing from the >> time a >> packet is received in the phy to the time a transmit interrupt is >> generated? > > > Huh? rx -> tx interrupt? Understand also that there are many different > parts and a question like this is likely chip+bus+software dependent. Yes, I meant receive path interrupt line latency from the hardware to the CPU. I'm assuming a PCI bus for my work, but just wanted to know what the delay in PHY and MAC processing in the Atheros chipset was before the rx interrupt is signalled. Sorry for the confusion and typo. > >> >> >> 4: The latest driver looks like it honors the beacon cfp duration >> field by >> setting the most recently received value into the HAL. That is, NAV >> management >> appears to be under software control. However there is a comment in >> the source >> that tends to make me believe that NAV management is in the hardware. >> Something >> to the effect that the hardware honors PCF with respect to cfp >> duration in >> station mode. > > > All parts will honor CFP if the hardware is programmed properly. I > don't believe the current code does this. The comment refers to the > fact that the part will not transmit during CFP but to do this right > it needs some parameters programmed into the hardware from the > CFParameters element in the received beacon. Reading what you wrote, it seems to imply that if the CFParameter element is not written back into the hardware through the Hal, then the hardware will not honor the cfp period. This is what i'm actually looking for by the way. If this is true, don't fix it. > >> >> Is this under software control and not honored in AP mode? >> Thinking about possible DoS situations. > > > Is what under software control? In AP operation CFP is specified by > the AP so your question doesn't make a lot of sense (unless you''re > thinking of overlapping BSS's using CFP in which case you should read > the 802.11 spec). Yes I was thinking about situations like overlapping BSS's and other things. I am aware of the paragraphs in the spec. about handling those situations essentially using random backoff. If my response about your CFParameters comment is correct, then what I'm looking for is already addressed. Thanks for your responses Sam. > > Sam > > |
From: David B. <dbe...@ze...> - 2004-08-20 18:47:05
|
Sam Leffler wrote: > On Aug 18, 2004, at 6:12 PM, David Beberman wrote: > >> Hi, >> >> Just pulled down the merged WPA version of the driver. >> As some more specific questions in addition to looking for a >> technical spec.: >> >> 1: Can anybody describe under what circumstances the receiving >> HAL/Atheros >> chipset will not transmit an ACK for received data? I assume it won't >> transmit >> an ACK to a multicast or broadcast packet. Similarly not for a >> beacon, and for >> management frames. Are there any others? > > > The chip follows 802.11 in acking frames. Not to belabor this question, but is there anyway to prevent the receiving side from ACKing a unicast dataframe right now? > >> >> 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set >> for AP >> mode does that mean that PIFS is used before transmitting, or only when >> transmitting a beacon frame? Under what circumstances will the >> HAL/chips use a >> PIFS or SIFS for a queued tx packet descriptor? > > > Again it follows the spec. There are mechanisms for altering the IFS > parameters on a per h/w tx-q basis but the existing mechanism > (setTxQParameters) has some problems that will be addressed soon as > part of wme/wsm work. > >> >> 3: Does anybody have an estimate of the delay in processing from the >> time a >> packet is received in the phy to the time a transmit interrupt is >> generated? > > > Huh? rx -> tx interrupt? Understand also that there are many different > parts and a question like this is likely chip+bus+software dependent. > >> >> >> 4: The latest driver looks like it honors the beacon cfp duration >> field by >> setting the most recently received value into the HAL. That is, NAV >> management >> appears to be under software control. However there is a comment in >> the source >> that tends to make me believe that NAV management is in the hardware. >> Something >> to the effect that the hardware honors PCF with respect to cfp >> duration in >> station mode. > > > All parts will honor CFP if the hardware is programmed properly. I > don't believe the current code does this. The comment refers to the > fact that the part will not transmit during CFP but to do this right > it needs some parameters programmed into the hardware from the > CFParameters element in the received beacon. > >> >> Is this under software control and not honored in AP mode? >> Thinking about possible DoS situations. > > > Is what under software control? In AP operation CFP is specified by > the AP so your question doesn't make a lot of sense (unless you''re > thinking of overlapping BSS's using CFP in which case you should read > the 802.11 spec). > > Sam > > |
From: Sam L. <sa...@er...> - 2004-08-20 21:21:04
|
On Friday 20 August 2004 11:46 am, David Beberman wrote: > Sam Leffler wrote: > > On Aug 18, 2004, at 6:12 PM, David Beberman wrote: > >> Hi, > >> > >> Just pulled down the merged WPA version of the driver. > >> As some more specific questions in addition to looking for a > >> technical spec.: > >> > >> 1: Can anybody describe under what circumstances the receiving > >> HAL/Atheros > >> chipset will not transmit an ACK for received data? I assume it won't > >> transmit > >> an ACK to a multicast or broadcast packet. Similarly not for a > >> beacon, and for > >> management frames. Are there any others? > > > > The chip follows 802.11 in acking frames. > > Not to belabor this question, but is there anyway to prevent the > receiving side from ACKing a unicast dataframe right now? There is a mechanism to turn off all h/w ACKs (for diagnostic purposes) that I want to expose in a future hal. No ETA. Sam |
From: David B. <dbe...@ze...> - 2004-08-20 19:09:31
|
Sam Leffler wrote: > On Aug 18, 2004, at 6:12 PM, David Beberman wrote: > >> Hi, >> >> Just pulled down the merged WPA version of the driver. >> As some more specific questions in addition to looking for a >> technical spec.: >> >> 1: Can anybody describe under what circumstances the receiving >> HAL/Atheros >> chipset will not transmit an ACK for received data? I assume it won't >> transmit >> an ACK to a multicast or broadcast packet. Similarly not for a >> beacon, and for >> management frames. Are there any others? > > > The chip follows 802.11 in acking frames. Please disregard last message. Believe we have a solution to our problem. > >> >> 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set >> for AP >> mode does that mean that PIFS is used before transmitting, or only when >> transmitting a beacon frame? Under what circumstances will the >> HAL/chips use a >> PIFS or SIFS for a queued tx packet descriptor? > > > Again it follows the spec. There are mechanisms for altering the IFS > parameters on a per h/w tx-q basis but the existing mechanism > (setTxQParameters) has some problems that will be addressed soon as > part of wme/wsm work. > >> >> 3: Does anybody have an estimate of the delay in processing from the >> time a >> packet is received in the phy to the time a transmit interrupt is >> generated? > > > Huh? rx -> tx interrupt? Understand also that there are many different > parts and a question like this is likely chip+bus+software dependent. > >> >> >> 4: The latest driver looks like it honors the beacon cfp duration >> field by >> setting the most recently received value into the HAL. That is, NAV >> management >> appears to be under software control. However there is a comment in >> the source >> that tends to make me believe that NAV management is in the hardware. >> Something >> to the effect that the hardware honors PCF with respect to cfp >> duration in >> station mode. > > > All parts will honor CFP if the hardware is programmed properly. I > don't believe the current code does this. The comment refers to the > fact that the part will not transmit during CFP but to do this right > it needs some parameters programmed into the hardware from the > CFParameters element in the received beacon. > >> >> Is this under software control and not honored in AP mode? >> Thinking about possible DoS situations. > > > Is what under software control? In AP operation CFP is specified by > the AP so your question doesn't make a lot of sense (unless you''re > thinking of overlapping BSS's using CFP in which case you should read > the 802.11 spec). > > Sam > > |
From: David B. <dbe...@ze...> - 2004-08-20 22:29:48
|
I've been continuing to dig through the source code. Beacons look like they are setup with ath_beacon_setup() to tell the HAL. It then looks like the HAL does an interrupt HAL_INT_SWBA periodically to ask the driver to generate a beacon. In ath_beacon_tasklet, the beacon frame is queued on the beacon task queue and the queue is started with ath_hal_txstart. My question is: If a beacon is queued to the beacon task queue and started without the beacon setup and subsequent interrupt, will it still be transmitted, and specifically under PCF rules? Thanks David Beberman |
From: Sam L. <sa...@er...> - 2004-08-21 04:01:37
|
On Aug 20, 2004, at 3:29 PM, David Beberman wrote: > I've been continuing to dig through the source code. > Beacons look like they are setup with ath_beacon_setup() to tell the > HAL. > It then looks like the HAL does an interrupt HAL_INT_SWBA periodically > to ask the driver to generate a beacon. > In ath_beacon_tasklet, the beacon frame is queued on the beacon task > queue and > the queue is started with ath_hal_txstart. > My question is: > If a beacon is queued to the beacon task queue and started without the > beacon setup > and subsequent interrupt, will it still be transmitted, and > specifically under PCF rules? The hal does not deliver SWBA, the hardware does. SWBA is a signal to the host to ready a beacon frame for the next time a beacon should be transmitted. Frames queued on the beacon transmit queue are gated by the hardware beacon timer. If you don't setup the timer then no frames will be transmitted. PCF is irrelevant here. If you are trying to implement PCF you have a lot of work on your hands as the Atheros hardware provides no help; you'll have to do everything in software. Sam |