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
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
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
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
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
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
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
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 <[email protected]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
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
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
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
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