This ioctl is used when radar is delected on a channel. Data frames must stop
but management frames must be allowed to continue for some time to communicate
the channel switch to stations.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: linux-2.6.16/net/d80211/hostapd_ioctl.h
On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:
> This ioctl is used when radar is delected on a channel. Data frames must stop
> but management frames must be allowed to continue for some time to communicate
> the channel switch to stations.
Which does lead to the question: How are you d
On Wed, 23 Aug 2006 09:25:06 +0200, Johannes Berg wrote:
> Should that really drop dataframes dead on the floor? And wouldn't it
> make sense stop the networking layer from injecting more data into the
> stack when stop_data_frame_tx is enabled?
I agree. That should be solved in an another way (st
ginal Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Wednesday, August 23, 2006 12:25 AM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch 5/5] d80211: add ioctl to stop data frame tx
On Tue, 2006-08-22 at 10:34
Hi Jiri (and Johannes),
Jiri Benc <[EMAIL PROTECTED]> writes:
> On Wed, 23 Aug 2006 09:25:06 +0200, Johannes Berg wrote:
> > Should that really drop dataframes dead on the floor? And wouldn't it
> > make sense stop the networking layer from injecting more data into the
> > stack when stop_data_fr
Hi Johannes,
Johannes Berg <[EMAIL PROTECTED]> writes:
> On Tue, 2006-08-22 at 10:34 -0700, David Kimdon wrote:
> > This ioctl is used when radar is delected on a channel. Data
> > frames must stop but management frames must be allowed to continue
> > for some time to communicate the channel swi
Hi Elliot,
Thanks for the explanation.
> Radar is initially detected by the low-level radio driver. Userspace
> gets notified of radar via calls to ieee80211_radar_status, which
> generates a "fake" management frame with a struct ieee80211_radar_info
> in it. Userspace is then responsible for
On Tue, Aug 29, 2006 at 09:30:57AM +0200, Johannes Berg wrote:
> > Radar is initially detected by the low-level radio driver. Userspace
> > gets notified of radar via calls to ieee80211_radar_status, which
> > generates a "fake" management frame with a struct ieee80211_radar_info
> > in it. User
On Tue, Aug 29, 2006 at 07:45:23AM -0400, John W. Linville wrote:
> On Tue, Aug 29, 2006 at 09:30:57AM +0200, Johannes Berg wrote:
> > I think that would warrant a new netlink multicast group and doing over
> > nl80211 to start with ;) Inserting fake management frames into the mgt
> > interface so
On Tue, 2006-08-29 at 11:39 -0700, Jouni Malinen wrote:
> What would be the preferred way of doing the conversion here? I think I
> would prefer to get the radar detection code in as-is and then move all
> the messages to use a new mechanism as one change once that mechanism
> becomes available.
On Wed, Aug 30, 2006 at 09:26:21AM +0200, Johannes Berg wrote:
> On Tue, 2006-08-29 at 11:39 -0700, Jouni Malinen wrote:
>
> > What would be the preferred way of doing the conversion here? I think I
> > would prefer to get the radar detection code in as-is and then move all
> > the messages to use
On Wed, 2006-08-30 at 09:01 -0700, Jouni Malinen wrote:
> Well, it would be nice to get these in quite soon. I know that the
> current mechanism works since it has been used for years, but if the
> netlink-based solution is considered stable and working and unlikely to
> require major changes soon
On Tue, 22 Aug 2006 10:34:19 -0700, David Kimdon wrote:
> This ioctl is used when radar is delected on a channel. Data frames must stop
> but management frames must be allowed to continue for some time to communicate
> the channel switch to stations.
Any progress here? Is what Simon wrote (quoted
13 matches
Mail list logo
