No internet using wifi on 7490 with 7.xy firmware

[donacarr]

I just built 07.01-freetz-devel-15014.en and when I upgrade from 06.84-freetz-devel-14887.en the wifi does not have any connection to internet. Ethernet connection works fine. If you need further details please let me know. Thank you.

[BlackStar999]

Set in Freetz: rc.custom

ifconfig wlan up

[donacarr]

Thank you for the workaround! I hope will be solved definitely in future freetz build.... Bye

[fda77]

I never had this issue on 7490 + 7590, should depend on something unknown

[fda77]

No, i never had this issue with 7490, have it since release and it's one the first models. I know this thread, but cant reproduce it. Maybe some of my patches fixed it, not sure. You tried it?

[Ferk]

I also have this issue, with a git build from a few days ago (using the international firmware, I didn't try if in the German firmware it's working fine). The devices connect to the wireless but they are not given an IP.

I thought it might have been some dhcp issue so I tried using dnsmasq instead, but that doesn't work either. Even setting a static IP from the device doesn't work.

In the end I made it work by restarting multid (and I made it so it restarts it shortly after boot), then it works. I didn't try doing instead "ifconfig wlan up" I guess that'd be better than restarting the whole multid, I'll try that out later when I reach home.

Even after having done that, there are some times when maybe a device cannot connect and I have to manually restart multid for it to work properly.

[benleb]

I have this problem also since few weeks (before i had no freetz and also no problem). Wifi connection is okay but no IP will be assigned. I am currently solving this by going to "Mesh Settings", "Network Settings" an "Mesh Repeater" menu points and click "save" without changing anything. This (or probably just one of them) triggers something which make it work. Ugly but working ✌️

[fda77]

"before i had no freetz" means without Freetz?

[Ferk]

In my case, I was using 6.31 freetz (international) before, and the problem was not present there. I think the issue has been there for a long time. I remember trying Freetz 7.0x (international) several months ago and having problems like these, so I decided to stay in 6.31 up until recently.

I also didn't see the problem in 7.x German without Freetz (ie. the official firmware I had initially). This is a box that was released with German firmware but I installed the international version.

I could try to install the German 7.0x freetz and see if it's actually fixed there. Would the freetz update allow me to switch language versions with no problems?

[benleb]

"before i had no freetz" means without Freetz?

sorry, no. before freetz there was no problem.

[PeterPawn]

What's the output from

grep -i multid .config

(run on the build-system or with a complete .config on the box) for devices with that problem?

Another hint could be found in the process list (with ps w) - the interesting part is the PID of multid before and after the ifconfig call. The fact of interest is, whether multid gets restarted with the ifconfig command or not.

[benleb]

FREETZ_AVMDAEMON_DISABLE_MULTIDPORTS=y
FREETZ_LIB_libmultid=y
FREETZ_LIB_libmultid_WITH_ANYIP=y
FREETZ_LIB_libmultid_WITH_DNS=y
FREETZ_LIB_libmultid_WITH_DHCP=y
FREETZ_LIB_libmultid_WITH_LLMNR=y
FREETZ_AVM_HAS_MULTID_LEASES_FORMAT_V2=y

[PeterPawn]

I'd bet, the problem is a result of "libmultid" pre-loading (this lib changes socket binds slightly) ... at least, if all others with this problem have the appropriate settings in their .config to use libmultid, too.

If that's really the difference between devices with and without this problem, further research is needed. AVM changed the handling of WLAN connections from the roots, since times when libmultid was invented first ... that's why I would start an investigation at this point.

Meanwhile the current WLAN configuration is built more dynamically by AVM and the network devices (for WLAN) are enabled and disabled as needed.

To make sure, that there's a difference between two multid instances (or first, that the assumed restart of multid is executed as expected using ifconfig), a glance on the process list is needed (see above).

If there are two different instances of multid before and after ifconfig (that is a single multid instance at a time, but with different PIDs), another command (grep multid /proc/$(pidof multid)/smaps) may get used to check, whether libmultid is loaded in an instance or not.

[PrinzVonBillAir]

@PeterPawn In the link I posted 4 days ago in one of the last posts there's a user that mentioned something about "discarded libmultid" in his log. Maybe this is related.

See here: https://www.ip-phone-forum.de/threads/7490-freetz-mit-6-98-keine-wlan-verbindung.299639/page-2#post-2304077

Unfortunatly I don't have my old 7490 anymore but 1 year ago I certainly had the same issue with the beta of FritzOS 06.98. With my 7580 and 7590 I didn't need a fix in rc.customs for wifi to be working.

[PeterPawn]

Probably there are different problems with the same result ... some people have had the reported issue with an image, where libmultid should not exist at all.

Due to the various (long lasting :grin: ) problem reports, I'd like to gather more info first ... and only take current problems into account, 'cause the WLAN implementation is currently always "under construction" for AVM ... and older problems may have been solved already.

[albigro]

For me i could not connect even with static ipv4 address, with android phones. Reactivating ipv6 support "fixed" it, devices get an ipv4 address assigned now. 7490 7.01 freetz-devel-15014 rebuild kernel

[Ferk]

I found several of these in crash.log in my 7490 with this problem ..although I'm not sure if it's related:

2019-02-25 23:28:45(1) [Segmentation fault] multid([30799]) CRASHED at avmipc_msg_send+0xc (/lib/libavmcsock.so.2 at 0001e628) accessing 00000020
SIGNO 11 ERRNO 0 CODE 1
Version: 07.01
Watchdog triggered 1 seconds ago
No bugmsg
ze: 00000000 at: 10800108 v0: 00000010 v1: 77579794
a0: 00000000 a1: 0045aa9c a2: 77579780 a3: 00000011
t0: 00000001 t1: 779d2c3c t2: 00000000 t3: 65666978
t4: 77827824 t5: 00000000 t6: 00000000 t7: 779d2038
s0: 77579780 s1: 00000000 s2: 0045aa9c s3: 00000038
s4: 00470000 s5: 00470000 s6: 00000000 s7: 7fb64908
t8: 00000011 t9: 7784261c k0: 7fb6464e k1: 00000000
gp: 778b0970 sp: 7fb64860 fp: 00000000 ra: 778427f4
FA 00000020
PC 77842628 avmipc_msg_send+0xc (/lib/libavmcsock.so.2 at 0001e628)
PC Code: 3c1c0007 279ce354 0399e021 <8c820020> 27bdffc0 30420001 afbc0020 afbf003c 50400004
RA 778427f4 avmipc_msg_vprintf+0x78 (/lib/libavmcsock.so.2 at 0001e7f4)
RA Code: 02402821 0320f809 02202021 <8fbc0010> 8fa40018 afa20020 8f85801c 8f998530 2406060b
[bt]  77842628 avmipc_msg_send+0xc (/lib/libavmcsock.so.2 at 0001e61c/0x1e628)
                        Code: 3c1c0007 279ce354 0399e021 <8c820020> 27bdffc0 30420001 afbc0020 afbf003c 50400004
[bt]  778427ec avmipc_msg_vprintf+0x70 (/lib/libavmcsock.so.2 at 0001e77c/0x1e7ec)
                        Code: 02003021 8f998ba4 02402821 <0320f809> 02202021 8fbc0010 8fa40018 afa20020 8f85801c
[bt]  77842858 avmipc_msg_printf+0x28 (/lib/libavmcsock.so.2 at 0001e830/0x1e858)
                        Code: afbf0024 afbc0010 afa70018 <0320f809> 00000000 8fbf0024 03e00008 27bd0028 3c1c0007
[bt]  00418924 [004183e8] <0+0x4183e8>+0x53c (/sbin/multid at 004183e8/0x418924)
                        Code: 3c050046 8e04004c 24c6bee4 <0320f809> 24a5aa9c 8fa200c8 26050088 26246020 aeb643b0
[bt]  004189b0 [00418978] <0+0x418978>+0x38 (/sbin/multid at 00418978/0x4189b0)
                        Code: afa20010 8e0700a0 8e06009c <0c1060ff> 8e040084 24020001 ae020080 8fbf0024 8fb00020
[bt]  0040b3fc main+0x1e48 (/sbin/multid at 004095b4/0x40b3fc)
                        Code: 8f998138 0320f809 00000000 <0c10625e> 00000000 8e4400b8 10800005 8fbc0028 8f998388
[bt] finished.

[olistudent]

Okay. I'll build an 7490 image without dnsmasq (and without libmultid). We will see if this fixes the problem...

[olistudent]

Problem persists even without dnsnmasq and without libmutlid on 7490 07.01. Perhaps a race condition at startup. Guest wifi doesn't show this behaviour.

[fda77]

Hab das Problem noch nie auf 7320,7390,7490&7590 mit dnsmasq und libmultid gehabt. Vielleicht liegts an den ganzen Fehlerbehebungen in Freetz-NG? Bin mir jetzt aber keinem in diesem Bezug bewusst. Vielleicht könnte jemand wie @olistudent der das Problem mal prüfen ob es mit Freeetz-NG auch auftritt?

[WileC]

Ich habe das Problem auf meinen 3490ern ... auf meiner 4040, die mit WLAN an einem Hotspot hängt, habe ich keine Probleme bezüglich des wlan-interfaces...

[benleb]

scheint behoben/nicht mehr aufzutreten mit der 07.08-66900. Kann das noch jemand bestätigen?

[WileC]

Also bei mir tritt der Fehler bei einer 3490 mit Firmware 3490_07.01-freetz-master-5629f9509-190412 tritt das WLAN-Problem weiterhin auf.

Ich brauche zwingend in der rc.custom:

sleep 8
ifconfig wlan up

Ansonsten bekommen meine WLAN-Clients nur eine APIPA-Adresse.

[PeterPawn]

Die Leute, die hier immer das zusätzliche "ifconfig wlan up" brauchen, müßten mal ein paar mehr Daten zur Verfügung stellen bzw. das Problem etwas näher untersuchen.

Die Tatsache, daß es bei dem einen auftritt und beim Nächsten wieder nicht, kann durchaus auch mit dem konkreten WLAN vor Ort zusammenhängen.

Ich kann hier jedenfalls auch mit der originalen AVM-Firmware (07.08-66226) die Situation nachstellen, daß das "wlan"-Interface gar nicht Bestandteil der "lan"-Bridge ist und daher auch kein DHCP-Request über WLAN beantwortet wird ... wie gesagt, mit der originalen AVM-Firmware (und bestückter serieller Schnittstelle) bei einer 7490.

Damit ist das mit hoher Wahrscheinlichkeit kein Freetz-Problem und diejenigen, die dieses Problem bei sich feststellen, sollten bitte noch einmal mit einer originalen AVM-Firmware testen, ob es dort (mit identischer Konfiguration natürlich, also nicht etwa die Box auf Werkseinstellungen setzen) nicht ebenfalls auftritt.

Schaut man dann in die Supportdaten (mit Freetz hat man ggf. auch Shell-Zugriff, mit der Stock-Firmware greift man auf die Supportdaten zurück), sieht man in der "lan"-Bridge kein "wlan" als Interface ... nach dem manuellen "ifconfig wlan up" hingegen sehr wohl (da wird wohl ein AVM-Listener beim "ifup" getriggert, der die Brigde-Konfiguration noch einmal erneuert).

Handelt es sich nicht um ein Freetz-induziertes Problem, kann man zwar weiterhin den Workaround benutzen, aber dann muß man nicht länger überlegen, wo in Freetz die Ursache liegen könnte. Es wäre also schön, wenn ein oder zwei andere, die ansonsten von dem Problem betroffen sind, noch einmal mit der originalen AVM-Firmware den Gegentest machen könnten - ich will auch mein Ergebnis nicht verallgemeinern ohne weiteren Input.

Bei mir spielt es auch keine Rolle, ob ich das 5 GHz-Band einschalte oder nicht ... die Radarsuche bei bestimmten Kanälen sollte damit also auch nichts zu tun haben. Allerdings ist diese Box in keinem Mesh und verwendet für die beiden Bänder unterschiedliche SSIDs. Ggf. hat das noch etwas mit dem Problem zu tun ... also bitte auch alles, was einem wichtig erscheint zur WLAN-Konfiguration, angeben (besser zuviel, als zuwenig), wenn der Fehler bei jemandem reproduzierbar auftritt.

[PrinzVonBillAir]

Die Leute, die hier immer das zusätzliche "ifconfig wlan up" brauchen, müßten mal ein paar mehr Daten zur Verfügung stellen bzw. das Problem etwas näher untersuchen.

Die Tatsache, daß es bei dem einen auftritt und beim Nächsten wieder nicht, kann durchaus auch mit dem konkreten WLAN vor Ort zusammenhängen.

Ich kann hier jedenfalls auch mit der originalen AVM-Firmware (07.08-66226) die Situation nachstellen, daß das "wlan"-Interface gar nicht Bestandteil der "lan"-Bridge ist und daher auch kein DHCP-Request über WLAN beantwortet wird ... wie gesagt, mit der originalen AVM-Firmware (und bestückter serieller Schnittstelle) bei einer 7490.

Damit ist das mit hoher Wahrscheinlichkeit kein Freetz-Problem und diejenigen, die dieses Problem bei sich feststellen, sollten bitte noch einmal mit einer originalen AVM-Firmware testen, ob es dort (mit identischer Konfiguration natürlich, also nicht etwa die Box auf Werkseinstellungen setzen) nicht ebenfalls auftritt.

Wie weiter oben schon gesagt, ich habe leider keine 7490 mehr da, aber ich weiß 100 %, dass es vor einem Jahr, als ich das Problem mit meiner ehemaligen 7490 und der 06.98 Beta hatte, ausschließlich mit Freetz bei mir auftrat, mit der "Original"-(Beta-)Firmware jedoch nicht. Als ich dann von 7490 zur 7580 und später 7590 geswitched war, war das Problem mit Freetz und der 06.98 Beta dann verschwunden. Es scheint also sehr wahrscheinlich ein Problem mit VR9-Boxen im Speziellen zu sein und nicht mit Frimware XY an sich.

Edit: Was ich weiterhin definitiv sagen kann, dass ich in Freetz als zusätzliche Pakete (weil sich dies auch in dem Jahr nicht verändert hat) nur dnsmasq, WOL und den bootmanager ausgewählt hatte. Im AVM Web-IF hatte ich außerdem 2,4 und 5 GHz mit gleicher SSID und gleichem Passwort gewählt.

[PeterPawn]

ausschließlich mit Freetz bei mir auftrat, mit der "Original"-(Beta-)Firmware jedoch nicht.

Ich frage lieber noch einmal nach, damit es kein Mißverständnis gibt ... heißt das jetzt "mit Freetz trat es das erste Mal auf und vorher nie" oder "nachdem das auftrat, hatte ich mit der originalen Firmware noch einmal probiert (durch einfaches "Umschalten" von linux_fs_start, weil ja ansonsten die Konfiguration nicht mehr dieselbe gewesen wäre) und da bestand das Problem nicht"?

Ich will es nur "verstehen", wo das Problem liegen könnte ... zumal es bei mir eben in der aktuellen Labor-Reihe auftritt (die 7490 ist auch nur noch zum Testen da, daher bemerke ich das mit dem WLAN gar nicht immer) und ich gerade erst mit der 68152 von heute noch einmal testen will, ob das damit weiterhin besteht.

[PrinzVonBillAir]

Das Problem trat glaube ich (festnageln will ich mich darauf aber nicht) ab irgendeiner späteren 06.98 Beta auf, nicht jedoch mit den ersten 06.98 Betaversionen. Weiterhin war das (glaube ich) so: Ich hatte eine gefreetzte 06.98 FW (mit höherer Revision) über eine vorherige 06.98 gefreetzte FW (mit niedrigerer Revision) drübergespielt und dann an allen WLAN Geräten, die an der 7490 angemeldet waren keine IP/DNS mehr zugewiesen bekommen. Ich hatte dann die Original / ungefreetzte 06.98 Beta (mit der höheren Revision, die mit freetz nicht funktionierte) dort nochmal darübergespielt und dann ging es wieder. Ebenfalls ging es wieder mit dem Workaround, den Matty im IPPF nach einiger Zeit gepostet hatte (ifconfig wlan up). Ein Settingsreset wurde bei keinem dieser FW Flashes durchgeführt.

[PeterPawn]

Danke für's Konkretisieren ... ich kann inzwischen festhalten, daß es auch mit der 68152 nicht funktioniert.

Die "lan"-Bridge enthält kein "wlan" ... kein Traffic zwischen LAN und WLAN möglich und DHCP-Server ist bei mir ein anderer im LAN.

---

OT: Ich kann mich ohnehin des Eindrucks nicht erwehren, daß AVM im Moment nur Gülle produziert ... ich kann praktisch keine einzige TR-064-Funktion bei dieser Box mit der 07.08-68152 aufrufen, weil (bei Zugriff über die LAN-seitige IP-Adresse und den Port 49443 - hier KANN ein SNI-Header also keine Rolle spielen) anstelle der fälligen "Server Hello"-Antwort immer seitens der FRITZ!Box die Verbindung zurückgesetzt wird.

Identische Aufrufe bei älteren Versionen funktionieren hingegen einwandfrei.

Ich frage mich so langsam, ob es bei AVM überhaupt so etwas wie automatische Unit-Tests gibt oder ob man sich da auch sagt: "Scheißegal, welches Ergebnis diese Tests bringen, veröffentlicht wird trotzdem.".

Ich bin jedenfalls (mal wieder) bei dem Punkt angelangt, daß ich erst die Release-Version teste und dann an deren Fehlern herummäkele, weil mir das Testen der Labor-Versionen einfach zu anstrengend wird.

Man kann nur noch raten, ob irgendetwas nun ein Bug oder "by design" ist und das Feedback durch AVM ist unter aller Kanone. Sollen sie sich ihre Firmware weichkochen ... mich interessieren nur noch Release-Versionen, die ja (vermeintlich) fertig und frei von Fehlern - zumindest von den gröbsten und so offensichtlichen, daß die bei mir schon beim nächsten Neustart der Box direkt durchfallen - sein sollten.

Nach dem Update auf die 68152 hatte sich die Box dann auch erst mal gleich noch vom ATA-Modus (das ist der Router-Modus über LAN1) auf "IP-Client" umgestellt und dabei natürlich über die interne Bridge auch wieder die eigentlich getrennten Netze verknüpft - passiert das bei jemandem ohne VLANs und mit kaskadierten Routern, steht der nackt im Internet.

Es ist zum Haareraufen ... aber zumindest weiß ich jetzt, daß der WLAN-Fehler stabil ist, weil auch das Einspielen der 07.01-Konfiguration (Dez. 2018) am WLAN-Problem nichts ändert.

Aber das ist ja (teilweise zumindest) ohnehin OT ... ich klinke mich jedenfalls bei JEDEM weiteren Versuch, irgendetwas für eine AVM-Laborversion zu ergründen, die ein Problem mit Freetz verursacht, aus.

Einfach abwarten, was das nächste Release bringt ... ob man bei AVM-Laboren Probleme sucht und meldet oder ob in China ein Sack Reis umfällt, hat vermutlich dieselbe Relevanz. Ich bin es leid ...

[WileC]

Ich benutze auch einen externen DHCP/DNS Server. Wenn ich in meiner FritzBox 3490 den AVM DHCP aktiviere, bekommen die WLAN-Clients eine ordentliche IP-Adresse aus dem konfigurierten Bereich.

Deaktiviere ich den DHCP von AVM und führe NICHT das "ifconfig wlan up" durch, bekommen die WLAN-Clients zwar eine Verbindung, aber lediglich eine APIPA Adresse zugewiesen.

Erst mit "Ifconfig wlan up" bekommen die WLAN-Clients bei mir dann die IP vom externen DHCP zugwiesen.

[er13]

Irgendjemand (weiß leider nicht mehr wer genau) hat mal geschrieben, dass das Problem nur dann auftritt, wenn man von 06.xx auf 06.98/07.xx updatet. Macht man ein Recover auf 07.xx und spielt erst danach Freetz auf die Box drauf, so tritt das Problem angeblich nicht auf. Trifft das wirklich zu? Kann das jemand bestätigen?

[WileC]

Das war glaube ich, ich: #102, #109

[er13]

@WileC:

Hast Du zufälligerweise die Backups der folgenden AVM-Konfigurationen aufbewahrt?

• Nach dem Update von 06.xx auf 06.98/07.xx, das wäre meiner Erwartung nach die Variante "das Problem tritt auf"
• Nach dem Recover auf 07.xx und dem anschließenden Aufspielen von Freetz, das entspreche meiner Erwartung nach der Variante "das Problem tritt NICHT auf"

Könntest Du bitte die ar7.cfg aus diesen beiden Backus vergleichen? Fällt Dir etwas auf? Lässt sich die These von @PeterPawn belegen, dass es an dem in der "lan"-Bridge fehlenden "wlan"-Interface liegt?

Und noch eine Frage. Ist es bei der Vorgehensweise "erst Recover auf 07.xx, dann Freetz" von Bedeutung, ob man die AVM-Einstellungen komplett neu vornimmt oder diese aus irgendeinem älteren ggf. einem 06.xx-Backup aufspielt?

Danke!

[WileC]

@er13 also eine alte ar7.cfg habe ich nicht mehr. Nur eine aktuelle ar7.cfg einer 3490 7.01.

Ich hatte damals einfach direkt freetz-7.01 per freetz-WebIF auf eine freetz-6.83 hochgeladen... Danach tritt das WLAN-Problem auf. Ich brauche derzeit immernoch zwingend beim boot das "ifconfig wlan up" da sonst im "ifconfig" das wlan-device fehlt...

Das mit dem Recover war nötig, weil das LAN-Interface nicht mehr ging, sowie die Einstellungen des INETD nicht gespeichert wurden (#102 #109)

Deswegen habe ich direkt einen AVM-Recover auf 7.01 gemacht, dann freetz-7.01 per Bootloader drauf geladen, dann erst aus einem 6.83 Backup die AVM-Einstellungen importiert und zuletzt nur dann noch die freetz-Einstellungen importiert.

Dann ging wieder alles... bis auf eben zur Zeit das WLAN... also ohne "ifconfig wlan up" beim boot der Box bekommen WLAN-Clients nur eine APIPA-Adresse.

[er13]

Jetzt hast Du mich verwirrt. Also trifft die Aussage

Nach einem Recover auf 07.xx und dem erst anschließend stattfindenden Aufspielen von Freetz ist kein "ifconfig wlan up" als Workaround notwendig

doch nicht zu?

Was passiert, wenn Du nach dem Recover auf 07.xx die Einstellungen nicht aus einem 06.xx Backup importierst, sondern diese komplett neu vornimmst?

Und auf der 3490-Box, auf der Du aktuell das Problem nachstellen kannst, ist auf dieser das wlan-Interface in der lan-Bridge enthalten oder nicht?

[WileC]

@er13 Das Recover hatte ich gemacht, weil das LAN-Device beim Boot nicht mehr startete und die Einstellungen des INETD bei jedem boot auf "standard" gesetzt wurden.

Nach dem Recover verhält sich alles so, wie es soll. Lediglich das WLAN muss ich mittels "ifconfig wlan up" derzeit noch starten, damit meine WLAN-Clients mittels externen DHCP bedient werden können.

Sobald der interne DHCP der FritzBox, also der AVM-seitige läuft, tritt dieses Problem mit dem WLAN-Interfache nicht auf...

[PeterPawn]

Hmm ... mit dieser Konfiguration hat sich dann ein weiterer Verdacht erledigt, den ich hatte. Ich betreibe die Box ja im ATA-Modus, da ist LAN1 (eth0) das WAN-Interface und eth1 bis eth3 bilden LAN2 bis LAN4. Die Vermutung ging also in die Richtung, daß das fehlende "eth0" in der LAN-Konfiguration die Ursache für das Problem bei mir sein könnte (z.B. wg. des "Laternenmast-Problems" o.ä.) ... hat sich das also auch erledigt und ich muß nicht weiter in dieser Richtung testen.

Was ich aber sagen kann ... die L2-Verbindung im WLAN funktioniert problemlos. Versucht sich ein Gerät (mit der FRITZ!WLAN-App) per WLAN zu verbinden, zeigt das GUI der Box dieses auch bereits dann als "verbunden" an, wenn es nur einen alten Eintrag in den Leases hat (einfach mit "aicmd multid dhcpd leases" zu überprüfen), aber gar keine DHCP-Pakete (weder REQ noch RESP) ihr Ziel erreichten. Hier reicht es also schon aus, wenn das Gerät auf L2 als "neighbor" sichtbar ist. Fehlt dieser Eintrag für die (alte) Lease (kann man ja löschen), ändert sich auch die Anzeige im GUI nicht - das Gerät erhält aber in beiden Fällen keine IP-Adresse und es spielt auch keine Rolle, ob der interne DHCP-Server im "multid" für das LAN-Segment aktiv ist oder nicht ("aicmd multid dhcpd interfaces").

Alles ab L3 ist tot und das Interface "wlan" taucht auch nicht irgendwann später (oder nach dem De-/Aktivieren des WLANs) wieder auf in der "lan"-Bridge. Ich bin allerdings auch nicht sicher, ob ein "brctl addif lan wlan" von Hand ausreicht - das klappt jedenfalls nicht immer.

Ich habe nur die DHCP-Requests nicht mitgeschnitten und kann daher nicht zweifelsfrei sagen, ob das Gerät mit der App diese weiterhin aussendet - zumal die App dann irgendwann ohnehin auf das nächste bekannte Netz geht und davon habe ich leider zuviele bei mir, da jede Test-Box ihr eigenes aufmacht. Ich müßte erst alle anderen Netze aus der App entfernen und scheue den Aufwand, das nach dem Test dann alles wieder einrichten zu müssen.

[er13]

@WileC: ich würde Dir empfehlen Dein Attachment aus https://github.com/Freetz/freetz/issues/87#issuecomment-490461043 zu entfernen (ich kann es leider nicht machen). Da stehen einige sensible Informationen, die man lieber nicht so ins Netz stellen sollte.

[WileC]

So, nach Update einer 3490 auf FOS 7.11 bleibt der Fehler weiterhin: ohne "ifconfig wlan up" bekommen bei laufenden DNSMASQ die Clients lediglich eine APIPA Adresse.

Somit brauche ich weiterhin per rc.custom ein "ifconig wlan up", dann klappts auch mit einer 192.168.x IP.

[WileC]

Also, auf meiner 6820 brauche ich kein "ifconfig wlan up" ... Hier gibts gar kein WLAN-Interface?! Obwohl die Geräte ber WLAN verbunden sind.

[NDiGH]

Also, auf meiner 6820 brauche ich kein "ifconfig wlan up" ...

Meines Wissens nach existiert das Problem bisher nur bei den VR9-Modellen (u.a. 3490, 7362 SL, 7430, 7490 usw.) mit FRITZ!OS >=7.00. Die 6820 gehört bekanntlich nicht zu den VR9-Modellen!

[jpsollie]

(sorry, my German is limited) I can confirm as well that the wlan device is not brought up... But the hostapd functionality is. Nevertheless, the wlan0 device is not part of the lan bridge (initially). When I bring up the wlan device & add it to the bridge, everything seems fine *edit: using a 3490 7.01 fritz box

[Bodenseematze]

Bei mir besteht das Problem mit meiner 7490 ebenfalls. Mit allen auf AVM's Firmware 7.x basierenden Freetz-Versionen.

Der Eintrag mit "ifconfig wlan up" führt zu einer neuen PID für den multid. Die Ausgabe der proc-Einträge sind aber vor und nach dem Neustart des multid gleich und enthalten immer zweimal die "libmultid".

brctl enthält erst nach dem "icconfig wlan up" das "wlan" als Bridge-Interface zum "lan".

Ob es mit einem Original AVM-Image auch eintritt kann ich nicht so ohne weiteres testen...

[notlebowski]

Nach ausführlichen tests mit einige 7590 und danach mit 7490 habe ich 42 7490 ein "upgrade" nach 7.12 gegeben wonach die Hölle ausbrach. 1 7490 habe ich geflashed mit die gleichen AVM-firmware und die funktionierte danach.

Danach habe ich herausgefunden das "ifconfig wlan up" dieses problem löst.

Ich habe 73 Fritz!boxen zur verfügung. Wie kann ich helfen um dieses Problem mit Freetz auf zu klären?

[WileC]

Ich wollte auch mal ein kurzes Feedback hinterlasen:

mit der 3490_07.12-freetz-master-20200713-bfbcfca09.de_20200713-123831 besteht das Problem weiterhin...

ohne ifconfig wlan up gehts nicht...

[Bodenseematze]

das Problem bzw. der Umgang damit (dass da seit 1,5 Jahren keine Lösung erarbeitet/eingecheckt wird) war der Hauptgrund für mich, zu freetz-ng zu wechseln...

[PeterPawn]

der Umgang damit

Ah ja ... und dort ist das dann gelöst? Wie denn genau?

[Bodenseematze]

Ich bin da ehrlich: ich habe keine Ahnung - vielleicht ist es ja durch einen üblen Hilf-Fix oder einfach nur dadurch gelöst, dass das o.a. "ifconfig wlan up" automatisch eingefügt ist... ...es ist mir aber auch egal - auf jeden Fall brauche ich mich nicht darum zu kümmern und es hatte "Out Of The Box" funktioniert.

Als das Problem bei mir in Freetz aufgetaucht war, hatte ich eine ganze Weile rumgesucht (natürlich den Fehler bei mir gesucht), immer wieder neue Freetz-Versionen gebaut mit unterschiedlichen Konfigurationen und weil es nicht funktioniert hatte, bin ich dann immer wieder auf die 6.y-Firmware zurückgegangen und habe es erst wieder Wochen später mit aktuelleren Versionen nochmals probiert (was dann immer noch nicht funktioniert hat). Erst nach einer ganzen Weile bin ich auf die Idee gekommen, mal im Forum nachzufragen, ob noch jemand anderes das Problem hat - und da wurde mir dann mit o.a. Workaround ("ifconfig wlan up" in rc.custom einzutragen) oder eben mit dem Hinweis zu freetz-ng zu wechseln, weil dort das Problem gelöst sei, geholfen.

Ich habe zum damaligen Zeitpunkt weder im freetz-Wiki noch über die Suche im Forum etwas darüber gefunden - und warum der o.a. Workaround bis heute nicht enthalten ist, ist mir ein Rätsel...

[PeterPawn]

Das klang halt anders, daher habe ich nachgefragt.

Ich weiß auch nicht, wann das Problem bei Dir das erste Mal auftrat ... aber die Issue hier gibt es auch schon länger und noch länger (ja, sogar länger als Freetz-NG als Fork) gibt es den Thread im IPPF, wo das schon für die Labor-Version vor FRITZ!OS 7 (und zwar auch mit möglichem Workaround) beschrieben wurde: https://www.ip-phone-forum.de/threads/7490-freetz-mit-6-98-keine-wlan-verbindung.299639/.

Die Frage, wer hier Ei und wer Henne war/ist und warum Du den nicht gefunden hast, müssen wir gar nicht klären - ich wollte auch nur aufzeigen, daß es schon länger klar ist, wie man das Problem "umschiffen" kann.

Trotzdem hat es auch bisher noch keiner derjenigen, die (a) Freetz-Mod verwenden (was die Zahl schon mal verringert) und (b) von dem Problem betroffen sind (was mit der Beschränkung auf die VR9-Boxen das noch weiter eindampft), auf die Reihe gebracht, einen entsprechenden Patch "anzubieten" - zumindest sehe ich hier keinen.

Nur ist Freetz eben ein Projekt einer Community und das lebt nicht nur vom Nehmen, sondern auch vom Mitmachen. Zumindest sollte es so sein, auch wenn hier Wunsch/Anspruch und Wirklichkeit schon desöfteren in einem heftigen "culture clash" aufeinandertrafen und vermutlich ein "einfacher Workaround" sogar wieder rundweg abgelehnt würde - bei manchem ist es eben Usus, das noch funktionierende TV-Gerät schon heute zum Wertstoffhof zu fahren (weil die Couch da ohnehin gerade hin muß), da in 1-2 Jahren ohnehin die Anschaffung eines neuen ansteht.

Nur wird man das mit der wahrscheinlichen Ablehnung auch nie erfahren (und damit nachweisen können), solange man einen solchen Workaround nicht selbst "eingefordert" bzw. "angeboten" hat - und das macht man nun mal am besten als Betroffener und verläßt sich dabei nicht auf andere (die das ggf. bei sich nicht mal richtig nachstellen können).

---

Ich weiß im Moment auch nicht, was Freetz-NG da macht und eine eigene Suche danach ist auch ziemlich aussichtslos, solange man nicht (automatisch) davon ausgehen kann, daß dort ein Commit steht, der auf diese Diskussion hier Bezug nimmt und man keinen Schimmer hat, in welcher Datei da geändert wurde - potentielle "Angriffspunkte" dafür gäbe es ja viele.

Würde der entsprechende Commit in Freetz-NG das hier referenzieren, dann gäbe es hier automatisch eine Meldung - immerhin gab es ziemlich sicher (am Beginn dieser Diskussion hier) auch in Freetz-NG noch keinen Workaround, wie man am Inhalt der ersten Beiträge sieht; hier stellt sich also die Frage einer "Reihenfolge" auch nicht.

Die "rc.custom" wäre vermutlich "von Freetz aus" eine der schlechteren Lösungen, weil die vom Benutzer ja verändert/gelöscht werden kann und für sich gar kein Bestandteil von Freetz oder auch nur eines Freetz-Images ist - die steht (wenn es sie gibt) in den gespeicherten (Freetz-)Einstellungen in der Box und um da etwas zusätzlich einzutragen (und das dann auch nur einmalig, wenn Du nicht nach dem 30. Start da dreißig Zeilen ifconfig wlan up haben willst), brauchst Du schon mal mindestens ein zusätzliches Skript (oder Du bringst das in einem anderen mit unter, das sind aber auch nicht nur zwei Zeilen oder gar nur eine einzige).

Das könnte schon mal ein Grund sein, warum das

und warum der o.a. Workaround bis heute nicht enthalten ist, ist mir ein Rätsel...

weiterhin der Fall ist. Die "rc.custom" ist also vielleicht der richtige Ort für den Workaround, wenn Du ihn selbst einträgst - für einen automatischen ist sie eher "suboptimal". Damit stehst Du also wieder vor der Aufgabe, Dir erst mal eine passende Stelle dafür zu suchen - und dafür ist natürlich das Verständnis der eigentlichen Ursache schon extrem hilfreich - nur muß sie dann eben auch jemand suchen, der (wen wundert's) davon betroffen ist.

Ich hatte irgendwann bei mir mal nach der Ursache gesehen (weil ich das auch ohne Freetz bei einer bestimmten Version des FRITZ!OS hatte) und dabei festgestellt, daß im "nicht funktionierenden Zustand" eben gar nicht das WLAN selbst nicht arbeitet, sondern daß es nur daran liegt, daß der DHCP-Server den Clients keine IP-Adressen zuweist (das konnte auch mit einem externen DHCP-Server anstelle eines "dnsmasq" passieren - beim "multid" gibt es das Problem wohl nicht) und diese das mit "kein WLAN" gleichzusetzen geruhten.

Nun kann man das sicherlich erst einmal mit einem "ifconfig wlan up" korrigieren (ich würde das dann am ehesten noch in den Start des "dnsmasq" mit einbinden, weil das die naheliegendste Stelle bei DHCP-Problemen wäre - allerdings hilft es da bei externem DHCP-Server auch nicht) ... es dürfte ohnehin nur daran liegen (reine Vermutung und mangels Gerät bzw. Problem mit späteren Versionen auch nicht mehr durch mich zu testen), daß da das Timing zwischen dem "dsld" und dem "wland" bei Konfigurieren und Starten des WLANs nicht stimmt und daher das "wlan"-Interface zu dem Zeitpunkt, wo der "dsld" die Bridge einrichtet, noch nicht Bestandteil der "lan"-Bridge wird - so stellte es sich zumindest bei mir dar und da half dann ein einfaches Hinzufügen zur Bridge auch nicht.

Das kann m.E. auch wieder nur dadurch zustande kommen, daß es das Interface "wlan" (was ja auch mehrere physikalische zu einem logischen bündelt) zu diesem Zeitpunkt, wo der "dsld" die Bridge konfiguriert, noch gar nicht (funktionsfähig) gibt und dessen Einbinden daher scheitert bzw. "nicht richtig" erfolgt - was aber vermutlich schon deshalb ignoriert wird vom "dsld", damit nicht ein defektes oder verkonfiguriertes WLAN automatisch auch den Rest der Box lahmlegt (würde jedenfalls Sinn ergeben in meinen Augen).

Nur kann diese Situation vermutlich auch danach noch auftreten, wenn man etwas an der Port- und der WLAN-Konfiguration ändert, was den "wland" und den "dsld" zum Neustart veranlaßt - daher ist ein wirklich zuverlässige Lösung (noch dazu, wo die Ursachen offenbar sehr unterschiedlich sind und es wohl eher darauf hinausläuft, daß da verschiedene Probleme mit denselben Symptomen in einen Topf geworfen wurden) auch kaum zu erzielen, wenn man das Problem nicht hat und damit auch nicht (durch eigene, gezielte Tests) ermitteln kann, wann es auftritt und wie es dann am besten behoben wird.

Ich bin zwar immer noch nicht von dem Problem betroffen ... aber wenn ich es wäre oder jemals wieder sein sollte, würde ich mir die Events des "udevd" genauer ansehen und sollte ich dabei eines finden, was mir Änderungen am "wlan"-Interface signalisiert, würde ich versuchen, mich mit einer passenden Regel für den "udevd" da anzuhängen und beim Wechsel auf "bereit" dann dafür sorgen, daß noch einmal ein "ifconfig wlan up" abgesetzt wird ("geben sie mir ein "wlan up", Vasili. und bitte nur ein einziges" - damit das nicht in einer Schleife endet, falls das Kommando noch einmal dasselbe Event produziert) - letztlich dürfte ohnehin nur das davon ausgelöste NETLINK-Event (https://man7.org/linux/man-pages/man7/netlink.7.html) dafür verantwortlich sein, daß hinterher alles wieder funktioniert.

Vielleicht wäre es sogar sinnvoller, den DHCP-Server (wenn's wirklich nur ein Problem mit dem "dnsmasq" sein sollte, wobei sich das ja auch "eher uneinheitlich" darstellt, was dann zur Vermutung mit verschiedenen Ursache für dasselbe Symptom führt) neu zu starten, wenn ein Netzwerk-Interface seinen Zustand ändert. Irgendein "udev"-Event wird es da garantiert geben.

Was mich hier viel mehr interessieren würde, ist die Frage, ob die anderen Boxen mit Scorpion-WiSoC von Qualcomm dieselben Probleme bereiten ... für die 3490 war es hier ja schon zu lesen. Blieben noch 549x (davon sind wenige im Privateigentum und sehr wenige wohl modifiziert), 6820 (das sind schon mehr) und einige Repeater-Modelle (ich weiß gerade nicht welche) - wenn die alle das Problem haben sollten, wäre es vermutlich irgendetwas im Zusammenspiel mit dem Linux auf dem Scorpion-SoC ... was AVM bei der eigenen Firmware aber offensichtlich in den Griff bekommen hat.

Aber das wäre natürlich parallel auch schon für die Frage interessant, bei welchen Geräten denn dieser Workaround überhaupt einzubauen wäre ...

[DaniDD]

@PeterPawn das ist wohl der Fix: https://trac.boxmatrix.info/freetz-ng/changeset/16031/freetz-ng

[PeterPawn]

Gut, danke. Damit findet man dann auch den Commit im GitHub-Repo: https://github.com/freetz-ng/freetz-ng/commit/9f1eec67f7

Im Großen und Ganzen ist das dann also so umgesetzt, wie ich schon weiter oben gemutmaßt habe - anstatt das in die "rc.custom" zu bringen (was wie geschrieben tricky wäre), steht es jetzt in der "rc.mod" zwei Schritte vor dem Ausführen der "rc.custom". Ob man deshalb tatsächlich gleich alle "PATCH"-Symbole noch mit in die "options.cfg" schreiben lassen muß, ist sicherlich eher Geschmackssache - ich hätte mich wohl auf das einzelne Symbol beschränkt (unter dem Aspekt, nur das wirklich Notwendige zu ändern) bzw. den Teil aus dem "wlan_up()" wieder herausgepatcht (oder überhaupt erst hinein).

Wobei hier Freetz ohnehin "unlesbar" ist ... das "grep" bei OPTION_NAMES (https://github.com/Freetz/freetz/blob/master/patches/scripts/900-add_options_cfg.sh#L11) ist eher etwas für Eingeweihte oder "Klammerzähler". Das kann man auch deutlich eleganter und vor allem wartungsfreundlicher umsetzen, z.B. so: https://github.com/PeterPawn/YourFreetz/blob/collected_diffs_to_upstream/tools/clrconfig#L5 (und auch das hat noch Optimierungspotential).

Aber letzten Endes steht eben auch in diesem Commit ausdrücklich, daß es sich nur um den hier auch bereits aufgezeigten Workaround handelt - um die eigentliche Ursache kümmert sich seitdem auch niemand mehr. Das kann sicherlich auch noch eine Weile gut gehen ... irgendwann kommt AVM bei seinem Mesh dann mit der nächsten Änderung um die Ecke, die das nächste WLAN-Problem aufwirft und so hangelt man sich dann von Workaround zu Workaround, bis das am Ende irgendwann dazu führt, daß gerade so ein (längst in Vergessenheit geratener) Workaround zur Ursache eines (anderen/neuen) Problems wird.

Was will ich damit sagen? Es wäre sicherlich nicht unklug, auch mal in Freetz eine Liste all der "schmutzigen Tricks" anzulegen (oder die zumindest für andere "nachlesbar" zu machen mit entsprechenden Verlinkungen/Verweisen) - ansonsten sucht man sich früher oder später einen Wolf, warum wieder mal etwas unter Freetz nicht funktioniert, was doch bei Vanilla-Firmware einwandfrei funktioniert und mittlerweile hat dann vielleicht sogar der Autor so eines Workarounds das Zeitliche gesegnet.

Wenn jedenfalls die Annahme, daß das nur im Zusammenspiel eines VR9-Systems mit einem Scorpion-WiSoC auftritt, sich bestätigen sollte (die 6820 und die Repeater basieren ja direkt auf dem Qualcomm-SoC und haben keinen VR9-Teil), dann wäre auch im Freetz-NG-Patch die Bedingung mit der VR9-Plattform zu weit gefaßt (für den Patch an sich, es wird ja noch einmal geprüft, ob das WLAN schon da ist). Denn es gäbe weitaus mehr VR9-Boxen, als die vier Modelle, bei denen wohl die Kombination aus VR9 und Scorpion anzutreffen ist. Bisher gab es m.W. auch nur Meldungen dieses Problems, die sich auf eines dieser vier Modelle bezogen.

[WileC]

Also bei meiner 6820 habe ich kein "ifconfig wlan up" gebraucht ... da ging das ohne ...