Revert openwrt patch which caused too high tx powers

Since the reverted patch, device specific antenna gain is not set for some reason.
Reverting the patch in question fixes this issue.

THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS FIXED PROPERLY!

Signed-off-by: Fabian Bläse <fabian@blaese.de>
Tested-by: Fabian Bläse <fabian@blaese.de>
---
 ...do-not-apply-broken-power-limits-with-ATH.patch | 173 +++++++++++++++++++++
 1 file changed, 173 insertions(+)
 create mode 100644 build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch

Am Samstag, den 20.01.2018, 15:50 +0100 schrieb Fabian Bläse:
> Since the reverted patch, device specific antenna gain is not set for
> some reason.
> Reverting the patch in question fixes this issue.
Warum? Woher kommt die Erkenntnis?

> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
> FIXED PROPERLY!
-v bitte..

Wer wird es mal "richtig" fixen?

Tim

> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> Tested-by: Fabian Bläse <fabian@blaese.de>
> ---
>  ...do-not-apply-broken-power-limits-with-ATH.patch | 173
> +++++++++++++++++++++
>  1 file changed, 173 insertions(+)
>  create mode 100644 build_patches/openwrt/0020-Revert-ath-do-not-
> apply-broken-power-limits-with-ATH.patch
> 
> diff --git a/build_patches/openwrt/0020-Revert-ath-do-not-apply-
> broken-power-limits-with-ATH.patch b/build_patches/openwrt/0020-
> Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch
> new file mode 100644
> index 0000000..760a454
> --- /dev/null
> +++ b/build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-
> power-limits-with-ATH.patch
> @@ -0,0 +1,173 @@
> +From e1fb372bc2466a04fdf57d2f806e362931a43daf Mon Sep 17 00:00:00
> 2001
> +From: =?UTF-8?q?Fabian=20Bl=C3=A4se?= <fabian@blaese.de>
> +Date: Sat, 20 Jan 2018 02:33:59 +0100
> +Subject: [PATCH] Revert "ath: do not apply broken power limits with
> + ATH_USER_REGD"
> +
> +This reverts commit a9728799bc41e68de4d50995bb4ad689784ef55e.
> +This is a workaround to fix txpower calculation
> +---
> + .../mac80211/patches/402-ath_regd_optional.patch   | 44 +++------
> -------------
> + .../mac80211/patches/403-world_regd_fixup.patch    |  4 +-
> + .../patches/406-ath_relax_default_regd.patch       |  8 ++--
> + 3 files changed, 12 insertions(+), 44 deletions(-)
> +
> +diff --git a/package/kernel/mac80211/patches/402-
> ath_regd_optional.patch b/package/kernel/mac80211/patches/402-
> ath_regd_optional.patch
> +index c8ede7f583..0d6d3dbdbd 100644
> +--- a/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> ++++ b/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> +@@ -1,14 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -24,6 +24,7 @@
> +- #include "regd_common.h"
> +- 
> +- static int __ath_regd_init(struct ath_regulatory *reg);
> +-+static struct reg_dmn_pair_mapping *ath_get_regpair(int regdmn);
> +- 
> +- /*
> +-  * This is a set of common rules used by our world regulatory
> domains.
> +-@@ -116,6 +117,9 @@ static const struct ieee80211_regdomain
> ++@@ -116,6 +116,9 @@ static const struct ieee80211_regdomain
> +  
> +  static bool dynamic_country_user_possible(struct ath_regulatory
> *reg)
> +  {
> +@@ -18,7 +10,7 @@
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +-@@ -188,6 +192,8 @@ static bool dynamic_country_user_possibl
> ++@@ -188,6 +191,8 @@ static bool dynamic_country_user_possibl
> +  
> +  static bool ath_reg_dyn_country_user_allow(struct ath_regulatory
> *reg)
> +  {
> +@@ -27,7 +19,7 @@
> +  	if (!IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_REG_HINTS))
> +  		return false;
> +  	if (!dynamic_country_user_possible(reg))
> +-@@ -341,6 +347,9 @@ ath_reg_apply_beaconing_flags(struct wip
> ++@@ -341,6 +346,9 @@ ath_reg_apply_beaconing_flags(struct wip
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -37,7 +29,7 @@
> +  	for (band = 0; band < NUM_NL80211_BANDS; band++) {
> +  		if (!wiphy->bands[band])
> +  			continue;
> +-@@ -374,6 +383,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> ++@@ -374,6 +382,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> +  {
> +  	struct ieee80211_supported_band *sband;
> +  
> +@@ -47,7 +39,7 @@
> +  	sband = wiphy->bands[NL80211_BAND_2GHZ];
> +  	if (!sband)
> +  		return;
> +-@@ -402,6 +414,9 @@ static void ath_reg_apply_radar_flags(st
> ++@@ -402,6 +413,9 @@ static void ath_reg_apply_radar_flags(st
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -57,19 +49,7 @@
> +  	if (!wiphy->bands[NL80211_BAND_5GHZ])
> +  		return;
> +  
> +-@@ -539,6 +554,11 @@ void ath_reg_notifier_apply(struct wiphy
> +- 		ath_reg_dyn_country(wiphy, reg, request);
> +- 		break;
> +- 	}
> +-+
> +-+	/* Prevent broken CTLs from being applied */
> +-+	if (IS_ENABLED(CPTCFG_ATH_USER_REGD) &&
> +-+	    reg->regpair != common->reg_world_copy.regpair)
> +-+		reg->regpair = ath_get_regpair(WOR0_WORLD);
> +- }
> +- EXPORT_SYMBOL(ath_reg_notifier_apply);
> +- 
> +-@@ -634,6 +654,10 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -634,6 +648,10 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	const struct ieee80211_regdomain *regd;
> +  
> +  	wiphy->reg_notifier = reg_notifier;
> +@@ -80,18 +60,6 @@
> +  	wiphy->regulatory_flags |= REGULATORY_STRICT_REG |
> +  				   REGULATORY_CUSTOM_REG;
> +  
> +-@@ -762,10 +786,7 @@ ath_regd_init(struct ath_regulatory *reg
> +- 	if (r)
> +- 		return r;
> +- 
> +--	if (ath_is_world_regd(reg))
> +--		memcpy(&common->reg_world_copy, reg,
> +--		       sizeof(struct ath_regulatory));
> +--
> +-+	memcpy(&common->reg_world_copy, reg, sizeof(struct
> ath_regulatory));
> +- 	ath_regd_init_wiphy(reg, wiphy, reg_notifier);
> +- 
> +- 	return 0;
> + --- a/drivers/net/wireless/ath/Kconfig
> + +++ b/drivers/net/wireless/ath/Kconfig
> + @@ -23,6 +23,9 @@ config WLAN_VENDOR_ATH
> +diff --git a/package/kernel/mac80211/patches/403-
> world_regd_fixup.patch b/package/kernel/mac80211/patches/403-
> world_regd_fixup.patch
> +index 2043083158..2b04309ce5 100644
> +--- a/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> ++++ b/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -44,7 +44,8 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -43,7 +43,8 @@ static int __ath_regd_init(struct ath_re
> +  					 NL80211_RRF_NO_OFDM)
> +  
> +  /* We allow IBSS on these on a case by case basis by regulatory
> domain */
> +@@ -10,7 +10,7 @@
> +  					 NL80211_RRF_NO_IR)
> +  #define ATH9K_5GHZ_5470_5850	REG_RULE(5470-10, 5850+10, 80,
> 0, 30,\
> +  					 NL80211_RRF_NO_IR)
> +-@@ -62,57 +63,56 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -61,57 +62,56 @@ static int __ath_regd_init(struct ath_re
> +  #define ATH9K_5GHZ_NO_MIDBAND	ATH9K_5GHZ_5150_5350, \
> +  				ATH9K_5GHZ_5725_5850
> +  
> +diff --git a/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch b/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> +index 35b0f2b76e..b6190b9363 100644
> +--- a/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> ++++ b/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -115,6 +115,16 @@ static const struct ieee80211_regdomain
> ++@@ -114,6 +114,16 @@ static const struct ieee80211_regdomain
> +  	)
> +  };
> +  
> +@@ -17,7 +17,7 @@
> +  static bool dynamic_country_user_possible(struct ath_regulatory
> *reg)
> +  {
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +-@@ -123,6 +133,9 @@ static bool dynamic_country_user_possibl
> ++@@ -122,6 +132,9 @@ static bool dynamic_country_user_possibl
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +@@ -27,7 +27,7 @@
> +  	switch (reg->country_code) {
> +  	case CTRY_UNITED_STATES:
> +  	case CTRY_JAPAN1:
> +-@@ -208,11 +221,6 @@ static inline bool is_wwr_sku(u16 regd)
> ++@@ -207,11 +220,6 @@ static inline bool is_wwr_sku(u16 regd)
> +  		(regd == WORLD));
> +  }
> +  
> +@@ -39,7 +39,7 @@
> +  bool ath_is_world_regd(struct ath_regulatory *reg)
> +  {
> +  	return is_wwr_sku(ath_regd_get_eepromRD(reg));
> +-@@ -658,6 +666,9 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -652,6 +660,9 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +  		return 0;
> +  
> +-- 
> +2.11.0
> +
> -- 
> 2.11.0
>

Hallo Tim,

>> Since the reverted patch, device specific antenna gain is not set for
>> some reason.
>> Reverting the patch in question fixes this issue.
> Warum? Woher kommt die Erkenntnis?
Viel testen, googlen, ..
Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.

Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.

>> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>> FIXED PROPERLY!
> -v bitte..
Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.

> Wer wird es mal "richtig" fixen?
Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)

Fabian

Hallo

Tested-by: Christian Dresel <fff@chrisi01.de>

Getestet wurde, ob die dbm Anzeige stimmt, dies kann ich bestätigen hier
sind die Werte dann wieder richtig.
Weiterhin hab ich einen ganz groben Test mit dem Handy durchgeführt, ich
hab versucht es exakt genauso wie mit der alten Firmware zu platzieren
(direkt an der Antenne) und ich konnte den Wert der vorher problemlos
erreichbar war nicht mehr erreichen. Gefühlt hat sich also die
Sendeleistung verringert wobei das natürlich nicht gerade ein genauer
Test ist. Allerdings waren es am Ende tatsächlich ziemlich genau diese
6db am 1043er die ich durch dieses Patch "verloren" habe. Es hat also
eine Auswirkung ob allerdings vorher "richtig" war oder jetzt "richtig"
ist kann ich nicht sagen.

Ich würde dieses Patch so erstmal einbauen für einen reviewed-by begreif
ich aber einfach viel zu wenig was es überhaupt tut.

mfg

Christian

On 20.01.2018 15:50, Fabian Bläse wrote:
> Since the reverted patch, device specific antenna gain is not set for some reason.
> Reverting the patch in question fixes this issue.
> 
> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS FIXED PROPERLY!
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> Tested-by: Fabian Bläse <fabian@blaese.de>
> ---
>  ...do-not-apply-broken-power-limits-with-ATH.patch | 173 +++++++++++++++++++++
>  1 file changed, 173 insertions(+)
>  create mode 100644 build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch
> 
> diff --git a/build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch b/build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch
> new file mode 100644
> index 0000000..760a454
> --- /dev/null
> +++ b/build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch
> @@ -0,0 +1,173 @@
> +From e1fb372bc2466a04fdf57d2f806e362931a43daf Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Fabian=20Bl=C3=A4se?= <fabian@blaese.de>
> +Date: Sat, 20 Jan 2018 02:33:59 +0100
> +Subject: [PATCH] Revert "ath: do not apply broken power limits with
> + ATH_USER_REGD"
> +
> +This reverts commit a9728799bc41e68de4d50995bb4ad689784ef55e.
> +This is a workaround to fix txpower calculation
> +---
> + .../mac80211/patches/402-ath_regd_optional.patch   | 44 +++-------------------
> + .../mac80211/patches/403-world_regd_fixup.patch    |  4 +-
> + .../patches/406-ath_relax_default_regd.patch       |  8 ++--
> + 3 files changed, 12 insertions(+), 44 deletions(-)
> +
> +diff --git a/package/kernel/mac80211/patches/402-ath_regd_optional.patch b/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> +index c8ede7f583..0d6d3dbdbd 100644
> +--- a/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> ++++ b/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> +@@ -1,14 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -24,6 +24,7 @@
> +- #include "regd_common.h"
> +- 
> +- static int __ath_regd_init(struct ath_regulatory *reg);
> +-+static struct reg_dmn_pair_mapping *ath_get_regpair(int regdmn);
> +- 
> +- /*
> +-  * This is a set of common rules used by our world regulatory domains.
> +-@@ -116,6 +117,9 @@ static const struct ieee80211_regdomain
> ++@@ -116,6 +116,9 @@ static const struct ieee80211_regdomain
> +  
> +  static bool dynamic_country_user_possible(struct ath_regulatory *reg)
> +  {
> +@@ -18,7 +10,7 @@
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +-@@ -188,6 +192,8 @@ static bool dynamic_country_user_possibl
> ++@@ -188,6 +191,8 @@ static bool dynamic_country_user_possibl
> +  
> +  static bool ath_reg_dyn_country_user_allow(struct ath_regulatory *reg)
> +  {
> +@@ -27,7 +19,7 @@
> +  	if (!IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_REG_HINTS))
> +  		return false;
> +  	if (!dynamic_country_user_possible(reg))
> +-@@ -341,6 +347,9 @@ ath_reg_apply_beaconing_flags(struct wip
> ++@@ -341,6 +346,9 @@ ath_reg_apply_beaconing_flags(struct wip
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -37,7 +29,7 @@
> +  	for (band = 0; band < NUM_NL80211_BANDS; band++) {
> +  		if (!wiphy->bands[band])
> +  			continue;
> +-@@ -374,6 +383,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> ++@@ -374,6 +382,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> +  {
> +  	struct ieee80211_supported_band *sband;
> +  
> +@@ -47,7 +39,7 @@
> +  	sband = wiphy->bands[NL80211_BAND_2GHZ];
> +  	if (!sband)
> +  		return;
> +-@@ -402,6 +414,9 @@ static void ath_reg_apply_radar_flags(st
> ++@@ -402,6 +413,9 @@ static void ath_reg_apply_radar_flags(st
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -57,19 +49,7 @@
> +  	if (!wiphy->bands[NL80211_BAND_5GHZ])
> +  		return;
> +  
> +-@@ -539,6 +554,11 @@ void ath_reg_notifier_apply(struct wiphy
> +- 		ath_reg_dyn_country(wiphy, reg, request);
> +- 		break;
> +- 	}
> +-+
> +-+	/* Prevent broken CTLs from being applied */
> +-+	if (IS_ENABLED(CPTCFG_ATH_USER_REGD) &&
> +-+	    reg->regpair != common->reg_world_copy.regpair)
> +-+		reg->regpair = ath_get_regpair(WOR0_WORLD);
> +- }
> +- EXPORT_SYMBOL(ath_reg_notifier_apply);
> +- 
> +-@@ -634,6 +654,10 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -634,6 +648,10 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	const struct ieee80211_regdomain *regd;
> +  
> +  	wiphy->reg_notifier = reg_notifier;
> +@@ -80,18 +60,6 @@
> +  	wiphy->regulatory_flags |= REGULATORY_STRICT_REG |
> +  				   REGULATORY_CUSTOM_REG;
> +  
> +-@@ -762,10 +786,7 @@ ath_regd_init(struct ath_regulatory *reg
> +- 	if (r)
> +- 		return r;
> +- 
> +--	if (ath_is_world_regd(reg))
> +--		memcpy(&common->reg_world_copy, reg,
> +--		       sizeof(struct ath_regulatory));
> +--
> +-+	memcpy(&common->reg_world_copy, reg, sizeof(struct ath_regulatory));
> +- 	ath_regd_init_wiphy(reg, wiphy, reg_notifier);
> +- 
> +- 	return 0;
> + --- a/drivers/net/wireless/ath/Kconfig
> + +++ b/drivers/net/wireless/ath/Kconfig
> + @@ -23,6 +23,9 @@ config WLAN_VENDOR_ATH
> +diff --git a/package/kernel/mac80211/patches/403-world_regd_fixup.patch b/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> +index 2043083158..2b04309ce5 100644
> +--- a/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> ++++ b/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -44,7 +44,8 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -43,7 +43,8 @@ static int __ath_regd_init(struct ath_re
> +  					 NL80211_RRF_NO_OFDM)
> +  
> +  /* We allow IBSS on these on a case by case basis by regulatory domain */
> +@@ -10,7 +10,7 @@
> +  					 NL80211_RRF_NO_IR)
> +  #define ATH9K_5GHZ_5470_5850	REG_RULE(5470-10, 5850+10, 80, 0, 30,\
> +  					 NL80211_RRF_NO_IR)
> +-@@ -62,57 +63,56 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -61,57 +62,56 @@ static int __ath_regd_init(struct ath_re
> +  #define ATH9K_5GHZ_NO_MIDBAND	ATH9K_5GHZ_5150_5350, \
> +  				ATH9K_5GHZ_5725_5850
> +  
> +diff --git a/package/kernel/mac80211/patches/406-ath_relax_default_regd.patch b/package/kernel/mac80211/patches/406-ath_relax_default_regd.patch
> +index 35b0f2b76e..b6190b9363 100644
> +--- a/package/kernel/mac80211/patches/406-ath_relax_default_regd.patch
> ++++ b/package/kernel/mac80211/patches/406-ath_relax_default_regd.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -115,6 +115,16 @@ static const struct ieee80211_regdomain
> ++@@ -114,6 +114,16 @@ static const struct ieee80211_regdomain
> +  	)
> +  };
> +  
> +@@ -17,7 +17,7 @@
> +  static bool dynamic_country_user_possible(struct ath_regulatory *reg)
> +  {
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +-@@ -123,6 +133,9 @@ static bool dynamic_country_user_possibl
> ++@@ -122,6 +132,9 @@ static bool dynamic_country_user_possibl
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +@@ -27,7 +27,7 @@
> +  	switch (reg->country_code) {
> +  	case CTRY_UNITED_STATES:
> +  	case CTRY_JAPAN1:
> +-@@ -208,11 +221,6 @@ static inline bool is_wwr_sku(u16 regd)
> ++@@ -207,11 +220,6 @@ static inline bool is_wwr_sku(u16 regd)
> +  		(regd == WORLD));
> +  }
> +  
> +@@ -39,7 +39,7 @@
> +  bool ath_is_world_regd(struct ath_regulatory *reg)
> +  {
> +  	return is_wwr_sku(ath_regd_get_eepromRD(reg));
> +-@@ -658,6 +666,9 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -652,6 +660,9 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +  		return 0;
> +  
> +-- 
> +2.11.0
> +
>

Hi

Reviewed und applied.

Tim

Am Samstag, den 20.01.2018, 15:50 +0100 schrieb Fabian Bläse:
> Since the reverted patch, device specific antenna gain is not set for
> some reason.
> Reverting the patch in question fixes this issue.
> 
> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
> FIXED PROPERLY!
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> Tested-by: Fabian Bläse <fabian@blaese.de>
> ---
>  ...do-not-apply-broken-power-limits-with-ATH.patch | 173
> +++++++++++++++++++++
>  1 file changed, 173 insertions(+)
>  create mode 100644 build_patches/openwrt/0020-Revert-ath-do-not-
> apply-broken-power-limits-with-ATH.patch
> 
> diff --git a/build_patches/openwrt/0020-Revert-ath-do-not-apply-
> broken-power-limits-with-ATH.patch b/build_patches/openwrt/0020-
> Revert-ath-do-not-apply-broken-power-limits-with-ATH.patch
> new file mode 100644
> index 0000000..760a454
> --- /dev/null
> +++ b/build_patches/openwrt/0020-Revert-ath-do-not-apply-broken-
> power-limits-with-ATH.patch
> @@ -0,0 +1,173 @@
> +From e1fb372bc2466a04fdf57d2f806e362931a43daf Mon Sep 17 00:00:00
> 2001
> +From: =?UTF-8?q?Fabian=20Bl=C3=A4se?= <fabian@blaese.de>
> +Date: Sat, 20 Jan 2018 02:33:59 +0100
> +Subject: [PATCH] Revert "ath: do not apply broken power limits with
> + ATH_USER_REGD"
> +
> +This reverts commit a9728799bc41e68de4d50995bb4ad689784ef55e.
> +This is a workaround to fix txpower calculation
> +---
> + .../mac80211/patches/402-ath_regd_optional.patch   | 44 +++------
> -------------
> + .../mac80211/patches/403-world_regd_fixup.patch    |  4 +-
> + .../patches/406-ath_relax_default_regd.patch       |  8 ++--
> + 3 files changed, 12 insertions(+), 44 deletions(-)
> +
> +diff --git a/package/kernel/mac80211/patches/402-
> ath_regd_optional.patch b/package/kernel/mac80211/patches/402-
> ath_regd_optional.patch
> +index c8ede7f583..0d6d3dbdbd 100644
> +--- a/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> ++++ b/package/kernel/mac80211/patches/402-ath_regd_optional.patch
> +@@ -1,14 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -24,6 +24,7 @@
> +- #include "regd_common.h"
> +- 
> +- static int __ath_regd_init(struct ath_regulatory *reg);
> +-+static struct reg_dmn_pair_mapping *ath_get_regpair(int regdmn);
> +- 
> +- /*
> +-  * This is a set of common rules used by our world regulatory
> domains.
> +-@@ -116,6 +117,9 @@ static const struct ieee80211_regdomain
> ++@@ -116,6 +116,9 @@ static const struct ieee80211_regdomain
> +  
> +  static bool dynamic_country_user_possible(struct ath_regulatory
> *reg)
> +  {
> +@@ -18,7 +10,7 @@
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +-@@ -188,6 +192,8 @@ static bool dynamic_country_user_possibl
> ++@@ -188,6 +191,8 @@ static bool dynamic_country_user_possibl
> +  
> +  static bool ath_reg_dyn_country_user_allow(struct ath_regulatory
> *reg)
> +  {
> +@@ -27,7 +19,7 @@
> +  	if (!IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_REG_HINTS))
> +  		return false;
> +  	if (!dynamic_country_user_possible(reg))
> +-@@ -341,6 +347,9 @@ ath_reg_apply_beaconing_flags(struct wip
> ++@@ -341,6 +346,9 @@ ath_reg_apply_beaconing_flags(struct wip
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -37,7 +29,7 @@
> +  	for (band = 0; band < NUM_NL80211_BANDS; band++) {
> +  		if (!wiphy->bands[band])
> +  			continue;
> +-@@ -374,6 +383,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> ++@@ -374,6 +382,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
> +  {
> +  	struct ieee80211_supported_band *sband;
> +  
> +@@ -47,7 +39,7 @@
> +  	sband = wiphy->bands[NL80211_BAND_2GHZ];
> +  	if (!sband)
> +  		return;
> +-@@ -402,6 +414,9 @@ static void ath_reg_apply_radar_flags(st
> ++@@ -402,6 +413,9 @@ static void ath_reg_apply_radar_flags(st
> +  	struct ieee80211_channel *ch;
> +  	unsigned int i;
> +  
> +@@ -57,19 +49,7 @@
> +  	if (!wiphy->bands[NL80211_BAND_5GHZ])
> +  		return;
> +  
> +-@@ -539,6 +554,11 @@ void ath_reg_notifier_apply(struct wiphy
> +- 		ath_reg_dyn_country(wiphy, reg, request);
> +- 		break;
> +- 	}
> +-+
> +-+	/* Prevent broken CTLs from being applied */
> +-+	if (IS_ENABLED(CPTCFG_ATH_USER_REGD) &&
> +-+	    reg->regpair != common->reg_world_copy.regpair)
> +-+		reg->regpair = ath_get_regpair(WOR0_WORLD);
> +- }
> +- EXPORT_SYMBOL(ath_reg_notifier_apply);
> +- 
> +-@@ -634,6 +654,10 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -634,6 +648,10 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	const struct ieee80211_regdomain *regd;
> +  
> +  	wiphy->reg_notifier = reg_notifier;
> +@@ -80,18 +60,6 @@
> +  	wiphy->regulatory_flags |= REGULATORY_STRICT_REG |
> +  				   REGULATORY_CUSTOM_REG;
> +  
> +-@@ -762,10 +786,7 @@ ath_regd_init(struct ath_regulatory *reg
> +- 	if (r)
> +- 		return r;
> +- 
> +--	if (ath_is_world_regd(reg))
> +--		memcpy(&common->reg_world_copy, reg,
> +--		       sizeof(struct ath_regulatory));
> +--
> +-+	memcpy(&common->reg_world_copy, reg, sizeof(struct
> ath_regulatory));
> +- 	ath_regd_init_wiphy(reg, wiphy, reg_notifier);
> +- 
> +- 	return 0;
> + --- a/drivers/net/wireless/ath/Kconfig
> + +++ b/drivers/net/wireless/ath/Kconfig
> + @@ -23,6 +23,9 @@ config WLAN_VENDOR_ATH
> +diff --git a/package/kernel/mac80211/patches/403-
> world_regd_fixup.patch b/package/kernel/mac80211/patches/403-
> world_regd_fixup.patch
> +index 2043083158..2b04309ce5 100644
> +--- a/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> ++++ b/package/kernel/mac80211/patches/403-world_regd_fixup.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -44,7 +44,8 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -43,7 +43,8 @@ static int __ath_regd_init(struct ath_re
> +  					 NL80211_RRF_NO_OFDM)
> +  
> +  /* We allow IBSS on these on a case by case basis by regulatory
> domain */
> +@@ -10,7 +10,7 @@
> +  					 NL80211_RRF_NO_IR)
> +  #define ATH9K_5GHZ_5470_5850	REG_RULE(5470-10, 5850+10, 80,
> 0, 30,\
> +  					 NL80211_RRF_NO_IR)
> +-@@ -62,57 +63,56 @@ static struct reg_dmn_pair_mapping *ath_
> ++@@ -61,57 +62,56 @@ static int __ath_regd_init(struct ath_re
> +  #define ATH9K_5GHZ_NO_MIDBAND	ATH9K_5GHZ_5150_5350, \
> +  				ATH9K_5GHZ_5725_5850
> +  
> +diff --git a/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch b/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> +index 35b0f2b76e..b6190b9363 100644
> +--- a/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> ++++ b/package/kernel/mac80211/patches/406-
> ath_relax_default_regd.patch
> +@@ -1,6 +1,6 @@
> + --- a/drivers/net/wireless/ath/regd.c
> + +++ b/drivers/net/wireless/ath/regd.c
> +-@@ -115,6 +115,16 @@ static const struct ieee80211_regdomain
> ++@@ -114,6 +114,16 @@ static const struct ieee80211_regdomain
> +  	)
> +  };
> +  
> +@@ -17,7 +17,7 @@
> +  static bool dynamic_country_user_possible(struct ath_regulatory
> *reg)
> +  {
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +-@@ -123,6 +133,9 @@ static bool dynamic_country_user_possibl
> ++@@ -122,6 +132,9 @@ static bool dynamic_country_user_possibl
> +  	if (IS_ENABLED(CPTCFG_ATH_REG_DYNAMIC_USER_CERT_TESTING))
> +  		return true;
> +  
> +@@ -27,7 +27,7 @@
> +  	switch (reg->country_code) {
> +  	case CTRY_UNITED_STATES:
> +  	case CTRY_JAPAN1:
> +-@@ -208,11 +221,6 @@ static inline bool is_wwr_sku(u16 regd)
> ++@@ -207,11 +220,6 @@ static inline bool is_wwr_sku(u16 regd)
> +  		(regd == WORLD));
> +  }
> +  
> +@@ -39,7 +39,7 @@
> +  bool ath_is_world_regd(struct ath_regulatory *reg)
> +  {
> +  	return is_wwr_sku(ath_regd_get_eepromRD(reg));
> +-@@ -658,6 +666,9 @@ ath_regd_init_wiphy(struct ath_regulator
> ++@@ -652,6 +660,9 @@ ath_regd_init_wiphy(struct ath_regulator
> +  	if (IS_ENABLED(CPTCFG_ATH_USER_REGD))
> +  		return 0;
> +  
> +-- 
> +2.11.0
> +
> -- 
> 2.11.0
>

Hallo,


ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit Update auf
20180802 habe ich tote meshrouter.

Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos
funktionierten, gehen nun gar nicht mehr.

Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.

https://monitoring.freifunk-franken.de/routers/5704

Ganz schlimm:

https://monitoring.freifunk-franken.de/routers/5842

https://monitoring.freifunk-franken.de/routers/4873

Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm


Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?



Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
> Hallo Tim,
>
>>> Since the reverted patch, device specific antenna gain is not set for
>>> some reason.
>>> Reverting the patch in question fixes this issue.
>> Warum? Woher kommt die Erkenntnis?
> Viel testen, googlen, ..
> Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>
> Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>
>>> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>>> FIXED PROPERLY!
>> -v bitte..
> Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>
>> Wer wird es mal "richtig" fixen?
> Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
> Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>
> Fabian
>
>

Hallo,


gerade bin ich noch hierüber gestolpert:

https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html

Am 23.09.2018 um 00:54 schrieb Florian Wiessner:
> Hallo,
>
>
> ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit Update auf
> 20180802 habe ich tote meshrouter.
>
> Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos
> funktionierten, gehen nun gar nicht mehr.
>
> Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>
> https://monitoring.freifunk-franken.de/routers/5704
>
> Ganz schlimm:
>
> https://monitoring.freifunk-franken.de/routers/5842
>
> https://monitoring.freifunk-franken.de/routers/4873
>
> Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>
>
> Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>
>
>
> Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>> Hallo Tim,
>>
>>>> Since the reverted patch, device specific antenna gain is not set for
>>>> some reason.
>>>> Reverting the patch in question fixes this issue.
>>> Warum? Woher kommt die Erkenntnis?
>> Viel testen, googlen, ..
>> Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>>
>> Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>>
>>>> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>>>> FIXED PROPERLY!
>>> -v bitte..
>> Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>>
>>> Wer wird es mal "richtig" fixen?
>> Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
>> Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>>
>> Fabian
>>
>>
>
> -- 
> Mit freundlichen Grüßen
>
> Florian Wiessner
>
>
> <http://www.smart-kvm.com/>
>
>
> smart-kvm.com
> c/o Smart Weblications GmbH
> Martinsberger Str. 1
> D-95119 Naila
> fon.: +49 9282 9638 200
> fax.: +49 9282 9638 205
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min*
> http://www.smart-kvm.com
>
> --
> Sitz der Gesellschaft: Naila
> Geschäftsführer: Florian Wiessner
> HRB-Nr.: HRB 3840 Amtsgericht Hof
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Hallo Florian,

es ist genau umgekehrt: Die alte Firmware hatte eine zu hohe Sendeleistung, alle Router mit 20170918 haben by default eine illegale Sendeleistung.

Die im Monitoring angezeigte Leistung ist OHNE Antennengewinn, die 20 dB gelten aber mit Antenne.

Die Ubiquity Geräte sind immer noch falsch, hier muss man den antenna-gain manuell einstellen.

Grüße

Adrian

On September 23, 2018 12:54:03 AM GMT+02:00, Florian Wiessner <f.wiessner@smart-kvm.com> wrote:
>Hallo,
>
>
>ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit
>Update auf
>20180802 habe ich tote meshrouter.
>
>Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos
>funktionierten, gehen nun gar nicht mehr.
>
>Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>
>https://monitoring.freifunk-franken.de/routers/5704
>
>Ganz schlimm:
>
>https://monitoring.freifunk-franken.de/routers/5842
>
>https://monitoring.freifunk-franken.de/routers/4873
>
>Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>
>
>Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>
>
>
>Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>> Hallo Tim,
>>
>>>> Since the reverted patch, device specific antenna gain is not set
>for
>>>> some reason.
>>>> Reverting the patch in question fixes this issue.
>>> Warum? Woher kommt die Erkenntnis?
>> Viel testen, googlen, ..
>> Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr
>(zumindest für die getesteten Geräte), was vorher der Fall war.
>>
>> Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig
>zuverlässige Möglichkeit.
>>
>>>> THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>>>> FIXED PROPERLY!
>>> -v bitte..
>> Lässt sich einrichten, gibts dann in einer v2 wenn der Rest
>ausdiskutiert ist.
>>
>>> Wer wird es mal "richtig" fixen?
>> Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das
>Problem selbst mal ansehen.
>> Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden,
>immerhin senden manche Geräte aktuell mit einem vielfachen der
>erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>>
>> Fabian
>>
>>
>
>-- 
>Mit freundlichen Grüßen
>
>Florian Wiessner
>
>
><http://www.smart-kvm.com/>
>
>
>smart-kvm.com
>c/o Smart Weblications GmbH
>Martinsberger Str. 1
>D-95119 Naila
>fon.: +49 9282 9638 200
>fax.: +49 9282 9638 205
>24/7: +49 900 144 000 00 - 0,99 EUR/Min*
>http://www.smart-kvm.com
>
>--
>Sitz der Gesellschaft: Naila
>Geschäftsführer: Florian Wiessner
>HRB-Nr.: HRB 3840 Amtsgericht Hof
>*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Hallo Florian,

wenn du irgendwelche Indizien hast, dass da wirklich was nicht passt, wäre das natürlich interessant. Bis jetzt glaube ich da aber eher nicht dran.

Speziell  bei der CPE210 ist das wohl der Grund, warum fast alle sagen, dass die scheiße ist.
(Die Leistung ist immerhin achtfach bei 20 dB im Vergleich zu 11 dB.)

Wenn du unserer fw nicht traust und experimentieren willst, kannst du meine adsc9 Firmware probieren. Die basiert direkt auf openwrt-1806, da ist zwar ein gleichwertiger Patch drin, aber halt nicht von uns, sondern direkt in openwrt.
Ich erwarte aber das gleiche Ergebnis.

Im übrigen passt die Angabe der dB jetzt  auch zu den anderen Werten der noch älteren FWs, bevor openwrt das kaputt gepatcht hat.

Grüße

Adrian



On September 23, 2018 1:30:53 AM GMT+02:00, Florian Wiessner <f.wiessner@smart-kvm.com> wrote:
>Hallo Adrian,
>
>Am 23.09.2018 um 01:05 schrieb Adrian Schmutzler:
>> Hallo Florian,
>>
>> es ist genau umgekehrt: Die alte Firmware hatte eine zu hohe
>Sendeleistung,
>> alle Router mit 20170918 haben by default eine illegale
>Sendeleistung.
>> Die im Monitoring angezeigte Leistung ist OHNE Antennengewinn, die 20
>dB
>> gelten aber mit Antenne.
>>
>> Die Ubiquity Geräte sind immer noch falsch, hier muss man den
>antenna-gain
>> manuell einstellen.
>>
>
>
>Davon bin ich nicht überzeugt, ich habe eher das Gefühl dass es in der
>aktuellen
>FW doppelt gefixt wurde. Wie kann es
> sein dass zwei wr1043n-v5 welche weiter ausseinander stehen und durch
>Beton
>funken müssen besseren Link haben als zwei cpe210, die von Dach zu Dach
>ohne
>Hindernisse funken können:
>
>https://monitoring.freifunk-franken.de/routers/5977
>
>Die CPE210 geben 11dbm an. Das haben die wohl auch wenn ich mir die
>Link-Quality
>anschaue im Vgl. zu den zwei wr1043n-v5 mit 14dbm.:
>
>https://monitoring.freifunk-franken.de/routers/5703
>
>Bzgl CPE210v2 FW - Konnte ich heute erfolgreich über 1.5km testen.
>
>
>> Grüße
>>
>> Adrian
>>
>> On September 23, 2018 12:54:03 AM GMT+02:00, Florian Wiessner
>> <f.wiessner@smart-kvm.com> wrote:
>>
>>     Hallo,
>>
>>
>>     ich hab das "Gefühl" dieser Patch funktioniert nicht richtig.
>Seit Update
>>     auf 20180802 habe ich tote meshrouter.
>>
>>     Ich habe enorme Reichweiteneinbußen, und Links die vorher
>reibungslos
>>     funktionierten, gehen nun gar nicht mehr.
>>
>>     Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>>
>>     https://monitoring.freifunk-franken.de/routers/5704
>>
>>     Ganz schlimm:
>>
>>     https://monitoring.freifunk-franken.de/routers/5842
>>
>>     https://monitoring.freifunk-franken.de/routers/4873
>>
>>     Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>>
>>
>>     Was tun? Soll ich den Patch reverten und Firmware selbst neu
>bauen?
>>
>>
>>
>>     Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>>>     Hallo Tim,
>>>
>>>>>     Since the reverted patch, device specific antenna gain is not
>set for
>>>>>     some reason.
>>>>>     Reverting the patch in question fixes this issue.
>>>>     Warum? Woher kommt die Erkenntnis?
>>>     Viel testen, googlen, ..
>>>     Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr
>(zumindest für die getesteten Geräte), was vorher der Fall war.
>>>
>>>     Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig
>zuverlässige Möglichkeit.
>>>
>>>>>     THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE
>ISSUE IS
>>>>>     FIXED PROPERLY!
>>>>     -v bitte..
>>>     Lässt sich einrichten, gibts dann in einer v2 wenn der Rest
>ausdiskutiert ist.
>>>
>>>>     Wer wird es mal "richtig" fixen?
>>>     Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir
>das Problem selbst mal ansehen.
>>>     Bis dahin sollte die Geschichte imho möglichst schnell gefixt
>werden, immerhin senden manche Geräte aktuell mit einem vielfachen der
>erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>>>
>>>     Fabian
>>>
>>>
>>
>>     -- 
>>     Mit freundlichen Grüßen
>>
>>     Florian Wiessner
>>
>>
>>     <http://www.smart-kvm.com/>
>>
>>
>>     smart-kvm.com
>>     c/o Smart Weblications GmbH
>>     Martinsberger Str. 1
>>     D-95119 Naila
>>     fon.: +49 9282 9638 200
>>     fax.: +49 9282 9638 205
>>     24/7: +49 900 144 000 00 - 0,99 EUR/Min*
>>     http://www.smart-kvm.com
>>
>>     --
>>     Sitz der Gesellschaft: Naila
>>     Geschäftsführer: Florian Wiessner
>>     HRB-Nr.: HRB 3840 Amtsgericht Hof
>>     *aus dem dt. Festnetz, ggf. abweichende Preise aus dem
>Mobilfunknetz
>>
>
>-- 
>Mit freundlichen Grüßen
>
>Florian Wiessner
>
>
><http://www.smart-kvm.com/>
>
>
>smart-kvm.com
>c/o Smart Weblications GmbH
>Martinsberger Str. 1
>D-95119 Naila
>fon.: +49 9282 9638 200
>fax.: +49 9282 9638 205
>24/7: +49 900 144 000 00 - 0,99 EUR/Min*
>http://www.smart-kvm.com
>
>--
>Sitz der Gesellschaft: Naila
>Geschäftsführer: Florian Wiessner
>HRB-Nr.: HRB 3840 Amtsgericht Hof
>*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Hallo,

 

den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht ist jemand anderes schlauer als ich …

 

Grüße

 

Adrian

 

From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Florian Wiessner
Sent: Sonntag, 23. September 2018 01:01
To: Fabian Bläse <fabian@blaese.de>; franken-dev@freifunk.net; Tim Niemeyer <tim@tn-x.org>
Subject: Re: [PATCH] Revert openwrt patch which caused too high tx powers

 

Hallo,


gerade bin ich noch hierüber gestolpert:

https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html

Am 23.09.2018 um 00:54 schrieb Florian Wiessner:

Hallo,


ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit Update auf 20180802 habe ich tote meshrouter.

Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos funktionierten, gehen nun gar nicht mehr.

Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.

https://monitoring.freifunk-franken.de/routers/5704

Ganz schlimm:

https://monitoring.freifunk-franken.de/routers/5842

https://monitoring.freifunk-franken.de/routers/4873

Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm


Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?



Am 20.01.2018 um 16:09 schrieb Fabian Bläse:

Hallo Tim,
 

Since the reverted patch, device specific antenna gain is not set for
some reason.
Reverting the patch in question fixes this issue.

Warum? Woher kommt die Erkenntnis?

Viel testen, googlen, ..
Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
 
Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
 

THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
FIXED PROPERLY!

-v bitte..

Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
 

Wer wird es mal "richtig" fixen?

Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
 
Fabian

Hallo Adrian,


ich habe jetzt mal die Firmware ohne besagten Patch gebaut und komme nun wieder
auf normale Werte. Ich habe gesehen dass für die Ubiquity Geräte separat ein
File existiert, wo Antenna Gain gesetzt wird. Unter anderem ist dies auch für
den WR1043ND v1 so. Mit der aktuellen Firmware funktioniert das jedenfalls nicht
so wie es gedacht ist:

https://monitoring.freifunk-franken.de/routers/3000

Hier bleibt TX-Power nach wie vor auf 20dbm. Das ist die aktuelle Firmware und
das abziehen der 3dbi Antenna Gain scheint nicht zu funktionieren, obwohl es sollte:
cat ./src/packages/fff/fff-wireless/files/etc/wifi.tl-wr1043nd-v1
uci -q set wireless.radio0.antenna_gain=3
uci -q commit wireless

Das besagte File finde ich mit 20180802 nicht auf dem Gerät.

Bei den wr1043nd v2 - v5 habe ich noch mal nachgeforscht, hier ist mit der
aktuellen Firmware die TX-Power mit 14dbm etwas zu niedrig. Lt.
https://wiki.freifunk.net/TP-Link_WR1043ND haben die Antennen 3dbi, d.h. hier
sollte die TX-Power auf 17dbm stehen und nicht auf 14dbm. Da bei den v2 - v4
Geräten die Antennen getauscht werden können, würde es meiner Meinung nach schon
Sinn machen, das evtl. über das Webinterface des Routers konfigurierbar zu
machen. Bzgl den CPE210 hat die Stock-Firmware ebenfalls 11dbm, allerdings ist
Deine Behauptung, die würden mit der alten Firmware mit 800mW EIRP raushauen
nicht richtig. Hardwareseitig schaffen die CPE210 max 27dbm (inkl. Antennen) ~
500mW und lt. Datastheet schafft sie auch nicht mehr als 500mW. Interessant ist,
dass mit der Stockfirmware im Test-Mode hier sich max. 27dbm Einstellen lassen -
diese Einstellung inkludiert jedoch die 9dbi Gain. Es ist hier also nicht so,
dass man 36dbm erhält wenn man 27dbm einstellt, d.h. die Stockfirmware
berücksichtigt das gleich. Interessanterweise sind die CPE210 seit dem Update
auf 20180802 trotzdem irgendwie leiser als die Stockfirmware, ich kann es leider
mangels Equipment nicht genau nachmessen.

Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:

- warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es ein
Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?
- warum flappt batman-adv von client-mode zu off:
[64826.379519] batman_adv: bat0: Changing gw mode from: off to: client
[64885.313160] batman_adv: bat0: Changing gw mode from: client to: off
[64886.336979] batman_adv: bat0: Changing gw mode from: off to: client
[64945.314169] batman_adv: bat0: Changing gw mode from: client to: off
[64946.334612] batman_adv: bat0: Changing gw mode from: off to: client
[65005.314302] batman_adv: bat0: Changing gw mode from: client to: off

- iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
iw reg get
global
country DE: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 14), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)

- wieso ist die batman-adv loop protection abgeschaltet?




Am 23.09.2018 um 16:40 schrieb Adrian Schmutzler:
>
> Hallo,
>
>  
>
> den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht ist
> jemand anderes schlauer als ich …
>
>  
>
> Grüße
>
>  
>
> Adrian
>
>  
>
> *From:*franken-dev [mailto:franken-dev-bounces@freifunk.net] *On Behal**f Of
> *Florian Wiessner
> *Sent:* Sonntag, 23. September 2018 01:01
> *To:* Fabian Bläse <fabian@blaese.de>; franken-dev@freifunk.net; Tim Niemeyer
> <tim@tn-x.org>
> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx powers
>
>  
>
> Hallo,
>
>
> gerade bin ich noch hierüber gestolpert:
>
> https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html
>
> Am 23.09.2018 um 00:54 schrieb Florian Wiessner:
>
>     Hallo,
>
>
>     ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit Update
>     auf 20180802 habe ich tote meshrouter.
>
>     Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos
>     funktionierten, gehen nun gar nicht mehr.
>
>     Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>
>     https://monitoring.freifunk-franken.de/routers/5704
>
>     Ganz schlimm:
>
>     https://monitoring.freifunk-franken.de/routers/5842
>
>     https://monitoring.freifunk-franken.de/routers/4873
>
>     Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>
>
>     Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>
>
>
>     Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>
>         Hallo Tim,
>
>          
>
>                 Since the reverted patch, device specific antenna gain is not set for
>
>                 some reason.
>
>                 Reverting the patch in question fixes this issue.
>
>             Warum? Woher kommt die Erkenntnis?
>
>         Viel testen, googlen, ..
>
>         Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>
>          
>
>         Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>
>          
>
>                 THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>
>                 FIXED PROPERLY!
>
>             -v bitte..
>
>         Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>
>          
>
>             Wer wird es mal "richtig" fixen?
>
>         Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
>
>         Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>
>          
>
>         Fabian
>

hi

On 10/9/18 12:13 PM, Florian Wiessner wrote:
> Hallo Adrian,
> 
> 
> ich habe jetzt mal die Firmware ohne besagten Patch gebaut und komme nun
> wieder auf normale Werte. Ich habe gesehen dass für die Ubiquity Geräte
> separat ein File existiert, wo Antenna Gain gesetzt wird. Unter anderem
> ist dies auch für den WR1043ND v1 so. Mit der aktuellen Firmware
> funktioniert das jedenfalls nicht so wie es gedacht ist:
> 
> https://monitoring.freifunk-franken.de/routers/3000
> 
> Hier bleibt TX-Power nach wie vor auf 20dbm. Das ist die aktuelle
> Firmware und das abziehen der 3dbi Antenna Gain scheint nicht zu
> funktionieren, obwohl es sollte:
> cat ./src/packages/fff/fff-wireless/files/etc/wifi.tl-wr1043nd-v1
> uci -q set wireless.radio0.antenna_gain=3
> uci -q commit wireless
> 
> Das besagte File finde ich mit 20180802 nicht auf dem Gerät.
> 
> Bei den wr1043nd v2 - v5 habe ich noch mal nachgeforscht, hier ist mit
> der aktuellen Firmware die TX-Power mit 14dbm etwas zu niedrig. Lt.
> https://wiki.freifunk.net/TP-Link_WR1043ND haben die Antennen 3dbi, d.h.
> hier sollte die TX-Power auf 17dbm stehen und nicht auf 14dbm. Da bei
> den v2 - v4 Geräten die Antennen getauscht werden können, würde es
> meiner Meinung nach schon Sinn machen, das evtl. über das Webinterface
> des Routers konfigurierbar zu machen. Bzgl den CPE210 hat die
> Stock-Firmware ebenfalls 11dbm, allerdings ist Deine Behauptung, die
> würden mit der alten Firmware mit 800mW EIRP raushauen nicht richtig.
> Hardwareseitig schaffen die CPE210 max 27dbm (inkl. Antennen) ~ 500mW
> und lt. Datastheet schafft sie auch nicht mehr als 500mW. Interessant
> ist, dass mit der Stockfirmware im Test-Mode hier sich max. 27dbm
> Einstellen lassen - diese Einstellung inkludiert jedoch die 9dbi Gain.
> Es ist hier also nicht so, dass man 36dbm erhält wenn man 27dbm
> einstellt, d.h. die Stockfirmware berücksichtigt das gleich.
> Interessanterweise sind die CPE210 seit dem Update auf 20180802 trotzdem
> irgendwie leiser als die Stockfirmware, ich kann es leider mangels
> Equipment nicht genau nachmessen.
> 
> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:
> 
> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es
> ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?

diese Frage kann ich dir beantworten:
.
die 11n Datenraten bilden sich (irgendwie Magie[TM]) aus 11g Datenraten ab.

hwmode:
Selects the wireless protocol to use, possible values are 11b, 11g, and
11a (note that 11ng and 11na are not available options, see ticket 17541
-> https://dev.openwrt.org/ticket/17541 )

Quelle: https://wiki.openwrt.org/doc/uci/wireless

Bzw. aus dem Ticket:
Expected, config changed. 11g / 11a selects the band, htmode NOHT
disables 11n, htmode HT20 / htmode HT40 enables 11n.

Wichtig ist das ein htmode gesetzt ist, was bei uns auch der Fall ist.
Es ist also 11n bereits aktiv und hier muss nichts mehr getan werden.

mfg

Christain


> - warum flappt batman-adv von client-mode zu off:
> [64826.379519] batman_adv: bat0: Changing gw mode from: off to: client
> [64885.313160] batman_adv: bat0: Changing gw mode from: client to: off
> [64886.336979] batman_adv: bat0: Changing gw mode from: off to: client
> [64945.314169] batman_adv: bat0: Changing gw mode from: client to: off
> [64946.334612] batman_adv: bat0: Changing gw mode from: off to: client
> [65005.314302] batman_adv: bat0: Changing gw mode from: client to: off
> 
> - iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
> iw reg get
> global
> country DE: DFS-ETSI
>         (2400 - 2483 @ 40), (N/A, 20), (N/A)
>         (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
>         (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
>         (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>         (5725 - 5875 @ 80), (N/A, 14), (N/A)
>         (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> 
> phy#0
> country US: DFS-FCC
>         (2402 - 2472 @ 40), (N/A, 30), (N/A)
>         (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>         (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>         (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
>         (5735 - 5835 @ 80), (N/A, 30), (N/A)
>         (57240 - 63720 @ 2160), (N/A, 40), (N/A)
> 
> - wieso ist die batman-adv loop protection abgeschaltet?
> 
> 
> 
> 
> Am 23.09.2018 um 16:40 schrieb Adrian Schmutzler:
>>
>> Hallo,
>>
>>  
>>
>> den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht
>> ist jemand anderes schlauer als ich …
>>
>>  
>>
>> Grüße
>>
>>  
>>
>> Adrian
>>
>>  
>>
>> *From:*franken-dev [mailto:franken-dev-bounces@freifunk.net] *On
>> Behal**f Of *Florian Wiessner
>> *Sent:* Sonntag, 23. September 2018 01:01
>> *To:* Fabian Bläse <fabian@blaese.de>; franken-dev@freifunk.net; Tim
>> Niemeyer <tim@tn-x.org>
>> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx
>> powers
>>
>>  
>>
>> Hallo,
>>
>>
>> gerade bin ich noch hierüber gestolpert:
>>
>> https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html
>>
>> Am 23.09.2018 um 00:54 schrieb Florian Wiessner:
>>
>>     Hallo,
>>
>>
>>     ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit
>>     Update auf 20180802 habe ich tote meshrouter.
>>
>>     Ich habe enorme Reichweiteneinbußen, und Links die vorher
>>     reibungslos funktionierten, gehen nun gar nicht mehr.
>>
>>     Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>>
>>     https://monitoring.freifunk-franken.de/routers/5704
>>
>>     Ganz schlimm:
>>
>>     https://monitoring.freifunk-franken.de/routers/5842
>>
>>     https://monitoring.freifunk-franken.de/routers/4873
>>
>>     Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>>
>>
>>     Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>>
>>
>>
>>     Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>>
>>         Hallo Tim,
>>
>>          
>>
>>                 Since the reverted patch, device specific antenna gain is not set for
>>
>>                 some reason.
>>
>>                 Reverting the patch in question fixes this issue.
>>
>>             Warum? Woher kommt die Erkenntnis?
>>
>>         Viel testen, googlen, ..
>>
>>         Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>>
>>          
>>
>>         Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>>
>>          
>>
>>                 THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>>
>>                 FIXED PROPERLY!
>>
>>             -v bitte..
>>
>>         Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>>
>>          
>>
>>             Wer wird es mal "richtig" fixen?
>>
>>         Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
>>
>>         Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>>
>>          
>>
>>         Fabian
>>
> 
> -- 
> Mit freundlichen Grüßen
> 
> Florian Wiessner
> 
> 
> <http://www.smart-kvm.com/>
> 
> 
> smart-kvm.com
> c/o Smart Weblications GmbH
> Martinsberger Str. 1
> D-95119 Naila
> fon.: +49 9282 9638 200
> fax.: +49 9282 9638 205
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min*
> http://www.smart-kvm.com
> 
> --
> Sitz der Gesellschaft: Naila
> Geschäftsführer: Florian Wiessner
> HRB-Nr.: HRB 3840 Amtsgericht Hof
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Hallo Fabian,

 

das separate File zum Setzen des Antenna-Gain gibt es nur in meiner Firmware (im der offiziellen wurde es zwar jetzt committed, aber es ist nicht in 20180802 enthalten). Dies deckt alle die Geräte ab, bei denen OpenWRT den Antenna-Gain gar nicht berücksichtigt (alle Ubiquiti und der 1041v1).

 

Deine Beobachtung ist also korrekt: Für alle Versionen der offiziellen FW werden alle Ubiquiti-Geräte und der 1043v1 standardmäßig mit einer illegal hohen Leistung betrieben, sofern nicht der Nutzer manuell den korrekten Antenna-Gain setzt.

 

Für die anderen Geräte holt sich OpenWRT die Antennenwerte irgendwie aus dem ath9k Treiber (frag mich nicht, was da genau passiert). Deshalb weicht der Wert auch manchmal 1 dB vom angegebenen Antennengain ab.

 

Wo Freifunk die 3dbi beim 1043er her hat, weiß ich nicht, ich glaube, das war nur beim v1 so. Alle ab dem v2 sollten 5 db haben, z.B.

 

https://static.tp-link.com/res/down/doc/TL-WR1043ND(UN)_3.0.pdf

 

(Seite 4 links)

 

Gemessen habe ich nie, ich habe das Thema immer nur theoretisch betrachtet/betrachten können.

 

Zum Rest:

 

11g/11n kann ich mich nicht äußern

 

- warum flappt batman-adv von client-mode zu off:

 

Das ist Absicht, weil nur so die Änderung der announcten Bandbreite pro Gateway berücksichtigt werden kann

 

- iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?

 

Das wurde in einem der OpenWRT Patches geändert, die du irgendwann zwischendrin verlinkt hattest.

 

- wieso ist die batman-adv loop protection abgeschaltet?

 

Hast du dazu einen Link?

 

Grüße

 

Adrian

 

 

From: Florian Wiessner [mailto:f.wiessner@smart-kvm.com] 
Sent: Dienstag, 9. Oktober 2018 12:13
To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
Subject: Re: [PATCH] Revert openwrt patch which caused too high tx powers

 

Hallo Adrian,


ich habe jetzt mal die Firmware ohne besagten Patch gebaut und komme nun wieder auf normale Werte. Ich habe gesehen dass für die Ubiquity Geräte separat ein File existiert, wo Antenna Gain gesetzt wird. Unter anderem ist dies auch für den WR1043ND v1 so. Mit der aktuellen Firmware funktioniert das jedenfalls nicht so wie es gedacht ist:

https://monitoring.freifunk-franken.de/routers/3000

Hier bleibt TX-Power nach wie vor auf 20dbm. Das ist die aktuelle Firmware und das abziehen der 3dbi Antenna Gain scheint nicht zu funktionieren, obwohl es sollte:
cat ./src/packages/fff/fff-wireless/files/etc/wifi.tl-wr1043nd-v1
uci -q set wireless.radio0.antenna_gain=3
uci -q commit wireless

Das besagte File finde ich mit 20180802 nicht auf dem Gerät.

Bei den wr1043nd v2 - v5 habe ich noch mal nachgeforscht, hier ist mit der aktuellen Firmware die TX-Power mit 14dbm etwas zu niedrig. Lt. https://wiki.freifunk.net/TP-Link_WR1043ND haben die Antennen 3dbi, d.h. hier sollte die TX-Power auf 17dbm stehen und nicht auf 14dbm. Da bei den v2 - v4 Geräten die Antennen getauscht werden können, würde es meiner Meinung nach schon Sinn machen, das evtl. über das Webinterface des Routers konfigurierbar zu machen. Bzgl den CPE210 hat die Stock-Firmware ebenfalls 11dbm, allerdings ist Deine Behauptung, die würden mit der alten Firmware mit 800mW EIRP raushauen nicht richtig. Hardwareseitig schaffen die CPE210 max 27dbm (inkl. Antennen) ~ 500mW und lt. Datastheet schafft sie auch nicht mehr als 500mW. Interessant ist, dass mit der Stockfirmware im Test-Mode hier sich max. 27dbm Einstellen lassen - diese Einstellung inkludiert jedoch die 9dbi Gain. Es ist hier also nicht so, dass man 36dbm erhält wenn man 27dbm einstellt, d.h. die Stockfirmware berücksichtigt das gleich. Interessanterweise sind die CPE210 seit dem Update auf 20180802 trotzdem irgendwie leiser als die Stockfirmware, ich kann es leider mangels Equipment nicht genau nachmessen.

Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:

- warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?
- warum flappt batman-adv von client-mode zu off:
[64826.379519] batman_adv: bat0: Changing gw mode from: off to: client
[64885.313160] batman_adv: bat0: Changing gw mode from: client to: off
[64886.336979] batman_adv: bat0: Changing gw mode from: off to: client
[64945.314169] batman_adv: bat0: Changing gw mode from: client to: off
[64946.334612] batman_adv: bat0: Changing gw mode from: off to: client
[65005.314302] batman_adv: bat0: Changing gw mode from: client to: off

- iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
iw reg get
global
country DE: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 14), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)

- wieso ist die batman-adv loop protection abgeschaltet?




Am 23.09.2018 um 16:40 schrieb Adrian Schmutzler:

	Hallo,

	 

	den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht ist jemand anderes schlauer als ich …

	 

	Grüße

	 

	Adrian

	 

	From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Florian Wiessner
	Sent: Sonntag, 23. September 2018 01:01
	To: Fabian Bläse <fabian@blaese.de> <mailto:fabian@blaese.de> ; franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> ; Tim Niemeyer <tim@tn-x.org> <mailto:tim@tn-x.org> 
	Subject: Re: [PATCH] Revert openwrt patch which caused too high tx powers

	 

	Hallo,
	
	
	gerade bin ich noch hierüber gestolpert:
	
	https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html
	
	Am 23.09.2018 um 00:54 schrieb Florian Wiessner:

		Hallo,
		
		
		ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit Update auf 20180802 habe ich tote meshrouter.
		
		Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos funktionierten, gehen nun gar nicht mehr.
		
		Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
		
		https://monitoring.freifunk-franken.de/routers/5704
		
		Ganz schlimm:
		
		https://monitoring.freifunk-franken.de/routers/5842
		
		https://monitoring.freifunk-franken.de/routers/4873
		
		Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
		
		
		Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
		
		
		
		Am 20.01.2018 um 16:09 schrieb Fabian Bläse:

			Hallo Tim,
			 

					Since the reverted patch, device specific antenna gain is not set for
					some reason.
					Reverting the patch in question fixes this issue.

				Warum? Woher kommt die Erkenntnis?

			Viel testen, googlen, ..
			Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
			 
			Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
			 

					THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
					FIXED PROPERLY!

				-v bitte..

			Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
			 

				Wer wird es mal "richtig" fixen?

			Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
			Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
			 
			Fabian

Hallo,


soweit ich den ath9k treiber verstehe, holt dieser das Antenna-Gain aus dem
EEPROM. Von hier aus zitiert (https://patchwork.kernel.org/patch/2854533/):

"

Right now ath9k has an antenna gain value in the EEPROM, and it compares
it against the channel max_antenna_gain value.

Let's assume we have configured the tx power to the maximum value, the
regdb allows 3 dB antenna gain, and the ath9k EEPROM contains an antenna
gain of 3 dB as well.
If we now add another 3 dB of user-configured antenna gain, it first
starts tapping into the regulatory-allowed antenna gain before reducing
tx power in mac80211. The driver needs to know about this, so I put the
calculated maximum antenna gain into the hw conf as well.
"

Das heisst für mich, selbst wenn ich als txpower 20dbm setze, kümmert sich der
ath9k Treiber um den Rest und zieht das Antenna-Gain automatisch ab? Das würde
aber bedeuten dass wir dies nicht explizit runterregeln müssen.



Wegen der batman-adv bl:

https://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance

root@VillaMusica:~# batctl bl
disabled

Ist also nicht aktiviert.

Am 09.10.2018 um 12:29 schrieb Adrian Schmutzler:
>
> Hallo Fabian,
>
>  
>
> das separate File zum Setzen des Antenna-Gain gibt es nur in meiner Firmware
> (im der offiziellen wurde es zwar jetzt committed, aber es ist nicht in
> 20180802 enthalten). Dies deckt alle die Geräte ab, bei denen OpenWRT den
> Antenna-Gain gar nicht berücksichtigt (alle Ubiquiti und der 1041v1).
>
>  
>
> Deine Beobachtung ist also korrekt: Für alle Versionen der offiziellen FW
> werden alle Ubiquiti-Geräte und der 1043v1 standardmäßig mit einer illegal
> hohen Leistung betrieben, sofern nicht der Nutzer manuell den korrekten
> Antenna-Gain setzt.
>
>  
>
> Für die anderen Geräte holt sich OpenWRT die Antennenwerte irgendwie aus dem
> ath9k Treiber (frag mich nicht, was da genau passiert). Deshalb weicht der
> Wert auch manchmal 1 dB vom angegebenen Antennengain ab.
>
>  
>
> Wo Freifunk die 3dbi beim 1043er her hat, weiß ich nicht, ich glaube, das war
> nur beim v1 so. Alle ab dem v2 sollten 5 db haben, z.B.
>
>  
>
> https://static.tp-link.com/res/down/doc/TL-WR1043ND(UN)_3.0.pdf
> <https://static.tp-link.com/res/down/doc/TL-WR1043ND%28UN%29_3.0.pdf>
>
>  
>
> (Seite 4 links)
>
>  
>
> Gemessen habe ich nie, ich habe das Thema immer nur theoretisch
> betrachtet/betrachten können.
>
>  
>
> Zum Rest:
>
>  
>
> 11g/11n kann ich mich nicht äußern
>
>  
>
> - warum flappt batman-adv von client-mode zu off:
>
>  
>
> Das ist Absicht, weil nur so die Änderung der announcten Bandbreite pro
> Gateway berücksichtigt werden kann
>
>  
>
> - iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
>
>  
>
> Das wurde in einem der OpenWRT Patches geändert, die du irgendwann
> zwischendrin verlinkt hattest.
>
>  
>
> - wieso ist die batman-adv loop protection abgeschaltet?
>
>  
>
> Hast du dazu einen Link?
>
>  
>
> Grüße
>
>  
>
> Adrian
>
>  
>
>  
>
> *From:*Florian Wiessner [mailto:f.wiessner@smart-kvm.com]
> *Sent:* Dienstag, 9. Oktober 2018 12:13
> *To:* Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx powers
>
>  
>
> Hallo Adrian,
>
>
> ich habe jetzt mal die Firmware ohne besagten Patch gebaut und komme nun
> wieder auf normale Werte. Ich habe gesehen dass für die Ubiquity Geräte
> separat ein File existiert, wo Antenna Gain gesetzt wird. Unter anderem ist
> dies auch für den WR1043ND v1 so. Mit der aktuellen Firmware funktioniert das
> jedenfalls nicht so wie es gedacht ist:
>
> https://monitoring.freifunk-franken.de/routers/3000
>
> Hier bleibt TX-Power nach wie vor auf 20dbm. Das ist die aktuelle Firmware und
> das abziehen der 3dbi Antenna Gain scheint nicht zu funktionieren, obwohl es
> sollte:
> cat ./src/packages/fff/fff-wireless/files/etc/wifi.tl-wr1043nd-v1
> uci -q set wireless.radio0.antenna_gain=3
> uci -q commit wireless
>
> Das besagte File finde ich mit 20180802 nicht auf dem Gerät.
>
> Bei den wr1043nd v2 - v5 habe ich noch mal nachgeforscht, hier ist mit der
> aktuellen Firmware die TX-Power mit 14dbm etwas zu niedrig. Lt.
> https://wiki.freifunk.net/TP-Link_WR1043ND haben die Antennen 3dbi, d.h. hier
> sollte die TX-Power auf 17dbm stehen und nicht auf 14dbm. Da bei den v2 - v4
> Geräten die Antennen getauscht werden können, würde es meiner Meinung nach
> schon Sinn machen, das evtl. über das Webinterface des Routers konfigurierbar
> zu machen. Bzgl den CPE210 hat die Stock-Firmware ebenfalls 11dbm, allerdings
> ist Deine Behauptung, die würden mit der alten Firmware mit 800mW EIRP
> raushauen nicht richtig. Hardwareseitig schaffen die CPE210 max 27dbm (inkl.
> Antennen) ~ 500mW und lt. Datastheet schafft sie auch nicht mehr als 500mW.
> Interessant ist, dass mit der Stockfirmware im Test-Mode hier sich max. 27dbm
> Einstellen lassen - diese Einstellung inkludiert jedoch die 9dbi Gain. Es ist
> hier also nicht so, dass man 36dbm erhält wenn man 27dbm einstellt, d.h. die
> Stockfirmware berücksichtigt das gleich. Interessanterweise sind die CPE210
> seit dem Update auf 20180802 trotzdem irgendwie leiser als die Stockfirmware,
> ich kann es leider mangels Equipment nicht genau nachmessen.
>
> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:
>
> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es ein
> Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?
> - warum flappt batman-adv von client-mode zu off:
> [64826.379519] batman_adv: bat0: Changing gw mode from: off to: client
> [64885.313160] batman_adv: bat0: Changing gw mode from: client to: off
> [64886.336979] batman_adv: bat0: Changing gw mode from: off to: client
> [64945.314169] batman_adv: bat0: Changing gw mode from: client to: off
> [64946.334612] batman_adv: bat0: Changing gw mode from: off to: client
> [65005.314302] batman_adv: bat0: Changing gw mode from: client to: off
>
> - iw reg get liefert für global zwar DE, für phy0 aber nach wie vor US?
> iw reg get
> global
> country DE: DFS-ETSI
>         (2400 - 2483 @ 40), (N/A, 20), (N/A)
>         (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
>         (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
>         (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>         (5725 - 5875 @ 80), (N/A, 14), (N/A)
>         (57000 - 66000 @ 2160), (N/A, 40), (N/A)
>
> phy#0
> country US: DFS-FCC
>         (2402 - 2472 @ 40), (N/A, 30), (N/A)
>         (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>         (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>         (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
>         (5735 - 5835 @ 80), (N/A, 30), (N/A)
>         (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> - wieso ist die batman-adv loop protection abgeschaltet?
>
>
>
>
> Am 23.09.2018 um 16:40 schrieb Adrian Schmutzler:
>
>     Hallo,
>
>      
>
>     den inhalt der verlinkten Mail verstehe ich leider nicht. Vielleicht ist
>     jemand anderes schlauer als ich …
>
>      
>
>     Grüße
>
>      
>
>     Adrian
>
>      
>
>     *From:*franken-dev [mailto:franken-dev-bounces@freifunk.net] *On Behal**f
>     Of *Florian Wiessner
>     *Sent:* Sonntag, 23. September 2018 01:01
>     *To:* Fabian Bläse <fabian@blaese.de> <mailto:fabian@blaese.de>;
>     franken-dev@freifunk.net <mailto:franken-dev@freifunk.net>; Tim Niemeyer
>     <tim@tn-x.org> <mailto:tim@tn-x.org>
>     *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx powers
>
>      
>
>     Hallo,
>
>
>     gerade bin ich noch hierüber gestolpert:
>
>     https://lists.openwrt.org/pipermail/openwrt-devel/2017-August/008512.html
>
>     Am 23.09.2018 um 00:54 schrieb Florian Wiessner:
>
>         Hallo,
>
>
>         ich hab das "Gefühl" dieser Patch funktioniert nicht richtig. Seit
>         Update auf 20180802 habe ich tote meshrouter.
>
>         Ich habe enorme Reichweiteneinbußen, und Links die vorher reibungslos
>         funktionierten, gehen nun gar nicht mehr.
>
>         Meine CPE210s senden nur noch mit 11dbm statt vorher 20dbm.
>
>         https://monitoring.freifunk-franken.de/routers/5704
>
>         Ganz schlimm:
>
>         https://monitoring.freifunk-franken.de/routers/5842
>
>         https://monitoring.freifunk-franken.de/routers/4873
>
>         Es betrifft also auch wr1043n/nd. hier nur 14dbm statt 20dbm
>
>
>         Was tun? Soll ich den Patch reverten und Firmware selbst neu bauen?
>
>
>
>         Am 20.01.2018 um 16:09 schrieb Fabian Bläse:
>
>             Hallo Tim,
>
>              
>
>                     Since the reverted patch, device specific antenna gain is not set for
>
>                     some reason.
>
>                     Reverting the patch in question fixes this issue.
>
>                 Warum? Woher kommt die Erkenntnis?
>
>             Viel testen, googlen, ..
>
>             Seit diesem Patch setzt der Treiber den Antenna Gain nicht mehr (zumindest für die getesteten Geräte), was vorher der Fall war.
>
>              
>
>             Ich hab das nicht ausgemessen, dazu hab ich gar keine richtig zuverlässige Möglichkeit.
>
>              
>
>                     THIS SHOULD BE ONLY CONSIDERD AS A TEMPORARY FIX UNTIL THE ISSUE IS
>
>                     FIXED PROPERLY!
>
>                 -v bitte..
>
>             Lässt sich einrichten, gibts dann in einer v2 wenn der Rest ausdiskutiert ist.
>
>              
>
>                 Wer wird es mal "richtig" fixen?
>
>             Ich werde noch ein Issue im Openwrt Bugtracker anlegen und mir das Problem selbst mal ansehen.
>
>             Bis dahin sollte die Geschichte imho möglichst schnell gefixt werden, immerhin senden manche Geräte aktuell mit einem vielfachen der erlaubten Sendeleistung! (Beispiel CPE210: 29dBm statt 20dBm EIRP)
>
>              
>
>             Fabian
>
>  
>

Hallo,

Am 09.10.2018 um 12:24 schrieb Christian Dresel:
> hi
>
> On 10/9/18 12:13 PM, Florian Wiessner wrote:
>> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:
>>
>> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es
>> ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?
> diese Frage kann ich dir beantworten:
> .
> die 11n Datenraten bilden sich (irgendwie Magie[TM]) aus 11g Datenraten ab.
>
> hwmode:
> Selects the wireless protocol to use, possible values are 11b, 11g, and
> 11a (note that 11ng and 11na are not available options, see ticket 17541
> -> https://dev.openwrt.org/ticket/17541 )
>
> Quelle: https://wiki.openwrt.org/doc/uci/wireless
>
> Bzw. aus dem Ticket:
> Expected, config changed. 11g / 11a selects the band, htmode NOHT
> disables 11n, htmode HT20 / htmode HT40 enables 11n.
>
> Wichtig ist das ein htmode gesetzt ist, was bei uns auch der Fall ist.
> Es ist also 11n bereits aktiv und hier muss nichts mehr getan werden.
>
> mfg

Danke für die Info. Ich sehe es ist HT20 konfiguriert - spricht was dagegen auf
40MHz HT40 zu gehen?

Hallo Florian,

 

> Das heisst für mich, selbst wenn ich als txpower 20dbm setze, kümmert sich der ath9k Treiber um den Rest und zieht das Antenna-Gain automatisch ab? Das würde aber bedeuten dass wir dies nicht explizit runterregeln müssen.



OpenWRT schaut sich an, was im iw reg steht und passt dann automatisch die txpower an. Du kannst auch manuell glaube ich gar keine höhere txpower setzen (habs jetzt nicht probiert).

ABER:

-          Für Ubiquiti-Geräte funktioniert das nicht (entweder ist der Wert dort im EEPROM nicht gesetzt oder es klappt was beim lesen nicht => antenna_gain = 0)

-          In dem OpenWRT-Patch, den wir reverten (und OpenWRT im master auch revertet hat), ist genau das kaputt gegangen; => antenna_gain immer 0

 

Bei den Geräten, wo ich weiß, dass es nicht automatisch geht, setze ich daher den antennagain von Hand.

 

Wenn du jetzt beim OpenWRT-master txpower 20 setzt, gehe ich davon aus, dass der dich dann trotzdem runterregelt. Du kannst da auch mit „iw set“ experimentieren und mal auf US umstellen und kucken, was dann passiert.

 

Das bridgeloop Zeug muss ich mir mal in Ruhe anschauen.

 

Grüße

 

Adrian

hi

On 10/9/18 1:11 PM, Florian Wiessner wrote:
> Hallo,
> 
> Am 09.10.2018 um 12:24 schrieb Christian Dresel:
>> hi
>>
>> On 10/9/18 12:13 PM, Florian Wiessner wrote:
>>> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben:
>>>
>>> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es
>>> ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen?
>> diese Frage kann ich dir beantworten:
>> .
>> die 11n Datenraten bilden sich (irgendwie Magie[TM]) aus 11g Datenraten ab.
>>
>> hwmode:
>> Selects the wireless protocol to use, possible values are 11b, 11g, and
>> 11a (note that 11ng and 11na are not available options, see ticket 17541
>> -> https://dev.openwrt.org/ticket/17541 )
>>
>> Quelle: https://wiki.openwrt.org/doc/uci/wireless
>>
>> Bzw. aus dem Ticket:
>> Expected, config changed. 11g / 11a selects the band, htmode NOHT
>> disables 11n, htmode HT20 / htmode HT40 enables 11n.
>>
>> Wichtig ist das ein htmode gesetzt ist, was bei uns auch der Fall ist.
>> Es ist also 11n bereits aktiv und hier muss nichts mehr getan werden.
>>
>> mfg
> 
> Danke für die Info. Ich sehe es ist HT20 konfiguriert - spricht was
> dagegen auf 40MHz HT40 zu gehen?

Für mich ja:

https://wiki.freifunk-franken.de/w/WLAN_Frequenzen#2.2C4_GHZ_Band

Das 2,4GHz Band ist eh schon recht klein und sehr voll, das jetzt auch
noch mit 40MHz vollmüllen empfinde ich für übertrieben.

Wer es UNBEDINGT für seine Hood im keyxchange gesetzt haben will, den
setze ich das natürlich aber default lasse ich 20MHz und rate davon ab
es auf 40MHz zu setzen.

Wenn man ein schnelleres WLAN haben will, sollte man auf 5GHz ausweichen
und bedenken das VPN sowieso meist der begrenzende Faktor ist, hier
würde dann https://wiki.freifunk-franken.de/w/Dezentrale_Hood oder
http://lists.freifunk.net/pipermail/franken-freifunk.net/2018-October/015810.html
(FreifunkV3) helfen.

mfg

Christian

> 
> 
> -- 
> Mit freundlichen Grüßen
> 
> Florian Wiessner
> 
> 
> <http://www.smart-kvm.com/>
> 
> 
> smart-kvm.com
> c/o Smart Weblications GmbH
> Martinsberger Str. 1
> D-95119 Naila
> fon.: +49 9282 9638 200
> fax.: +49 9282 9638 205
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min*
> http://www.smart-kvm.com
> 
> --
> Sitz der Gesellschaft: Naila
> Geschäftsführer: Florian Wiessner
> HRB-Nr.: HRB 3840 Amtsgericht Hof
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Ggf. kann es durch HT40 sogar für einen selbst langsamer werden, wenn man viele Interferenzen auf einem der belegten Kanäle hat.

 

From: Christian Dresel [mailto:fff@chrisi01.de] 
Sent: Dienstag, 9. Oktober 2018 13:24
To: Florian Wiessner <f.wiessner@smart-kvm.com>; franken-dev@freifunk.net; Adrian Schmutzler <mail@adrianschmutzler.de>
Subject: Re: [PATCH] Revert openwrt patch which caused too high tx powers

 

hi 

On 10/9/18 1:11 PM, Florian Wiessner wrote: 
> Hallo, 
> 
> Am 09.10.2018 um 12:24 schrieb Christian Dresel: 
>> hi 
>> 
>> On 10/9/18 12:13 PM, Florian Wiessner wrote: 
>>> Ein paar weitere Fragen haben sich nach Sichtung der Firmware etc ergeben: 
>>> 
>>> - warum wird nur 11g gesetzt, nicht 11n - soweit ich das verstehe ist es 
>>> ein Setting aus dem Hoodfile, spricht etwas dagegen auf 11n zu gehen? 
>> diese Frage kann ich dir beantworten: 
>> . 
>> die 11n Datenraten bilden sich (irgendwie Magie[TM]) aus 11g Datenraten ab. 
>> 
>> hwmode: 
>> Selects the wireless protocol to use, possible values are 11b, 11g, and 
>> 11a (note that 11ng and 11na are not available options, see ticket 17541 
>> -> https://dev.openwrt.org/ticket/17541 ) 
>> 
>> Quelle: https://wiki.openwrt.org/doc/uci/wireless 
>> 
>> Bzw. aus dem Ticket: 
>> Expected, config changed. 11g / 11a selects the band, htmode NOHT 
>> disables 11n, htmode HT20 / htmode HT40 enables 11n. 
>> 
>> Wichtig ist das ein htmode gesetzt ist, was bei uns auch der Fall ist. 
>> Es ist also 11n bereits aktiv und hier muss nichts mehr getan werden. 
>> 
>> mfg 
> 
> Danke für die Info. Ich sehe es ist HT20 konfiguriert - spricht was 
> dagegen auf 40MHz HT40 zu gehen? 

Für mich ja: 

https://wiki.freifunk-franken.de/w/WLAN_Frequenzen#2.2C4_GHZ_Band 

Das 2,4GHz Band ist eh schon recht klein und sehr voll, das jetzt auch 
noch mit 40MHz vollmüllen empfinde ich für übertrieben. 

Wer es UNBEDINGT für seine Hood im keyxchange gesetzt haben will, den 
setze ich das natürlich aber default lasse ich 20MHz und rate davon ab 
es auf 40MHz zu setzen. 

Wenn man ein schnelleres WLAN haben will, sollte man auf 5GHz ausweichen 
und bedenken das VPN sowieso meist der begrenzende Faktor ist, hier 
würde dann https://wiki.freifunk-franken.de/w/Dezentrale_Hood oder 
http://lists.freifunk.net/pipermail/franken-freifunk.net/2018-October/015810.html 
(FreifunkV3) helfen. 

mfg 

Christian 

> 
> 
> -- 
> Mit freundlichen Grüßen 
> 
> Florian Wiessner 
> 
> 
> <http://www.smart-kvm.com/> 
> 
> 
> smart-kvm.com 
> c/o Smart Weblications GmbH 
> Martinsberger Str. 1 
> D-95119 Naila 
> fon.: +49 9282 9638 200 
> fax.: +49 9282 9638 205 
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min* 
> http://www.smart-kvm.com 
> 
> -- 
> Sitz der Gesellschaft: Naila 
> Geschäftsführer: Florian Wiessner 
> HRB-Nr.: HRB 3840 Amtsgericht Hof 
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz

Hallo,



mir geht es hierbei konkret um einen Anwendungsfall, nämlich ob es für
Richtfunkstrecken die auf einem anderen Kanal liegen, die Bandbreite erhöhen
kann. So wie ich das sehe müsse ich doch mittels Sektorfile in der Lage sein,
das manuell zu überschreiben, was aus dem Hoodfile kommt, korrekt?

Am 09.10.2018 um 13:25 schrieb Adrian Schmutzler:
>
> Ggf. kann es durch HT40 sogar für einen selbst langsamer werden, wenn man
> viele Interferenzen auf einem der belegten Kanäle hat.
>
>  
>
> *From:*Christian Dresel [mailto:fff@chrisi01.de]
> *Sent:* Dienstag, 9. Oktober 2018 13:24
> *To:* Florian Wiessner <f.wiessner@smart-kvm.com>; franken-dev@freifunk.net;
> Adrian Schmutzler <mail@adrianschmutzler.de>
> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx powers
>
>  
>

hi

Die Sektorfile wurde revertet:

https://github.com/FreifunkFranken/firmware/commit/b194e8f8cdb3f983885177e7d55d87ae6f8c801a

Für Richtfunk macht sowieso Stockfirmware auf 5GHz deutlich mehr Sinn:

https://wiki.freifunk-franken.de/w/Richtfunk
https://wiki.freifunk-franken.de/w/Batman_Funkbr%C3%BCcke
https://wiki.freifunk-franken.de/w/Antennen-FAQ
usw.

mfg

Christian

On 10/9/18 1:42 PM, Florian Wiessner wrote:
> Hallo,
> 
> 
> 
> mir geht es hierbei konkret um einen Anwendungsfall, nämlich ob es für
> Richtfunkstrecken die auf einem anderen Kanal liegen, die Bandbreite
> erhöhen kann. So wie ich das sehe müsse ich doch mittels Sektorfile in
> der Lage sein, das manuell zu überschreiben, was aus dem Hoodfile kommt,
> korrekt?
> 
> Am 09.10.2018 um 13:25 schrieb Adrian Schmutzler:
>>
>> Ggf. kann es durch HT40 sogar für einen selbst langsamer werden, wenn
>> man viele Interferenzen auf einem der belegten Kanäle hat.
>>
>>  
>>
>> *From:*Christian Dresel [mailto:fff@chrisi01.de]
>> *Sent:* Dienstag, 9. Oktober 2018 13:24
>> *To:* Florian Wiessner <f.wiessner@smart-kvm.com>;
>> franken-dev@freifunk.net; Adrian Schmutzler <mail@adrianschmutzler.de>
>> *Subject:* Re: [PATCH] Revert openwrt patch which caused too high tx
>> powers
>>
>>  
>>
> 
> -- 
> Mit freundlichen Grüßen
> 
> Florian Wiessner
> 
> 
> <http://www.smart-kvm.com/>
> 
> 
> smart-kvm.com
> c/o Smart Weblications GmbH
> Martinsberger Str. 1
> D-95119 Naila
> fon.: +49 9282 9638 200
> fax.: +49 9282 9638 205
> 24/7: +49 900 144 000 00 - 0,99 EUR/Min*
> http://www.smart-kvm.com
> 
> --
> Sitz der Gesellschaft: Naila
> Geschäftsführer: Florian Wiessner
> HRB-Nr.: HRB 3840 Amtsgericht Hof
> *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz