Firmwarebäckerei: 1.5.0

Fortsetzung der Diskussion von In der Firmwarebäckerei:

Für 1.5.0 machen wir hier weiter, 1.5.0~71 basiert auf gluon-v2022.1.3. Let’s go!

Wie schon oben beschrieben … auch mit Version 1.5.0~71
Windows sagt leider auch „Kein Internet“

fehlendes IPv4

Hallo,

Wie schon oben beschrieben … auch mit Version 1.5.0~71
Windows sagt leider auch „Kein Internet“

ich habe das Verhalten hier mit der 1.4.0~74 unter Android (und bisher
einem Windows-Rechner) ebenfalls beobachtet. Geräte verbinden sich und
zeigen dann „kein Internet“ an. Werden aber als Client auf der Karte
gezeigt. Manchmal half ein Neustart des Smartphone/PC. Ich habe es
aber darauf geschoben, dass hier relativ viele Knoten untereinander
per WLAN meshen und gleichzeitig auch Internet per WAN bekommen.
Nachdem ich bei den betroffenen Knoten das Meshen per WLAN
ausgeschaltet habe, bilde ich mir ein, dass es besser geworden ist.

Viele Grüße

Andreas

Thanks, that definitely helps. Denn das hieße auch, daß es nicht auf Gluon v2022 begrenzt ist.

Ich habe das teilweise bei meinem, ähem, ›gewagt‹ angebundenen Knoten im OG beobachtet — der hängt an einem WLAN-Client, dessen (Steckdosen-)AP im Raum darunter per WDS-Strecke vom zentralen AP versorgt wird, also quasi hinter zwei ›WLAN-Kabeln‹ hängt. Meistens tut’s, aber manchmal bekommt der Androide zwar 'ne v4-IP, doch Android sagt »ohne Internet verbunden«. Habe das bislang irritiert auf zu schlechtes »Funkwetter« geschoben – siehe Anbindung –, aber dann dürfte eigentlich auch DHCP nicht tun. Werde dies nun Mal genauer beobachten, sieht mir nämlich mehr nach IP(v4-)-Weiterleitungsthema auf dem GW aus (weil DHCP ja tut).

Wenn das Gerät per WLAN eine IP-Verbindung hat, aber trotzdem „Kein Internet“ angezeigt wird, liegt das manchmal an einem fehlenden/kaputten/langsamen DNS.

Man könnte von dem Androiden mit einer „Ping-App“ versuchen „1.1.1.1“ anzupingen, oder „one.one.one.one“. Wenn ersteres klappt, letzteres aber nicht, dann liegt es nicht am Routing, sondern eher am DNS. Ausprobieren mit einer manuellen DNS-Server-Konfiguration im Android, und statt dem DNS-Server, den man per DHCP bekam, einen anderen nutzen (1.1.1.1 oder 8.8.8.8 zum Testen).

So hab ich das Problem schon einige Male gelöst als der ISP-DNS-Resolver nicht tat.

In meinem Fall probiere ich dann, per App »Ping & Net« einen traceroute zu 1.1.1.1 — der versackt dann i. d. R. schon bei Hop 1, also der GW-VM im RZ. Die NS werden mit der 10er-Mesh-IP auch vom Gateway-Smokping erfasst — aber ggf. ist es eben ein Unterschied, ob das GW die Anfrage stellt oder ein Client dahinter (IP-Forwarding und/oder Routing im Batman-Mesh).

Hmm, zusammen mit dem Setup-Thema hier könnte einiges tatsächlich auf karpottes Resolving zurückzuführen sein. Muß nächste Woche mal den neuen Code ausrollen, der mehr als den gatewaylokalen Resolver per DHCP/RA ausliefert …

FTR: 1.5.0~76 basiert nun auf Gluon „master“, das bringt u. a. Unterstützung für den D-Link⁣ DAP-X1860⁣ a1, der ist seit OpenWrt 22.03.4 supported …

18 EUR derzeit bei MediaMarkt, 29 EUR bei Amazon, für einen DualBand-Steckdosen-AP nicht so übel — auch wenn die Performance dem Preis wohl eher angemessen ist:

At the moment I still compare the device with the Xiaomi RM1800 and need to say the Xiaomi-Device with the IPQ6018 chipsets is still nearly double the speed of the nice DAP- X1860. - So hopefully the drivers for the MT7915 will get an development-Improvement.

(Dank an @TomH für den Hinweis in der FFRN-Matrix :beers:)

FTR: Ich habe mir zwei DAP-X1860⁣ zur Abholung im lokalen Mediamarkt für Montag bestellt, u. a. als Ersatz für meine TL-WA860RE v1 …

@wusel kannst du für die nächsten Build denn 1200er von AVM mit rein nehmen? Wollte einmal testen pb der 5GHz Link damit besser klappt.
Meinen 300e muss ich mir jetzt einmal genauer anschauen. Den hat es mit den letzten Update scheinbar raus gekegelt.

Es sollten alle unterstützten Geräte gebaut werden; aber 1.5 hat aktuell das Problem, daß WiFi nicht richtig tut (Clients können nicht connected) …

OK, das erklärt das Problem mit meinem 300e
Die Mesh Verbindung ist bei ihm auch weg gebrochen. Habe ihn jetzt erst mal wieder ein Kabel verpasst.

Meshen tun die 1.5er bei mir, aber Clients werden nicht richtig verbunden.

Gemesht hat er erst auch, aber keine IPs verteilt. Und irgendwann war er dann auch ganz offline über das Mesh

Moin,

tng 1.5.0~96 und folgende sollten nun tun. (Es war ein ebtables-Filterpaket in die Liste der Packages reingerutscht, welches in unserer Konfiguration alles außer ULA wegfilterte …)

Please test, auch gerne vom Configmode an!

Ist drin. Und – siehe RT #5179 – wir haben auch den ersten Zyxel NWA50AX im Netz — sowie D-Link DAP-X1860 A1 :wink:

Aktuell versuche ich, mit Tri-Band-Geräten was zu werden, z. B. Linksys EA8300/MR8300 oder GL-B2200, die könnten für’s Meshing in bestimmten Umgebungen (Syrtaki, Parkbad, …) interessant sein.

Tri-Band heißt i. d. R. 1x 2,4-, 2x 5 GHz-Radio, d. h. 5-GHz-Mesh könnte auf anderem Kanal als der 5-GHz-Access stattfinden. Gluon kann leider noch nicht mit >2 Radios umgehen – Issues sind seit Jahren ohne sichtbares Ziel offen –, und aktuelles OpenWrt kann kein 802.11s (Mesh) mehr auf DFS-Kanälen. *Hrmpft*

TNG-Ast für D-Link XAP

## Your node's setup is now complete.

Your node *33332-cord-de-2* is currently rebooting and will try to connect to other nearby Freifunk nodes after that. For more information about the Freifunk community in **Munich**, have a look at [our homepage](**https://ffmuc.net/**).

Your node should appear on our map at **[ffmuc.net/map/](https://ffmuc.net/map/)** in a few minutes.

Guter Punkt, danke:

wusel@cohen:~/4830.org$ grep -ri ffmuc.net/map .
./site-ffgt-v2023.1/i18n/en.po:"<a href=\"https://ffmuc.net/map/\">ffmuc.net/map/</a> "
./site-ffgt-v2023.1/CHANGELOG.md:    - change url from ffmuc.net/map to map.ffmuc.net
./site-ffgt-v2022.1/i18n/en.po:"<a href=\"https://ffmuc.net/map/\">ffmuc.net/map/</a> "
./site-ffgt-v2022.1/CHANGELOG.md:    - change url from ffmuc.net/map to map.ffmuc.net

(Hintergrund: der neue Build-Aufbau wurde von ffmuc kopiert.)

„Munich“ sollte auch noch ersetzt werden.

1.5.0~125 sieht so aus:

»unserer Website« zeigt auf https://4830.org/.

Oh. Ich realisiere gerade, Du hast eine EN-Locale? Puh, nicht unwahrscheinlich, daß non-DE nicht angepaßt wurde — Volunteers? Würde sonst non-DE komplett entsorgen, wer kein DE versteht, möge dann halt Google Translate bemühen.