RE: [clarification request] ieee80211_tx_control.pkt_type
On Fri, 2006-08-18 at 09:25 -0700, Simon Barber wrote: It might be appropriate to change it from pkt_type to a flag indicating that a timestamp should be added at TX time add_timestamp. This may well also end up being used for beacons too on hardware where the beacons are completely software generated. I'll leave that to you or Jouni, was merely asking about the uses :) Thanks, johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [clarification request] ieee80211_tx_control.pkt_type
On Fri, Aug 18, 2006 at 01:41:57PM +0200, Johannes Berg wrote: I was pondering the ieee80211_tx_control type and don't see anyone using the pkt_type field. d80211 makes great effort to have it correct, but no driver uses it. Hence, my question: What is the purpose of this field? Under what circumstances would a driver have to know this? Especially considering that it's only normal vs. probe response... Some hardware designs require this configuration for TX frames. It is used to select whether some of the fields are being filled in hardware (e.g., timestamp for Probe Response). This would only be needed for AP mode and IBSS (adhoc), so it is possible that not all low-level dirvers have yet been implemented to support such operation. This pkt_type was added at generic 802.11 layer in order to avoid forcing the low-level driver to even look at the 802.11 header when queuing the frame for transmission. Taken into account how simple operation it is to get the type and subtype from the frame control field, this tx ctrl pkt_type could be removed, if desired. However, it was added there for a reason. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [clarification request] ieee80211_tx_control.pkt_type
On Fri, 2006-08-18 at 07:33 -0700, Jouni Malinen wrote: Some hardware designs require this configuration for TX frames. It is used to select whether some of the fields are being filled in hardware (e.g., timestamp for Probe Response). Ah ok, timestamp makes sense. This would only be needed for AP mode and IBSS (adhoc), so it is possible that not all low-level dirvers have yet been implemented to support such operation. Right. This pkt_type was added at generic 802.11 layer in order to avoid forcing the low-level driver to even look at the 802.11 header when queuing the frame for transmission. Taken into account how simple operation it is to get the type and subtype from the frame control field, this tx ctrl pkt_type could be removed, if desired. However, it was added there for a reason. No, that's ok, I was just wondering why it is there at all. Thanks for clarifying, johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [clarification request] ieee80211_tx_control.pkt_type
It might be appropriate to change it from pkt_type to a flag indicating that a timestamp should be added at TX time add_timestamp. This may well also end up being used for beacons too on hardware where the beacons are completely software generated. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 7:51 AM To: Jouni Malinen Cc: netdev@vger.kernel.org; Simon Barber; Jiri Benc Subject: Re: [clarification request] ieee80211_tx_control.pkt_type On Fri, 2006-08-18 at 07:33 -0700, Jouni Malinen wrote: Some hardware designs require this configuration for TX frames. It is used to select whether some of the fields are being filled in hardware (e.g., timestamp for Probe Response). Ah ok, timestamp makes sense. This would only be needed for AP mode and IBSS (adhoc), so it is possible that not all low-level dirvers have yet been implemented to support such operation. Right. This pkt_type was added at generic 802.11 layer in order to avoid forcing the low-level driver to even look at the 802.11 header when queuing the frame for transmission. Taken into account how simple operation it is to get the type and subtype from the frame control field, this tx ctrl pkt_type could be removed, if desired. However, it was added there for a reason. No, that's ok, I was just wondering why it is there at all. Thanks for clarifying, johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
