[clarification request] ieee80211_tx_control.pkt_type

[clarification request] ieee80211_tx_control.pkt_type

[Johannes Berg]

Hey,

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"...

johannes

Re: [clarification request] ieee80211_tx_control.pkt_type

[Jouni Malinen]

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 Malinen                                            PGP id EFC895FA

Re: [clarification request] ieee80211_tx_control.pkt_type

[Johannes Berg]

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

RE: [clarification request] ieee80211_tx_control.pkt_type

[Simon Barber]

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:johannes@sipsolutions.net] 
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

RE: [clarification request] ieee80211_tx_control.pkt_type

[Johannes Berg]

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