Nö. Hat ja monatelang funktioniert. xD WAN ist eher ne zusätzliche LAN Buchse. Wie LAN 5 oder so.
1 „Gefällt mir“
Es wird ja immer „lustiger“. Ich konnte es jetzt noch mit MR200/400 an einer Fritzbox probieren… zuerst dachte ich ja es gibt nur 2 Möglichkeiten:
Heute bin ich schlauer… es gibt 3 
Offenbar interpretiert bzw. ändert die Fritzbox den RTSP SETUP Request des 400er anders, weil er auch etwas anders aufgebaut ist.
Noch mal zur Erinnerung… beim MR401 wird aus:
Transport: MP2T/RTP/UDP;unicast;client_port=3160;source=87.141.220.115;server_port=32154-32155;ssrc=2604190
das:
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203
Und vom Server kommt dann
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203
Und das wird 1:1 so an den MR401 im LAN weitergeleitet und der weiss mit dem Client-Port nichts anzufangen und startet den Stream nicht.
Beim MR400 sieht die Zeile so aus:
Transport: MP2T/RTP/UDP;unicast;client_port=3002-3003,MP2T/TCP;unicast;interleaved=0-1,MP2T/UDP;unicast;client_port=3002-3003,MP2T/RTP/TCP;unicast;interleaved=0-1
Und nein, das ist kein C&P Fehler, man muss genau hingucken, ich habs mal n bissl hervorgehoben. Während der 401er nur MP2T/RTP/UDP dem Server anbietet, bietet der MR400 auch noch MP2T/(RTP)/TCP und MP2T/UDP an.
Naja, der Witz daran ist dann, dass die Fritzbox nur den 2. client_port von MP2T/UDP umschreibt (der nächste Bug in der Implementierung!?). Im WAN Richtung Server geht dann:
Transport: MP2T/RTP/UDP;unicast;client_port=3002-3003,MP2T/TCP;unicast;interleaved=0-1,MP2T/UDP;unicast;client_port=61020-61021,MP2T/RTP/TCP;unicast;interleaved=0-1
Der Server entscheidet sich offenbar für den 1., denn zurück kommt dann:
Transport: MP2T/RTP/UDP;unicast;client_port=3002-3003;source=87.141.220.114;server_port=32194-32195;ssrc=3714417
Und das wird 1:1 so ins LAN weitergeleitet - hier ists vielleicht gut, dass die FB die Antwort nicht mehr anfasst - denn würde sie die client_ports, die der Server vorgibt, in ihrer NAT Tabelle suchen, würde sie die Antwort der gerade anderen aktiven STB zuordnen oder eben gar nicht finden.
Jedenfalls hat sie das NAT trotzdem für die UDP Pakete gespeichert und NATed dann fleissig die UDP Pakete in beide Richtungen.
LAN:
WAN:
Den Server scheint das nicht zu interessieren, dass die Pakete plötzlich von Port 61020 kommen, obwohl sie von 3002 angekündigt wurden - der scheint nur den Serverport zur Identifizierung der Verbindung zu nehmen - Glück gehabt. Theoretisch gesehen könnte man sich also wohl auch den ganzen Eingriff in die RTSP Pakete einfach sparen, weils dem Server eh egal ist, ob die dazwischen umgeschrieben werden oder nicht. Oder man machts halt richtig 
Es ist imho wirklich einigermaßen verrückt und ein kleines Wunder, dass das überhaupt funktioniert.
Irgendwie seltsam und kompliziert das ganze. 
Genauso die Frage, warum das Bild bei den 401ern nicht immer stehen bleibt mit der Meldung. Konnte heute zum Beispiel ständig auf dem Zweitreceiver hin und her schalten und das Problem nicht rekonstruieren. Irgendwann wollte der Receiver dann doch nicht und das Problem kam dann doch.
Jetzt siehst du mal wie es uns ging, als wir versucht haben dein Problem nachzustellen 
Im Grunde ist es recht ja einfach. Der Fehler tritt eben nur oder genau dann auf, wenn der MR einen Port verwenden will, der bereits in Verwenundung ist. Dann muss die FB einen anderen freien Port suchen und die Pakete umschreiben und das macht sie eben nur in Sende- aber nicht mehr in Empfangsrichtung und dann steht das Bild.
Wenn die Receiver schon eine Weile laufen ist die Wahrscheinlichkeit noch relativ gering, da sie etwas bei den Ports auseinander laufen. Aber wenn man beide frisch hochfährt, beginnen sie immer beim gleichen Port und so kann man es eben gut nachstellen.
Sorry im Voraus aber bei dem ganzen Fachchinesisch komme ich nicht mehr mit. Danke für das Entschlüsseln
1 „Gefällt mir“
Hat jemand ne Ahnung, wie das beim Support von AVM generell abläuft? Falls die das ganze nachstellen und beheben können, bekommt man von AVM ne spezielle Firmware zugeschickt oder wird das einfach in der nächsten Labor behoben und es bekommen alle Tester?
Es gab schon fälle wo man eine Vorab Version bekommen hat wo halt der Fehler “eventuell” gefixt wurden ist
In der finalen OS 7 sollte das Problem nun Schnee von gestern sein, oder? In einer In-house Version hatten die das Problem nämlich behoben.
In welcher?
Ich hab die 06.98-58834 zum testen bekommen. Die hat den Fehler nicht mehr.
Die aktuelle ist Version: 06.98-59298. Also dürfte der Fehler endlich weg sein.
Hast es mal probiert? Ich hab noch die Testversion drauf, falls noch mal nachfragen kommen. Aber seitdem ist Funkstille. Bin mir jetzt auch nicht sicher, ob der Fix schon übernommen wurde. Das war ja keine Inhaus, sondern eine Intern-Version. Keine Ahnung ob alles was da drin ist automatisch übernommen wird. Eine “Gutmeldung” hatte ich aber geschickt.
Ich warte auf die finale Version 7, die eigentlich schon hätte erscheinen sollen.
Ich habe zurzeit die 06.98.59355
Werd ich heute auch mal testen bei gelegenheit
Interessant wäre es, wie es in der Theorie im Mitschnitt und in der Praxis beim Umschalten ist
Wie du meinen bitte? Leider nicht gerade Versteh was du meinst. Danke
1 „Gefällt mir“
Theorie: Wie es im Mitschnitt im Wireshark zu lesen ist. Ob die Fritzbox den client_port nicht wieder umschreibt
Praxis: Ob beim Umschalten das Bild wieder stehen bleibt oder nicht.
Spontaner Test bei mir. Auto Motor Sport live in HD bei MR 401 und dann beim 201 paar Unicast Sender durchgeschaltet (Sport Sender und BBC World, Deutsche Welle).
Sehr schnelles durchschalten ohne Probleme. Wie es sein soll
Umgekehrt auch keine Probleme.
Und davor war es nicht so?
Dann lade ich mir die auch mal. Dürfte mittlerweile stabil genug sein.
Davor gab es doch diese Fehlermeldung. Die kommt halt nicht mehr sondern man kann ganz normal schnell durchschalten