[SOLVED] 5GHz-Kanäle DE (Aktuelle GE Firmware auf TL-WDR4300)

Das hilft auch nicht, das Ändern der BSSID ebenfalls nicht.
Ich habe heute morgen mal die Grünen besucht, die ja wohl auch einen WDR4300 mit GE Firmware 0.7.2 haben (siehe hier) und die haben ebenfalls kein 5GHz. Es liegt also offensichtlich am Firmware Image für den WDR4300. Wie sieht es denn mit anderen 5GHz-Geräten aus, wie z.B. dem WDR3600? Oder anders gefragt: hat überhaupt jemand mit der aktuellen GE Firmware funktionierendes 5GHz?

Ich werde es heute Abend mal mit einem selbst gebauten Image testen. Wurde für die offiziellen Images dieses repo verwendet? Welcher Branch/Tag/Commit? Und wurden außer der site.conf und site.mk wirklich keine weiteren Anpassungen vorgenommen?

Mit den site.mk/.conf wurde gebaut.
Gut würde mit dem aktuellen Release (v2015.1.1) ausgeschenkt.
Vielen Dank fürs Testen.
Ich werde schauen, ob ich einen 3600er kurzfristig auftreiben kann.

Kann nicht zufällig hiermit zutun haben ? (wurde oben schon einmal erwähnt)

5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)

Heisst für mich erstmal (1) kein adhoc (2) dfs sollte funktionieren damit der ap hier auch funkt
oder sehe ich das falsch?

LG

Kein 5GHz bei meinem 3600er. Cafe Faber 4300 auch nicht.

Nachtrag: ich muss mich korrigieren bzw. relativieren - ich habe nicht nachgeschaut, ob 5 GHz nicht eh abgeschaltet ist bei der 3600er.

Da war ohnehin ein ganz schlauer Fuchs unterwegs, der die 5 GHz ins untere Band unters Wetterradar konfiguriert hat, wo nur 1/5 der Ausgangsleistung erlaubt sind in der Regdom DE. Selbst wenn man DFS und TPC auf dem IBSS anbekommt… :grin:

Ich denke mal, dass wir wahlweise auf die Kanäle 36/40/44/48 müssen oder aber die Regdomain auf US schalten müssen… (letzteres verbietet sich natürlich von selbst)

Will sagen: Fehler unsererseits! Kommt ein Update!

Alles unter Kanal 100 dürfte mindestens dramatisch reduzierte Sendeleistung haben…und hat auch noch die Einschränkung auf indoor:

Kanäle 36 - 64 an einem 3600er bspw. 200 mW - 3 db für fehlendes TPC - 3 db für die Antenne = 50 mW an der Leistungsstufe und nur indoor Nutzung!?

Ich habe jetzt mal v15.1.1 und v15.1.x (HEAD) gebaut → gleiches Problem.

Jetzt wollte ich noch v15.1 testen, aber das bricht ab mit:

if [ -f /usr/src/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/pkginfo/hostapd.wpad-mini.install.clean ]; then rm -f /usr/src/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/pkginfo/hostapd.wpad-mini.install /usr/src/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/pkginfo/hostapd.wpad-mini.install.clean; fi; echo "hostapd-common" >> /usr/src/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/pkginfo/hostapd.wpad-mini.install
WARNING: skipping hostapd-common-old -- package not selected
make[4]: Leaving directory `/usr/src/gluon/openwrt/package/network/services/hostapd'
make[3]: Leaving directory `/usr/src/gluon/build/ar71xx-generic/openwrt'
make[2]: *** [/usr/src/gluon/build/ar71xx-generic/openwrt/staging_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/stamp/.package_compile] Error 2
make[2]: Leaving directory `/usr/src/gluon/build/ar71xx-generic/openwrt'
make[1]: *** [prepare] Error 2
make[1]: Leaving directory `/usr/src/gluon/build/ar71xx-generic/openwrt'
make: *** [all] Fehler 2

Mit welchem Kanal hast Du getestet?

Ich glaube @babak ließt nicht was hier geschrieben wird … es kann nicht funktionieren!

Zumindest nicht mit den hohen Kanälen.

ffrg stand früher auf RegDomain US (das ja mehrmals Diskussionen darum…)

auf Regdomain=DE scheint es so zu sein, dass das OpenWRT „mangels DFS“ auf den höheren Kanälen (über 48) gar nicht mehr sendet, aus Prinzip nicht.

1 „Gefällt mir“

… 20 Zeichen …

Welche Graph-Anzeige hängt und was hat das mit den 4300ern (und dem hier besprochenen 5GHz-Problem) zu tun?
Mir fehlt gerade wirklich eine Idee, wie das zusammen hängen könnte.

Ich habe es in der tat nicht aufmerksam gelesen, hätte ich es getan, hätte ich mir die Arbeit auch sparen können. :expressionless:

Ich frage mich aber, wenn das so offensichtlich ist, warum spekulieren wir hier dann schon seit Tagen über mögliche Ursachen?
Ich kann jedenfalls bestätigen, dass es mit Kanal 44 auf Anhieb funktioniert.

Gibt es eine Möglichkeit etwas gesprächigere logs zu bekommen, um solche Fehler nachzuvollziehen?

Weil niemand vermutet hätte, dass bei der Migration von „US“ nach „DE“ das Openwrt die RegDomain wirklich ernst nimmt und schlicht „zumacht“.
(Warum ffrg früher auf US gefunkt hat: Weiss icht nicht. Aber auch da war der Kanal ein anderer. Ist halt erst so aufgefallen.)
Ansonsten: Update propagiert wohl nur ziemlich langsam.
Wer Interesse hat, den autoupdater mal auf der Kommandozeile von Hand anstoßen.

Das ist auch in der Tat ein sehr seltsames verhalten, zumal in den logs nichts dazu auftaucht.

autoupdater will nicht:

# autoupdater 
Connecting to [fda0:747e:ab29:209:ff00::1] ([fda0:747e:ab29:209:ff00::1]:80)
wget: can't connect to remote host: Connection refused
There seems to have gone something wrong downloading the manifest from http://[fda0:747e:ab29:209:ff00::1]/images/stable/sysupgrade
wget: bad address 'images.ffgek'
There seems to have gone something wrong downloading the manifest from http://images.ffgek/stable/sysupgrade
No usable mirror found.

Habs jetzt manuell gemacht → läuft. Danke!

edit:
Kurzer Hinweis: http://46.38.238.147/images/stable/site/site.conf wirft 403

Ganz so seltsam ist das Verhalten nicht, denn das ist das in der OpenWRT dokumentierte Verhalten, wenn das Image ohne die DFS Option kompiliert wurde…

Siehe: Wireless configuration [Old OpenWrt Wiki]

If you define a channel in your wireless config that requires DFS according to your country regulations, the 5GHz radio device won't start up if you run an OpenWRT version that lacks DFS support or if your system is not configured properly.

Vielleicht noch ein Hinweis an dieser Stelle: Mit aktiviertem DFS in OpenWrt kann der hostapd aktuell kein HT40 auf Kanälen wo DFS verpflichtend ist.
Kann man nämlich auch nicht in den Logs sehen, dass genau das dann das Problem ist. Da stirbt der hostapd Prozess dann auch sofort sang- und klanglos.

2 „Gefällt mir“

Ich verschiebe das mal von /Gelsenkirchen nach /Technik, da es vermutlich auch andere betreffen könnte, wenn sie hoffen, dass dass OpenWRT einfach DFS oder Regdomain ignoriert… was es zumindest in BarrierBreaker nimmer tut.

Wobei auch diese Warnung auf der wireless Seite steht :wink:

Habt ihr DFS bei euch schon in Betrieb?