[Frage] FB antwortet auch mit inaktiver Adresse auf DNS query

[RSchnauzer]

... die IP egal ob intern oder extern.

Und wie findet dann der client einen unattended Server im lokalen Netz? Da hab ich echt Verständnis Probleme, oder geht der session Aufbau über eine externe Verbindung?

 

[HabNeFritzbox]

Anfrage läuft über Internet, der Datenverkehr selbst dann halt über LAN.

 

[PeterPawn]

der Datenverkehr selbst dann halt über LAN.

Getestet ?

 

[HabNeFritzbox]

Einfach mal Daten kopieren, dann siehst es, dass es über die Internetgeschwindigkeit hinausgeht.

 

[PeterPawn]

Einfach mal Daten kopieren, dann siehst es, dass es über die Internetgeschwindigkeit hinausgeht.

Ok, mein Edit auf der letzten Seite ist durch den Wechsel auf eine neue Seite nicht sichtbar ... blöd.

Mein Einwand gegen diese Konstruktion steht in #20 ... ist sicherlich die Frage, wie man "LAN" an dieser Stelle definiert. Wenn die Daten durch die FB gehen (und zwar durch den Router und nicht nur durch den Switch/die Bridge) bei beiden Geräten in einer Broadcast-Domain - wo also ARP aufgelöst werden könnte - ist das für mich kein LAN. Aber die Daten gehen natürlich nicht über den Provider, also könnte man das auch noch als "Local Area Network" bezeichnen.

 

[HabNeFritzbox]

Problem mit WLAN oder LAN sehe ich nicht, LAN wird bevorzugt wenn beides aktiv.

Wie Teamviewer genau intern das macht weiß ich nicht.

 

[PeterPawn]

Problem mit WLAN oder LAN sehe ich nicht, LAN wird bevorzugt wenn beides aktiv.

Den Zusammenhang zwischen LAN und WLAN sehe ich hier nicht, ich meine etwas anderes:

1. PC A meldet sich am Vermittlungsserver mit der externen Adresse der FB und seinem geNATteten Port an und wartet auf Verbindungen.
2. PC B meldet sich ebenfalls am VS und fragt nach der Adresse von PC A.
3. Er bekommt vom VS die externe Adresse (und den Port) von PC A, unabhängig davon, ob ext. PC A == ext. PC B ist.
4. PC B nimmt nun selbst mit PC A direkt Kontakt auf, aber eben unter der ext. Adresse und das geht über die Box (eben wie bei RTP und 'direct media').

War jedenfalls bis TV7 so, kann/konnte man leicht mit 'netstat' bei aktiver Sitzung verifizieren, daß da die Verbindung nicht zu einer Adresse im LAN lief.

 

[HabNeFritzbox]

War auch nur ne Idee, die ja klappen kann wenn beide Geräte ins Internet dürfen.

Sonst bleibt immer Problem, dass der DNS ggf. falsche IP zurück gibt oder man halt zwei Hostnamen abfragen muss im Programm was anfragt.

 

[PeterPawn]

Klappt auch genau so, wie dargestellt ...

Problem ist halt nur, daß das Internet-Gateway die ganze Zeit auch zur Verfügung stehen muß. Startet eine der beiden beteiligten Stationen die Box neu, ist die Teamviewer-Verbindung auch weg.

Das mit dem Vergleich der externen Adresse (und dann einfach der Verwendung der internen anstelle der externen) funktioniert imho deshalb nicht, weil TV ja nicht nur für private Nutzung gedacht ist.

Wenn in einer Firma der Admin den Rechner eines MA steuern will, kommen die mit einiger Wahrscheinlichkeit auch von derselben externen IP beim Vermittlungsserver an. Das heißt ja aber noch lange nicht, daß diese beiden Rechner sich im firmeninternen LAN dann überhaupt sehen können, da gibt es diverse Techniken (z.B. VLAN), die genau gegen diese Sichtbarkeit untereinander entwickelt wurden.

 

[RSchnauzer]

Ok, Teamviewer funktioniert für den Sessionaufbau über einen externen Server, wie ich es in Erinnerung habe. So hab ich den auch extern genutzt, als dyndns.org seinen support eingestellt hat.

Und wie bereinige ich jetzt die DNS-Einträge der FB? Das kann ja auch noch für andere Nutzungen zu Problemen führen.

 

[PeterPawn]

Und wie bereinige ich jetzt die DNS-Einträge der FB? Das kann ja auch noch für andere Nutzungen zu Problemen führen.

Nochmal meine Frage: Löschen in der Netzwerk-Übersicht ?

 

[RSchnauzer]

... Löschen in der Netzwerk-Übersicht ?

Weder Umbenennen noch Löschen nützt. Im Status-Support sind beide Einträge unter localinfo:
BYIZB3.fritz.box (mdns):
192.168.178.23
192.168.178.29 (dynamic)

BYIZB3-WLAN.fritz.box (none):
192.168.178.23

 

[PeterPawn]

Weder Umbenennen noch Löschen nützt.

Löschen und anschließender Neustart der Box hilft auch nicht ?

Was steht in der ar7.cfg unter "landevices" ?

Wenn der Eintrag dort steht, mit nvi editieren und nach dem Speichern (5 Sekunden warten) durch Strom aus/Strom an neu starten ... wenn der das auch überlebt, brauchst Du einen Holzpflock oder einen Exorzisten.

 

[RSchnauzer]

Vielen Dank für den Tip,
aber die Box läuft jetzt seit 96 Tagen durch. Zeigen die AVM support status daten (sieh oben) nicht das selbe wie die ar7.cfg?
Wenn ich mit telnet an die box gehe, hab ich dann wieder die blöde Fehlernachricht von AVM auf der Anzeige, oder gibt es eine anderen Weg an die ar7.cfg zu kommen?
Irgendwann muss die lease ja auch aus timen.
Für den Erkenntnisgewinn zum DSL-Server will ich mir die Config nicht durcheinander bringen, solange ich einen bypass habe.

 

[PeterPawn]

aber die Box läuft jetzt seit 96 Tagen durch.

Rekordjagd ?

Zeigen die AVM support status daten (sieh oben) nicht das selbe wie die ar7.cfg?

Da die ar7.cfg die permanente Speicherung übernimmt und die Box ja auch Daten aus dem "laufenden Betrieb" in den Support-Daten ausgibt, beantwortet sich diese Frage von selbst.

Wenn Du keinen Neustart gemacht hast/machen willst, könnte der AVM-multid irgendwann mal "aufräumen" ... das bezweifle ich allerdings bzw. das hat meines Wissens noch niemand so genau getestet - da wird ja auch mit so ziemlich jeder Version dran herumgeschraubt.

Wenn ich mit telnet an die box gehe, hab ich dann wieder die blöde Fehlernachricht von AVM auf der Anzeige, oder gibt es eine anderen Weg an die ar7.cfg zu kommen?

Nein, es gibt keinen anderen Weg, an die ar7.cfg eines laufenden Systems zu kommen. Beim Export/Modifizieren/Import wird auch neu gestartet ...

Die Fehlermeldung im GUI loszuwerden, ist nur eine Fingerübung. Wenn Du wissen willst, wie Du das in einer Telnet-Session direkt vor dem Logout hinbekommst, suche einfach nach 'tffs', 'clear_id' und '87' ...

Es würde Dir aber ohnehin nur helfen, die ar7.cfg im laufenden System zu aktualisieren (und das ist auch nur notwendig, wenn der monierte Eintrag da überhaupt enthalten ist), wenn Du parallel dann wenigstens den multid und den ctlmgr neu startest, wobei Du Dich bei der Reihenfolge dann am Ablauf bei AVM orientieren solltest. Ob das aber Deinem Rekordversuch zuträglich ist ? Der ctlmgr hat eine "interne Kopie" der ar7.cfg, d.h. den muß man vor dem Speichern der Datei beenden und dann zeitnah neu starten, sonst stören sich die anderen Komponenten daran, daß man ihnen die zentrale Managementinstanz entzieht und starten ihrerseits die Box neu.

Irgendwann muss die lease ja auch aus timen.

Viel Glück beim Warten ... auch ein Lease-Timeout heißt ja nur, daß die Adresse nicht mehr "reserviert" ist. Nach meinem Dafürhalten (so genau habe ich das aber auch nie getestet) nimmt die FB keine bereits vergebenen Adressen und weist sie anderen Clients zu. Damit soll - imho - vermieden werden, daß man z.B. einem Windows-System, das mal 14 Tage nicht lief und dann als erstes nach der letzten DHCP-Adresse per Request schreit, eine negative Antwort geben muß (NACK).
Wenn Du irgendwann herausgefunden hast, ob die Box beim Lease-TO (die Default-Time sind imho 10 Tage) auch den DNS-Eintrag löscht, obwohl sie das ja nicht einmal macht, wenn Du den betreffenden Client in den Netzwerk-Einstellungen löschst oder umbenennst (oder ich habe da etwas total falsch verstanden), dann könntest Du netterweise die Dauer vom letzten "Auftauchen" eines Gerätes im Netzwerk der FB bis zum Verlust der "Erinnerungen" daran (ohne Neustart (!), ansonsten sollte das beim Neustart automatisch passieren, da der multid die multid.leases m.W. nicht mehr führt und die "festen" Zuordnungen über die ar7.cfg persistiert werdenandere Konfiguration bei mir, multid.leases wird doch verwendet, wenn die Box selbst DHCP-Server ist) noch hier dokumentieren. In der 'landevices'-Sektion der ar7.cfg tauchen aber auch Clients ohne feste Zuordnung auf, nach welchem Schema das passiert, ist mir persönlich vollkommen unklar und offenbar auch immer wieder Gegenstand heftiger Korrekturversuche durch AVM beim Erscheinen neuer Versionen.

solange ich einen bypass habe.

Der muß mir entgangen sein, wenn Du damit nicht nur den Aufruf von vnc mit der IP-Adresse meinst ...

Eins ist mir noch aufgefallen, der Linux-Rechner wird ja zumindest aktuell auch über mdns gefunden. Das dürfte für "ahavi" auf dieser Maschine sprechen (das habe ich oben bei der Discovery eines Hostnamens glatt vergessen) und ob multicast-DNS-Adressen überhaupt gelöscht werden, solange dafür keine neue annonciert wird, bezweifle ich stark. Das Protokoll ist ja gerade darauf ausgelegt, daß sich Geräte auch ohne zentrale Instanz wie einen DHCP-/DNS-Server gegenseitig im Netz finden. Ob da ein Lease-TO der DHCP-Adresse überhaupt zum "Gedächtnisverlust" führt ? Dann müßte AVM diese eigentlich ziemlich unabgängigen Dienste (auch wenn es alles in einem Daemon läuft) schon recht eng verzahnt haben ... aber auch das wäre natürlich denkbar.

Wenn Du das alles ohne Neustart wirklich hinbekommen solltest, würde es mich wundern ... aber ich würde mich über eine entsprechende Meldung hier dann auch freuen, damit ich für die Zukunft besser Bescheid weiß.

 

[RSchnauzer]

Danke für die ausführliche Antwort.
Ich werde das weiter genau beobachten und mich auf jeden Fall wieder melden, wenn ich etwas raus bekomme.
Der Leidensdruck ist nicht groß genug für Experimente, es ging mehr um das Verstehen der beobachteten Effekte.
Die überwachten Linux PCs stehen zum Testen im Anbau und sind da auch gut zu Fuß zu erreichen.
Und es ist hoffentlich auch eine Hilfe für andere, die auf diesen DNS Effekt hereinfallen, falls andere Anwendungen auch nur die erste Adresse der DNS-query answer nutzen.

 

[sf3978]

... symbolischen Namen.

... inaktive IP-Adresse auf DNS-requests von der FB zurückgemeldet werden?
...

Hat deine FritzBox wegen dem identischen "symbolischen Namen", das inaktive Netzwerkgerät als "mit der FritzBox verbunden über das aktive Netzwerkgerät" konfiguriert? Bei meiner FB6360 ist das der Fall.

 

[RSchnauzer]

... "mit der FritzBox verbunden über das aktive Netzwerkgerät" konfiguriert...

Die Linux PC hängen an einer FB 7050 hinter einer Ethernet-over-Power Verbindung alternativ über LAN oder WLAN. Für die FB 7270 mit dem Internet Anschluss und dem DHCP/DNS-Server sieht das so aus, als ob der Linux PC mit dem selben Namen aber unterschiedlichen MACs nacheinander am LAN hängt. Und so merkt sie sich das auch, aber den inaktiven Eintrag hab ich inzwischen zum Test aus dem Heimnetz gelöscht, in den internen DNS-Tabellen existiert der aber noch.

 

[sf3978]

... hab ich inzwischen zum Test aus dem Heimnetz gelöscht, ...

OK, dann kannst Du das nicht mehr feststellen/sehen. Denn bei meiner FB6360 wird diese Konfiguration, im Heimnetz/Netzwerk angezeigt.

EDIT:

D. h. auch, ich kann mit tcpdump an wlan0 sehen, was über eth0 geht. Z. B.:

sudo tcpdump -vvveni wlan0 host <int.-IPv4-Adresse-von-eth0>

EDIT 2:

Auf einer gefreetzten FB (... nicht meine FB6360) kann ich mit dem multid (... durch stoppen und neu starten des multid), den DNS-Cache dieser FB löschen.

EDIT 3:

Im UU-Forum, ein ähnlicher Fall: http://forum.ubuntuusers.de/topic/automatische-auswahl-der-netzwerkschittstelle-/

 

[RSchnauzer]

Nach einem Neustart der FB sind alle alten DNS Einträge weg. Neues Spiel, neues Glück.

P.S: Die Telekom hat mich durch einen DSL Ausfall von 11:15 bis 18:57 zu einem Neustart überzeugt . Die Störungsstelle meinte nach 10 min "bitte warten" es gebe eine Wartung in meinem Bereich.