- 10 Oct, 2007 40 commits
-
-
Johannes Berg authored
Add a new file 'ifindex' to each key's debugfs dir to allow finding which interface the key was configured on. This isn't done as a symlink because of possible netdev name changes. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Michael Wu <flamingice@sourmilk.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Johannes Berg authored
This moves all the key handling code out from ieee80211_ioctl.c into key.c and also does the following changes including documentation updates in mac80211.h: 1) Turn off hardware acceleration for keys when the interface is down. This is necessary because otherwise monitor interfaces could be decrypting frames for other interfaces that are down at the moment. Also, it should go some way towards better suspend/resume support, in any case the routines used here could be used for that as well. Additionally, this makes the driver interface nicer, keys for a specific local MAC address are only ever present while an interface with that MAC address is enabled. 2) Change driver set_key() callback interface to allow only return values of -ENOSPC, -EOPNOTSUPP and 0, warn on all other return values. This allows debugging the stack when a driver notices it's handed a key while it is down. 3) Invert the flag meaning to KEY_FLAG_UPLOADED_TO_HARDWARE. 4) Remove REMOVE_ALL_KEYS command as it isn't used nor do we want to use it, we'll use DISABLE_KEY for each key. It is hard to use REMOVE_ALL_KEYS because we can handle multiple virtual interfaces with different key configuration, so we'd have to keep track of a lot of state for this and that isn't worth it. 5) Warn when disabling a key fails, it musn't. 6) Remove IEEE80211_HW_NO_TKIP_WMM_HWACCEL in favour of per-key IEEE80211_KEY_FLAG_WMM_STA to let driver sort it out itself. 7) Tell driver that a (non-WEP) key is used only for transmission by using an all-zeroes station MAC address when configuring. 8) Change the set_key() callback to have access to the local MAC address the key is being added for. Signed-off-by: -
Johannes Berg authored
Remove adding a fake key with a NONE key algorithm for each associated STA. If we have hardware with such TX filtering we should probably extend the sta_table_notification() callback with the sta information instead; the fact that it's treated as a key for some atheros hardware shouldn't bother the stack. Signed-off-by:
-
Johannes Berg authored
Remove the default_wep_only stuff, this wasn't really done well and no current driver actually cares. Signed-off-by:
-
Johannes Berg authored
they aren't really refcounted anyway Signed-off-by:
-
Johannes Berg authored
This patch embeds the struct ieee80211_key_conf into struct ieee80211_key and thus avoids allocations and having data present twice. This required some more changes: 1) The removal of the IEEE80211_KEY_DEFAULT_TX_KEY key flag. This flag isn't used by drivers nor should it be since we have a set_key_idx() callback. Maybe that callback needs to be extended to include the key conf, but only a driver that requires it will tell. 2) The removal of the IEEE80211_KEY_DEFAULT_WEP_ONLY key flag. This flag is global, so it shouldn't be passed in the key conf structure. Pass it to the function instead. Also, this patch removes the AID parameter to the set_key() callback because it is currently unused and the hardware currently cannot know about the AID anyway. I suspect this was used with some hardware that actually selected the AID itself, but that functionality was removed. Additionally, I've removed the ALG_NULL key algorithm since we have ALG_NONE. Signed-off-by: -
Jiri Slaby authored
mac80211, remove bitfields from struct ieee80211_sub_if_data Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Jiri Slaby authored
mac80211, remove bitfields from struct ieee80211_if_sta Signed-off-by:
-
Jiri Slaby authored
mac80211, remove bitfields from struct ieee80211_txrx_data Signed-off-by:
-
Jiri Slaby authored
remove bitfields from struct ieee80211_tx_packet_data [Johannes: completely clear flags in ieee80211_remove_tx_extra] Signed-off-by:
-
Johannes Berg authored
The transmit code needs to set the addresses depending on the interface type, a likely() for AP/VLAN is quite wrong since most people will be using STA; convert to a switch statement to make it look nicer. Signed-off-by:
-
Johannes Berg authored
Create a new file event.c that will contain code to send mac/mlme events to userspace. For now put the Michael MIC failure condition into it and remove sending of that condition via the management interface, hostapd interestingly doesn't do anything when it gets such a packet besides printing a message, it reacts only on the private iwevent. Signed-off-by:
-
Johannes Berg authored
The key_mgmt variable for STA interfaces doesn't seem well-defined nor do we actually use the values other than "NONE", so change it to be named better. Signed-off-by:
-
Johannes Berg authored
The ioctls * PRISM2_PARAM_RADAR_DETECT * PRISM2_PARAM_SPECTRUM_MGMT are not used by hostapd or wpa_supplicant, Signed-off-by:
-
Johannes Berg authored
The ioctls * PRISM2_PARAM_STA_ANTENNA_SEL * PRISM2_PARAM_TX_POWER_REDUCTION * PRISM2_PARAM_DEFAULT_WEP_ONLY are not used by hostapd or wpa_supplicant. Signed-off-by:
-
Johannes Berg authored
The ioctls * PRISM2_PARAM_ANTENNA_MODE * PRISM2_PARAM_STAT_TIME are not used by hostapd or wpa_supplicant. Signed-off-by:
-
Johannes Berg authored
When doing key selection for software decryption, mac80211 gets a few things wrong: it always uses pairwise keys if configured, even if the frame is addressed to a multicast address. Also, it doesn't allow using a key index of zero if a pairwise key has also been found. This patch changes the key selection code to be (more) in line with the 802.11 specification. I have confirmed that with this, multicast frames are correctly decrypted and I've tested with WEP as well. While at it, I've cleaned up the semantics of the hardware flags IEEE80211_HW_WEP_INCLUDE_IV and IEEE80211_HW_DEVICE_HIDES_WEP and clarified them in the mac80211.h header; it is also now allowed to set the IEEE80211_HW_DEVICE_HIDES_WEP option even if it only applies to frames that have been decrypted by the hw, unencrypted frames must be dropped but encrypted frames that the hardware couldn't handle can be passed up unmodified. Signed-off-by:
-
Johannes Berg authored
Unused in drivers, userspace and mac80211. Signed-off-by:
-
Johannes Berg authored
Neither hostapd nor wpa_supplicant really use it. Signed-off-by:
-
Johannes Berg authored
Many if not all of these messages can be triggered by sending a few rogue frames which is trivially done and then we overflow our logs. Signed-off-by:
-
Johannes Berg authored
Signed-off-by:
-
Johannes Berg authored
This now is unused in hostapd/wpa_supplicant. Signed-off-by:
-
Johannes Berg authored
The flag is never checked because drivers can simply call ieee80211_beacon_get() regardless of setting this flag. Signed-off-by:
-
Johannes Berg authored
The callback isn't used so remove it. Signed-off-by:
-
Johannes Berg authored
This fixes two issues with the key debugfs: 1) key index obviously isn't unique 2) various missing break statements led to bogus output Signed-off-by:
-
Johannes Berg authored
David Woodhouse noticed that under some circumstances the number of slab allocations kept growing. After looking a bit, this seemed to happen when you had a management mode interface that was *down*. The reason for this is that when the device is down, all management frames get queued to the in-kernel MLME (via ieee80211_sta_rx_mgmt) but then the sta work is invoked but doesn't run when the netif is down. When you then bring the interface up, all such frames are freed, but if you change the mode all of them are lost because the skb queue is reinitialised as soon as you go back to managed mode. The skb queue is correctly cleared when the interface is brought down, but the code doesn't account for the fact that it may be filled while it is not up. This patch should fix the issue by simply ignoring all interfaces that are down when going through the RX handlers. Signed-off-by:
-
Alex Villacís Lasso authored
This dongle does not follow the usb-irda specification, so it needs its own special driver. First, it uses control URBs for data transfer, instead of bulk or interrupt transfers; the only interrupt endpoint exposed seems to be a dummy to prevent the interface from being rejected. Second, it uses obfuscation and padding at the USB traffic level, for no apparent reason other than to make reverse engineering harder (full details on obfuscation in comments at beginning of source). Although it is advertised as a "4 Mbps FIR dongle", it apparently loses packets at speeds greater than 57600 bps. On plugin, this dongle reports vendor and device IDs: 0x07d0:0x4959 . The Windows driver that is used normally to control this dongle has a filename of KS-959.SYS . Signed-off-by:
Alex Villacís Lasso <a_villacis@palosanto.com> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
-
Alex Villacís Lasso authored
This dongle does not follow the usb-irda specification, so it needs its own special driver. Just like the Kingsun/Donshine dongle, it exposes two interrupt endpoints. Reception is performed through direct reads from the input endpoint. Transmission requires splitting the IrDA frames into 8-byte segments, in which the first byte encodes how many of the remaining 7 bytes are used as data. Speed change is made with a control URB just like the one in cypress_m8, and it seems to support up to 115200 bps. On plugin, this dongle reports vendor and device IDs: 0x07d0:0x4100 Signed-off-by:
-
Samuel Ortiz authored
Signed-off-by:
-
Ilpo Järvinen authored
Hopefully captured all single statement cases under net/. I'm not too sure if there is some policy about #includes that are "guaranteed" (ie., in the current tree) to be available through some other #included header, so I just added linux/kernel.h to each changed file that didn't #include it previously. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Robert Olsson authored
As noted by Christoph Hellwig, pktgen was the only user so it can now be removed. [ Add missing cases caught by Adrian Bunk. -DaveM ] Signed-off-by:
Robert Olsson <robert.olsson@its.uu.se> Signed-off-by:
-
Robert Olsson authored
It's not a job for pktgen. Signed-off-by:
-
Robert Olsson authored
Below some pktgen support to send into different TX queues. This can of course be feed into input queues on other machines Signed-off-by:
-
Denis Cheng authored
This could make future redesign of struct netlink_sock easier. Signed-off-by:
Denis Cheng <crquan@gmail.com> Signed-off-by:
-
Thomas Graf authored
Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Masahide NAKAMURA authored
IPv4 IPsec tunnel gateway incorrectly sends redirect to sender if it is onlink host when network device the IPsec tunnelled packet is arrived is the same as the one the decapsulated packet is sent. With this patch, it omits to send the redirect when the forwarding skbuff carries secpath, since such skbuff should be assumed as a decapsulated packet from IPsec tunnel by own. Request for comments: Alternatively we'd have another way to change net/ipv4/route.c (__mkroute_input) to use RTCF_DOREDIRECT flag unless skbuff has no secpath. It is better than this patch at performance point of view because IPv4 redirect judgement is done at routing slow-path. However, it should be taken care of resource changes between SAD(XFRM states) and routing table. In other words, When IPv4 SAD is changed does the related routing entry go to its slow-path? If not, it is reasonable to apply this patch. Signed-off-by:
Masahide NAKAMURA <nakam@linux-ipv6.org> Signed-off-by:
-
Masahide NAKAMURA authored
IPv6 IPsec tunnel gateway incorrectly sends redirect to router or sender when network device the IPsec tunnelled packet is arrived is the same as the one the decapsulated packet is sent. With this patch, it omits to send the redirect when the forwarding skbuff carries secpath, since such skbuff should be assumed as a decapsulated packet from IPsec tunnel by own. It may be a rare case for an IPsec security gateway, however it is not rare when the gateway is MIPv6 Home Agent since the another tunnel end-point is Mobile Node and it changes the attached network. Signed-off-by:
-
Noriaki TAKAMIYA authored
When XFRM policy and state are ready after TCP connection is started, the traffic should be transformed immediately, however it does not on IPv6 TCP. It depends on a dst cache replacement policy with connected socket. It seems that the replacement is always done for IPv4, however, on IPv6 case it is done only when routing cookie is changed. This patch fix that non-transformation dst can be changed to transformation one. This behavior is required by MIPv6 and improves IPv6 IPsec. Fixes by Masahide NAKAMURA. Signed-off-by:
Noriaki TAKAMIYA <takamiya@po.ntts.co.jp> Signed-off-by:
-
Brian Haley authored
Add v4mapped address inline to avoid calls to ipv6_addr_type(). Signed-off-by:
Brian Haley <brian.haley@hp.com> Signed-off-by:
-
Stephen Hemminger authored
This driver has been marked obsolete for a long time and is superseded by traffic schedulers. Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
