mac80211 driver interface semantics

mac80211 driver interface semantics

[Daniel Drake]

There has been some recent confusion as to how monitor interfaces should 
operate, how multiple interfaces should be handled by drivers, and how 
MAC addresses should be handled.

Based on some recent discussions, and what bcm43xx does, I started 
writing some documentation:

http://www.linuxwireless.org/en/developers/mac80211/semantics

Discuss :)
I probably made some mistakes. Corrections are very welcome.

Thanks,
Daniel

Re: mac80211 driver interface semantics

[Ulrich Kunitz]

Daniel Drake wrote:

> There has been some recent confusion as to how monitor interfaces should 
> operate, how multiple interfaces should be handled by drivers, and how 
> MAC addresses should be handled.
> 
> Based on some recent discussions, and what bcm43xx does, I started 
> writing some documentation:
> 
> http://www.linuxwireless.org/en/developers/mac80211/semantics

This is a certainly a very good idea. If the description is
accepted by the wireless developers, I would also suggest to
update the documentation comments in the kernel accordingly.

As far as I know the phy0/add_iface entry can be used to add a new
interface. Notify though the "file" has write access for other,
you will need network admin capabilities, which is satisfied by
being root. For example:

# cat mon0 >/sys/class/net/wmaster0/phy80211/add_iface
# iwconfig mon0 mode monitor
# iwcondig mon0 up

Notify that /sys/class/net/wmaster0/phy80211 is a symbolic link.

> Discuss :)
> I probably made some mistakes. Corrections are very welcome.

I think you should mention IEEE80211_HW_MONITOR_DURING_OPER in the
description of the monitor modes. There are some comments to be
found in the mac80211.h header in the kernel.

-- 
Uli Kunitz

Re: mac80211 driver interface semantics

[Andy Green]

Somebody in the thread at some point said:

> As far as I know the phy0/add_iface entry can be used to add a new
> interface. Notify though the "file" has write access for other,
> you will need network admin capabilities, which is satisfied by
> being root. For example:
> 
> # cat mon0 >/sys/class/net/wmaster0/phy80211/add_iface

echo -n mon0 ... ;-)

you can also come at this through

/sys/class/ieee80211/phy<n>/add_iface

Nice idea to document it Daniel.  Seeing it written down makes it a
little more obviously "huh?" about the hard and soft monitor distinction
IMO.  There seems to be some agreement that in the future the number of
virtual interfaces that happen to be lying around shouldn't determine
the functionality of Monitor mode like that.

-Andy

Re: mac80211 driver interface semantics

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Fri, 2007-08-03 at 08:59 +0100, Andy Green wrote:

> There seems to be some agreement that in the future the number of
> virtual interfaces that happen to be lying around shouldn't determine
> the functionality of Monitor mode like that.

I think that only happens if you don't have monitor_during_oper set;
otherwise it's a bug.

I am, however, not entirely sure we should be forwarding packets with
failed CRC on hard monitor interfaces. Because if you have both a hard
monitor and a regular interface (monitor_during_oper allowed) then we
will never check the CRC on frames that enter the networking path and
can get corrupted TCP packets in etc.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: mac80211 driver interface semantics

[Joerg Mayer]

On Fri, Aug 03, 2007 at 11:54:54AM +0200, Johannes Berg wrote:
> On Fri, 2007-08-03 at 08:59 +0100, Andy Green wrote:
>
> > There seems to be some agreement that in the future the number of
> > virtual interfaces that happen to be lying around shouldn't determine
> > the functionality of Monitor mode like that.
>
> I think that only happens if you don't have monitor_during_oper set;
> otherwise it's a bug.
>
> I am, however, not entirely sure we should be forwarding packets with
> failed CRC on hard monitor interfaces. Because if you have both a hard
> monitor and a regular interface (monitor_during_oper allowed) then we
> will never check the CRC on frames that enter the networking path and
> can get corrupted TCP packets in etc.

Having that as a configurable option that defaults to off (no invalid
frames) would be the ideal solution :-)

Ciao
     Joerg
--
Joerg Mayer                                           <jmayer@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

Re: mac80211 driver interface semantics

[Andy Green]

Somebody in the thread at some point said:
> On Fri, 2007-08-03 at 08:59 +0100, Andy Green wrote:
> 
>> There seems to be some agreement that in the future the number of
>> virtual interfaces that happen to be lying around shouldn't determine
>> the functionality of Monitor mode like that.
> 
> I think that only happens if you don't have monitor_during_oper set;
> otherwise it's a bug.
> 
> I am, however, not entirely sure we should be forwarding packets with
> failed CRC on hard monitor interfaces. Because if you have both a hard
> monitor and a regular interface (monitor_during_oper allowed) then we
> will never check the CRC on frames that enter the networking path and
> can get corrupted TCP packets in etc.

Hm well outside of that question I don't think failed CRC packets should
be on by default for Monitor mode.  It should be something you can ask
for explicitly if you are interested.

Inside that question, if you mark up skb->ip_summed with CHECKSUM_NONE,
include/linux/skbuff.h says this:

/* A. Checksumming of received packets by device.
 *
 *      NONE: device failed to checksum this packet.
 *              skb->csum is undefined.

If we mark up the skb with FCS-broken packets with that, maybe it would
be compatible with the networking stack for this purpose.

-Andy

Re: mac80211 driver interface semantics

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Fri, 2007-08-03 at 11:27 +0100, Andy Green wrote:

> Inside that question, if you mark up skb->ip_summed with CHECKSUM_NONE,
> include/linux/skbuff.h says this:
> 
> /* A. Checksumming of received packets by device.
>  *
>  *      NONE: device failed to checksum this packet.
>  *              skb->csum is undefined.
> 
> If we mark up the skb with FCS-broken packets with that, maybe it would
> be compatible with the networking stack for this purpose.

No, that's the IP checksum. It may or may not be broken if the FCS CRC
fails.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: mac80211 driver interface semantics

[Andy Green]

Somebody in the thread at some point said:
> On Fri, 2007-08-03 at 11:27 +0100, Andy Green wrote:
> 
>> Inside that question, if you mark up skb->ip_summed with CHECKSUM_NONE,
>> include/linux/skbuff.h says this:
>>
>> /* A. Checksumming of received packets by device.
>>  *
>>  *      NONE: device failed to checksum this packet.
>>  *              skb->csum is undefined.
>>
>> If we mark up the skb with FCS-broken packets with that, maybe it would
>> be compatible with the networking stack for this purpose.
> 
> No, that's the IP checksum. It may or may not be broken if the FCS CRC
> fails.

Right, but since we marked up the skb "the integrity of the IP checksum
is unknown", if anything wants to use the packet it should re-check it
itself.  Won't that do?

-Andy

Re: mac80211 driver interface semantics

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Fri, 2007-08-03 at 11:35 +0100, Andy Green wrote:

> Right, but since we marked up the skb "the integrity of the IP checksum
> is unknown", if anything wants to use the packet it should re-check it
> itself.  Won't that do?

It'll check the IP checksum anyway since we don't have hardware that
checks it as far as I know, but we want to check the FCS.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: mac80211 driver interface semantics

[Andy Green]

Somebody in the thread at some point said:
> On Fri, 2007-08-03 at 11:35 +0100, Andy Green wrote:
> 
>> Right, but since we marked up the skb "the integrity of the IP checksum
>> is unknown", if anything wants to use the packet it should re-check it
>> itself.  Won't that do?
> 
> It'll check the IP checksum anyway since we don't have hardware that
> checks it as far as I know, but we want to check the FCS.

I guess I didn't understand where the problem can come from, then.

''Because if you have both a hard monitor and a regular interface
(monitor_during_oper allowed) then we will never check the CRC on frames
that enter the networking path and can get corrupted TCP packets in etc.''

If the rest of the networking stack didn't trust the packet anyway and
confirms the IP-level checksum, then it can make its own opinion about
the packet.

For stuff that is looking at the whole rx packet including the ieee80211
header, we can add a bit in the radiotap flags on top of the packet
noting that it failed FCS.

-Andy

Re: mac80211 driver interface semantics

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Fri, 2007-08-03 at 11:49 +0100, Andy Green wrote:

> ''Because if you have both a hard monitor and a regular interface
> (monitor_during_oper allowed) then we will never check the CRC on frames
> that enter the networking path and can get corrupted TCP packets in etc.''
> 
> If the rest of the networking stack didn't trust the packet anyway and
> confirms the IP-level checksum, then it can make its own opinion about
> the packet.

Maybe it helps if I add that the FCS covers more of the packet than the
IP checksum; hence, if the FCS fails due to a bit in the area the IP
checksum does not cover we will not ACK the packet and get a
retransmission, but the IP checksum will check out as good and we'll
have a duplicate packet.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: mac80211 driver interface semantics

[Andy Green]

Somebody in the thread at some point said:
> On Fri, 2007-08-03 at 11:49 +0100, Andy Green wrote:
> 
>> ''Because if you have both a hard monitor and a regular interface
>> (monitor_during_oper allowed) then we will never check the CRC on frames
>> that enter the networking path and can get corrupted TCP packets in etc.''
>>
>> If the rest of the networking stack didn't trust the packet anyway and
>> confirms the IP-level checksum, then it can make its own opinion about
>> the packet.
> 
> Maybe it helps if I add that the FCS covers more of the packet than the
> IP checksum; hence, if the FCS fails due to a bit in the area the IP
> checksum does not cover we will not ACK the packet and get a
> retransmission, but the IP checksum will check out as good and we'll
> have a duplicate packet.

Fair enough, thanks for the explanation.

-Andy