Re: [PATCH v2 net-next] net: netlink: Update attr validation to require exact length for some types
Well.. This did not go well with gmail defaults and the mailing list.. Sending this with something safer and plaintext only version to get this on the mailing list as well: On Wed, Nov 8, 2017 at 7:59 AM, David Ahern <dsah...@gmail.com> wrote: > Attributes using NLA_U* and NLA_S* (where * is 8, 16,32 and 64) are > expected to be an exact length. Split these data types from > nla_attr_minlen into nla_attr_len and update validate_nla to require > the attribute to have exact length for them. While I understand and support this change in general, I have to note that this resulted in some unfortunate user space regressions that came apparent when testing Wi-Fi with Linux 4.15-rc1. When a new nl80211 attribute was added for controlling SMPS modes in 2014 the kernel contribution added this with NLA_U8 policy while the user space contribution to hostapd used NLA_PUT_U32. This has apparently been unnoticed until now since the first byte contained the appropriate value on little endian devices (no one testing this on big endian hosts?).. I'll obviously fix the encoding of this attribute in hostapd, but it should be noted that Linux 4.15 will result in significant functionality issues if the kernel is updated without a user space fix going in first. -- Jouni MalinenPGP id EFC895FA
Re: [PATCH] bridge: Add support for IEEE 802.11 Proxy ARP for IPv6
On Fri, Feb 24, 2017 at 11:55:37AM -0800, Stephen Hemminger wrote: > The concept is fine. Thanks for taking a look. > Please add some comments to the code about what is happening and why. > The proposed patch is too sparse and has no comments. Sure, will do that for the next version. > > + skb = alloc_skb(hlen + sizeof(struct ipv6hdr) + sizeof(*msg) + > > + ndisc_opt_addr_space(dev, > > +NDISC_NEIGHBOUR_ADVERTISEMENT) + > > + tlen, GFP_ATOMIC); > > + if (!skb) > > + return; > > Why not netdev_alloc_skb which takes care of padding and setting skb->dev? This implementation in br_ndisc_send_na() was trying to follow ndisc_send_na() design for the operations.. If this function remains (see below), I can clean this up further. > Rather than doing copy/paste of the code to generate a ND message, it would > be better to have one function in IPv6 code that handles that. That would keep > from having to fix code in two places in the future. Is there some way > to extend ndisc_send_na? That was the original plan and adding the target_lladdr part would be straightforward. The part that gets complex is in figuring out how to use a foreign link layer source address (the MAC address on behalf of which the local device is replying) in the outgoing NA when using the IEEE 802.11/Hotspot 2.0 design. ndisc_send_na() uses the full IPv6 stack for building the frame when calling ndisc_send_skb(). dst_output() ends up sending this through ip6_output(), I'd assume, and after building the IPv6 header, the local MAC address of the outgoing interface gets assigned to the Ethernet header. I'm not sure how to override that functionality in any clean way. The dev_hard_header() call in the mostly copy-pasted version in br_ndisc_send_na() followed by use of the custom br_ndisc_send_na_finish() to call dev_queue_xmit(skb) was done to allow the link layer source address to be modified. The normal path in the net stack seemed to use dev_hard_header() with saddr = NULL which maps to eth_header() saddr = NULL case to use device source address. Either those would need to be somehow modified for this special skb containing the NA with different source address requirement or something after these calls would need to modify the frame to change the source address. Would you happen to know any convenient means for modifying the IPv6 stack behavior for ndisc_send_skb() cases conditionally to allow the link layer source address to be modified while still being able to use the existing IPv6 header and the Ethernet header construction function? -- Jouni MalinenPGP id EFC895FA
[PATCH] bridge: Add support for IEEE 802.11 Proxy ARP for IPv6
This is an IPv6 extension of commit 958501163ddd ("bridge: Add support
for IEEE 802.11 Proxy ARP"). The IEEE 802.11 Proxy ARP feature is
defined in IEEE Std 802.11-2012, 10.23.13. It allows the AP devices to
keep track of the hardware-address-to-IP-address mapping of the mobile
devices within the WLAN network.
The AP will learn this mapping via observing NS/NA frames (this part is
implemented in user space, e.g., in hostapd). When a request for such
information is made (i.e., Neighbor Solicitation), the AP will respond
on behalf of the associated mobile device. In the process of doing so,
the AP will drop the multicast request frame that was intended to go out
to the wireless medium.
To meet the Hotspot 2.0 requirement of using the target devices MAC
address as the sender's MAC address in the NA frame (when AP replies on
behalf of an associated station), the full link layer header needs to be
built with a custom function instead of going through the existing
ndisc.c implementation.
Signed-off-by: Jouni Malinen <jo...@codeaurora.org>
---
net/bridge/br_multicast.c | 268 ++
1 file changed, 268 insertions(+)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b760f26..7a375a7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#endif
@@ -1815,6 +1816,272 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
}
#if IS_ENABLED(CONFIG_IPV6)
+static int br_ndisc_send_na_finish(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ return dev_queue_xmit(skb);
+}
+
+void br_ndisc_send_na(struct net_device *dev,
+ const struct in6_addr *daddr,
+ const struct in6_addr *solicited_addr,
+ const u8 *target_lladdr, bool solicited,
+ bool override, const u8 *dest_hw)
+{
+ struct sk_buff *skb;
+ struct nd_msg *msg;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
+ struct dst_entry *dst;
+ struct net *net = dev_net(dev);
+ struct sock *sk = net->ipv6.ndisc_sk;
+ struct inet6_dev *idev;
+ int err;
+ struct ipv6hdr *hdr;
+ struct icmp6hdr *icmp6h;
+ u8 type;
+ const struct in6_addr *saddr = solicited_addr;
+ int pad, data_len, space;
+ u8 *opt;
+
+ skb = alloc_skb(hlen + sizeof(struct ipv6hdr) + sizeof(*msg) +
+ ndisc_opt_addr_space(dev,
+NDISC_NEIGHBOUR_ADVERTISEMENT) +
+ tlen, GFP_ATOMIC);
+ if (!skb)
+ return;
+
+ skb->protocol = htons(ETH_P_IPV6);
+ skb->dev = dev;
+
+ skb_reserve(skb, hlen + sizeof(struct ipv6hdr));
+ skb_reset_transport_header(skb);
+
+ /* Manually assign socket ownership as we avoid calling
+* sock_alloc_send_pskb() to bypass wmem buffer limits
+*/
+ skb_set_owner_w(skb, sk);
+
+ msg = (struct nd_msg *)skb_put(skb, sizeof(*msg));
+ *msg = (struct nd_msg) {
+ .icmph = {
+ .icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT,
+ .icmp6_router = false,
+ .icmp6_solicited = solicited,
+ .icmp6_override = override,
+ },
+ .target = *solicited_addr,
+ };
+
+ /* We are replying on behalf of other entity. Let that entity's
+* address be the target ll addr and src_addr.
+*/
+ pad = ndisc_addr_option_pad(skb->dev->type);
+ data_len = skb->dev->addr_len;
+ space = ndisc_opt_addr_space(skb->dev, NDISC_NEIGHBOUR_ADVERTISEMENT);
+ opt = skb_put(skb, space);
+
+ opt[0] = ND_OPT_TARGET_LL_ADDR;
+ opt[1] = space >> 3;
+
+ memset(opt + 2, 0, pad);
+ opt += pad;
+ space -= pad;
+
+ memcpy(opt + 2, target_lladdr, dev->addr_len);
+ data_len += 2;
+ opt += data_len;
+ space -= data_len;
+ if (space > 0)
+ memset(opt, 0, space);
+
+ dst = skb_dst(skb);
+ icmp6h = icmp6_hdr(skb);
+
+ type = icmp6h->icmp6_type;
+
+ if (!dst) {
+ struct flowi6 fl6;
+
+ icmpv6_flow_init(sk, , type, saddr, daddr,
+skb->dev->ifindex);
+ dst = icmp6_dst_alloc(skb->dev, );
+ if (IS_ERR(dst))
+ goto out;
+
+ skb_dst_set(skb, dst);
+ }
+
+ icmp6h->icmp6_cksum = csum_ipv6_magic(saddr, daddr, skb->len,
+ IPPROTO_ICMPV6,
+ csum_partial(icmp6h,
+ skb->len,
Re: [PATCH] mac80211_hwsim: Added vendor echo command
On Sat, Jun 25, 2016 at 06:08:01PM +0200, Erik Stromdahl wrote: > The mac80211_hwsim driver is currently defining the QCA vendor ID > 0x001374 for some reason. That is used for allowing nl80211 vendor specific commands and events to be tested. The particular vendor command was properly assigned from the QCA 00:13:74 OUI. > Also, all current vendor commands are using the "QCA_" prefix, hence > the reason why I decided to add the new vendor command with the > "QCA_" prefix as well. > > Anyway, I understand that you don't want the hwsim driver bloated > with definitions that does not belong there. That's not the issue here; the issue is in getting vendor subcommands assigned by the entity who controls the OUI that is used. > Is there any reason why hwsim uses the QCA vendor id? Yes, that's an OUI for which there is a process that allows new values to be assigned.. I happen to be the one who is in control of assigning such values. > Perhaps it would be best if the hwsim driver would define its own vendor id? That would need an OUI which are a bit expensive to acquire. I don't see any point for mac80211_hwsim to need a different OUI since there is already a friendly vendor who has provided an OUI that can be used for this type of purposes. In other words, you just need to follow the process defined for assigning unique vendor subcommands/attribute identifiers for this OUI 00:13:74 and that process is what I pointed out in the previous email: > >As far as the QCA vendor specific identifiers are concerned, their > >assignment process is described here: > >http://w1.fi/cgit/hostap/plain/src/common/qca-vendor.h All you need to do is to prepare a hostap.git contribution that requests a new subcommand/attribute to be assigned and once that gets applied to the hostap.git master branch, the values have been assigned and can be used for whatever purpose they were assigned, e.g., in mac80211_hwsim. More details on how to make such a hostap.git contribution: http://w1.fi/cgit/hostap/plain/CONTRIBUTIONS -- Jouni MalinenPGP id EFC895FA
Re: [PATCH] mac80211_hwsim: Added vendor echo command
On Fri, Jun 24, 2016 at 10:13:54AM +0200, Erik Stromdahl wrote:
> The purpose of the echo command is to provide a test
> facility for user space programs.
> diff --git a/drivers/net/wireless/mac80211_hwsim.c
> b/drivers/net/wireless/mac80211_hwsim.c
> @@ -332,14 +332,16 @@ static const struct ieee80211_rate hwsim_rates[] = {
> #define QCA_NL80211_SUBCMD_TEST 1
> +#define QCA_NL80211_SUBCMD_ECHO 2
NAK. That QCA vendor specific value has not been assigned nor have I
even seen a request to assign such a value.
> enum qca_nl80211_vendor_subcmds {
> QCA_WLAN_VENDOR_ATTR_TEST = 8,
> - QCA_WLAN_VENDOR_ATTR_MAX = QCA_WLAN_VENDOR_ATTR_TEST
> + QCA_WLAN_VENDOR_ATTR_ECHO,
And this vendor attribute value has already been assigned for another
purpose.
It is no acceptable to pick arbitrary values of identifiers without
proper request to the owner of the OUI that is used to assign the
values.
As far as the QCA vendor specific identifiers are concerned, their
assignment process is described here:
http://w1.fi/cgit/hostap/plain/src/common/qca-vendor.h
Please do not submit kernel changes that use any unassigned vendor
identifier or even worse, a value that have already been assigned for a
completely different purpose.
--
Jouni MalinenPGP id EFC895FA
Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations
On Mon, Feb 29, 2016 at 05:30:20PM -0500, João Paulo Rechi Vita wrote: > I agree there is a difference in the logic here, thanks for taking the > time to point it out so clearly, and sorry for missing this. But AFAIU > userspace should not call RFKILL_OP_CHANGE with ev.type == > RFKILL_TYPE_ALL, as RFKILL_OP_CHANGE is intended to be used to > block/unblock one RFKill switch, and it is not possible to create a > RFKill switch with type == RFKILL_TYPE_ALL (rfkill_alloc() would > return NULL). Interesting. Maybe Johannes can comment on that part since I think he wrote the code that interacts with kernel for the rfkill test cases. > I tried to look into the source code of the test suite you pointed, > but couldn't easily figure out how it ends up with that combination. > Could you please explain (or point me in the code) how is that a valid > operation? If I'm not missing anything, we should probably return > EINVAL in this case. These specific failures were shown for the test cases in this file: http://w1.fi/cgit/hostap/tree/tests/hwsim/test_rfkill.py The interaction with kernel is done using this code: http://w1.fi/cgit/hostap/tree/tests/hwsim/rfkill.py It does indeed look like TYPE_ALL is used here (the block() and unblock() implementations). If this is incorrect, we can certainly change the script since I'd assume this is not used for anything else than the hwsim test cases (or well who knows, it is available out there, so if someone needs python code to do rfkill operations..). -- Jouni MalinenPGP id EFC895FA
Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations
On Mon, Feb 22, 2016 at 11:36:39AM -0500, João Paulo Rechi Vita wrote:
> Using a switch to handle different ev.op values in rfkill_fop_write()
> makes the code easier to extend, as out-of-range values can always be
> handled by the default case.
This breaks rfkill.. There are automated test scripts for testing this
area (and most of Wi-Fi for that matter. It would be nice if these were
used for changes before they get contributed upstream..
http://buildbot.w1.fi/hwsim/
This specific commit broke all the rfkill_* test cases because of
following:
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> @@ -1199,29 +1200,32 @@ static ssize_t rfkill_fop_write(struct file *file,
> const char __user *buf,
> - list_for_each_entry(rfkill, _list, node) {
> - if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
> - continue;
> -
> - if (rfkill->type != ev.type && ev.type != RFKILL_TYPE_ALL)
> - continue;
Note that RFKILL_TYPE_ALL here..
> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->type == ev.type ||
> + ev.type == RFKILL_TYPE_ALL)
> + rfkill_set_block(rfkill, ev.soft);
It was included for RFKILL_OP_CHANGE_ALL.
> + case RFKILL_OP_CHANGE:
> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->idx == ev.idx && rfkill->type == ev.type)
> + rfkill_set_block(rfkill, ev.soft);
but not for RFKILL_OP_CHANGE..
This needs following to work:
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 59ff92d..c4bbd19 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1239,7 +1239,9 @@ static ssize_t rfkill_fop_write(struct file *file, const
char __user *buf,
break;
case RFKILL_OP_CHANGE:
list_for_each_entry(rfkill, _list, node)
- if (rfkill->idx == ev.idx && rfkill->type == ev.type)
+ if (rfkill->idx == ev.idx &&
+ (rfkill->type == ev.type ||
+ev.type == RFKILL_TYPE_ALL))
rfkill_set_block(rfkill, ev.soft);
ret = 0;
break;
--
Jouni MalinenPGP id EFC895FA
Re: [PATCH 7/7] mac80211: Switch to new AEAD interface
On Mon, Jun 01, 2015 at 05:36:58PM +0200, Stephan Mueller wrote: Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg: IOW, I think something like this would make sense: That looks definitely cleaner :-) Indeed.. That AAD length-in-the-buffer design came from the over ten year old code that was optimized to cover the CCM construction with the same buffer and that was not cleaned up when this was converted to use cryptoapi couple of years ago. Though, my main concern was just to ensure that the aad length value is not zero. It won't be in IEEE 802.11 use cases. The exact length depends on the IEEE 802.11 frame type, but AAD is constructed in a way that it is normally a bit over 20 octets while allowing CCM to fit the related operations into two AES blocks. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: clean up frame receive handling
On Fri, Dec 14, 2007 at 01:13:05PM +0100, Johannes Berg wrote: Is there any way for an user space application to figure out whether a received EAPOL frame was encrypted? In theory, WPA/WPA2 Authenticators (e.g., hostapd) should verify that the frame was encrypted if pairwise keys are set (whereas IEEE 802.1X Authenticator accepts unencrypted EAPOL frames). Unfortunately not. Does that really matter? It seems that the verification whether the frame was encrypted would either be always require encryption when pairwise keys in use (which this patch doesn't do right now but could trivially be done) or simply don't care since it doesn't really matter. In theory, yes, this does matter and the implementation does not comply with the standard if we do not verify this for WPA/WPA2/IEEE 802.11 RSN. However, I do not believe there is any real security issue in not doing so and even worse, some client implementations end up using unencrypted EAPOL frames when they should really be encrypted.. hostapd has a place in the implementation where this information could be processed, but I did not actually ever enable such validation because of the potential interoperability issues. Likewise, wpa_supplicant does not validate this either. In other words, this would be kind of nice to have feature in the kernel interface, but not really something that would be strictly required from security view point. Did you/someone already verify that the Linux bridge code does not bridge EAPOL frames? The use of a separate interface for this removed the need for doing such filtering based on ethertype, but with EAPOL frames using the same netdev with other data frames, the bridge code should filter these out (mainly the PAE group addressed ones, but if I remember correctly, IEEE 802.1X specified all frames using EAPOL ethertype not to be bridged). Actually, 802.1X doesn't specify that, as I said previously it *recommends* it in C.3.3 (not C.1.1 as the 802.11 specs lead you to believe). Also, a patch to do this was rejected by Stephen Hemminger, so I decided to only pass up EAPOL frames that are either for our own unicast address or the link-local eapol address, both of which won't be bridged. It is a must requirement, but apparently only in informative clause of IEEE 802.1X. However, this is a real issue and if the bridging code cannot be changed to do this, so dropping multicast/broadcast EAPOL frames in mac80211 (in both RX and TX direction) sounds reasonable workaround to prevent cases where wireless clients could otherwise mess with other IEEE 802.1X authentications (e.g., for the wired port of an AP). PS. I added the C.3.3 vs. C.1.1 issue to my pending comments for the next IEEE 802.11 maintenance task group (TGmb). Should you find any other issues with IEEE Std 802.11-2007, I can add them to that list so that they can eventually be fixed. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: clean up frame receive handling
On Fri, Dec 14, 2007 at 01:14:03PM +0100, Johannes Berg wrote: I think in theory all eapol frames are sent to the PAE group address, but I have no idea which of the checks would be more efficient. It seems that the first could be optimised a lot because it's constant too... They are not.. PAE group address is used for all EAPOL frames in non-shared media LANs (e.g., wired Ethernet switch), but IEEE 802.11 uses the specific MAC address of the PAE since it is a shared media LAN (i.e., the frames are between the unicast MAC address of the non-AP STA/Supplicant and AP/Authenticator). If we end up having to drop the PAE group addressed EAPOL frames in mac80211 anyway due to Linux bridging code not doing this, we could combine these two validations and just accept the unicast MAC address of the device itself as a valid destination address for received EAPOL frames (and as the only valid source address for transmitted ones). -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PS3: gelic: Add wireless support for PS3
On Sun, Dec 16, 2007 at 12:49:14PM -0500, Dan Williams wrote: Yeah, I was going to propose that on Friday but got side-tracked. What would require a new key type? Are there some firmwares that _only_ accept the WPA passphrase? Because if there aren't (PS3 accepts WPA hex keys too) then the supplicant could just pass the hex key. Not quite sure what you mean here with new key type. It is a new key type regardless of whether it is PSK or passphrase. The current key types (IW_AUTH_CIPHER_*) are WEP40, TKIP, CCMP, and WEP104.. I don't know whether there are any Linux drivers that would use WPA passphrase, but at least the Mac OS X driver interface seems to only use passphrase for WPA-Personal, so it is apparently possible to design such a architecture ;-). Anyway, I would be fine with just adding IW_AUTH_CIPHER_PMK for now (and the new capability to figure out whether this is needed). That PMK would be PSK for WPA-Personal, but it could also be used as PMK for WPA-Enterprise, so the more generic PMK name. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PS3: gelic: Add wireless support for PS3
On Sun, Dec 16, 2007 at 06:10:10PM -0500, Dan Williams wrote: On Sun, 2007-12-16 at 10:11 -0800, Jouni Malinen wrote: It is a new key type regardless of whether it is PSK or passphrase. The current key types (IW_AUTH_CIPHER_*) are WEP40, TKIP, CCMP, and WEP104.. Ah, it's a different key because it's not set _during_ the 4-way handshake, but just sent to the fw directly and the fw handles it, right? There are two cases here, but in both of them, them PMK (i.e., PSK for WPA-Personal) needs to be set just before the 4-way handshake would start. When using WPA-Personal, the PSK would be set just before (or as part of) association request. When using WPA-Enterprise (WPA-EAP), the PMK would be set after having completed IEEE 802.1X/EAP authentication (and the driver/firmware would then take care of 4-way handshake). Both cases will end up disabling the user space supplicant from taking part in 4-way handshake, i.e., it will ignore EAPOL-Key frames should they be delivered through the netdev and expects the driver/firmware to process them. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PS3: gelic: Add wireless support for PS3
On Fri, Dec 14, 2007 at 07:58:47AM -0500, Dan Williams wrote: On Fri, 2007-12-14 at 14:03 +0900, Masakazu Mokuno wrote: The PS3 wireless device does the association and 4way handshake in its firmware/hypervisor. No interventions between them are allowed to the guest OSes. That sort of sucks; but I guess there's not too much you can do about it. That probably means that using wpa_supplicant + WPA is completely out of the picture, which unfortunately makes the PS3 wireless unlike any other card, which would require special-casing the PS3 in userspace tools. The current wpa_supplicant development branch (0.6.x) supports drivers that want to do 4-way handshake in the driver/firmware (e.g., OSX, iPhone, this PS3 driver). In case of WPA-PSK, this doesn't really mean more than just passing through the passphrase/PSK to the association routine, but still, this allows the driver to be configured through wpa_supplicant, if desired. However, there is a part that you are not going to like.. This is likely using a private ioctl for some parts of the association requests, i.e., no -Dwext.. I would assume that this could be cleaned up, though, if WEXT would be extended a bit to allow one more enc_capa to notify whether the driver wants to take care of 4-way handshake and to allow the PSK to be configured with a new key type. PS. It would be interesting to see whether the driver/firmware/hypervisor could be convinced to allow EAPOL frames to go through between association and 4-way handshake (which would be completed by driver/firmware). This is the way I can support WPA/WPA2-Enterprise with OSX.. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: clean up frame receive handling
On Wed, Dec 12, 2007 at 07:24:04PM +0100, Johannes Berg wrote: This cleans up the frame receive handling. After this patch * EAPOL frames addressed to us or the EAPOL group address are always accepted regardless of whether they are encrypted or not * other frames from a station are dropped if PAE is enabled and the station is not authorized Is there any way for an user space application to figure out whether a received EAPOL frame was encrypted? In theory, WPA/WPA2 Authenticators (e.g., hostapd) should verify that the frame was encrypted if pairwise keys are set (whereas IEEE 802.1X Authenticator accepts unencrypted EAPOL frames). Did you/someone already verify that the Linux bridge code does not bridge EAPOL frames? The use of a separate interface for this removed the need for doing such filtering based on ethertype, but with EAPOL frames using the same netdev with other data frames, the bridge code should filter these out (mainly the PAE group addressed ones, but if I remember correctly, IEEE 802.1X specified all frames using EAPOL ethertype not to be bridged). I haven't looked into the current implementations and/or proposed patches on for TX part, but I would assume that it is possible to select whether an EAPOL frame will be encrypted when injecting it(?). -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support for bridging ethernet and 802.11
On Thu, May 10, 2007 at 07:19:35PM +0200, Johannes Berg wrote: Ah forgot about that, I had only thought about AP/wired bridging. How would the prism driver actually do bridging in STA mode though? If that is referring to Host AP driver, there is support for using WDS in client mode. If the AP understands this, the client could use standard frames for its own packets (i.e., SA=own MAC addr) and WDS frames for frames from all other addresses. There are some experimental modes in Host AP driver that (if I remember correctly ;-) may allow this to be used on a single netdev (i.e., no additional netdev needed for the WDS link) and as such, this would look like working layer 2 bridging between wlan0 and eth0 even in managed mode. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support for bridging ethernet and 802.11
On Thu, May 10, 2007 at 07:06:21PM +0200, Johannes Berg wrote: On Thu, 2007-05-10 at 11:18 -0500, Kumar Gala wrote: I'm wondering how to tell if a given driver/device in the kernel supports the ability to bridge between ethernet and 802.11. From searching the web it looks like only the prism driver/device supports this. Normally wireless drivers do 802.3 framing as the 802.11 standard more or less requires, so it should just work. Am I missing something? IEEE 802.11 allows only the own MAC address to be used as the source address (addr2) when operating as a non-AP STA in BSS (client in Managed mode). In other words, layer 2 bridging does not work properly. AP mode and WDS links can be used for bridging without problems, but this will of course require the driver to support these. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HOSTAP] Make debug a run-time option
On Wed, Mar 14, 2007 at 12:03:56PM -0400, Kyle McMartin wrote: Build-time debugging isn't overly useful for distro kernel folks, nor is enabling huge amounts of debug spew by default. Provide the option of enabling debugging with module parameters. While I understand that it would be difficult to change the debug level options with binary distributions, I'm not sure whether I would like to see these changes going in. PRISM2_NO_DEBUG was added to make it possible to reduce the driver size considerably. In addition, the change to the default debug categories (i.e., disable all) may make it more difficult to understand reported issues. I would be more open to disabling debug messages one-by-one if there is something specific that can be agreed to cause more harm than benefit with extra output. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HOSTAP] Make debug a run-time option
On Wed, Mar 14, 2007 at 03:48:00PM -0400, John W. Linville wrote: What about a combined approach? The existing compile-time option could remain while runtime restrictions could be added for when the debug stuff is compiled into the driver? I would be perfectly fine with doing that assuming the default behavior is not changed with this patch (i.e., debugging would be enabled by default). I would consider changing the default setting a separate issue and for that, it might be more worthwhile approach to identify the debug messages that are undesired by default than to disable everything. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Mon, Mar 12, 2007 at 10:56:39AM -0700, Jean Tourrilhes wrote: I would guess that others use iwlib like that too. Which others ? The applications that process scan results can be counted on your fingers. And if you count the one actively developped, you can use one hand. Quick search of SIOCGIWSCAN with Google Code Search (http://www.google.com/codesearch) shows quite large set of uses. Most of them are from various drivers, but at least some (e.g., Xsupplicant, waproamd) are from user space applications. I did not actually verify whether any of these would be affected by the 64/32-bit issue, but I would assume some of the apps are indeed parsing the scan results with internal implementation. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Fri, Mar 09, 2007 at 01:35:31PM -0800, Jean Tourrilhes wrote: It's not as bad as it look like. All userspace programs nowadays use either the iwlib or wpa_supplicant. For example, NetworkManager gets its stuff through wpa_supplicant, and kdenetwork uses iwlib. So, in essence, there is only two places to fix. Which is why I would like to hear from Jouni. How confident are you of this being the full set? I did not use iwlib for two reasons: its license and it not being available (at least at that point in time) by default in many Linux distros. I would expect someone else having the same reasons, but I have to admit that I have not looked into this at all, so this is only a guess. By the way, I've just released version 29.pre16 which has a better band aid. It fixes bugs of the previous version and is more forward compatible (i.e. it's compatible with option 2). Hmm.. What should I look as the description of the latest proposed workaround? I was kind of hoping to see a nice description of the problem and proposed change in couple of paragraphs of text.. ;-) Anyway, I can see two changes when I diff wireless tools 29.pre14 and pre15 that are clearly related to this. Diff of pre14 vs. pre16 or pre15 vs. pre16 includes more changes and some of them do not seem to be related to issue. Unfortunately I do not have access to any system to test this workaround, so I cannot easily test this myself. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Thu, Mar 08, 2007 at 08:27:22PM +0100, Johannes Berg wrote: On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote: A proper fix would involve forcing the alignement in the kernel. Unfortunately, that would break 64bit-64bit configs. I think I can build a workaround for this in iwlib. Actually, other tools like network manager, wpa supplicant and possibly more don't use iwlib afaik and are affected too, so the only real fix seems to be possible in the kernel. Yes, workaround in just iwlib is not enough. If the only possible solution is user space workaround, it better be documented (and communicated to maintainers of user space apps) well so that all user space programs not using iwlib can be modified, too. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hidden SSID's
On Tue, Jan 30, 2007 at 08:35:18PM -0600, Larry Finger wrote: If one does the equivalent of 'iwlist eth1 scan essid myssid', then a probe response with NETWORK_EMPTY_ESSID set in the network flags will have 'myssid' returned in the SSID field of the returned buffer. If the input command were 'iwlist eth1 scan', then an empty SSID would be returned under the same circumstances. My code saves the SSID that is in the extra argument of the SIOCSIWSCAN call, and uses that in the SIOCGIWSCAN call. Well, yes, but SIOCSIWSCAN and SIOCGIWSCAN calls are not in any way linked together.. You could have two user space programs asking for a scan of different SSID at more or less the same time and then have them read the results with SIOCGIWSCAN. At this point, the SSID from the last SIOCSIWSCAN would be returned for all APs that are in the scan list without an SSID. This may not be the correct SSID and can produce quite confusing results. I don't see this as an improvement over just removing the hidden which will at least provide consistent results. The proper fix for this is to use the information from the AP (Probe Response frames) and create a local BSS list that has entries with SSID updated from Probe Responses. If the underlying hardware/firmware does not allow such handling, this kind of mapping of SSIDs from scan request to scan results should probably in the hardware driver that would have chance of mapping results from firmware to request for a given SSID. At that point, it might be feasible to change the SSID in scan results, but I see only problems for the case where this is done at higher layer. What is the method that should be used to associated with a given hidden AP? The 802.11 stack should fill in the proper SSID data from Probe Responses and maintain a local BSS list, i.e., the hidden APs would be marked with proper SSID whenever Probe Responses are processed. See, e.g., how driver/net/wireless/hostap/*.c use local-bss_list that will be filled with information from both Beacon and Probe Response frames or how wireless-dev.git net/d80211/ieee80211_sta.c handles updating of BSS entry from both Beacon and Probe Response frames (i.e., do not allow Beacon frames to replace data from Probe Response frames) in ieee80211_rx_bss_info(). In other words, the hidden SSIDs are resolved in the BSS list based on information from Probe Responses and user space programs will get proper information in the scan results regardless of how the real SSID was learned. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hidden SSID's
On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote: Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore any other probes. In addition, the response will have an empty SSID field. These responses are the only ones in which a substitution would occur. These are the same responses where the current code sends back the hidden pseudo-SSID. My change would put the correct one there. Is the SSID from the probe response really used here? Your patch did not look like that.. The SSID from the last scan request command may not be the one that triggered the last scan (e.g., one could request a new scan without specifying an SSID). We aren't guessing. The response frame with the empty SSID field must have come from the AP with the SSID we want. Filling in the expected value is just making it easier for the user-space tools. I don't see how the proposed patch would be using the correct SSID value in all cases. Especially cases where there are multiple APs using hidden SSIDs, but with different real SSID values and cases where multiple scan requests are being processed would be likely to leave windows open for reporting incorrect SSID. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hidden SSID's
On Sun, Jan 28, 2007 at 04:18:01PM -0600, Larry Finger wrote: Is there something funny about Cisco APs with hidden SSID? Yes, there is.. Or well, hidden SSID is funny concept in itself, but anyway.. Some APs set the SSID IE to an array of 0x00 octets with the length of the original SSID when hiding the SSID while others just use 0-length SSID. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hidden SSID's
On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote: Well, there's no way a userspace program could depend on all hidden SSID APs having the hidden tag, since if you stick in another, non-ieee80211-stack card it won't be like that. So I don't think we should care about hidden in d80211, but I don't think we can remove it from ieee80211 either. Use of 'hidden' is just not acceptable. IMHO, it should be removed from everywhere, including net/ieee80211. The sooner this is done, the better. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hidden SSID's
On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote: When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant, which searches through the scan data looking for a particular ssid. Because ieee80211 has substituted a false ssid, namely hidden, wpa_supplicant cannot authenticate. This behavior is fixed by adding a new argument to ieee80211_translate_scan that contains the expected ssid. Would this be replacing the SSID of all BSSes in scan results with the SSID for which the latest per-SSID scan was issued? If yes, this does not sound any better than the current behavior. The driver/802.11 code should not replace the SSID value with anything else than the value received from the AP. In case of hidden SSIDs, the 802.11 implementation should maintain a list of BSSes found during the scan(s) and update the SSID (in most cases, by creating a new BSS entry) with the SSID from Probe Response frames. In other words, if the scan is done for a specific SSID (Probe Request includes that SSID), the AP that is using hidden SSIDs will likely include the SSID in Probe Response and data from that Probe Response can be used to fill in the missing pieces for the BSSID,SSID pair. Generating false scan results by locally guessing what the SSID could be is just plain wrong. The scan results need to be based on real frames from the APs. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Thu, Nov 16, 2006 at 10:52:42AM +0100, Johannes Berg wrote: I think we should simplify the stack code by making it have *only* the distinction between between hardware and software crypto (on a per-key basis). Hmm.. I think I need to see the patch for doing this before being able to decide whether I'd like this or not.. Michael MIC is a bit unfortunate design since it happens at MSDU, not MPDU level. Because of this, most hardware designs have to do something special when fragmentation is used. If the fragmentation is done in the stack, it may be difficult to move the Michael MIC operations into the driver since they need to happen before fragmentation (which would be done in the stack in this case).. Other than this special case, it sounds reasonable to keep most of the small hardware design changes hidden in the driver code as long as the functions that are exported from the stack are the same ones that the stack would be using anyway (i.e., not having to maintain two versions of the same code). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: clean up some list and loop code
On Fri, Nov 17, 2006 at 12:04:29AM +0100, Johannes Berg wrote: Remove things like for (;;) or for (; condition ;). Ever heard of while loops? Isn't for (;;) the standard way of doing infinite loops? Please don't change that. Changing loops to use list_for_each*() is of course welcome. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Drain TX status before starting IRQs
On Thu, Nov 02, 2006 at 09:45:46AM +0100, Johannes Berg wrote: On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote: Has anyone used this patch, particularly with WPA encryption? When I try it, wpa_supplicant immediately uses 90+% of the cpu and never actually authenticates with my AP. I wonder if it is something with my system. What does wpa_supplicant do here? Have you looked at the debug log? Is it in some kind of busy loop doing something? Unless wpa supplicant is stupid [1] this cannot cause it any problems. johannes [1] by that, I mean sending out frames, turning off and on the interface, and then hoping to get a transmit status for frames sent before off/on cycle. wpa_supplicant does not receive or query TX status (at least yet; in the user space MLME case this is likely to change at some point). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about 802.11i IBSS support
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hostap_plx: fix CIS verification
On Tue, Oct 24, 2006 at 08:48:09PM -0400, Pavel Roskin wrote: I don't have Coverity to check, and I think the results of Coverity were misinterpreted. It doesn't know anything about CIS structure. Anyway, let me just check Jouni's suggestion on a real PLX card. It doesn't need to know anything about the CIS structure. The driver must not be allowed to run over a buffer even if given an invalid CIS data. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hostap_plx: fix CIS verification
On Tue, Oct 24, 2006 at 10:12:24PM -0400, Pavel Roskin wrote: Coverity has no means to interpret CIS. However, it may understand kmalloc, which allocates CIS_MAX_LEN for the CIS copy. The value of cis[pos + 1] has no bearing on the validity of the access to cis[pos + 5] from the point of view of a checking tool. Indeed. pos is already checked in the beginning of the loop to be small enough, but the check is not strong enough. The next tuple starts at (pos + cis[pos + 1] + 2), and we want that to be at most CIS_MAX_LEN. That's something Coverity could have found. Agreed and I went through the report at some point and I think I found it to be valid.. So, the right fix would be: - if (pos + cis[pos + 1] = CIS_MAX_LEN) + if (pos + 2 + cis[pos + 1] CIS_MAX_LEN) goto cis_error; I'm rewriting this with because it's easier to read. Next tuple at exactly CIS_MEX_LEN is fine - we just stop precessing at that point. I'm going to combine this with my previous fix and resend. Great, thanks! -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hostap_plx: fix CIS verification
On Fri, Oct 20, 2006 at 06:20:15PM -0400, Pavel Roskin wrote: The record length for numerical manufacturer ID should be at least 4 bytes (two 16-bit words). The code required 5 bytes, which would break for most (if not all) cards. Reported by [EMAIL PROTECTED] case CISTPL_MANFID: - if (cis[pos + 1] 5) + if (cis[pos + 1] 4) Hmm.. Interesting. I think this was changed from 4 to 5 due to a potential buffer overflow as reported by Coverity tools.. In addition, I think that I spent long time trying to understand why it could be a buffer overflow and since it was changed, likely finally figured out an example case.. Alas, I don't remember what exactly this was anymore. It looks like the comparison of the length field to be 5 was incorrect, but in order to avoid re-introducing any potential buffer overflows, that condition could be extended to verify that pos is small enough.. Something like (cis[pos + 1] 4 pos + 5 CIS_MAX_LEN) could be a better fix here. I don't have easy access to PLX cards anymore, so this is untested and I'm too lazy to copy this function into a separate program to run it against CIS dumps. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] cfg80211 and nl80211
vendor comes up with the great (yeah, right) security improvement by using a new WEP key length. In addition, this would mean that the same field can be shared (just like key_material) with all ciphers.. char * key_material unsigned/u8 enum index (one of DEFAULT, 1, 2, 3, 4) This is not specific to WEP, so could be shared with other algorithms.. None of the ATTR_WEP_KEY fields were actually specific to WEP.. Take a look at struct iw_encode_ext to see the needed parameters.. Some cards, like older aironet ones, can only do 1 key. I don't want to pollute nl80211 with limitations like that though, so the driver can just return -EINVAL if the card doesn't support it. I don't think it pays to have capability bits for something as far down in the driver implementation as this. Actually, this particular case could be nice to include in capability flags if someone were interested enough to implement WPA with Group Key only keys, i.e., this case is described in WPA/IEEE 802.11i as an exception and authenticator/supplicant would need to behave differently with it. Then again, I've never really needed this or have even heard a request to implement it, so maybe it can by ignored now. My impression of ENCODE and ENCODEEXT was that they were _just_ for setting keying material (except in the case of WEP where you set the auth mode open/shared too), and that AUTH was for higher level stuff. I think it is a design flaw to use ENCODE for open/shared auth_alg configuration and I never really understood that part of WE. That's why authentication algorithm was added separately in WE-19. IW_AUTH_* is just a subtyped way of being able to configure parameters without having to add a new ioctl for every one. They are not really tied to authentication, so the name is not exactly correct. - allowed wpa versions (why is this AUTH??) Can you do both WPA and WPA2 at the same time? You can certainly advertise both a WPA IE and an RSN IE at the same time. Is it possible to auth both types of clients? Sure you can. APs can have multiple stations and some of them can use WPA while others are using WPA2 (IEEE 802.11i/RSN). - setting pairwise and group ciphers (again.. AUTH??) Note that ENCODEEXT has a group key flag IW_ENCODE_EXT_GROUP_KEY too. The pairwise and group cipher stuff in AUTH only sets the cipher _type_, not the actual key material AFAICT. These parameters in IW_AUTH_ are for setting the allowed cipher suites. They are only used with drivers that generate WPA/RSN IE internally. * Static WEP - Keys: up to 4 group keys - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 - 802.11 Auth: Open System or Shared Key - Key Mgmt/Auth: none Static key mapping keys could be used, even though that is not very commonly used part of IEEE 802.11. In other words, there is individual WEP keys and up to four default keys. * Dynamic WEP (LEAP?) - Keys: up to 4 group keys - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 - 802.11 Auth: Open System (only?) - Key Mgmt/Auth: IEEE 802.1x with LEAP or EAP LEAP is an EAP method just like TLS, PEAP, etc. (it just happens to not follow the standard, but.. well, close enough). This should have the same keys as Static WEP, i.e., possibly multiple individual (unicast) keys. In addition, thanks to Cisco, there's Network EAP authentication algorithm and possibility of using non-zero key indexes for unicast keys.. * WPA PSK - Keys: pairwise group - Use WPA IEs - 802.11 Auth: Open System - Crypto: TKIP or CCMP - Key Mgmt/Auth: WPA-PSK (elided 802.1x) There are pairwise keys and up to four group keys (Notice the pattern? this is same as WEP above..). * WPA Enterprise * WPA2 PSK * WPA2 Enterprise And these have the exact same encryption options as WPA-PSK. In other words, encryption keys should be handled separately from auth_alg/key_mgmt configuration. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] cfg80211 and nl80211
On Thu, Oct 05, 2006 at 09:13:53AM -0400, Stuffed Crust wrote: (Leave out the RSNIE, AuthType and KeyMgmt stuff; while they're used in the actual key negotiation/derivation, they're separate problems and have no bearing on the crypto layer. From the driver's perspective the RSNIE is just an opaque blob to be appended to beacons,presps and [re]assoc frames, KeyMgmt is purely a matter for the authenticator/supplicant, and AuthType is just a toggle that happens to be off for post-802.11i, although LEAP v1 adds some complications there..) They are separate problems, but they do need to be taken into account in 802.11 interface to user space. Some drivers generate WPA/RSN IE internally and they need to be told about the allowed protocol version, authenticated key management suite, and pairwise/group cipher suites. In other words, key management is not purely for authenticator/supplicant. Each key has: * Key type (WEP/TKIP/AES-CCMP/NONE) * Key length (implied, but WEP can have varying key lengths) * Key index (only '0' is generally used for unicast frames, but 802.11i requires use of simultaneous broadcast keys) Pre-802.11i supported key mapping and multiple default keys.. To make things complex, many Cisco APs are configured to use non-zero key indexes with dynamic WEP keys.. ...Meanwhile. It's foolish to ignore the 802.11 MLME. It lists out pretty much everything that's necessary to get a working connection, and looking at its evolution (and changes in the pipeline) shows that it's impossible to do it all (right) the first time, and that changes, not just additions, will be necessary. There are non-standard WLAN security protocols (look at Cisco) and one needs to keep in mind that just looking at 802.11 MLME may not cover all cases that, in practice, have to be supported.. Anyway, I agree that MLME primitives do change and there will be new commands needed to cover needs of future amendments to 802.11 (see, e.g., 802.11r and 802.11w drafts). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request to postpone WE-21
On Thu, Oct 05, 2006 at 04:49:54PM -0400, John W. Linville wrote:
What about a patch like the one below? It tries to detect WE-20
ESSID/NICKN accesses and adjust them to WE-21 style. What am
I missing?
diff --git a/net/core/wireless.c b/net/core/wireless.c
+ else if (IW_IS_SET(cmd)) {
+ char essid[IW_ESSID_MAX_SIZE + 1];
+
+ err = copy_from_user(essid, iwr-u.data.pointer,
+ iwr-u.data.length *
+ descr-token_size);
+ if (essid[iwr-u.data.length] == '\0')
+ essid_compat = 1;
This looks somewhat confusing.. WE-20 (and older) included '\0' in both
the data value and length (well, at least in most drivers and user space
tools, if I remember correctly), i.e., essid[iwr-u.data.length] would
be pointing one byte after the '\0' termination.. And since '\0' is
valid character in SSID (it is just an arbitrary array of octets) it can
also be the last octet of the SSID and WE-21 style case could have
essid[iwr-u.data.length - 1] == '\0'..
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Request to postpone WE-21
On Thu, Oct 05, 2006 at 03:12:46PM -0700, Jean Tourrilhes wrote:
+ if((cmd == SIOCSIWESSID) ||
+(cmd == SIOCSIWNICKN)) {
+ if(extra[iwr-u.data.length - 1] == '\0') {
Can't iwr-u.data.length be zero here (with WE-21)? Maybe better add
'iwr-u.data.length 0 '..
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prism54: wpa support for fullmac cards
On Wed, Oct 04, 2006 at 04:12:26PM +0200, [EMAIL PROTECTED] wrote: the AP code never worked. And the hostapd-ioctl interface was designed for prism2/2.5/3 cards, but not for fullmac prism54. What do you mean by never working? I have seen fullmac Prism54 completing WPA authentication with hostapd.. This was using the driver_prism54.c in hostapd, not the Host AP driver interface. (BTW, hostapd's backend for prism54 uses a proprietary interface - PIMFOR -, which never made it into the kernel.) But it worked in the external driver. So yes, saying that the version in kernel tree never worked in AP mode would probably be valid. And as far as the WEXT interface in hostapd is concerned, no, there is no such thing yet. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wext
On Wed, Oct 04, 2006 at 10:37:23AM +0200, Johannes Berg wrote: On Mon, 2006-10-02 at 19:55 +0200, [EMAIL PROTECTED] wrote: This patch (wext-patch) is a proposal. It adds two new defines for the SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl. (it would be nice to have them, so that I can post the hostapd code for the prism54 card!) NACK from me. Please help me work on nl80211 instead :) SIOCSIWMLME was designed to allow additional MLME commands to be added. IMHO, a potential replacement in the future should not prevent us from extending WEXT at this point and stop all changes in something that is currently available. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: softmac mtu
On Thu, Sep 28, 2006 at 05:35:17PM +0200, Michael Buesch wrote: On Wednesday 27 September 2006 15:55, Johannes Berg wrote: On Wed, 2006-09-27 at 15:57 +0200, [EMAIL PROTECTED] wrote: Also I wonder what should be the max mtu. 2304, I think, as that's synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */ But maybe I'm interpreting the spec wrongly? Yes, I think so. ;) I am pretty sure this is the maximum _fragment_ size. But each packet (which max size is defined by the MTU) can be fragmented. I don't know if there's a limit on the max number of frags. No it's not. How about reading the standard.. ;-) Take a look at how MSDU and MPDU are defined.. MSDU can be fragmented into smaller MPDUs, but the limit here is indeed for MSDU, not MPDU. In other words, fragmentation in IEEE 802.11 is different from fragmentation in IP and it is also used for different purpose. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel: TKIP: replay detected:
On Mon, Sep 25, 2006 at 10:50:00AM -0400, John W. Linville wrote: On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote: My sylog is filled up with thousands of: Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \ STA=XX:XX:BB:LL:KK:00 previous TSC BLAa received TSC BLAa Opinion seems to be running that these messages are useless and should be removed. Anyone disagree? Yes, I disagree (again). In most cases, these are indication of an implementation error. The problem here is that this issue may be at the end of the connection. Anyway, if we are seeing large numbers of replays detected with the same TSC/PN, I would suggest verifying that the IEEE 802.11 duplicate detection is working correctly in the driver that is reporting these replays. TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a directed IEEE 802.11 frame is not acknowledged, it will be retransmitted (up to a certain limit). This retransmitted frame will use the same TSC/PN. However, the duplicate detection routine in the receiver (something that happens before TKIP/CCMP processing) should catch these cases since the frames from the same source address that use the same seq# and fragm# should be dropped at that layer. If it can be shown, that these errors are indeed caused by a broken transmitter (and that transmitter is not a Linux device for which we control the driver code ;-), I would be much more willing to accept patches that silence these messages (as long as the replay statistics are easily available in other ways) by default, but I would still not remove them completely. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: softmac mtu
On Thu, Sep 28, 2006 at 05:47:12PM +0200, Johannes Berg wrote: On Thu, 2006-09-28 at 17:35 +0200, Michael Buesch wrote: I am pretty sure this is the maximum _fragment_ size. But then why does it talk of MPDU and MSDU? Maybe because your understanding is closer to what the standard says.. ;-) IOW, I read it as an MSDU is the data that is supposed to be transmitted over the link and that can be at most 2304 bytes long, and then it may be fragmented or not and is then copied into (an) MPDU(s). Yes. But each packet (which max size is defined by the MTU) can be fragmented. I don't know if there's a limit on the max number of frags. There's only a 4 bit fragment counter ;) However, see above. And 4 bits is quite enough for sending the maximum number of fragments which is currently about 10 (256 octet min frag len and 2304 max MSDU len with some extra needed to cover the extra header in each fragment). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs
On Mon, Sep 25, 2006 at 10:49:12AM -0500, Larry Finger wrote: When using TKIP and CCMP for wireless encryption with ieee80211, the logs get filled with useless replay messages where the previous and received TSC are identical. This change deletes the log message for this case, but still prints the message when there are major differences in the TSC's. NAK. These are not useless messages; they are more or less always indication of a broken implementation. I have nothing against hiding the messages by default, but there should be an easy mechanism for noticing that this is the reason for connection not working.. --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c @@ -394,7 +394,7 @@ static inline int tkip_replay_check(u32 - (iv32_n == iv32_o iv16_n = iv16_o)) + (iv32_n == iv32_o iv16_n iv16_o)) --- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_ccmp.c @@ -287,7 +287,7 @@ static inline int ccmp_replay_check(u8 * - (iv32_n == iv32_o iv16_n = iv16_o)) + (iv32_n == iv32_o iv16_n iv16_o)) These changes would break replay protection and must not be applied. This is opening a security problem, not just limiting when something is being printed out. I would be more open to adding this extra condition for just the printk, i.e., changing net_ratelimit() to net_ratelimit() (iv32 and iv16 are same). Even this is a case that should not really happen unless something is broken since IEEE 802.11 duplicate detection should have filtered the frames before (and it should be fixed if it did not do its job correctly). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fix WX and association related races
On Thu, Sep 28, 2006 at 05:13:20PM +0200, Michael Buesch wrote: On Thursday 28 September 2006 16:52, Dan Williams wrote: As a counterpoint, does every developer _really_ want to run wpa_supplicant just to use a WEP-encrypted connection where you may occasionally get kicked off? I think that's the way we want to take. Even for unencrypted networks, probably. We want as much as possible of the high level MAC implementation in userspace. Remember the summit and Simon's talk? It was a good talk and made a lot of sense. I don't know whether every developer wants to run a userspace tool for that, but taken into account that I'm planning on focusing on the MLME code in wpa_supplicant instead of fine tuning similar code in kernel, it should be quite obvious what I would be voting for ;-). This userspace implementation should probably renamed from wpa_supplicant to wireless_supplicant or whatever. Yeah.. wpa_supplicant does not really describe the exact set of functionality in the program. Though, I'm not planning on renaming it just for the sake of having a better name. Then again, there are plans on merging (with build time options) wpa_supplicant and hostapd functionality, so there is a good point for renaming the end result to something else. At this point, it shouldn't have supplicant in the name either since it will be possible to include both supplicant and authenticator functionality into the same program (e.g., for IEEE 802.11i IBSS). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel: TKIP: replay detected:
On Thu, Sep 28, 2006 at 04:42:10PM -0500, Larry Finger wrote: @@ -544,6 +548,14 @@ int bcm43xx_rx(struct bcm43xx_private *b } frame_ctl = le16_to_cpu(wlhdr-frame_ctl); + seq_ctl = le16_to_cpu(wlhdr-seq_ctl); + + if ((frame_ctl == prev_frame) (seq_ctl == prev_seq)) + return -EINVAL; + + prev_frame = frame_ctl; + prev_seq = seq_ctl; By dropping those packets with frame_ctl and seq_ctl the same as the values in the previous packet, I was able to cut the number of TKIP replay messages, but some still come through. Is this what you had in mind, or is there somewhere else that I should be looking? This is quite close to what I had in mind and is likely okay for testing, but would not be generic enough to be something I would like to see in the main kernel tree. See IEEE 802.11 clause 9.2.9 for the details of what the receiver needs to do (mainly, the validation of addr2 and per STA prev_seq is needed for AP and IBSS modes). In addition, this should really be in the generic IEEE 802.11 code and there are couple of optimizations which can be used when combining this with defragmentation (see, e.g., net/d80211/ieee80211.c ieee80211_rx_h_check). Did the replay messages still show the same TSC/PN or did you get rid of all messages that had the same number repeated? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status
On Thu, Sep 21, 2006 at 03:55:14PM -0700, Jean Tourrilhes wrote: Jean, are there any other possibilities? Yes, dropping SIOCSIWAP (set) entirely, and keep only SIOCGIWAP (get). I don't think that this would be acceptable. We need to be pragmatic. Very few people need to set a fixed BSSID. I would even venture to say that in the case of most people setting a fixed BSSID, it's an error and they should not do it (it kills roaming, which is a desirable feature). I've yet to find a card which scanning is broken to the point that you need to fudge the BSSID. Maybe very few _people_ use it directly, but please keep in mind that programs like wpa_supplicant may control roaming and do it by using this SIOCSIWAP. In addition, being able to limit AP selection to one specific BSSID can be quite useful for number of uses. There are some drivers that don't support SIOCSIWAP (set), and it's usually not a problem, users are not complaining about it. That's why I claim we could drop the (set) support. Of course, we can't do it because one PhD student at Berkeley need the feature ;-) There's more than one PhD student needing this and I would be very much against removing it. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: roaming support for d80211 stack
On Tue, Sep 05, 2006 at 05:42:16PM -0700, Mohamed Abbas wrote: Are there any one working on roaming support for d80211 stack? I'm not actively working on this at the moment, but I do have plans on doing something on this area. The current implementation uses wpa_supplicant to take care of the roaming for both cases of ieee80211_sta.c being used (i.e., management frames processed in kernel) and user-space MLME (management frames in user space). The trigger for roaming is certainly not optimal; roaming process is started only after losing connection, but roaming itself should work. I will be most likely working with the user space MLME code in wpa_supplicant, i.e., there won't be much changes in the d80211 stack side. The changes there would more likely be in the area of providing some generic operations to help scanning and reporting current signal strength (etc.) to use space. The main changes in roaming logic would be wpa_supplicant. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18] WE-21 support (core API)
On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote: On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote: o modulation o long/short retry o relative power saving. What's the point of adding more ioctls that we'll be implementing them as wrappers around nl80211? Right now, those new ioctls/options aren't implemented in *any* driver at all so they're completely useless, and just add more to the pile of historic baggage we end up carrying around. If we add these to mainline now, it's another thing we'll have to carry for a long time even though it currently has no users... I don't know about the others, but long/short retry limits have users (e.g., Host AP driver) and these drivers are currently forced to use a hack to do this without this cleanup. Furthermore, this part does not add a new ioctl. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] d80211: add support for SIOCSIWNICKN SIOCGIWNICKN
On Tue, Aug 29, 2006 at 07:49:22AM -0400, John W. Linville wrote: On Tue, Aug 29, 2006 at 09:49:17AM +0200, Johannes Berg wrote: I intend to kill the nick command with nl80211 since it seems to be useless. Any objections? I can't defend it myself, but I have heard of people using it. I think some of the distro's init scripts might set it as well? Can anyone defend the practice of setting a nickname for a wireless device? I think that this was added either based on a non-802.11 protocol or based on a specific hardware/firmware design that had possibility of configuring a name for the client (to be exchanged with some proprietary network management protocol as the device name). After that, this ioctl seems to be just used for binding some arbitrary data to an interface to help scripts etc. In other words, I don't see any real use for this from the view point of IEEE 802.11 networks and it is confusing at best. This may be useful for some setup scripts, but I would rather hope they would use something else instead. The only reason for adding nick command would be to maintain backwards compatibility with some scripts. I do not use any distro configuration mechanisms for setting up wireless, so I do not know what is currently being used. I would not add these ioctls into d80211 unless someone can point out an existing (and widely used) mechanism that depends on these ioctls being available. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status
On Mon, Aug 28, 2006 at 02:17:34PM -0700, Michael Wu wrote: It would be helpful if you inlined your patches instead of attaching them next time. Agreed. I'm not comfortable with using the name for this purpose. And agreed. wireless.h has this to say about SIOCGIWNAME: #define SIOCGIWNAME 0x8B01 /* get name == wireless protocol */ /* SIOCGIWNAME is used to verify the presence of Wireless Extensions. * Common values : IEEE 802.11-DS, IEEE 802.11-FH, IEEE 802.11b... * Don't put the name of your driver there, it's useless. */ The proposed use here is against this and should not be applied. SIOCGIWAP can be used to indicate association status and SIOCGIWTXPOW can be used to indicate whether TX is powered which is quite close to radio off indication. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/3] d80211: add support for SIOCSIWRATE, SIOCSIWTXPOW and SIOCSIWPOWER
On Mon, Aug 21, 2006 at 05:30:22PM -0700, Mohamed Abbas wrote: the attached patch will add support to handle these iw_handle SIOC[S/G]IWRATE, SIOC[S/G]IWTXPOW and SIOC[S/G]IWPOWER. It also added some changes in ieee80211_ioctl_giwrange function to report supported channels and rates. a call to ieee80211_hw_config is needed to infor the low level driver about these changes, I guess we might need to add flag to indicate which parameters was changed so the low level driver does not need to make extra calls. Could you please separate SIOCSIWRATE from the rest. I did not go through the details yet, but I do not think the proposed change here would match the the way rate control was designed in the Devicescape stack and I would not like to see this getting in before more careful review and explanation of how this is expected to work. The way I see rate settings working is that the control would be applied to the rate control algorithm and not to the list of rates itself. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev 4/6] d80211: Send Layer 2 Update frames in kernel
On Thu, Aug 24, 2006 at 01:43:16PM +0200, Jiri Benc wrote: On Wed, 23 Aug 2006 22:39:30 -0700, Jouni Malinen wrote: Which part do you think is hackish here? Sending the layer 2 update frame or moving it to kernel? The latter. Is it really needed to send it unconditionally for each added STA? And cannot it be generated in userspace? Yes, it must be sent out whenever a STA associates with the AP, i.e., for every STA and for every association.. This is needed to update both the internal bridge tables in the AP and the external bridge tables in switches etc. connected to the same physical net in order to make sure that future frames to the STA's MAC address are delivered to the correct AP--and within that AP, to the correct port. This was originally done in hostapd in userspace, but this showed a bug in which the local bridge tables did not get updated correctly in some specific configurations. In addition, doing this in hostapd would require that hostapd knows (or can learn) how the bridge configuration is done on the device and this information is not really needed for anything else, so there would not really be much point in keeping that functionality in hostapd. The simplest solution for this seems to be to allow the layer 2 update frame to be sent through the exact same path as any data frame from the STA would be coming. This makes sure that it goes through the local bridge in the same way as other frames from the STA would go and it will also be sent out to correct external (wired/WDS) ports automatically based on bridge configuration. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev 4/6] d80211: Send Layer 2 Update frames in kernel
On Wed, Aug 23, 2006 at 07:22:56PM +0200, Jiri Benc wrote: On Mon, 07 Aug 2006 16:16:12 -0700, Jouni Malinen wrote: Send Layer 2 Update frame from the 802.11 code in kernel to the netdev that the STA is bound to. If the STA is bound to another VLAN netdev, send another update frame. This fixes an issue in which a local bridge table was not updated when hostapd sent this frame. I hope someone is going to describe why is this necessary and why it cannot be done in a less hackish way. Otherwise, I'd probably tend to ask for reverting this patch. Which part do you think is hackish here? Sending the layer 2 update frame or moving it to kernel? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/18] d80211: clean up exports
On Mon, Aug 21, 2006 at 09:41:15AM +0200, Johannes Berg wrote: This puts all EXPORT_SYMBOL() macros along with the function being exported, and changes some exports that are only relevant to rate control modules and to be GPL-only because they rate control modules need to be built against the internal ieee80211_i.h header. Moving the EXPORT_SYMBOL definitions sounds good, but I would like to keep changes between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL separate from this kind of cleanup. In addition, I'm not personally a huge fan of the EXPORT_SYMBOL_GPL in the first place since I believe the GPL should cover this without additional changes in the source code. In other words, I would prefer that the EXPORT_SYMBOL would not be changed to EXPORT_SYMBOL_GPL here. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] d80211: LED triggers
On Mon, Aug 21, 2006 at 09:41:08AM +0200, Johannes Berg wrote: This patch makes d80211 export LED triggers for rx/tx and introduces functions to allow device drivers to query the trigger names for setting default triggers. It also cleans up the Makefile LED related stuff. Is someone using these or planning on using them? I have been open to just removing all code due to lack of active use. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [clarification request] ieee80211_tx_control.pkt_type
On Fri, Aug 18, 2006 at 01:41:57PM +0200, Johannes Berg wrote: I was pondering the ieee80211_tx_control type and don't see anyone using the pkt_type field. d80211 makes great effort to have it correct, but no driver uses it. Hence, my question: What is the purpose of this field? Under what circumstances would a driver have to know this? Especially considering that it's only normal vs. probe response... Some hardware designs require this configuration for TX frames. It is used to select whether some of the fields are being filled in hardware (e.g., timestamp for Probe Response). This would only be needed for AP mode and IBSS (adhoc), so it is possible that not all low-level dirvers have yet been implemented to support such operation. This pkt_type was added at generic 802.11 layer in order to avoid forcing the low-level driver to even look at the 802.11 header when queuing the frame for transmission. Taken into account how simple operation it is to get the type and subtype from the frame control field, this tx ctrl pkt_type could be removed, if desired. However, it was added there for a reason. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: fix some 0 vs. NULL comparisons
On Mon, Aug 14, 2006 at 03:20:58PM +0200, Johannes Berg wrote:
Johannes Berg wrote:
-if (!local-hw-passive_scan) {
+if (local-hw-passive_scan == NULL) {
Alright, this is icky. I'll make another pass and change it all to if
(x) or if (!x) instead of comparing to NULL. Don't hold your breath
though, earliest next weekend.
Well.. I'm perfectly fine with comparing function pointers to NULL in
this kind of case.. In many cases, I find fp == NULL to be clearer than
!fp, but for the fp != NULL case I would rather not see != NULL.. Not
very consistent, but can't really help with that on this kind of coding
style opinions. Anyway, replacing 0 with NULL is a good change.
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ieee80211_set_encryption...
On Mon, Aug 14, 2006 at 10:16:53AM +0200, Johannes Berg wrote: ... is a big mess. Yes, and so is the number of different ways this has been implemented in hardware designs.. What's with all the comments saying 'maybe with blabla hardware that can be done in hw but disable here now' etc? Can't we just have a 'please decide' callback in the driver that tells us whether this can be done in hw or sw? For some cases yes, but it is a bit difficult to come up with a generic model that would work for everything. Supporting multiple BSSes in AP mode makes some quite complex cases. Or how about no_tkip_wmm_hwaccel? That seems pretty weird too. That's needed to allow TKIP hwaccel to be used for non-WMM case while falling back to software for WMM. This is needed to workaround some hardware issues. Sure, this could be hidden in the hardware driver, but I would prefer to allow the 802.11 stack support software encryption/decryption to keep the low-level drivers simpler (and to avoid their authors from doing some silly copy-paste things with encryption). I do realize that key management in the face of wpa2 and similar is difficult, but this seems overly complex. Comments? WPA2 is not the complex part; adding WMM into the picture with some hardware design was and multi-BSS support adds quite a bit more complexity here. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wlan#ap seems bogus
On Mon, Aug 14, 2006 at 10:22:34AM +0200, Johannes Berg wrote: As far as I understand the entire point of the wlan#ap interface is to receive all management relevant management frames. (If that's wrong, reply now and don't read the rest) Hence, I think it ought to be named 'wlan#mgmt' instead. However, I think it's hard-coded existence is bogus. How about we just add a new interface mode called MGT_MONITOR and wpa_supplicant simply creates a new device via the regular sysfs mechanism, and then sets that MGT_MONITOR mode via the relevant WEXT ioctl? iwconfig doesn't even need to be taught about this mode except for display purposes... Isn't this already done? I don't remember what happened with client mode case, but at least hostapd is requesting the management interface dynamically at startup time. Also, like I mentioned previously, the device naming can be changed by the user and there's no guarantee that wlan0ap corresponds to wmaster0. Etc. But if wpa_supplicant simply created the device itself, it could give it any name, say wlan0_mgt (if it was controlling wlan0), but if that name is already taken it simply appends a number or something until it hits a device name that's still free (or gives up after 100 tries or so...) :) Same here.. hostapd gets the ifindex from kernel and doesn't care about the name. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: get rid of the WME bitfield
On Mon, Aug 14, 2006 at 10:15:14AM +0200, Johannes Berg wrote: Somewhere, sometime, someone had to start getting rid of bitfields ;) Yes and you wouldn't believe how many times I have had to complain about this particular case internally with it always coming back as bitfield even after showing that it caused a unaligned access on one target platform.. However, I remember fixing this long time ago to use proper operation on u8 values. It looks like I just have forgotten to submit those changes to wireless-dev.git. There was quite a bit of additional cleanup, so it would probably be best if I were to take a closer look at propose an alternative patch for changing this and getting rid for struct qos_control. +u16 *p = (u16 *) (skb-data + ieee80211_get_hdrlen(fc) - 2); +u16 qos_hdr = skb-priority QOS_CONTROL_TAG1D_MASK; if (local-wifi_wme_noack_test) -qc-ack_policy = 1; +qos_hdr |= QOS_CONTROL_ACK_POLICY_NOACK +QOS_CONTROL_ACK_POLICY_SHIFT; +*p = cpu_to_le16(qos_hdr); I think that this is always 16-bit aligned in the current implementation, but I would be a bit careful with this type of change here. This can be done easily with u8 since the qos_control field has 8 bits of used data and 8 bits of reserved field. My change was handling this as two separate 8-bit values, so no issues with potential unaligned accesses. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Tue, Aug 08, 2006 at 05:06:31PM -0700, Jouni Malinen wrote: On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote: 1- I needed to use sta_info_get function to do rate scaling for 3945, although this function is exported but it was missing from d80211.h, for work around I had to copy more header files to my driver's directory, It this plan to add this function to d80211.h ? sta_info_get() (and well, any access to struct sta_info) was not designed to be available for the rate control modules. Could you please provide some more details on what kind of information you would need from there? Actually, that was not correct.. What I should have said is that sta_info was not supposed to be available for low-level drivers. If the rate control algorithm is tightly coupled with the driver, some cleanup would likely be needed here. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3945 driver using d80211
On Tue, Aug 08, 2006 at 02:27:37PM -0700, Mohamed Abbas wrote: 1- I needed to use sta_info_get function to do rate scaling for 3945, although this function is exported but it was missing from d80211.h, for work around I had to copy more header files to my driver's directory, It this plan to add this function to d80211.h ? sta_info_get() (and well, any access to struct sta_info) was not designed to be available for the rate control modules. Could you please provide some more details on what kind of information you would need from there? 2- Scanning; in 3945 driver, we can not tune to other channels while we are connected, this will cause a firmware error. The firmware provides a scanning command we call so the firmware will take care of switching of the available channels and gather beacons and probe responses. The current d80211 the stack will call config callback to switch to different channel and send the probe requests. One of our engineers did come up with a patch to add one more callback function if provided the d80211 will call this function to allow the registered driver to perform the scanning functionalities. For work around I currently check inside config callback if the scanning flag set I will issues the scan command then ignore the next config callback. If the hardware/firmware has such limitation, providing an alternative mechanism for this is indeed needed. However, I though 3945 did not have much firmware on it and I was not expecting this kind of requirement from it (though, I have to admit that I'm not at all familiar with the details of its design). Anyway, there are other wireless cards that will need similar mechanism, so this is needed to support more full mac type designs. 3- I can not access beacon's info from current associated AP. information I need to callback into the firmware like timestamp and aid, work around I would parse incoming management frame and filter beacon from associated AP to get this info. This is a duplicate code that d80211 stack doing, maybe there is away to get these info that I don’t know of. Also it will be nice to have some callback function on association, disassociation. What kind of information/events do you need in the low-level hardware driver? It sounds reasonable to add this kind of event callbacks. 4- I am been using the driver for sometime right now and it seems to be stable and liable although I am using SMP system. I hearted of some SMP issues in d80211 and I have the machine and time to help in this. Do you have any test script the cause this SMP problems? Or steps to reproduce it. I have heard of open claims on there being SMP issues, but I don't think I've ever seen any details on this. I've also added a dual core laptop to my testbed, so it will be interesting to see whether I can trigger any of the issues easily. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] d80211/bcm43xx: Modify struct ieee80211_rx_status for wireless statistics.
On Wed, Aug 09, 2006 at 10:21:16AM -0500, Larry Finger wrote: Dan Williams wrote: int ssi; + int maxssi; Spacing? Looks like you're using real tabs here, but the current code uses 8 spaces instead. Not sure if that's a problem. I am using tabs, which I think is the preferred way. I also remember that the rule is not to change the white space on things you are not touching. Is that correct? That's at least the way I would prefer to do this. Unrelated whitespace changes as part of a patch are almost always bad and large patch of modifying just the whitespaces around the tree is likely to add large number of conflicts for pending work that goes on at the moment. Unfortunately, I forgot to replace this part when making the initial release of the Devicescape stack. I've always used tabs myself, but some of the areas of the code that I did not write was done using spaces. Anyway, this should move to using tabs over time whenever source code is being modified. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.11/crypto questions
On Tue, Aug 08, 2006 at 01:35:22PM +0200, Johannes Berg wrote: Jouni Malinen wrote: Depends on what exactly you mean with on the fly. We have indeed changed between doing software and hardware crypto for some cases, e.g., when enabling another BSS while one BSS is using static WEP (which would need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for the receive case. Also, if we add a monitor if, does it disable hw crypto so we can see the undecrypted frames? I haven't looked at the current implementation (if this has been modified), but it would be nice to have an option for doing this. This gets a bit complex, but if having such an option is not going to slow down the normal case (i.e., monitor mode disabled), being able to select whether frames are decrypted in monitor interface could be useful. This would, of course, require that hwaccel is disabled for normal data packets when this kind of mode is enabled. Because of quite large CPU load difference, I would expect there to be valid use cases for both allowing hardware to continue decrypting frames (and monitor interface would show whatever was received from hardware, i.e., some frames may be decrypted, some not based on whether a key was configured) and stopping hardware acceleration and delivering unmodified frames into the monitor interface (and if a normal data connection is active at the same time, doing software decryption for frames before they are delivered to data interface). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Switch d80211_mgmt.h to ieee80211.h style definitions
On Sat, Aug 05, 2006 at 01:45:33AM -0700, Michael Wu wrote: d80211: Switch d80211_mgmt.h to ieee80211.h style definitions This patch switches a number of defines in d80211_mgmt.h to enums taken from ieee80211.h and makes the corresponding changes in net/d80211. include/net/d80211_mgmt.h | 153 net/d80211/ieee80211.c |2 - net/d80211/ieee80211_sta.c | 50 +++--- Is this really needed? Based on the changes here, these are mostly used internally in net/d80211/ieee80211_sta.c and not in other parts of the tree. In addition, I would actually like to see ieee80211_sta.c be made mostly obsolete with a user space implementation of client MLME (e.g., the one in wpa_supplicant which is based on this ieee80211_sta.c file). Changing WLAN_STATUS_* and WLAN_REASON_* to be enum's while keeping their old names is fine. However, I would rather not change the names of the information element IDs (WLAN_EID_*) into MFIE_TYPE_*. What is that 'MFIE' anyway? Management Frame IE? These IEs are not limited to management frames.. In other words, I would skip all the changes into ieee80211_sta.c and would only change d80211_mgmt.h to use enum's with old names. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.11/crypto questions
On Tue, Aug 01, 2006 at 07:40:52AM +0200, Johannes Berg wrote: Since there's been lots of talk about multi-STA or multi-BSSID devices (more than one client, more than one AP on the same PHY) and I was just looking into some crypto stuff on bcm43xx, it got me wondering. The bcm43xx has an elaborate group key matching thingie which will be useful if it's all WPA2, but if it's say just plain WEP, then that is a problem since you'd either need to use the same keys or disable the bcm43xx crypto hardware. Hence, I suppose the question really is -- does the dscape stack allow changing the 'sw crypto needed' flag on the fly? Depends on what exactly you mean with on the fly. We have indeed changed between doing software and hardware crypto for some cases, e.g., when enabling another BSS while one BSS is using static WEP (which would need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for the receive case. Not all configuration changes are yet supported with minimal modification, i.e., hostapd may end up having to disconnect all stations and start over with such a change, but still, the driver should be prepared on dynamically changing the key configuration and this can include moving some keys from hwaccel to software. If it can be done without major effort, I would recommend making the low-level drivers quite flexible as far as configuring keys to hardware accelaration is concerned. Depending on the hardware design, there may be multiple different ways of doing this and some multi-BSS configurations are likely to require changes in how the keys are used between hardware and software. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 2/6] d80211: Fix PS-Poll frame dropping
Fixed PS-Poll processing for STAs that are not authenticated or
associated:
- 80211.ko dropped these frames even though it should have sent them
to hostapd (this was broken by addition of IBSS support)
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3074,8 +3074,9 @@ ieee80211_rx_h_check(struct ieee80211_tx
rx-sdata-type != IEEE80211_IF_TYPE_IBSS
(!rx-sta || !(rx-sta-flags WLAN_STA_ASSOC {
if ((!(rx-fc IEEE80211_FCTL_FROMDS)
-!(rx-fc IEEE80211_FCTL_TODS)) ||
- !rx-u.rx.ra_match) {
+!(rx-fc IEEE80211_FCTL_TODS)
+(rx-fc IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)
+ || !rx-u.rx.ra_match) {
/* Drop IBSS frames and frames for other hosts
* silently. */
return TXRX_DROP;
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 3/6] d80211: Fix PLCP header length comment
Fixed a typo in a comment: PLCP header length is in microseconds, not milliseconds. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-dev/net/d80211/ieee80211.c === --- wireless-dev.orig/net/d80211/ieee80211.c +++ wireless-dev/net/d80211/ieee80211.c @@ -637,7 +637,7 @@ static int ieee80211_frame_duration(stru * 802.11 (DS): 15.3.3, 802.11b: 18.3.4 * aSIFSTime = 10 usec * aPreambleLength = 144 usec or 72 usec with short preamble -* aPLCPHeaderLength = 48 ms or 24 ms with short preamble +* aPLCPHeaderLength = 48 usec or 24 usec with short preamble */ dur = 10; /* aSIFSTime = 10 usec */ dur += short_preamble ? (72 + 24) : (144 + 48); -- -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 4/6] d80211: Send Layer 2 Update frames in kernel
Send Layer 2 Update frame from the 802.11 code in kernel to the netdev
that the STA is bound to. If the STA is bound to another VLAN netdev,
send another update frame. This fixes an issue in which a local bridge
table was not updated when hostapd sent this frame.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -15,6 +15,7 @@
#include linux/types.h
#include linux/slab.h
#include linux/skbuff.h
+#include linux/etherdevice.h
#include linux/if_arp.h
#include linux/wireless.h
#include net/iw_handler.h
@@ -215,6 +216,52 @@ static int ieee80211_ioctl_flush(struct
}
+/* Layer 2 Update frame (802.2 Type 1 LLC XID Update response) */
+struct iapp_layer2_update {
+ u8 da[ETH_ALEN]; /* broadcast */
+ u8 sa[ETH_ALEN]; /* STA addr */
+ u16 len; /* 6 */
+ u8 dsap; /* 0 */
+ u8 ssap; /* 0 */
+ u8 control;
+ u8 xid_info[3];
+} __attribute__ ((packed));
+
+static void ieee80211_send_layer2_update(struct net_device *dev,
+const u8 *addr)
+{
+ struct iapp_layer2_update *msg;
+ struct sk_buff *skb;
+
+ /* Send Level 2 Update Frame to update forwarding tables in layer 2
+* bridge devices */
+
+ skb = dev_alloc_skb(sizeof(*msg));
+ if (skb == NULL)
+ return;
+ msg = (struct iapp_layer2_update *) skb_put(skb, sizeof(*msg));
+
+ /* 802.2 Type 1 Logical Link Control (LLC) Exchange Identifier (XID)
+* Update response frame; IEEE Std 802.2-1998, 5.4.1.2.1 */
+
+ memset(msg-da, 0xff, ETH_ALEN);
+ memcpy(msg-sa, addr, ETH_ALEN);
+ msg-len = htons(6);
+ msg-dsap = 0;
+ msg-ssap = 0x01; /* NULL LSAP, CR Bit: Response */
+ msg-control = 0xaf; /* XID response lsb.F101.
+ * F=0 (no poll command; unsolicited frame) */
+ msg-xid_info[0] = 0x81; /* XID format identifier */
+ msg-xid_info[1] = 1; /* LLC types/classes: Type 1 LLC */
+ msg-xid_info[2] = 0; /* XID sender's receive window size (RW) */
+
+ skb-dev = dev;
+ skb-protocol = eth_type_trans(skb, dev);
+ memset(skb-cb, 0, sizeof(skb-cb));
+ netif_rx(skb);
+}
+
+
static int ieee80211_ioctl_add_sta(struct net_device *dev,
struct prism2_hostapd_param *param)
{
@@ -296,6 +343,10 @@ static int ieee80211_ioctl_add_sta(struc
sta_info_put(sta);
+ if (sdata-type == IEEE80211_IF_TYPE_AP ||
+ sdata-type == IEEE80211_IF_TYPE_VLAN)
+ ieee80211_send_layer2_update(dev, param-sta_addr);
+
return 0;
}
@@ -1168,6 +1219,10 @@ static int ieee80211_ioctl_set_sta_vlan(
dev-name, MAC_ARG(param-sta_addr),
new_vlan_dev-name);
#endif
+ if (sta-dev != new_vlan_dev) {
+ ieee80211_send_layer2_update(new_vlan_dev,
+sta-addr);
+ }
sta-dev = new_vlan_dev;
sta-vlan_id = param-u.set_sta_vlan.vlan_id;
dev_put(new_vlan_dev);
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 6/6] d80211: Fix TKIP replay protection
Fixed TKIP replay protection for the case where hwaccel is enabled.
rx_initialized flag was not set in this case and the TSC validation
was skipped for the frames.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/tkip.c
===
--- wireless-dev.orig/net/d80211/tkip.c
+++ wireless-dev/net/d80211/tkip.c
@@ -286,6 +286,7 @@ int ieee80211_tkip_decrypt_data(struct c
if (only_iv) {
res = TKIP_DECRYPT_OK;
+ key-u.tkip.rx_initialized[queue] = 1;
goto done;
}
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 0/6] Set of small fixes to net/d80211
Here's a set of small fixes to net/d80211 from the Devicescape tree. Please consider applying. -- -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 1/6] d80211: Fix RTS threshold use
Fixed dot11RTSThreshold use which was off-by-3:
- must add FCS_LEN to the skb-len
- frame length needs to be greater than threshold; not greater than
or equal
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -762,7 +762,7 @@ ieee80211_tx_h_misc(struct ieee80211_txr
struct ieee80211_tx_control *control = tx-u.tx.control;
if (!is_multicast_ether_addr(hdr-addr1)) {
- if (tx-skb-len = tx-local-rts_threshold
+ if (tx-skb-len + FCS_LEN tx-local-rts_threshold
tx-local-rts_threshold IEEE80211_MAX_RTS_THRESHOLD) {
control-use_rts_cts = 1;
control-retry_limit =
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev 5/6] d80211: Fix ieee80211_remove_tx_extra() if key not configured
QoS header processing mangled unencrypted WMM frames on software
retry. The QoS data needs to be removed even when encryption key is
not configured.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3977,11 +3977,11 @@ static void ieee80211_remove_tx_extra(st
pkt_data-requeue = control-requeue;
pkt_data-queue = control-queue;
- if (key == NULL)
- return;
-
hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+ if (key == NULL)
+ goto no_key;
+
switch (key-alg) {
case ALG_WEP:
iv_len = WEP_IV_LEN;
@@ -3996,7 +3996,7 @@ static void ieee80211_remove_tx_extra(st
mic_len = CCMP_MIC_LEN;
break;
default:
- return;
+ goto no_key;
}
if (skb-len = mic_len key-force_sw_encrypt)
@@ -4006,6 +4006,7 @@ static void ieee80211_remove_tx_extra(st
skb_pull(skb, iv_len);
}
+no_key:
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb-data;
u16 fc = le16_to_cpu(hdr-frame_control);
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] d80211: Switch d80211 to IEEE80211_ style names
On Tue, Aug 01, 2006 at 09:16:59PM +0200, Jiri Benc wrote:
From: Michael Wu [EMAIL PROTECTED]
This patch switches the WLAN_ definitions in d80211.h to IEEE80211_ style
definitions found in ieee80211.h. It also switches to MAC_ARG and MAC_FMT.
This kind of change is more than just search-and-replace since frame
type and subtype macros were using different style (not shifted left in
WLAN_FC_{TYPE,STYPE}_* and shifted left in IEEE80211_{FTYPE,STYPE}_*.
Some of these seemed to be caught in the patch, but not all. At least
the following changes look incorrect. I'm not sure whether this is a
complete list of issues, though, so going through all IEEE80211_STYPE_*
and IEEE80211_FTYPE_* cases again could be a worthwhile exercise.
ieee80211.c:
- if (WLAN_FC_GET_STYPE(fc) 0x08)
+ if ((fc IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_QOS_DATA)
(this is supposed to catch all QoS frames, not just QoS data subtype)
ieee80211.c:
- fc |= WLAN_FC_STYPE_QOS_DATA 4;
+ fc |= IEEE80211_STYPE_QOS_DATA 4;
ieee80211.c:
- fc = ~(WLAN_FC_STYPE_QOS_DATA 4);
+ fc = ~(IEEE80211_STYPE_QOS_DATA 4);
wme.c:
- qos = fc (WLAN_FC_STYPE_QOS_DATA 4);
+ qos = fc (IEEE80211_STYPE_QOS_DATA 4);
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: michael_mic in crypto api?
On Thu, Jul 20, 2006 at 01:39:05AM +1000, Herbert Xu wrote: Michael Wu [EMAIL PROTECTED] wrote: Simplicity and consistency. Whereas the relatively simple mic part of the TKIP algorithm is in crypto API, the (more important, more complicated) key mixing part is not in crypto api. Sure, I don't mind either way. I think Jouni wrote this originally, maybe he can share his thoughts with us? I was more or less told that TKIP implementation cannot be included in the kernel tree before this was moved into crypto api.. I don't really care much where it is, but since it is now in crypto api, it would sound easiest to just keep it there. If someone really wants to move it away from there and into TKIP code in ieee80211/d80211, feel free to do that. However, at least for some time, there are two different TKIP implementations (net/ieee80211 and net/d80211) so this would mean duplicating Michael MIC implementation and I would rather not do that. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make in-kernel hostap less annoying
On Mon, Jun 12, 2006 at 03:13:02PM -0400, Kyle McMartin wrote: Most user don't want their kern.log/dmesg filled with debugging gibberish, and could turn it on if prompted. ( Example: wifi0: TXEXC - status=0x0004 ([Discon]) tx_control=000c retry_count=0 tx_rate=0 fc=0x0108 (Data::0 ToDS) A1=00:0f:66:43:d7:0a A2=00:05:3c:06:63:01 A3=33:33:00:00:00:16 A4=00:00:00:00:00:00 ) I agree with removing these by default. However, I would prefer to do this in more selective manor than disabling all debugging information at build time. This would probably involve going through all debug messages using this mechanism and selecting whether they are reasonable to enable by default or not and ideally doing this as a run-time option. Also make hostap default to managed mode, instead of master mode, which has bitten a few users expecting it to behave like the orinoco driver it is replacing. NAK. Host AP has been configured to use master mode by default for the past six years and that is what most users would expect it to continue to do. I do understand that this default differs from all drivers that do not support AP mode, but I think it is too late to change this now. The default could change once Host AP gets replaced with net/d80211-based implementation for Prism2/2.5/3, but I would not change this for Host AP driver. Two minor things I've been carrying around in my personal tree for quite some time. (This is only relevant to the in-kernel driver, I see no reason to change the out-of-tree driver.) That would be even more confusing for the default mode.. I believe that both versions should continue to use Master mode as the default unless overridden by user. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hush noisy ieee80211 CCMP printks
On Sun, Jun 04, 2006 at 08:12:09PM -0400, Jason Lunz wrote: Don't swamp syslog with CCMP: decrypt failed: STA=00:12:17:3a:e2:c7 and CCMP: replay detected: STA=00:12:17:3a:e2:c7 previous PN 0004 received PN 0004 messages. These both seem to be completely normal in regular use, especially 'decrypt failed' whenever another wpa-using station on the same AP is within range. These are not normal, i.e., they should not really show up unless something goes wrong. In many cases, this may be caused by something missing in local filtering (e.g., retry duplicates are not filtered out correctly or messages to incorrect addresses are allowed through, etc.). In other cases, it can indicate incorrect implementation of rekeying or some other bugs in either end of the connection. Anyway, I don't have anything against removing the messages in default kernel builds. If there is a suitable build time debug option, that might be nicer way of doing this, though, since these can provide valuable information when figuring out why something does not work. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hush noisy ieee80211 CCMP printks
On Mon, Jun 05, 2006 at 12:03:35PM -0400, Jason Lunz wrote: If these are a real problem, I'll gladly help debug it. I'm using 2.6.17-rc5's bcm43xx and the in-kernel ieee80211 softmac stack. I'm using wpa/ccmp/aes with an openwrt AP. Do you happen to have a wireless sniffer that you could use to capture the frames? It would be interesting to see whether such a capture log could be mapped into the dropped frames shown in the kernel debug log. In many cases, this may be caused by something missing in local filtering (e.g., retry duplicates are not filtered out correctly or messages to incorrect addresses are allowed through, etc.). Is it the driver's responsibility to do this filtering, or the softmac stack's? Can you show me a code example where this filtering is done properly? This is generic functionality and something I would like to see implemented in the 802.11 stack so that every low-level driver would not need to do this. I don't remember what net/ieee80211 code does in this area. Devicescape code (net/d80211 in wireless-dev.git) has duplicate detection in ieee80211_rx_h_check(). I can try different implementations of WPA in the AP if necessary. I think openwrt has other options. My end is in-kernel ieee80211_softmac - is there anything you'd like me to look at there? Would you be interested in testing this with net/d80211 code and wireless-dev.git? It would be interesting to see whether you would get a different result with the AP end kept in identical configuration and just changing the client side 802.11 network stack. With net/d80211, the CCMP replay detection printk is disabled by default (which is what should be done with net/ieee80211 implementation, too), so that needs to be enabled at build time. Counters are available from procfs files, though, so number of replays can be compared. If the messages are actually useful, and unusual, then they should probably stay. But I get a LOT of them, and my wireless is working just fine. Unfortunately, they are not really unusual. They are useful--at least for developers--so #ifdef or run-time option for enabling/disabling them would be nice. I noticed that there are counters being incremented where those printks are. How do I see those counters from userspace? These used to be visible from procfs in the original implementation in Host AP driver. However, it looks like print_stats function is not called at all in the version that is in net/ieee80211, so the counters may not be exposed at the moment. They should be, though.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SIOCSIWESSID + SIOCSIWAP behaviour
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. I don't think there is requirement for doing a new scan here if recent scan results are available. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Same here. Neither of these commands should drop IEEE 802.11 authentication. I would say that neither should drop association either until a new association is available or it is clear that current configuration does not allow association to be created. First case would just report a new association (no disassociation reported) and second case would report disassociation to user space. Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, which causes softmac to associate twice, and that quickly confuses things. (I don't really understand why wpa_supplicant uses SIWAP when a BSSID isn't specified in the config file, but...) There are two different modes and what is being described here is ap_scan=1, i.e., wpa_supplicant being responsible for requesting scanning and selecting an AP. In this mode, it is actually assumed that the driver does not do extra scans with SIWAP or SIWESSID. wpa_supplicant is telling the driver which channel (SIOCSIWFREQ), SSID, and BSSID to use. In the other mode, ap_scan=2, wpa_supplicant is only configuring the SSID and requesting the driver (or well, kernel side 802.11 management code) to figure out which AP to use. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote: I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). What the standard says is somewhat irrelevant since there are APs that use multiple SSID with the same BSSID. I would say that it is reasonable for users to expect that this works with Linux, too. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. Keep in mind that it is also used by some programs (e.g., wpa_supplicant in ap_scan=1) without the user having to know anything about that level of details.. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. Number of drivers use an atomic associate command (usually, a private ioctl) with wpa_supplicant. If there were a standard way of doing that, it could be helpful. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dscape ieee80211: enabling/disabling the radio
On Wed, May 10, 2006 at 03:53:48PM +0200, Ivo van Doorn wrote: I think the problem is what the dscape exactly expects the driver to do when add_interface() is called by the stack. When that call has finished, does the stack expects the radio to be enabled, or should it instruct the driver to enable the radio later on through a field in the config structure. I think the current expectation is for the interface to be set into enabled state at this point. What currently happens in rt2x00 (Which might not be doing what the stack expects) is that when add_interface() is called the radio remains off untill open() is called or radio_enabled has been set in the config structure. We used radio_enabled (or well, the previously used name adm_status) as a soft disable, i.e., the radio hardware was mostly enabled, but no TX or RX happened. This could, e.g., mean masking out interrupts and/or disabling receive part of the radio. This has been used to provide a mechanism for disabling the radio without having to set the interface down, i.e., without causing IP addresses to be dropped or bridging status changed. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Add support for user space clientMLME
On Thu, May 04, 2006 at 02:26:53PM +0200, Johannes Berg wrote: On Wed, 2006-05-03 at 09:44 -0700, Jouni Malinen wrote: But there is.. I committed changes to the wpa_supplicant devel branch for this yesterday. It seems to work fine with net/d80211 and bcm43xx with this small patch to d80211 to allow the functionality to be moved into user space. Cool, do you have a list of things that we need to support for it to work on a 'softmac' based driver (iow removing softmac in favour of this)? This is still somewhat open, but at minimum, there needs to be a mechanism for receiving and sending management frames from user space. d80211 uses a management netdev for this currently (the same one that was used before with hostapd for AP mode). In addition to that, wpa_supplicant expect to be able to read list of support channels and TX rates (get_hw_feature_data handler in driver wrapper) and to be able to add and remove STA entries (e.g., for TX rate control and association status validation in kernel code). Currently, scanning is done simply by setting the channel with SIOCSIWFREQ and listening for management frames. However, the goal is to provide simple atomic operations that user space programs can request the kernel code to do. This would cover not only scanning, but also some other needs like IEEE 802.11k radio measurements. These operations could be something like stop transmit, move to channel 5, report received management frames, record noise level, do this for 5 ms, return to operational channel, enable transmit. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
On Fri, May 05, 2006 at 03:14:35PM -0500, Larry Finger wrote: * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo structure into the kernel. Information passed to the daemon will be the country code in ASCII and whether the interface is to be used indoors or outdoors. The driver may not know the country code, so there should be mechanism for user space to override this. * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit anyone with moderate skills from hacking the channel/power settings, but such hacking will require some effort. I did not see this included in the example file. Did you have more detailed plans on how this would be done? * Each channel in the resulting kernel data structure will have appropriate flags set indicating if it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a flag will be set if the channel is to conform with 802.11h or 802.11a standards. 802.11h, radar detection, and DFS may need to be more complex than just a one-bit value of it being enabled. Countries may have different requirements for different areas related to 802.11h.. The database consists of two sections. The first relates the Country Codes to a wireless group. The second section describes the channel parameters for the groups. Shown below is a fragment showing the Country Code - Group info for a few countries and the definitions for a few of the groups. One way to compress this and possible make maintaining quite a bit easier would be to use two different set of groups: one for 2.4 GHz band and another one for 5 GHz band. Many countries share the same requirements for 2.4 GHz, but have different 5 GHz requirements.. This is not really a requirement, but could end up making this easier to use. Number of Countries: 100 Number of Groups: 15 These are not really needed and unless a tool is used to update this file, they will most likely end up being out of sync at some point ;-). The parser can just read through the file twice if it need to know these numbers before parsing (though, that should not really be needed with dynamic data structures).. # group Country CodeDescription # 1 AT Austria (Standard EU) 1 DE Germany (Standard EU) 2 FRI France Indoor (Not Guyana or La Reunion) 3 FRO France Outdoor (Not Guyana or La Reunion) 4 FR1 French Departments of Guyana and La Reunion Indoor 5 FR2 French Departments of Guyana and La Reunion Outdoor Country code has to be two characters to fit into country IE.. AT and DE are a good example of possible use for different 2.4 GHz and 5 GHz groups.. If I remember correctly, they have the same rules for 2.4 GHz, but different for 5 GHz.. (unless--of course--they already changed them since I looked last time.. ;-) # Ch. Range - Minimum and Maximum Channels for this range # Ch. Spacing - Number of channels between adjacent entries Other option would be to use start channel and number of channels. Channel spacing is also fixed in practice (1 for 2.4 GHz, 4 for 5 GHz), so it may not be needed here. # Power in mW EIRP I would prefer to see the maximum TX power in dBm, not mW. # Flag Codes # B - Both Indoor and Outdoor # I - Indoor Only # O - Outdoor Only # P - Passive Scan Only Some more flags may need to be added in the future. It looks like the format used here makes this trivial to extend. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
On Thu, May 04, 2006 at 11:00:28AM +0200, Jiri Benc wrote: Ok. So what about PRISM2_HOSTAPD_MGMT_IF ioctl that will add management interface (if not added yet) and return its ifindex? It would accept a boolean parameter (like PRISM2_PARAM_HOSTAPD) to add/remove that interface. If you agree with this, I will make a patch. Yes, that would be fine. Of course, both hostapd and wpa_supplicant needs to be changed for that. This should not be a problem now as the d80211 stack is not in a common use yet. Sure, no problems with that at the moment. So wpa_supplicant needs to know if the card is softmac or fullmac and behave accordingly, right? Yes. Currently, I'm just using a configuration file parameter for this, but this information should eventually be exported by the kernel code to allow wpa_supplicant to select which mode to use without requiring user configuration. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
On Wed, May 03, 2006 at 06:28:15PM +0200, Jiri Benc wrote: It is too early for this. We need to implement some better communication interface between kernel and hostapd (or what will implement userspace MLME) first. The current solution, where there is some special net_device interface (wmaster0ap) abused to dump informations to userspace, is ugly and confusing for users. Why do you think that this would be too early now? I agree that the interface between kernel and user space MLME can be improved, but I see no point in making client MLME implementation wait for that to happen. Personally, I don't think that the wmaster#ap interface is really that ugly, but I have nothing against this being improved if someone has time for doing it. I just don't see it as the highest priority. There is no userspace MLME implementation yet. And if one is going to be written, I'm really convinced it should be written in a clean way. I think Simon said he would examine a possibility to convert this stuff to netlink - is there some progress there? But there is.. I committed changes to the wpa_supplicant devel branch for this yesterday. It seems to work fine with net/d80211 and bcm43xx with this small patch to d80211 to allow the functionality to be moved into user space. I have not yet heard of anyone working with details of converting the management frame communication to use netlink. Also, I'm not sure how fullmac cards could be (potentially) supported with this approach. In the same way as with the kernel space MLME implementation.. This does not really change regardless of where the MLME code is implemented. Some time ago, I sent a preliminary patch showing what kind of changes are needed and this was mainly avoiding calls to some ieee80211_sta.c functions. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
On Wed, May 03, 2006 at 08:10:59PM +0200, Jiri Benc wrote:
If you really feel this is a necessary feature (although I think we
should focus more on putting the stack to a form suitable for inclusion
in the kernel than on adding new features now), what about making the
wmaster0ap interface appear only when the device is switched to user
space MLME? Should I make a patch?
I think it would be nice to get this in so that both client and AP modes
can use the same mechanism (user space MLME); hostapd already needs this
wmaster0ap interface. In other words, if we do not want to see that
interface by default, we could just add a generic mechanism for
registering wmaster0ap that both hostapd and wpa_supplicant could use.
The Host AP driver (driver/net/wireless/hostap) is doing this with
PRISM2_PARAM_HOSTAPD parameter. I don't care how it's done, but some
simple mechanism would be preferred.
I had in mind cards with large parts of MLME implemented in their
firmware, when MLME is moved from the stack fully to userspace. Such
cards probably won't allow you to handle e. g. scanning by switching
channels and sending probe requests. I know, we're not going to support
them soon, but isn't this something that will disallow the suppport at
all?
No, move of MLME to user space should not change this at all. As an
example, wpa_supplicant supports both cases and the patch I'm working on
for getting Prism2 (full MAC for client mode) working with d80211 is
modifying the kernel side to allow this to be done. Both changes are
touching the same areas in the code, but there is no major change in
whether fullmac can be supported or not.
Some time ago, I sent a preliminary patch showing what kind of changes
are needed and this was mainly avoiding calls to some ieee80211_sta.c
functions.
Hm, I probably missed that patch (or maybe just can't remember). Could
you post a link or something?
http://hostap.epitest.fi/releases/testing/jkm-wireless-dev-patches.tar.gz
That is not up-to-date with wireless-dev.git anymore, though. The key
patch is d80211_fullmac_client.diff which is small enough to include
here. Please note that this is not yet complete, so consider it more an
example on what type of changes are needed.
d80211: Add support for hardware-based client MLME (fullmac)
Add support for using hardware/firmware-based client MLME (fullmac) into
the Devicescape IEEE 802.11 stack. This adds a new flag, hw_client_mlme,
for the low-level drivers to indicate that the client MLME (management
frame processing) is implemented in hardware/firmware. This disables
host-based MLME implementation for client mode.
In addition to changes in net/d80211, this patch fixes client mode for
the Prism2/2.5/3 driver in drivers/net/wireless/d80211 by using the new
mode of implementing client MLME in firmware. AP mode (Host AP) is still
using host-based MLME.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/prism3_hw.c
+++ wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
@@ -2931,6 +2931,7 @@ static struct ieee80211_hw prism3_hw = {
.version = IEEE80211_VERSION,
.name = prism3,
.host_broadcast_ps_buffering = 1,
+ .hw_client_mlme = 1,
.num_modes = 1,
.num_modes = NUM_ENTRIES(prism3_hw_modes),
.modes = prism3_hw_modes,
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -441,7 +441,11 @@ struct ieee80211_hw {
/* 1 = low-level driver supports skb fraglist (NETIF_F_FRAGLIST), i.e.,
* more than one skb per frame */
- unsigned int fraglist;
+ unsigned int fraglist:1;
+
+ /* 0 = client MLME in host software (softmac)
+* 1 = client MLME in hardware/firmware (fullmac) */
+ unsigned int hw_client_mlme:1;
/* This is the time in us to change channels
*/
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1028,10 +1028,16 @@ static int ieee80211_ioctl_scan_req(stru
u8 *pos = param-u.scan_req.ssid;
int left = param_len - ((u8 *) pos - (u8 *) param);
int len = param-u.scan_req.ssid_len;
+ struct ieee80211_local *local = dev-priv;
if (left len || len IEEE80211_MAX_SSID_LEN)
return -EINVAL;
+ if (local-hw-hw_client_mlme) {
+ /* TODO: add local-hw-scan_req() */
+ return 0;
+ }
+
return ieee80211_sta_req_scan(dev, pos, len);
}
@@ -1053,10 +1059,17 @@ static int ieee80211_ioctl_mlme(struct n
struct
net/d80211 and management interface (wmaster0ap)
It looks like one of your patches in wireless-dev.git broke management
interface. I'm not completely sure about how this was supposed to work,
but are the low-level drivers now expected to accept
IEEE80211_IF_TYPE_MGMT in add_interface handler or should ieee80211.c be
modified to accept wmaster0ap to be set UP without asking the low-level
driver? The patch below does the former by modifying bcm43xx_main.c to
have a special case for IEEE80211_IF_TYPE_MGMT. This interface itself
does not require additional functionality from the low-level driver.
In addition to this, it looked like sending packets from wmaster0ap did
not work. The packets were being dropped since originating device
(wmaster0ap) did not match in is_ieee80211_device(). This function
seemed to use wireless_handlers pointer for recognizing interfaces which
(like to comment says) is not that nice. wireless_handlers were not set
for apdev, so the patch below adds it to make TX work through
wmaster0ap.
Does these match with your understanding of how the management interface
is supposed to work now after your patches went in?
Allow management interface (wmaster0ap) to be set UP with bcm43xx and
allow frames to be sent through it by making sure that
is_ieee80211_device(apdev) returns 1.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -4115,6 +4115,8 @@ struct net_device *ieee80211_alloc_hw(si
ether_setup(apdev);
apdev-priv = local;
apdev-hard_start_xmit = ieee80211_mgmt_start_xmit;
+ apdev-wireless_handlers =
+ (struct iw_handler_def *) ieee80211_iw_handler_def;
apdev-change_mtu = ieee80211_change_mtu_apdev;
apdev-get_stats = ieee80211_get_stats;
apdev-open = ieee80211_open;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -4195,6 +4195,9 @@ static int bcm43xx_add_interface(struct
{
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ if (conf-type == IEEE80211_IF_TYPE_MGMT)
+ return 0;
+
if (bcm-interfaces 0)
return -ENOBUFS;
if (conf-type == IEEE80211_IF_TYPE_MNTR) {
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev] d80211: Add support for user space client MLME
Add a configuration option for disabling client MLME in kernel
code. This is used to enable user space MLME for client mode (e.g.,
with wpa_supplicant). The kernel MLME implementation is unmodified,
but it could be removed or at least made optional in build
configuration in the future.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/hostapd_ioctl.h
===
--- wireless-dev.orig/net/d80211/hostapd_ioctl.h
+++ wireless-dev/net/d80211/hostapd_ioctl.h
@@ -91,6 +91,7 @@ enum {
PRISM2_PARAM_KEY_MGMT = 1040,
PRISM2_PARAM_RADAR_DETECT = 1043,
PRISM2_PARAM_SPECTRUM_MGMT = 1044,
+ PRISM2_PARAM_USER_SPACE_MLME = 1045,
/* NOTE: Please try to coordinate with other active development
* branches before allocating new param numbers so that each new param
* will be unique within all branches and the allocated number will not
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3116,8 +3116,9 @@ ieee80211_rx_h_mgmt(struct ieee80211_txr
{
struct ieee80211_sub_if_data *sdata;
sdata = IEEE80211_DEV_TO_SUB_IF(rx-dev);
- if (sdata-type == IEEE80211_IF_TYPE_STA ||
- sdata-type == IEEE80211_IF_TYPE_IBSS) {
+ if ((sdata-type == IEEE80211_IF_TYPE_STA ||
+sdata-type == IEEE80211_IF_TYPE_IBSS)
+ !rx-local-user_space_mlme) {
ieee80211_sta_rx_mgmt(rx-dev, rx-skb, rx-u.rx.status);
} else {
/* Management frames are sent to hostapd for processing */
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1048,10 +1048,14 @@ static int ieee80211_ioctl_scan_req(stru
struct prism2_hostapd_param *param,
int param_len)
{
+ struct ieee80211_local *local = dev-priv;
u8 *pos = param-u.scan_req.ssid;
int left = param_len - ((u8 *) pos - (u8 *) param);
int len = param-u.scan_req.ssid_len;
+ if (local-user_space_mlme)
+ return -EOPNOTSUPP;
+
if (left len || len IEEE80211_MAX_SSID_LEN)
return -EINVAL;
@@ -1076,8 +1080,12 @@ static int ieee80211_ioctl_sta_get_state
static int ieee80211_ioctl_mlme(struct net_device *dev,
struct prism2_hostapd_param *param)
{
+ struct ieee80211_local *local = dev-priv;
struct ieee80211_sub_if_data *sdata;
+ if (local-user_space_mlme)
+ return -EOPNOTSUPP;
+
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata-type != IEEE80211_IF_TYPE_STA
sdata-type != IEEE80211_IF_TYPE_IBSS)
@@ -1136,6 +1144,10 @@ static int ieee80211_ioctl_set_sta_vlan(
static int ieee80211_set_gen_ie(struct net_device *dev, u8 *ie, size_t len)
{
struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_local *local = dev-priv;
+
+ if (local-user_space_mlme)
+ return -EOPNOTSUPP;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata-type == IEEE80211_IF_TYPE_STA ||
@@ -1745,6 +1757,7 @@ static int ieee80211_ioctl_siwessid(stru
struct iw_request_info *info,
struct iw_point *data, char *ssid)
{
+ struct ieee80211_local *local = dev-priv;
struct ieee80211_sub_if_data *sdata;
size_t len = data-length;
@@ -1754,8 +1767,16 @@ static int ieee80211_ioctl_siwessid(stru
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata-type == IEEE80211_IF_TYPE_STA ||
- sdata-type == IEEE80211_IF_TYPE_IBSS)
+ sdata-type == IEEE80211_IF_TYPE_IBSS) {
+ if (local-user_space_mlme) {
+ if (len IEEE80211_MAX_SSID_LEN)
+ return -EINVAL;
+ memcpy(sdata-u.sta.ssid, ssid, len);
+ sdata-u.sta.ssid_len = len;
+ return 0;
+ }
return ieee80211_sta_set_ssid(dev, ssid, len);
+ }
if (sdata-type == IEEE80211_IF_TYPE_AP) {
memcpy(sdata-u.ap.ssid, ssid, len);
@@ -1804,11 +1825,17 @@ static int ieee80211_ioctl_siwap(struct
struct iw_request_info *info,
struct sockaddr *ap_addr, char *extra)
{
+ struct ieee80211_local *local = dev-priv;
struct ieee80211_sub_if_data *sdata;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata-type == IEEE80211_IF_TYPE_STA ||
sdata-type == IEEE80211_IF_TYPE_IBSS) {
+ if (local
Re: [RFC] Geographical/regulatory information for ieee80211
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote: I don't think it would make that much difference as the user could easily lie about their locality and get any set of parameters that they wanted. Well, not any set.. One of the configured countries, yes, but that is not same as setting arbitrary TX power limit and allowed channel sets.. Anyway, users should be allowed to move from one country to another and still being able to use their wlan card (within the limits of the current location). I am leaning toward putting the geographical information into a userland daemon. That way we won't have to patch the kernel every time a country modifies its regulations. In addition, the kernel will be smaller. The downside is that the daemon will have to be updated and supplied in some convenient form, perhaps as part of a wireless tools package. I'm strongly in favor of doing this in user space, too. In order to provide some control on what end users do with this, I would consider including a signature on a data file and have the user space tool verify that signature before accepting the data. This signature need not be anything extra secure, i.e., it could just be a keyed checksum of the file using a well-known key. The main point here is that it shows some attempt on limiting end users from setting random values to regulatory limits. Of course, if someone really wants to change these values, they could do so since the source code for the tool would be available and so would the key used for signing the file in the first place. I don't know how secure a system would be needed to pass requirements that FCC and similar organizations place on wireless devices. I would like to handle this with fully open source tools and having some kind of simple signature on the data file would be good starting point. It is up to vendors then to decide whether they are fine with such a mechanism or whether some additional tool (like the Intel plan on using a closed source user space tool) would be needed on top of this. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/10] d80211: get rid of default management interface
On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote: Default management interface (wlanXap) confuses users. It is only needed for AP mode (and only until interfaces are converted to use native 802.11 frames). Or when using user space MLME in client mode which is something that I just got working as far as scanning and association is concerned. In other words, wpa_supplicant will be needing this interface.. This patch removes default management interface. When a new interface is switched to AP mode, a management interface is created automatically. This also fixes some problems with multiple AP interfaces - now you have different management interface for each AP interface. That sounds like something that could break multi-BSSID/SSID aware hostapd. Are you saying that there would be new wlanXap like interface for each BSS/VLAN interface? What are the problems this is fixing with multiple AP interfaces? So far, hostapd has been responsible for receiving all management from a single interface and then internally decide which BSS/multi-SSID entry to use for each. I would assume that hostapd could be changed to process frames from multiple interfaces (at least if this is only for multi-BSSID, not for multi-SSID/VLAN case). There may be some special cases, where it would be easier to just be able to use one interface. Likewise, I would expect single interface to be closer to a design that would be using netlink for getting management frames into user space. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SIOCGIWSCAN wireless event behaviour
On Thu, Apr 20, 2006 at 03:15:59PM +0100, Daniel Drake wrote: I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant (but have not confirmed that yet). No, they don't. madwifi-ng is already doing this with background scanning and as was pointed out, there can be multiple programs asking for scans, so user space must be prepared for multiple events anyway. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SIOCGIWSCAN wireless event behaviour
On Thu, Apr 20, 2006 at 09:43:54AM -0700, Jean Tourrilhes wrote: After we changed to behaviour of ipw, various users reported that wpa_supplicant was confused. I particularly trust the report of Bill Moss, who has been hacking ipw for a long time : http://sourceforge.net/mailarchive/forum.php?thread_id=10091113forum_id=38938 Hmm.. Can someone please describe what was changed? Just sending SIOCGIWSCAN events more frequently? I have not seen any problems with this in my tests (though, mainly with madwifi-ng). Is the broken case available in one of the kernel trees? 2.6.16? wireless-2.6? (i.e., where can I get the exact version of ipw2200 driver that is expected to show incorrect behavior)? Jouni was notified, but did not really answer to that bug report. Then, the ipw maintainers commited the following patch to ipw that fix or workaround that issue : http://marc.theaimsgroup.com/?l=linux-netdevm=114492056522667w=2 Hmm.. I don't remember having seen that report from Bill Moss.. How was I notified? ;-) The patch here seems to be moving ipw_disassociate() call, so it is not obviously clear from that what the impact on behavior is. I can try to reproduce this, but I would like to know what version to test with in order to avoid any possible workarounds from hiding the issue. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix crash on big-endian systems during scan
On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote: The original code was doing arithmetics on a little-endian value. John, please apply this to wireless-2.6 tree. This code is triggered at least for the case where WPA is not used. I had noticed it before, but I think I've only tested WPA/WPA2 on big endian systems.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
On Thu, Apr 13, 2006 at 02:19:26PM +0200, Johannes Berg wrote: But the question is rather -- should we block the program inside the kernel and only return from get scan after the scan is actually done, rather than returning we can't give you anything now, try later. We could do that too, but then the program would be blocked inside the kernel without any chance of saying bah, this takes too long, I'll ignore it. Please don't. That could be blocking an ioctl call for couple of seconds and would be quite horrible for single threaded programs. It is possible to wait for scan completion events, but what if some other program were to request a new scan between the completion event and the attempt to read the previous scan results.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
On Thu, Apr 13, 2006 at 03:28:53PM -0700, Pete Zaitcev wrote: On Thu, 13 Apr 2006 09:00:51 -0700, Jouni Malinen [EMAIL PROTECTED] wrote: That could be blocking an ioctl call for couple of seconds and would be quite horrible for single threaded programs. I would say that waiting for couple of seconds in the kernel would be quite wonderful for single threaded programs, when you consider the alternative. I can guess now what your concern is, even though you failed to articulate it: a single-threaded GUI application, which cannot respond to events when blocked in getting scan results. If that's the case, we should be looking at having both blocking and non-blocking calls to fetch scan results. No, my main concern was single-threaded design in wpa_suppliant.. If the ioctl call is blocking, I would need to create a new (well, the first additional) thread just for this use. Without that, the blocking call would also block all control interface commands (interaction with external programs) and controlling of other interfaces (if more than one is used). [...] but what if some other program were to request a new scan between the completion event and the attempt to read the previous scan results.. I do not see how this is relevant. That would make the application wait even if it properly waited for the scan complete event before reading the scan result. If the get-results call is blocking, the single-threaded application simply don't have any easy way of getting the results while being able to do something else while waiting for the scan to complete. Furthermore, blocking ioctl handlers is not really something I would like to see in the kernel.. Aren't there some locks/semaphores/etc. kept for some cases? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Prism2 driver for Devicescape 802.11 stack (AP and fullmac STA)
I've started creating a new Prism2/2.5/3 driver for the Devicescape 802.11 stack based on the Host AP driver. This allows access point mode to be tested with the current net/d80211 code in wireless-dev.git (requires hostapd snapshot from the development branch) and eventually, will be an example on how fullmac-type of client implementation (MLME in firmware/hardware) can be implemented. My changes are available for preview from http://hostap.epitest.fi/releases/testing/jkm-wireless-dev-patches.tar.gz (this is a tarball of quilt 'patches' directory for wireless-dev.git). The current version seems to allow WPA2-PSK/CCMP to be used in AP mode at least with PC Cards (prism3_cs.ko). I have not yet tested other hardware versions. In addition, some of the features (e.g., firmware download) are not yet enabled in this version. The client mode is not yet complete, but d80211_fullmac_client.diff shows what type of changes are needed to support fullmac design. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Prism2 driver for Devicescape 802.11 stack (AP and fullmac STA)
On Mon, Apr 10, 2006 at 04:23:47AM +0200, Michael Buesch wrote: When I am back home, I will continue at the bcm43xx AP stuff. Shouldn't be too hard to get it working, actually. So, there we will have another driver for testing AP mode. Yes, indeed. As far as I can tell, the main issue is in Beacon frames not being sent out. Many of my clients don't really care about that (well, as long as they are not going to use power save mode), so they can already associate with WPA using bcm43xx as the AP. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev] d80211: Replace MODULE_PARM with module_param
MODULE_PARM macro was removed and this broke net/d80211 build. Fix this by using module_param instead of MODULE_PARM. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-dev/net/d80211/ieee80211_ioctl.c === --- wireless-dev.orig/net/d80211/ieee80211_ioctl.c +++ wireless-dev/net/d80211/ieee80211_ioctl.c @@ -30,7 +30,7 @@ static int ieee80211_regdom = 0x10; /* FCC */ -MODULE_PARM(ieee80211_regdom, i); +module_param(ieee80211_regdom, int, 0444); MODULE_PARM_DESC(ieee80211_regdom, IEEE 802.11 regulatory domain; 64=MKK); /* @@ -40,7 +40,7 @@ MODULE_PARM_DESC(ieee80211_regdom, IEEE * module. */ static int ieee80211_japan_5ghz /* = 0 */; -MODULE_PARM(ieee80211_japan_5ghz, i); +module_param(ieee80211_japan_5ghz, int, 0444); MODULE_PARM_DESC(ieee80211_japan_5ghz, Vendor-updated firmware for 5 GHz); -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH wireless-dev] Move d80211-based drivers into new subdirectory
Move rt2x00 and bcm43xx-d80211 drivers into a new drivers/net/wireless/d80211 subdirectory. This directory is used for collecting wireless LAN drivers that use the Devicescape IEEE 802.11 stack (net/d80211). After applying this patch file, the existing directories must be moved with following commands: mv drivers/net/wireless/bcm43xx-d80211 drivers/net/wireless/d80211/bcm43xx mv drivers/net/wireless/rt2x00 drivers/net/wireless/d80211/rt2x00 Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-dev/drivers/net/wireless/d80211/README === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/README @@ -0,0 +1,2 @@ +This directory contains IEEE 802.11 wireless LAN drivers that are using +Devicescape IEEE 802.11 stack (net/d80211). Index: wireless-dev/drivers/net/wireless/Kconfig === --- wireless-dev.orig/drivers/net/wireless/Kconfig +++ wireless-dev/drivers/net/wireless/Kconfig @@ -506,8 +506,7 @@ config PRISM54 source drivers/net/wireless/hostap/Kconfig source drivers/net/wireless/bcm43xx/Kconfig -source drivers/net/wireless/bcm43xx-d80211/Kconfig -source drivers/net/wireless/rt2x00/Kconfig +source drivers/net/wireless/d80211/Kconfig # yes, this works even when no drivers are selected config NET_WIRELESS Index: wireless-dev/drivers/net/wireless/Makefile === --- wireless-dev.orig/drivers/net/wireless/Makefile +++ wireless-dev/drivers/net/wireless/Makefile @@ -37,9 +37,9 @@ obj-$(CONFIG_PRISM54) += prism54/ obj-$(CONFIG_HOSTAP) += hostap/ obj-$(CONFIG_BCM43XX) += bcm43xx/ -obj-$(CONFIG_BCM43XX_D80211) += bcm43xx-d80211/ -obj-$(CONFIG_RT2X00) += rt2x00/ - # 16-bit wireless PCMCIA client drivers obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o obj-$(CONFIG_PCMCIA_WL3501)+= wl3501_cs.o + +# Drivers using Devicescape IEEE 802.11 stack (net/d80211) +obj-y += d80211/ Index: wireless-dev/drivers/net/wireless/d80211/Kconfig === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/Kconfig @@ -0,0 +1,2 @@ +source drivers/net/wireless/d80211/bcm43xx/Kconfig +source drivers/net/wireless/d80211/rt2x00/Kconfig Index: wireless-dev/drivers/net/wireless/d80211/Makefile === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_BCM43XX_D80211) += bcm43xx/ +obj-$(CONFIG_RT2X00) += rt2x00/ -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RX processing order for packet sockets and bridge
On Wed, Mar 29, 2006 at 01:16:30PM -0800, [EMAIL PROTECTED] wrote: With STP disabled it is still possible to use the same type of packet socket to receive EAPOL frames. However, the frames will now end up being received from the bridge interface (e.g., br0), not Ethernet (eth0). In other words, the supplicant will need to know that it needs to bind to another interface. That is fixed in 2.6.17, STP and other link local frames go up through the stack, but are not forwarded. Thanks! This does indeed fix the issue I was seeing and does it nicely without requiring complex workarounds for being able to process EAPOL frames. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
