On Mon, 2007-02-05 at 12:45 -0500, Michael Wu wrote:
> Okay then, let's not use fake frames then.
:)
> Let's make monitor interfaces
> resemble monitoring ethernet a little more by reporting both RXed frames and
> TXed frames. *BSD does this too and it makes running ethereal on monitor
> interfaces much more useful.
We do this right now afaik.
> TX frame reporting can be done simply in the
> ieee80211_tx_status call, allowing the TX status to be reported on real
> frames.
I don't quite understand this comment. TX status reporting should go via
nl80211.
> Doing this is actually somewhat orthogonal to packet injection via netlink or
> monitor interface, but if we are reporting TXed frames with a radiotap
> header, we might as well allow frame injection with a radiotap frame for
> consistency.
Well, it hasn't got much merit because for anything useful you'll need
to get state information on nl80211.
johannes
On Mon, 2007-02-05 at 14:55 -0500, Michael Wu wrote:
> 1. Userspace usually expects to send things on network interfaces. The kernel
> usually receives frames from userspace on network interfaces. I don't see the
> point of making an exception for 802.11 frames. (or rather, the potential for
> simpler frame injection code is not enough to justify inventing a new
> interface for doing it)
I guess I'm a purist here and would expect to be able to push frames of
whatever type the interface says it supports, if any. But this breaks,
you'll be pushing some sort of extensible format down there. [1]
Also, assuming that we do transmit software in userspace then has to
parse the
> 2. nl80211/cfg80211 is for configuring interfaces. Everything there is related
> to configuration of wireless interfaces except for the frame injection hook.
> It doesn't look right.
Ok, well, I've removed it for now.
johannes
[1] it would have to be, I'm sure new frame injection requirements will
come up at some point and we can't break old apps
On Monday 05 February 2007 13:14, Johannes Berg wrote:
> > I'm not sure what you mean. The program can get the configuration info it
> > needs from nl80211/cfg80211/WE and send/inject frames through the monitor
> > interface.
>
> Well, I guess I'm saying that wpa_supplicant shouldn't need the monitor
> iface at all since it wants just management frames and we should give
> those to it via netlink to avoid having to add more radiotap foo.
>
Yeah, a monitor interface is overkill for wpa_supplicant. We can make the
IEEE80211_IF_TYPE_MGMT be a sort of filtered monitor interface optimized for
userspace MLME. Or maybe add some sort of filtering configuration for monitor
interfaces.. might be overkill. Anyway, netlink does not seem appropriate for
sending or receiving frames.
-Michael Wu
On Mon, 2007-02-05 at 13:14 -0500, Michael Wu wrote:
> Where? I don't remember getting TX frames when running ethereal on a monitor
> interface.
Ok, maybe it's missing. I think I saw them, but not sure. They do show
up on wmaster ;)
> If we report TXed frames at the point when the driver calls
> ieee80211_tx_status, we know whether or not an ack was received. This
> information can be added to the TX frame that is reported to the monitor
> interface.
Oh but do we really want to report them that late? I wouldn't think so.
That would give us out-of-order issues wrt. the air...
> I'm not sure what you mean. The program can get the configuration info it
> needs from nl80211/cfg80211/WE and send/inject frames through the monitor
> interface.
Well, I guess I'm saying that wpa_supplicant shouldn't need the monitor
iface at all since it wants just management frames and we should give
those to it via netlink to avoid having to add more radiotap foo.
johannes
On Mon, 05 Feb 2007 19:14:28 +0100, Johannes Berg wrote:
> Oh but do we really want to report them that late? I wouldn't think so.
> That would give us out-of-order issues wrt. the air...
No. It's the other way around, when they're reported immediately, they
will be out of order. ieee80211_tx_status is called from the interrupt
handler as the result of the frame being actually sent. Before that, a
frame can sit for an arbitrary long time in the hw queue or not sent at
all. Reporting only frames confirmed by ieee80211_tx_status as
successfully sent at the time the function is called reflects better
what is on the air (it's still not perfect as things like
retransmissions are not caught).
> Well, I guess I'm saying that wpa_supplicant shouldn't need the monitor
> iface at all since it wants just management frames and we should give
> those to it via netlink to avoid having to add more radiotap foo.
Agreed.
Jiri
--
Jiri Benc
SUSE Labs
On Monday 05 February 2007 14:24, Johannes Berg wrote:
> On Mon, 2007-02-05 at 14:23 -0500, Michael Wu wrote:
> > Anyway, netlink does not seem appropriate for
> > sending or receiving frames.
>
> Care to explain why you think so?
>
1. Userspace usually expects to send things on network interfaces. The kernel
usually receives frames from userspace on network interfaces. I don't see the
point of making an exception for 802.11 frames. (or rather, the potential for
simpler frame injection code is not enough to justify inventing a new
interface for doing it)
2. nl80211/cfg80211 is for configuring interfaces. Everything there is related
to configuration of wireless interfaces except for the frame injection hook.
It doesn't look right.
-Michael Wu
On Mon, 2007-02-05 at 19:29 +0100, Jiri Benc wrote:
> No. It's the other way around, when they're reported immediately, they
> will be out of order. ieee80211_tx_status is called from the interrupt
> handler as the result of the frame being actually sent. Before that, a
> frame can sit for an arbitrary long time in the hw queue or not sent at
> all. Reporting only frames confirmed by ieee80211_tx_status as
> successfully sent at the time the function is called reflects better
> what is on the air (it's still not perfect as things like
> retransmissions are not caught).
Yeah, you're right. Then again, it doesn't matter all that much since if
you want exact timing you need a card that never transmits in monitor
mode anyway.
johannes
On Mon, 05 Feb 2007 18:49:55 +0100, Johannes Berg wrote:
> > Let's make monitor interfaces
> > resemble monitoring ethernet a little more by reporting both RXed frames and
> > TXed frames. *BSD does this too and it makes running ethereal on monitor
> > interfaces much more useful.
>
> We do this right now afaik.
AFAIK we report RXed frames only.
> > TX frame reporting can be done simply in the
> > ieee80211_tx_status call, allowing the TX status to be reported on real
> > frames.
>
> I don't quite understand this comment. TX status reporting should go via
> nl80211.
I think Michael meant that an elegant way for sending also TXed frames
to monitor interfaces is to do that in ieee80211_tx_status. Makes sense
to me.
Jiri
--
Jiri Benc
SUSE Labs
On Mon, Feb 05, 2007 at 07:29:58PM +0100, Jiri Benc wrote:
> No. It's the other way around, when they're reported immediately, they
> will be out of order. ieee80211_tx_status is called from the interrupt
> handler as the result of the frame being actually sent. Before that, a
> frame can sit for an arbitrary long time in the hw queue or not sent at
> all. Reporting only frames confirmed by ieee80211_tx_status as
> successfully sent at the time the function is called reflects better
> what is on the air (it's still not perfect as things like
> retransmissions are not caught).
What is your definition for "successfully sent" in this context? I would
probably also include frames that did not receive ACK, but did have some
transmit tries. If there is place for reporting TX status (ack/no ack,
number of retries) that could be added here. In addition, some hardware
designs may also return the timestamp of the transmission in TX status,
so that could also be added. This would actually make it possible to
figure out the exact sequence of frames (in userspace app), if needed.
--
Jouni Malinen PGP id EFC895FA
On Monday 05 February 2007 12:49, Johannes Berg wrote:
> > Let's make monitor interfaces
> > resemble monitoring ethernet a little more by reporting both RXed frames
> > and TXed frames. *BSD does this too and it makes running ethereal on
> > monitor interfaces much more useful.
>
> We do this right now afaik.
>
Where? I don't remember getting TX frames when running ethereal on a monitor
interface.
> > TX frame reporting can be done simply in the
> > ieee80211_tx_status call, allowing the TX status to be reported on real
> > frames.
>
> I don't quite understand this comment. TX status reporting should go via
> nl80211.
>
If we report TXed frames at the point when the driver calls
ieee80211_tx_status, we know whether or not an ack was received. This
information can be added to the TX frame that is reported to the monitor
interface.
> > Doing this is actually somewhat orthogonal to packet injection via
> > netlink or monitor interface, but if we are reporting TXed frames with a
> > radiotap header, we might as well allow frame injection with a radiotap
> > frame for consistency.
>
> Well, it hasn't got much merit because for anything useful you'll need
> to get state information on nl80211.
>
I'm not sure what you mean. The program can get the configuration info it
needs from nl80211/cfg80211/WE and send/inject frames through the monitor
interface.
-Michael Wu
On Mon, 2007-02-05 at 14:23 -0500, Michael Wu wrote:
> Anyway, netlink does not seem appropriate for
> sending or receiving frames.
Care to explain why you think so?
johannes