diff options
10 files changed, 241 insertions, 277 deletions
diff --git a/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch b/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch new file mode 100644 index 000000000..2e6b0d2ec --- /dev/null +++ b/freed-ora/current/f18/3.10.-6-7-crashes-on-network-activity.patch @@ -0,0 +1,140 @@ +From 6aeddf9d409f3d9938b05b545d65810739237b2e Mon Sep 17 00:00:00 2001 +From: Felix Fietkau <nbd@openwrt.org> +Date: Tue, 20 Aug 2013 06:56:08 +0200 +Subject: [PATCH] 3.10.{6,7} crashes on network activity + +On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote: +> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote: +>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman +>> <gregkh@linuxfoundation.org> wrote: +>> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote: +>> >> Hi guys, +>> >> +>> >> Starting with 3.10.6 (and still present in .7) I get an oops on +>> >> connecting to the network. +>> >> +>> >> The attached picture shows the oops. In case it does not reach the ML, +>> >> the top of the call trace reads: +>> >> +>> >> brcms_c_compute_rtscts_dur +>> >> brcms_c_ampdu_finalize +>> >> ampdu_finalize +>> >> dma_txfast +>> >> brcms_c_txfifo +>> >> brcms_c_sendpkt_mac80211 +>> >> brcms_ops_tx +>> >> __ieee80211_tx +>> >> +>> >> I bisected the problem and the first bad commit is +>> >> +>> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 +>> >> Author: Felix Fietkau <nbd@openwrt.org> +>> >> Date: Fri Jun 28 21:04:35 2013 +0200 +>> >> +>> >> mac80211/minstrel_ht: fix cck rate sampling +>> >> +>> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream. +>> >> +>> >> Reverting it on top of .7 fixes the problem. +>> >> +>> >> I had the same (I suppose) problem on mainline some time ago, but I +>> >> have not bisected it, verified that the problem still occurs there, or +>> >> checked if reverting the upstream patch fixes it. I'd be happy to do +>> >> that if it would help though. +>> >> +>> >> Let me know if you need any more information. +>> > +>> > Do you have this same problem with 3.11-rc6 as well? +>> +>> Yes, I just confirmed. I also confirmed that reverting the mainline +>> commit on top of -rc6 fixes the problem. +> +> Great, thanks. +> +> Felix and Johannes, any chance we can get this reverted in Linus tree +> soon, and push that revert back to the 3.10 stable tree as well? +I'd like to avoid a revert, since that will simply replace one set of +issues with another. Let's limit the use of the feature that brcmsmac +can't handle to drivers that are known to work with it. Tom, Please +test this patch to see if it fixes your issue. + +- Felix +--- + drivers/net/wireless/ath/ath9k/init.c | 3 ++- + drivers/net/wireless/ath/carl9170/main.c | 3 ++- + drivers/net/wireless/rt2x00/rt2800lib.c | 3 ++- + include/net/mac80211.h | 1 + + net/mac80211/rc80211_minstrel_ht.c | 3 +++ + 5 files changed, 10 insertions(+), 3 deletions(-) + +diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c +index 2ba4945..bd126c2 100644 +--- a/drivers/net/wireless/ath/ath9k/init.c ++++ b/drivers/net/wireless/ath/ath9k/init.c +@@ -767,7 +767,8 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw) + IEEE80211_HW_PS_NULLFUNC_STACK | + IEEE80211_HW_SPECTRUM_MGMT | + IEEE80211_HW_REPORTS_TX_ACK_STATUS | +- IEEE80211_HW_SUPPORTS_RC_TABLE; ++ IEEE80211_HW_SUPPORTS_RC_TABLE | ++ IEEE80211_HW_SUPPORTS_HT_CCK_RATES; + + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION; +diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c +index e9010a4..0686375 100644 +--- a/drivers/net/wireless/ath/carl9170/main.c ++++ b/drivers/net/wireless/ath/carl9170/main.c +@@ -1857,7 +1857,8 @@ void *carl9170_alloc(size_t priv_size) + IEEE80211_HW_SUPPORTS_PS | + IEEE80211_HW_PS_NULLFUNC_STACK | + IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC | +- IEEE80211_HW_SIGNAL_DBM; ++ IEEE80211_HW_SIGNAL_DBM | ++ IEEE80211_HW_SUPPORTS_HT_CCK_RATES; + + if (!modparam_noht) { + /* +diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c +index 705aa33..7e66a90 100644 +--- a/drivers/net/wireless/rt2x00/rt2800lib.c ++++ b/drivers/net/wireless/rt2x00/rt2800lib.c +@@ -5912,7 +5912,8 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev) + IEEE80211_HW_SUPPORTS_PS | + IEEE80211_HW_PS_NULLFUNC_STACK | + IEEE80211_HW_AMPDU_AGGREGATION | +- IEEE80211_HW_REPORTS_TX_ACK_STATUS; ++ IEEE80211_HW_REPORTS_TX_ACK_STATUS | ++ IEEE80211_HW_SUPPORTS_HT_CCK_RATES; + + /* + * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices +diff --git a/include/net/mac80211.h b/include/net/mac80211.h +index 885898a..4e50d36 100644 +--- a/include/net/mac80211.h ++++ b/include/net/mac80211.h +@@ -1484,6 +1484,7 @@ enum ieee80211_hw_flags { + IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24, + IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25, + IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26, ++ IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27, + }; + + /** +diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c +index f5aed96..f3bbea1 100644 +--- a/net/mac80211/rc80211_minstrel_ht.c ++++ b/net/mac80211/rc80211_minstrel_ht.c +@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_priv *mp, struct minstrel_ht_sta *mi, + if (sband->band != IEEE80211_BAND_2GHZ) + return; + ++ if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES)) ++ return; ++ + mi->cck_supported = 0; + mi->cck_supported_short = 0; + for (i = 0; i < 4; i++) { +-- +1.8.3.1 + diff --git a/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch b/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch new file mode 100644 index 000000000..0c4fc2484 --- /dev/null +++ b/freed-ora/current/f18/ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch @@ -0,0 +1,63 @@ +From 2712c283acc085b5438fa1b22053423a0158468d Mon Sep 17 00:00:00 2001 +From: Hannes Frederic Sowa <hannes@stressinduktion.org> +Date: Fri, 16 Aug 2013 11:02:27 +0000 +Subject: [PATCH] ipv6: remove max_addresses check from ipv6_create_tempaddr + +Because of the max_addresses check attackers were able to disable privacy +extensions on an interface by creating enough autoconfigured addresses: + +<http://seclists.org/oss-sec/2012/q4/292> + +But the check is not actually needed: max_addresses protects the +kernel to install too many ipv6 addresses on an interface and guards +addrconf_prefix_rcv to install further addresses as soon as this limit +is reached. We only generate temporary addresses in direct response of +a new address showing up. As soon as we filled up the maximum number of +addresses of an interface, we stop installing more addresses and thus +also stop generating more temp addresses. + +Even if the attacker tries to generate a lot of temporary addresses +by announcing a prefix and removing it again (lifetime == 0) we won't +install more temp addresses, because the temporary addresses do count +to the maximum number of addresses, thus we would stop installing new +autoconfigured addresses when the limit is reached. + +This patch fixes CVE-2013-0343 (but other layer-2 attacks are still +possible). + +Thanks to Ding Tianhong to bring this topic up again. + +Cc: Ding Tianhong <dingtianhong@huawei.com> +Cc: George Kargiotakis <kargig@void.gr> +Cc: P J P <ppandit@redhat.com> +Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> +Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> +Acked-by: Ding Tianhong <dingtianhong@huawei.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +--- + net/ipv6/addrconf.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c +index fb8c94c..21b7a87 100644 +--- a/net/ipv6/addrconf.c ++++ b/net/ipv6/addrconf.c +@@ -1124,12 +1124,10 @@ retry: + if (ifp->flags & IFA_F_OPTIMISTIC) + addr_flags |= IFA_F_OPTIMISTIC; + +- ift = !max_addresses || +- ipv6_count_addresses(idev) < max_addresses ? +- ipv6_add_addr(idev, &addr, tmp_plen, ++ ift = ipv6_add_addr(idev, &addr, tmp_plen, + ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK, +- addr_flags) : NULL; +- if (IS_ERR_OR_NULL(ift)) { ++ addr_flags); ++ if (IS_ERR(ift)) { + in6_ifa_put(ifp); + in6_dev_put(idev); + pr_info("%s: retry temporary address regeneration\n", __func__); +-- +1.8.3.1 + diff --git a/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch b/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch deleted file mode 100644 index 08b360d10..000000000 --- a/freed-ora/current/f18/iwl4965-reset-firmware-after-rfkill-off.patch +++ /dev/null @@ -1,56 +0,0 @@ -Using rfkill switch can make firmware unstable, what cause various -Microcode errors and kernel warnings. Reseting firmware just after -rfkill off (radio on) helped with that. - -Resolve: -https://bugzilla.redhat.com/show_bug.cgi?id=977053 - -Reported-and-tested-by: Justin Pearce <whitefox@guardianfox.net> -Cc: stable@vger.kernel.org -Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> ---- - drivers/net/wireless/iwlegacy/4965-mac.c | 10 +++++----- - drivers/net/wireless/iwlegacy/common.c | 1 + - 2 files changed, 6 insertions(+), 5 deletions(-) - -diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c -index f0b7794..f2ed62e 100644 ---- a/drivers/net/wireless/iwlegacy/4965-mac.c -+++ b/drivers/net/wireless/iwlegacy/4965-mac.c -@@ -4460,12 +4460,12 @@ il4965_irq_tasklet(struct il_priv *il) - * is killed. Hence update the killswitch state here. The - * rfkill handler will care about restarting if needed. - */ -- if (!test_bit(S_ALIVE, &il->status)) { -- if (hw_rf_kill) -- set_bit(S_RFKILL, &il->status); -- else -- clear_bit(S_RFKILL, &il->status); -+ if (hw_rf_kill) { -+ set_bit(S_RFKILL, &il->status); -+ } else { -+ clear_bit(S_RFKILL, &il->status); - wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill); -+ il_force_reset(il, true); - } - - handled |= CSR_INT_BIT_RF_KILL; -diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c -index 3195aad..b03e22e 100644 ---- a/drivers/net/wireless/iwlegacy/common.c -+++ b/drivers/net/wireless/iwlegacy/common.c -@@ -4660,6 +4660,7 @@ il_force_reset(struct il_priv *il, bool external) - - return 0; - } -+EXPORT_SYMBOL(il_force_reset); - - int - il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif, --- -1.7.11.7 - --- -To unsubscribe from this list: send the line "unsubscribe linux-wireless" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html
\ No newline at end of file diff --git a/freed-ora/current/f18/kernel.spec b/freed-ora/current/f18/kernel.spec index d419f866b..9d296897e 100644 --- a/freed-ora/current/f18/kernel.spec +++ b/freed-ora/current/f18/kernel.spec @@ -112,7 +112,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 7 +%define stable_update 9 # Is it a -stable RC? %define stable_rc 0 # Set rpm version accordingly @@ -830,17 +830,15 @@ Patch25069: iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch #rhbz 969473 Patch25070: Input-elantech-fix-for-newer-hardware-versions-v7.patch -#rhbz 977053 -Patch25073: iwl4965-reset-firmware-after-rfkill-off.patch - -#rhbz 981445 -Patch25074: mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch -Patch25075: mac80211-ignore-HT-primary-channel-while-connected.patch -Patch25076: mac80211-continue-using-disabled-channels-while-connected.patch - #rhbz 963715 Patch25077: media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch +#CVE-2013-0343 rhbz 914664 999380 +Patch25078: ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch + +#rhbz 989269 +Patch25079: 3.10.-6-7-crashes-on-network-activity.patch + # END OF PATCH DEFINITIONS %endif @@ -1606,17 +1604,15 @@ ApplyPatch iwlwifi-dvm-fix-calling-ieee80211_chswitch_done-with-NULL.patch #rhbz 969473 ApplyPatch Input-elantech-fix-for-newer-hardware-versions-v7.patch -#rhbz 977053 -ApplyPatch iwl4965-reset-firmware-after-rfkill-off.patch - -#rhbz 981445 -ApplyPatch mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch -ApplyPatch mac80211-ignore-HT-primary-channel-while-connected.patch -ApplyPatch mac80211-continue-using-disabled-channels-while-connected.patch - #rhbz 963715 ApplyPatch media-cx23885-Fix-TeVii-S471-regression-since-introduction-of-ts2020.patch +#CVE-2013-0343 rhbz 914664 999380 +ApplyPatch ipv6-remove-max_addresses-check-from-ipv6_create_tempaddr.patch + +#rhbz 989269 +ApplyPatch 3.10.-6-7-crashes-on-network-activity.patch + # END OF PATCH APPLICATIONS %endif @@ -2469,6 +2465,23 @@ fi # ||----w | # || || %changelog +* Wed Aug 21 2013 Alexandre Oliva <lxoliva@fsfla.org> -libre +- GNU Linux-libre 3.10.9-gnu. + +* Wed Aug 21 2013 Josh Boyer <jwboyer@fedoraproject.org> +- Add patch to fix brcmsmac oops (rhbz 989269) +- CVE-2013-0343 handling of IPv6 temporary addresses (rhbz 914664 999380) + +* Tue Aug 20 2013 Josh Boyer <jwboyer@fedoraproject.org> +- Linux v3.10.9 + +* Tue Aug 20 2013 Josh Boyer <jwboyer@fedoraproject.org> - 3.10.8-100 +- Linux v3.10.8 +- CVE-2013-4254 ARM: perf: NULL pointer dereference in validate_event (rhbz 998878 998881) + +* Fri Aug 16 2013 Josh Boyer <jwboyer@fedoraproject.org> +- Add patch from Nathanael Noblet to fix mic on Gateway LT27 (rhbz 845699) + * Thu Aug 15 2013 Alexandre Oliva <lxoliva@fsfla.org> -libre - GNU Linux-libre 3.10.7-gnu. diff --git a/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch b/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch deleted file mode 100644 index 91dd1d7db..000000000 --- a/freed-ora/current/f18/mac80211-continue-using-disabled-channels-while-connected.patch +++ /dev/null @@ -1,43 +0,0 @@ -From ddfe49b42d8ad4bfdf92d63d4a74f162660d878d Mon Sep 17 00:00:00 2001 -From: Johannes Berg <johannes.berg@intel.com> -Date: Wed, 31 Jul 2013 18:52:03 +0000 -Subject: mac80211: continue using disabled channels while connected - -In case the AP has different regulatory information than we do, -it can happen that we connect to an AP based on e.g. the world -roaming regulatory data, and then update our database with the -AP's country information disables the channel the AP is using. -If this happens on an HT AP, the bandwidth tracking code will -hit the WARN_ON() and disconnect. Since that's not very useful, -ignore the channel-disable flag in bandwidth tracking. - -Cc: stable@vger.kernel.org -Reported-by: Chris Wright <chrisw@sous-sol.org> -Tested-by: Chris Wright <chrisw@sous-sol.org> -Signed-off-by: Johannes Berg <johannes.berg@intel.com> ---- -diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c -index 077a953..cc9e02d 100644 ---- a/net/mac80211/mlme.c -+++ b/net/mac80211/mlme.c -@@ -335,8 +335,17 @@ out: - if (ret & IEEE80211_STA_DISABLE_VHT) - vht_chandef = *chandef; - -+ /* -+ * Ignore the DISABLED flag when we're already connected and only -+ * tracking the APs beacon for bandwidth changes - otherwise we -+ * might get disconnected here if we connect to an AP, update our -+ * regulatory information based on the AP's country IE and the -+ * information we have is wrong/outdated and disables the channel -+ * that we're actually using for the connection to the AP. -+ */ - while (!cfg80211_chandef_usable(sdata->local->hw.wiphy, chandef, -- IEEE80211_CHAN_DISABLED)) { -+ tracking ? 0 : -+ IEEE80211_CHAN_DISABLED)) { - if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) { - ret = IEEE80211_STA_DISABLE_HT | - IEEE80211_STA_DISABLE_VHT; --- -cgit v0.9.2 diff --git a/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch b/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch deleted file mode 100644 index 49115f969..000000000 --- a/freed-ora/current/f18/mac80211-fix-infinite-loop-in-ieee80211_determine_chantype.patch +++ /dev/null @@ -1,32 +0,0 @@ -From b56e4b857c5210e848bfb80e074e5756a36cd523 Mon Sep 17 00:00:00 2001 -From: Chris Wright <chrisw@sous-sol.org> -Date: Wed, 31 Jul 2013 19:12:24 +0000 -Subject: mac80211: fix infinite loop in ieee80211_determine_chantype - -Commit "3d9646d mac80211: fix channel selection bug" introduced a possible -infinite loop by moving the out target above the chandef_downgrade -while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump -back up to re-run the while loop...indefinitely. Replace goto with -break and carry on. This may not be sufficient to connect to the AP, -but will at least keep the cpu from livelocking. Thanks to Derek Atkins -as an extra pair of debugging eyes. - -Cc: stable@kernel.org -Signed-off-by: Chris Wright <chrisw@sous-sol.org> -Signed-off-by: Johannes Berg <johannes.berg@intel.com> ---- -diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c -index ae31968..e3e7d2b 100644 ---- a/net/mac80211/mlme.c -+++ b/net/mac80211/mlme.c -@@ -338,7 +338,7 @@ out: - if (WARN_ON(chandef->width == NL80211_CHAN_WIDTH_20_NOHT)) { - ret = IEEE80211_STA_DISABLE_HT | - IEEE80211_STA_DISABLE_VHT; -- goto out; -+ break; - } - - ret |= chandef_downgrade(chandef); --- -cgit v0.9.2 diff --git a/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch b/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch deleted file mode 100644 index ba5d2a478..000000000 --- a/freed-ora/current/f18/mac80211-ignore-HT-primary-channel-while-connected.patch +++ /dev/null @@ -1,121 +0,0 @@ -From 5cdaed1e878d723d56d04ae0be1738124acf9f46 Mon Sep 17 00:00:00 2001 -From: Johannes Berg <johannes.berg@intel.com> -Date: Wed, 31 Jul 2013 09:23:06 +0000 -Subject: mac80211: ignore HT primary channel while connected - -While we're connected, the AP shouldn't change the primary channel -in the HT information. We checked this, and dropped the connection -if it did change it. - -Unfortunately, this is causing problems on some APs, e.g. on the -Netgear WRT610NL: the beacons seem to always contain a bad channel -and if we made a connection using a probe response (correct data) -we drop the connection immediately and can basically not connect -properly at all. - -Work around this by ignoring the HT primary channel information in -beacons if we're already connected. - -Also print out more verbose messages in the other situations to -help diagnose similar bugs quicker in the future. - -Cc: stable@vger.kernel.org [3.10] -Acked-by: Andy Isaacson <adi@hexapodia.org> -Signed-off-by: Johannes Berg <johannes.berg@intel.com> ---- -diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c -index e5c3cf4..077a953 100644 ---- a/net/mac80211/mlme.c -+++ b/net/mac80211/mlme.c -@@ -211,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - struct ieee80211_channel *channel, - const struct ieee80211_ht_operation *ht_oper, - const struct ieee80211_vht_operation *vht_oper, -- struct cfg80211_chan_def *chandef, bool verbose) -+ struct cfg80211_chan_def *chandef, bool tracking) - { -+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; - struct cfg80211_chan_def vht_chandef; - u32 ht_cfreq, ret; - -@@ -231,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan, - channel->band); - /* check that channel matches the right operating channel */ -- if (channel->center_freq != ht_cfreq) { -+ if (!tracking && channel->center_freq != ht_cfreq) { - /* - * It's possible that some APs are confused here; - * Netgear WNDR3700 sometimes reports 4 higher than -@@ -239,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - * since we look at probe response/beacon data here - * it should be OK. - */ -- if (verbose) -- sdata_info(sdata, -- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n", -- channel->center_freq, ht_cfreq, -- ht_oper->primary_chan, channel->band); -+ sdata_info(sdata, -+ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n", -+ channel->center_freq, ht_cfreq, -+ ht_oper->primary_chan, channel->band); - ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT; - goto out; - } -@@ -297,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - channel->band); - break; - default: -- if (verbose) -+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) - sdata_info(sdata, - "AP VHT operation IE has invalid channel width (%d), disable VHT\n", - vht_oper->chan_width); -@@ -306,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - } - - if (!cfg80211_chandef_valid(&vht_chandef)) { -- if (verbose) -+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) - sdata_info(sdata, - "AP VHT information is invalid, disable VHT\n"); - ret = IEEE80211_STA_DISABLE_VHT; -@@ -319,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata, - } - - if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) { -- if (verbose) -+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT)) - sdata_info(sdata, - "AP VHT information doesn't match HT, disable VHT\n"); - ret = IEEE80211_STA_DISABLE_VHT; -@@ -346,7 +346,7 @@ out: - ret |= chandef_downgrade(chandef); - } - -- if (chandef->width != vht_chandef.width && verbose) -+ if (chandef->width != vht_chandef.width && !tracking) - sdata_info(sdata, - "capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n"); - -@@ -386,7 +386,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata, - - /* calculate new channel (type) based on HT/VHT operation IEs */ - flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper, -- vht_oper, &chandef, false); -+ vht_oper, &chandef, true); - - /* - * Downgrade the new channel if we associated with restricted -@@ -3838,7 +3838,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata, - ifmgd->flags |= ieee80211_determine_chantype(sdata, sband, - cbss->channel, - ht_oper, vht_oper, -- &chandef, true); -+ &chandef, false); - - sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss), - local->rx_chains); --- -cgit v0.9.2 diff --git a/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign b/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign deleted file mode 100644 index 7ec555505..000000000 --- a/freed-ora/current/f18/patch-3.10-gnu-3.10.7-gnu.xz.sign +++ /dev/null @@ -1,7 +0,0 @@ ------BEGIN PGP SIGNATURE----- -Version: GnuPG v2.0.19 (GNU/Linux) - -iEYEABECAAYFAlINNCkACgkQvLfPh359R6d+VgCfZ5IDuYgwvFxl3DmCGGAAZ2GN -rgcAn19RHhD8yY5I1PsmE0bjt+CGC14Y -=bYR9 ------END PGP SIGNATURE----- diff --git a/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign b/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign new file mode 100644 index 000000000..681efc247 --- /dev/null +++ b/freed-ora/current/f18/patch-3.10-gnu-3.10.9-gnu.xz.sign @@ -0,0 +1,7 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.0.19 (GNU/Linux) + +iEYEABECAAYFAlIUL0sACgkQvLfPh359R6dkwACggEmHHThn2ZIsrWunYCkWic4R +JOIAnj2JDOiLHFayW4/3CQZvZyrQhsu8 +=YFWR +-----END PGP SIGNATURE----- diff --git a/freed-ora/current/f18/sources b/freed-ora/current/f18/sources index 3232d9c50..02b7f4a1c 100644 --- a/freed-ora/current/f18/sources +++ b/freed-ora/current/f18/sources @@ -1,2 +1,2 @@ d562fd52580a3b6b18b6eeb5921d1d5c linux-libre-3.10-gnu.tar.xz -8d05dec5772b17c4c21c00b93da42bd8 patch-3.10-gnu-3.10.7-gnu.xz +312e4b4203d2e74201a14f1a9633482d patch-3.10-gnu-3.10.9-gnu.xz |
