After my recent patch drivers can now tell the stack that a frame was
damaged. That doesn't do much good, however, if the user cannot tell the
stack to generate such frames. But we need to go level by level so first
mac80211 needs to know about it.
After some discussion and review of Daniel's document (thanks!) we came
up with the following ideas:
1)
Define new filter flags
* FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
* FIF_ALLMULTI (all multicast frames are allowed through)
* FIF_BROADCAST (broadcast frames are allowed through)
* FIF_FCSFAIL (frames with bad FCS are allowed through)
* FIF_PLCPFAIL (frames with bad PLCP checksum are allowed through)
* FIF_CONTROL (control frames are shown)
* FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
other filters)
[missing anything?]
It should be permitted to silently 'upgrade', say if a driver can't
support PROMISC_IN_BSS but only get all packets then it does that
instead, but PROMISC_IN_BSS is still useful if possible.
2)
Remove IEEE80211_HW_MONITOR_DURING_OPER, it becomes useless; same with
soft monitor mode interface stuff
3)
When a monitor interface is added, set FIF_OTHER_BSS and FIF_CONTROL;
depending on the interface flags set FIF_PROMISC_IN_BSS, FIF_MCAST,
FIF_BCAST. No longer tell drivers about monitor interfaces with
add_interface/remove_interface, but rather call set_multicast_list()
with changed flags when a monitor interface comes on.
4)
Change the "int flags" argument to the set_multicast_list callback to
"int *flags" so drivers can indicate whether they supported a flag or
not by clearing all flags they did not honour. Additional advantage:
drivers break and people will be forced to re-examine their code to use
the new flags.
5) [FUTURE]
Introduce cfg80211/nl80211 API to ask for bad FCS/bad PLCP on a monitor
interface.
johannes
Johannes Berg wrote:
> > A bunch
> > of parameters are already set with a single function, only config
> > and config_interface need to be replaced by parameter-specific
> > functions. Reset should be removed.
>
> Not sure what reset is for.
Now, we are at least two.
> > add_interface() and
> > remove_interface() are comparable to my enable_mac() and
> > disable_mac() as you discovered.
>
> Aha, but they're not fully compatible. First of all, you were talking
> about multiple MACs which isn't something we're going to support
> (multiple MAC addresses yes).
I would state we should the support the functionality that the
device supports. Everything else is "form follows function".
> Secondly, a WDS and AP interface will be
> running with the same MAC address but have quite different
> configuration. Thirdly, always doing lookups by MAC address (even if it
> were possible which it is not due to WDS vs AP) is rather inefficient.
The MAC address lookup issue could be handled.
Assuming that the device would be able to create beacons on a
specific MAC address, would it need to know about WDS or AP mode?
> > Tell the driver on the real interface, which packets it should
> > report to the mac80211 stack.
>
> That's what I proposed.
>
> > Don't bother the driver with virtual
> > interfaces. The stack should handle it completely transparently.
>
> What I'm trying to explain to you is that basically you cannot do that.
> AP vs WDS interfaces, lookups by MAC address, beaconing, ...
Beaconing needs to be supported by the device. AP and WDS are
working on the same MAC address, but why should the people know
about it. It doesn't look into the packets transmitted.
> > Don't call the driver before open() or after stop() is called.
>
> Do we do that? In any case, it's rather orthogonal to the issue at hand.
Sure. Some drivers support the configuration of the channel before
the device is up. There has been the request for the zd1211rw
driver to shadow the configuration in the device data structure.
But I believe that is something the stack should handle.
Ciao,
Uli
--
Uli Kunitz
On Sat, 2007-08-04 at 00:09 +0200, Johannes Berg wrote:
> 4)
> Change the "int flags" argument to the set_multicast_list callback to
> "int *flags" so drivers can indicate whether they supported a flag or
> not by clearing all flags they did not honour. Additional advantage:
> drivers break and people will be forced to re-examine their code to use
> the new flags.
Hmm. I think this is confusing because set_multicast_list is also a
netdev callback. Maybe we should do the flags in another callback after
all? Just so people who've written a regular net driver won't be
confused.
johannes
Hi,
> * FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
> * FIF_ALLMULTI (all multicast frames are allowed through)
> * FIF_BROADCAST (broadcast frames are allowed through)
> * FIF_FCSFAIL (frames with bad FCS are allowed through)
> * FIF_PLCPFAIL (frames with bad PLCP checksum are allowed through)
> * FIF_CONTROL (control frames are shown)
> * FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
> other filters)
> [missing anything?]
rt2x00 registers have the 2 following entries as well:
Physical error
Version error
The rest of the idea looks pretty good, si I will be happy to implement it for rt2x00. :)
Ivo
[as for the rest of the mail]
> I would suggest something like this:
>
> int (*enable_phy)(struct ieee80211_hw *hw, int flags);
> int (*disable_phy)(struct ieee80211_hw *hw, int flags);
> int (*set_phy_freq)(struct ieee80211_hw *hw, int /* ? */ freq, int flags);
> ...
>
> int (*enable_mac)(struct ieee80211_hw *hw, u8 *mac_addr,
> int filter_flags, int flags);
> int (*disable_mac)(struct ieee80211_hw *hw, u8 *mac_addr);
> int (*set_mac_bssid)(struct ieee80211_hw *hw, u8 *mac_addr, u8 *bssid);
> int (*enable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr,
> struct ieee80211_beacon_config *config);
> int (*disable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr);
> ...
>
> The call sequence could be:
>
> enable_phy
> set_phy_freq
> set_phy_rate
> enable_mac
> set_mac_bssid // For AP this will be the own mac address.
> enable_mac_beacon // first mac address will be master
> enable_mac // for second mac address if needed
> set_mac_bssid // set bssid for second mac
> disable_mac
> disable_mac
> disable_phy
>
> I would make it to a rule that the setter functions could only be
> called if the corresponding layer (phy, mac) has been enabled. All
> the interface semantics for the upper layer should be handled by
> the mac80211 stack including the persistent storage of a frequency
> value before the the device has been brought up.
I don't think I like this. First of all, it's quite a large step away
from how mac80211 operates and thus a lot of work. Secondly, the driver
would continually have to look up things by mac address. As far as I can
tell everything you have there as MAC-level configuration is right now
covered by the add/remove_interface callbacks. And then what you have as
MAC level configuration is rather incomplete by only setting a MAC
address and no other MAC parameters. But as I said, many callbacks don't
make sense unless you have two (lower) MACs in the device which I think
is just a misunderstanding and you only have two MAC *addresses*. So
then mixing PHY and MAC configuration isn't so bad because you have only
one of each anyway. And having per-interface configuration to the driver
covers the remaining things nicely.
johannes
Daniel Drake wrote:
> Johannes Berg wrote:
> >1)
> >Define new filter flags
> > * FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
> > * FIF_ALLMULTI (all multicast frames are allowed through)
> > * FIF_BROADCAST (broadcast frames are allowed through)
> > * FIF_FCSFAIL (frames with bad FCS are allowed through)
> > * FIF_PLCPFAIL (frames with bad PLCP checksum are allowed
> > through)
> > * FIF_CONTROL (control frames are shown)
> > * FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
> > other filters)
> >[missing anything?]
>
> Incase this wasn't clear to anyone else, the proposal is that we add a
> bitfield to the set_multicast_list parameters for the above flags. The
> stack would then 'fabricate' some calls to set_multicast_list.
>
> I like the filter flags concept here, but I think this may be better as
> its own callback, or perhaps we should just rename set_multicast_list to
> configure_filter or something like that.
ACK.
> This also sounds nice to implement from a driver standpoint. After
> documenting how I feel the soft/hard monitor interfaces should behave
> should we have such a system, I'm not keen on the idea of actually
> implementing that.
>
>
> As for the other problems mentioned in followup mails, how about
> something like the following:
>
> A new configure_device callback with these parameters:
> - ieee80211_hw *hw
> - int state: possible values NOCHANGE, ON, OFF
> - int filter_flags: FIF_ flags from above
> - u8 *mac_addr
>
> This would combine the ideas of add_interface, remove_interface and
> open/stop into one.
>
> state: this would become ON when the first interface is brought up, and
> would become OFF when the last interface is brought down. For all other
> calls into this function, state is NOCHANGE
Just my 2 cents: I wonder, how you would handle the situation,
that a device can support two MACs in parallel?
I would suggest two things: Clearly distinguish between PHY layer
and MAC layer functions in the interface and don't do
set_config-like functions at all, because they mix things in an
unclear way. The drivers will have to set all parameters in the
config structures or there must be a flag structure to mark those
values, which need to be updated. Which looks awfully like an
IOCTL-like interface then.
I would suggest something like this:
int (*enable_phy)(struct ieee80211_hw *hw, int flags);
int (*disable_phy)(struct ieee80211_hw *hw, int flags);
int (*set_phy_freq)(struct ieee80211_hw *hw, int /* ? */ freq, int flags);
...
int (*enable_mac)(struct ieee80211_hw *hw, u8 *mac_addr,
int filter_flags, int flags);
int (*disable_mac)(struct ieee80211_hw *hw, u8 *mac_addr);
int (*set_mac_bssid)(struct ieee80211_hw *hw, u8 *mac_addr, u8 *bssid);
int (*enable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr,
struct ieee80211_beacon_config *config);
int (*disable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr);
...
The call sequence could be:
enable_phy
set_phy_freq
set_phy_rate
enable_mac
set_mac_bssid // For AP this will be the own mac address.
enable_mac_beacon // first mac address will be master
enable_mac // for second mac address if needed
set_mac_bssid // set bssid for second mac
disable_mac
disable_mac
disable_phy
I would make it to a rule that the setter functions could only be
called if the corresponding layer (phy, mac) has been enabled. All
the interface semantics for the upper layer should be handled by
the mac80211 stack including the persistent storage of a frequency
value before the the device has been brought up.
This interface would be fitting ZD1211 quite nicely, if all the
functions beside tx would be non-atomic. But I don't know about
the other drivers.
--
Uli Kunitz
On Sat, 2007-08-04 at 00:09 +0200, Johannes Berg wrote:
> depending on the interface flags set FIF_PROMISC_IN_BSS, FIF_MCAST,
> FIF_BCAST.
That should be FIF_ALLMULTI and FIF_BROADCAST.
johannes
On Sun, 2007-08-05 at 11:29 +0200, Ivo van Doorn wrote:
> those could be send to the mac80211 stack without the DECRYPTED flag set.
> It will be up to mac80211 to take another shot at decrypting, send it further upstream as-is
> or just simply drop it.
Come to think of it, that's actually necessary because you may change
keys in hardware but still get packets for the old keys under some
circumstances.
johannes
On Wed, 2007-08-08 at 00:03 +0200, Ulrich Kunitz wrote:
> > Aha, but they're not fully compatible. First of all, you were talking
> > about multiple MACs which isn't something we're going to support
> > (multiple MAC addresses yes).
>
> I would state we should the support the functionality that the
> device supports. Everything else is "form follows function".
But we don't have any devices that have multiple MACs. Yes, we *do* have
devices that support multiple _MAC addresses_ but I don't think any of
them support multiple _MACs_.
> > Secondly, a WDS and AP interface will be
> > running with the same MAC address but have quite different
> > configuration. Thirdly, always doing lookups by MAC address (even if it
> > were possible which it is not due to WDS vs AP) is rather inefficient.
>
> The MAC address lookup issue could be handled.
>
> Assuming that the device would be able to create beacons on a
> specific MAC address, would it need to know about WDS or AP mode?
Say it supports multiple BSSes on a single AP MAC address like many APs
do. Then we have to look up beacons by BSS and other things by MAC
address and it really gets confusing quickly. I think that abstracting
it all down to BSS IDs and MAC addresses gets rather confusing because
the driver authors are also users at the other end and adds interfaces
for testing. If they can see the effect of adding an interface I think
there's a better chance of understanding what's going on.
> Beaconing needs to be supported by the device.
Yes, but how many different beacons does it support? That's something
easily solved by limiting
1) the number of devices to the number of MAC addresses supported
2) the number of AP devices to the number of different beacons
supported
When you start abstracting it down to MAC addresses and BSSIDs these are
IMHO far less clear.
In any case, you're welcome to implement such an API as you're proposing
to demonstrate the feasibility and ease of use. But you probably should
first understand what is possible. And please don't confuse "MAC" and
"MAC address" too much.
johannes
On Sat, 2007-08-04 at 00:09 +0200, Johannes Berg wrote:
> After some discussion and review of Daniel's document (thanks!) we came
> up with the following ideas:
Of course, this also means that drivers now get to keep track of any
added interfaces to program/unprogram the MAC address.
On the other hand, with these changed semantics open/close could make
more sense again since drivers now need not always count interfaces and
monitor interfaces are no longer added/removed to the driver; hence the
open/close callbacks could be used by drivers that allow only one
operating interface at a time.
johannes
On 8/4/07, Ivo van Doorn <[email protected]> wrote:
> Hi,
>
> > * FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
> > * FIF_ALLMULTI (all multicast frames are allowed through)
> > * FIF_BROADCAST (broadcast frames are allowed through)
> > * FIF_FCSFAIL (frames with bad FCS are allowed through)
> > * FIF_PLCPFAIL (frames with bad PLCP checksum are allowed through)
> > * FIF_CONTROL (control frames are shown)
> > * FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
> > other filters)
> > [missing anything?]
>
> rt2x00 registers have the 2 following entries as well:
>
> Physical error
> Version error
>
>
> The rest of the idea looks pretty good, si I will be happy to implement it for rt2x00. :)
>
> Ivo
>
>
What about decryption error ?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, 2007-08-03 at 18:56 -0400, Daniel Drake wrote:
> As for the other problems mentioned in followup mails, how about
> something like the following:
>
> A new configure_device callback with these parameters:
> - ieee80211_hw *hw
> - int state: possible values NOCHANGE, ON, OFF
> - int filter_flags: FIF_ flags from above
> - u8 *mac_addr
>
> This would combine the ideas of add_interface, remove_interface and
> open/stop into one.
That isn't going to work as soon as you have multiple MAC addresses
which I'm told zd1211 supports. Didn't you or Uli just complain that
struct wiphy has only one address?
> state: this would become ON when the first interface is brought up, and
> would become OFF when the last interface is brought down. For all other
> calls into this function, state is NOCHANGE
Why NOCHANGE? The driver surely knows whether it's on or off so just
on/off should be enough.
> Also I was wanting to add communication from mac80211 to the driver
> about supported rates in the ESS (softmac does this, zd1211rw uses this
> info). This would also fall in the same category. And maybe we should
> add the multicast list above too.
Overload IMHO. Let's have a few calls. add/remove_interface are still
required because you still need the if_id to ask the stack for beacons
(IIRC); open/close (can we rename those to start/stop?) can be
well-defined with this instead of having ON/OFF/NOCHANGE flags (NOCHANGE
would just mean no start/stop callback).
Then we can have one call for filtering setup which includes multicast
and filter flags.
> I feel the above would make life fairly easy for drivers, or am I
> over-designing this? Perhaps I am also missing some considerations for
> IBSS/AP mode...
Yeah, for beacons you need to know about the interfaces that were added
to get the beacons.
johannes
On Mon, 2007-08-06 at 23:23 +0200, Ulrich Kunitz wrote:
> I don't think so enable_phy/disable_phy is open and stop.
True. I don't really care what those are named :)
> A bunch
> of parameters are already set with a single function, only config
> and config_interface need to be replaced by parameter-specific
> functions. Reset should be removed.
Not sure what reset is for.
> add_interface() and
> remove_interface() are comparable to my enable_mac() and
> disable_mac() as you discovered.
Aha, but they're not fully compatible. First of all, you were talking
about multiple MACs which isn't something we're going to support
(multiple MAC addresses yes). Secondly, a WDS and AP interface will be
running with the same MAC address but have quite different
configuration. Thirdly, always doing lookups by MAC address (even if it
were possible which it is not due to WDS vs AP) is rather inefficient.
> Tell the driver on the real interface, which packets it should
> report to the mac80211 stack.
That's what I proposed.
> Don't bother the driver with virtual
> interfaces. The stack should handle it completely transparently.
What I'm trying to explain to you is that basically you cannot do that.
AP vs WDS interfaces, lookups by MAC address, beaconing, ...
> Don't call the driver before open() or after stop() is called.
Do we do that? In any case, it's rather orthogonal to the issue at hand.
johannes
On Sat, 2007-08-04 at 09:46 +0200, Ulrich Kunitz wrote:
> Just my 2 cents: I wonder, how you would handle the situation,
> that a device can support two MACs in parallel?
I think you're not thinking about two MACs but rather two MAC addresses,
right? If so, yes, not having multiple MAC addresses was an omission in
cfg80211 that should be fixed, but I don't think it makes sense to
actually have two full MACs.
johannes
On Sat, 2007-08-04 at 00:25 +0200, Johannes Berg wrote:
> On the other hand, with these changed semantics open/close could make
> more sense again
In fact, it seems it will be required because drivers won't be told
about new monitor interfaces, and keeping track of add_interface *and*
the new flags seems a bit tough especially since some flags could still
be set when a monitor interface goes down. Or something.
johannes
Somebody in the thread at some point said:
> After my recent patch drivers can now tell the stack that a frame was
> damaged. That doesn't do much good, however, if the user cannot tell the
> stack to generate such frames. But we need to go level by level so first
> mac80211 needs to know about it.
>
> After some discussion and review of Daniel's document (thanks!) we came
> up with the following ideas:
I don't know enough abut the insides of the drivers and stack to have
any useful opinion on the details of the implementation as Ulrich has.
Definitely the additional functionality and the granularity of the
filtering that can eventually be requested (if not delivered on by any
particular driver) will be really nice. Throwing out the soft Monitor
mode but being able to emulate that and more with the new range of
selections is great. As is making selectability of broken packets
official, eventually.
-Andy
Johannes Berg wrote:
> > I would suggest something like this:
> >
> > int (*enable_phy)(struct ieee80211_hw *hw, int flags);
> > int (*disable_phy)(struct ieee80211_hw *hw, int flags);
> > int (*set_phy_freq)(struct ieee80211_hw *hw, int /* ? */ freq, int flags);
> > ...
> >
> > int (*enable_mac)(struct ieee80211_hw *hw, u8 *mac_addr,
> > int filter_flags, int flags);
> > int (*disable_mac)(struct ieee80211_hw *hw, u8 *mac_addr);
> > int (*set_mac_bssid)(struct ieee80211_hw *hw, u8 *mac_addr, u8 *bssid);
> > int (*enable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr,
> > struct ieee80211_beacon_config *config);
> > int (*disable_mac_beacon)(struct ieee80211_hw *hw, u8 *mac_addr);
> > ...
> >
> > The call sequence could be:
> >
> > enable_phy
> > set_phy_freq
> > set_phy_rate
> > enable_mac
> > set_mac_bssid // For AP this will be the own mac address.
> > enable_mac_beacon // first mac address will be master
> > enable_mac // for second mac address if needed
> > set_mac_bssid // set bssid for second mac
> > disable_mac
> > disable_mac
> > disable_phy
> >
> > I would make it to a rule that the setter functions could only be
> > called if the corresponding layer (phy, mac) has been enabled. All
> > the interface semantics for the upper layer should be handled by
> > the mac80211 stack including the persistent storage of a frequency
> > value before the the device has been brought up.
>
> I don't think I like this. First of all, it's quite a large step away
> from how mac80211 operates and thus a lot of work.
I don't think so enable_phy/disable_phy is open and stop. A bunch
of parameters are already set with a single function, only config
and config_interface need to be replaced by parameter-specific
functions. Reset should be removed. add_interface() and
remove_interface() are comparable to my enable_mac() and
disable_mac() as you discovered.
There are two main things I'm asking for:
Tell the driver on the real interface, which packets it should
report to the mac80211 stack. Don't bother the driver with virtual
interfaces. The stack should handle it completely transparently.
Don't call the driver before open() or after stop() is called.
This means of course that the stack would have to maintain all
parameters for the device. The advantage would be that suspend and
resume support would become very easy. The stack would close the
device in suspend() and would open and configure the device in
resume(). These operations would not differ a lot from normal
open and normal stop.
--
Uli Kunitz
On Sunday 05 August 2007, Tomas Winkler wrote:
> On 8/4/07, Ivo van Doorn <[email protected]> wrote:
> > Hi,
> >
> > > * FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
> > > * FIF_ALLMULTI (all multicast frames are allowed through)
> > > * FIF_BROADCAST (broadcast frames are allowed through)
> > > * FIF_FCSFAIL (frames with bad FCS are allowed through)
> > > * FIF_PLCPFAIL (frames with bad PLCP checksum are allowed through)
> > > * FIF_CONTROL (control frames are shown)
> > > * FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
> > > other filters)
> > > [missing anything?]
> >
> > rt2x00 registers have the 2 following entries as well:
> >
> > Physical error
> > Version error
> >
> >
> > The rest of the idea looks pretty good, si I will be happy to implement it for rt2x00. :)
> >
> > Ivo
> >
> >
> What about decryption error ?
those could be send to the mac80211 stack without the DECRYPTED flag set.
It will be up to mac80211 to take another shot at decrypting, send it further upstream as-is
or just simply drop it.
Ivo
Johannes Berg wrote:
> 1)
> Define new filter flags
> * FIF_PROMISC_IN_BSS (BSS filters still on, but otherwise promisc)
> * FIF_ALLMULTI (all multicast frames are allowed through)
> * FIF_BROADCAST (broadcast frames are allowed through)
> * FIF_FCSFAIL (frames with bad FCS are allowed through)
> * FIF_PLCPFAIL (frames with bad PLCP checksum are allowed through)
> * FIF_CONTROL (control frames are shown)
> * FIF_OTHER_BSS (frames from other BSSes are shown, subject to the
> other filters)
> [missing anything?]
Incase this wasn't clear to anyone else, the proposal is that we add a
bitfield to the set_multicast_list parameters for the above flags. The
stack would then 'fabricate' some calls to set_multicast_list.
I like the filter flags concept here, but I think this may be better as
its own callback, or perhaps we should just rename set_multicast_list to
configure_filter or something like that.
This also sounds nice to implement from a driver standpoint. After
documenting how I feel the soft/hard monitor interfaces should behave
should we have such a system, I'm not keen on the idea of actually
implementing that.
As for the other problems mentioned in followup mails, how about
something like the following:
A new configure_device callback with these parameters:
- ieee80211_hw *hw
- int state: possible values NOCHANGE, ON, OFF
- int filter_flags: FIF_ flags from above
- u8 *mac_addr
This would combine the ideas of add_interface, remove_interface and
open/stop into one.
state: this would become ON when the first interface is brought up, and
would become OFF when the last interface is brought down. For all other
calls into this function, state is NOCHANGE
filter_flags: Johannes' proposal above
mac_addr: if NULL, do not do anything. Otherwise, change the device MAC
address to the one provided. This may be provided as all-zeros in some
situations.
During a fairly standard session, the callback would be called in the
following ways:
Device gets plugged in, registers interface. Default managed wlan0 gets
created.
User brings wlan0 up.
-> callback called with (hw, ON, default FIF, device MAC)
-> driver powers up device, sets mac address and filtering
User creates new additional monitor interface and brings it up
-> callback called with (hw, NOCHANGE, new FIF, NULL)
-> driver changes filtering params
User deletes managed interface (wlan0)
-> callback called with(hw, NOCHANGE, maybe new FIF?, 0x000000000000)
-> driver changes filtering params and writes zero mac addr
User deletes monitor interface
-> callback called with (hw, OFF, dontcare, dontcare)
-> driver powers down device
After thinking through the above, I wonder if we should also roll
config_interface into this: also pass in a BSSID for RX filtering
purposes (or NULL of no change required).
Also I was wanting to add communication from mac80211 to the driver
about supported rates in the ESS (softmac does this, zd1211rw uses this
info). This would also fall in the same category. And maybe we should
add the multicast list above too.
I feel the above would make life fairly easy for drivers, or am I
over-designing this? Perhaps I am also missing some considerations for
IBSS/AP mode...
Daniel
Ulrich Kunitz wrote:
> Just my 2 cents: I wonder, how you would handle the situation,
> that a device can support two MACs in parallel?
I think that mac80211 would need quite a bit more work (in places like
TX and RX path) to support devices with "multiple radios" (or
pseudo-radios) anyway. Of course, I'm just speculating on how such
hardware could/would operate. While we don't have any, I'm not sure it's
worth increasing complexity so much to accommodate this.
Daniel