[Berlin-wireless] : Firmware-Hacking - DNS-problems

[Philipp Borgers]

Die Option "dns" ist nur für das dhcp Interface gesetzt. D.h. nur wenn das aktiv
ist, werden DNS-Server gesetzt. Wir nehmen keine DNS-Server an, die wir über den
WAN-Port lernen.

Ev. will man die dns-Konfiguration einfach über das loopback-Interfaces machen,
da das immer vorhanden ist.

Gruß Philipp

On Sat, Apr 23, 2016 at 02:30:27AM +0200, Marcel wrote:
> moin,
> 
> also kurz und knapp:
> 
> sobald das interface "dhcp" (egal ob als bridge oder nicht) aus welchen gruenden auch immer nicht zur verfuegung steht ist der knoten nicht mehr in der lage eine dns-aufloseung in richtung internet durchzufuehren.
> 
> einfachstes beispiel:
> 
> knoten wurde gerade per freifunkassistent eingerichtet, nach dem neustart baut der knoten auch den vpn03-tunnel auf.
> sobald jedoch "dhcp" z.b. in der gui per netzwerk -> schnittstellen temporaer gestoppt wird, kann der vpn03-tunnel nicht mehr neu aufgebaut werden:
> 
> > daemon.err openvpn(ffvpn)[4151]: RESOLVE: Cannot resolve host address: vpn03.berlin.freifunk.net: Name or service not known
> > daemon.notice openvpn(ffvpn)[4151]: SIGUSR1[soft,init_instance] received, process restarting
> > daemon.warn openvpn(ffvpn)[4151]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
> > daemon.err openvpn(ffvpn)[4151]: RESOLVE: Cannot resolve host address: vpn03-backup.berlin.freifunk.net: Name or service not known
> 
> usw.
> 
> nach einem reboot des knotens ist das interface wieder da und der von03-tunnel wird wieder aufgebaut.
> 
> 
> anderes beispiel:
> 
> gleiches fehlerbild wenn das interface "dhcp" in der gui per netzwerk -> schnittstellen -> "dhcp" -> "Erweiterte Einstellungen"-> "Während des Bootvorgangs starten" dauerhaft deaktiviert wird oder wenn das aktive interface "dhcp" per "Physikalische Einstellungen" von allen eingestellten schnittstellen z.b. nur noch auf ein nicht existierendes vlan oder schnittstelle geparkt wird.
> Folge: vpn03-tunnel kann auch nach einem reboot des knotens nicht mehr aufgebaut werden.
> 
> einfachste loesung die ich gefunden habe:
> 
> auf dem interface "wan" per "Erweiterte Einstellungen" den parameter "Benutze die von der Gegenstelle zugewiesenen DNS-Server" zu aktivieren
> 
> ich hoffe das hilft weiter
> gruesse
> marcel
> 
> 
> > Am 22. April 2016 um 21:37 schrieb Sven Roederer <freifunk at it-solutions.geroedel.de>:
> > Marcel,
> > 
> > kannst du nochmal genau aufschreiben, was du genau deaktivierst und ist
> > es dann reproduzierbar?
> > 
> > 
> > 
> >> On 22.04.2016 01:14, Marcel wrote:
> >> moin,
> >> 
> >> ich habe beim testen von kathleen unstable auf nem nexx wt3020f ein sonderbares verhalten beobachtet. dieses verhalten habe ich nun auch auf nem tplink wr4300 sowie nem 1043nd mit 0.1.2 festgestellt.
> >> 
> >> sobald das dhcp-interface inaktiv ist oder per gui gestoppt wurde, in der gui stehen dann nur nullen bei der mac-adresse, schafft es der knoten nicht mehr die dns-adressen fuer den vpn aufzuloesen.
> >> 
> >> fuer mich wirkt das wie ein bug, hoechstwahrscheinlich liege ich da auch falsch. was sagt ihr?
> >> 
> >> dank & gruesse
> >> marcel
> > 
> > 
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > Diese Mailingliste besitzt ein öffentlich einsehbares Archiv



> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160423/f72dcfa3/attachment.sig>